Proposal of a Transparent Relay System with vNIC for Encrypted Overlay Networks

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 15, No. 8, August 2017
Proposal of a Transparent Relay System with vNIC
for Encrypted Overlay Networks
Satoshi Kodama
Tokyo University of Science
Department of Information Science
2641 Yamazaki, Noda-shi, Chiba-prefecture, JAPAN
kodama@is.noda.tus.ac.jp
Rei Nakagawa, Toshimitsu Tanouchi
Tokyo University of Science
Department of Information Science
2641 Yamazaki, Noda-shi, Chiba-prefecture, JAPAN
j6316627@gmail.com, j6316625@ed.tus.ac.jp
Abstract— New generations of applications call for new demands
that are totally different from previous uses of the Internet (e.g.,
cross-layer and network function virtualization), and the existing
networks are not optimized for these new demands due to being
overwhelmed by enormous numbers of external network
protocols. Overlay network technologies aim to respond to such
future network demands. Systems on overlay networks mitigate
this protocol overload by exploiting the unlimited
programmability of the overlay nodes comprising the system.
This paper proposes an overlay node that works as a transparent
proxy server and router for encrypted communication over
overlay networks. This overlay node acts as a virtual switch over
multiple layers of the OSI reference model (the datalink, network,
transport, and session layers) using general-purpose components
(a personal computer, physical network interface card, and
virtual network interface card, developed using the C language).
The ideas behind this proposal derive from the effectiveness of
software-defined networks and network function virtualization.
Finally, we examine the performance of the overlay node
experimentally and suggest possible designs for future overlay
networks.
Keywords Cross-Layer; Network Design; Software-Defined
Management; Transport Layer Security; Transparent Proxy
Server; Overlay Networks;
I. INTRODUCTION
The remarkable success of TCP/IP networks over the past
five decades highlights the importance of the traditional
address resolution system. However, the new generations of
applications make new demands, totally different from the
current uses of the Internet (e.g., cross-layer and network
function virtualization (NFV)), and the existing network has
been unable to meet these new demands due to the
requirements of enormous numbers of external network
protocols. Therefore, deployment of customized network
protocols to satisfy such new demands has recently become an
essential issue.
To solve this problem, overlay network technologies
constitute a new research area with the potential to provide a
flexible foundation for the demands of new applications [1–3].
Our understanding of these studies is that overlay network
technology is a powerful framework that breaks the current
end-to-end principle by placing resources and intelligence for
customized policies in the middle of the network. For
theoretical implications, the core features of deploying overlay
networks include scalability and cost-effectiveness. Scalability
provides extensions to the network infrastructure that are
specialized for innovative ideas, such as defining new network
applications in terms of existing network applications and
defining effective support protocols for existing network
protocols, all while ensuring backward compatibility with
external network protocols. This is cost-effective because the
number of overlay network nodes required is minimal. Overlay
nodes must be virtualized for backward compatibility, and it
then becomes possible to receive the various benefits of
network virtualization. In particular, the cost-effectiveness
derives from the benefits which can be provided with a
minimal number of overlay nodes placed discreetly over the
Internet.
In engineering terms, the core feature of an overlay network
is the software-defined system, i.e., the daemon, which enables
cooperation among the overlay nodes. The daemon software
installed on each of the overlay nodes works as both a service
provider for the overlay network and a virtualized switch for
multiple layers in the network protocol stack. The service
providers coordinate the global state of the cloud solution to
provide new applications or services that can be accessed by
external clients. The virtualized switches provide packet
processors that refer to the header information from each layer
of the network protocol stack and rewrite this information as
necessary, working as routers between overlay nodes. This is
the architecture of software-defined networks (SDNs) on the
overlay network, which have made a remarkable contribution
to network virtualization research. Based on these
considerations, overlay network technologies will be able to
respond to the demands of future networks.
This paper proposes a software-defined architecture for a
transparent proxy server (an overlay network infrastructure
technology) in an overlay node. This server can access
application data encrypted in the session layer of the OSI
reference model. Overlay nodes with this new functionality
will lead to overlay network systems based on a highly secure
content cache mechanism (discussed in Section 6). The
architecture of the transparent proxy server is composed of
physical network interface cards (pNICs) and virtual network
interface cards (vNICs) for the packet processor corresponding
149 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

to the datalink, network, transport, and application layers of the
OSI reference model (discussed in Section 3).
First, however, in the following section, we discuss some of
the related research that inspired the proposed system.
II. RELATED WORK
While designing the architecture of the proposed system,
we were inspired by some related works. We used an
NFV/SDN architecture [4–11]. Using an SDN mitigates
network complexities caused by having too many protocols
installed on the network’s infrastructure as it separates the data
and control planes. The data plane refers to the data processing
systems (e.g., IP, TCP, and Ethernet), whereas the control
plane refers to the systems that determine how and where
packets are forwarded (e.g., routers, traffic management, and
firewalls). Separating the data and control planes is an effective
method for making network control flexible and scalable not
only within a network device but also over the entire network.
NFV provides network services, such as firewalls, traffic
caching, intrusion detection system, network address
translation, multicast routing, and redundancy, in a virtualized
infrastructure. The principle of NFV is to deploy the new
network service architecture on the virtualized infrastructure
provided by the SDN.
We aim to take advantage of the effectiveness of the
NFV/SDN by incorporating a packet processor into the data
plane and the new virtualized network services on the SDN
(including a packet processor) into our software-defined
overlay node architecture. In terms of a detailed blueprint for
the software-defined overlay node architecture, there have been
several helpful discussions related to the engineering of
network virtualization architectures [6, 10, 11]. In particular,
Jain and Paul have suggested that open application delivery
networks (openADNs) [6] will represent the future of cloud
computing architectures, the idea being that most applications
can easily obtain computing and storage facilities from cloud
services by multiple providers distributed across the Internet.
They discussed an architecture for virtualized NICs, assuming
the existence of virtual service providers (vSPs) in the cloud
and highlighting the lack of scalability affecting pNICs. In
other words, they insisted that each vSP needs its own NIC and
proposed three virtualization designs based around NICs. We
believe that these network virtualization architectures are
closely related to the software-defined architecture of overlay
nodes acting as service providers. Our architecture aims to
provide vNICs as fundamental software components via the
supervisor node, which has been proposed by virtual machine
software vendors and uses a virtual Ethernet bridge (VEB).
Looking at overlay networks from a conceptual standpoint,
there have been several theoretical discussions about the
applicability of overlay networks [2–4]. In particular,
Chowdhury and Boutaba discussed network virtualization
environments (NVEs) in detail [4]. In their discussion of
underlying overlay network concepts, they investigated the
applicability of overlay networks, which provide infrastructures
for innovative technologies such as cloud services. NVEs are
composed of several client–server systems, which is virtualized
over a physical network infrastructure that provides the
network resources needed to offer end-to-end services to clients,
wherein each client–server system connects to clients through a
virtual network (VN). Our overlay network system shares the
following design goals of NVE architectures: flexibility,
manageability, scalability, isolation, and programmability.
Flexibility indicates that there is freedom in every aspect of
networking in the NVE: network virtualization must offer
services without having to coordinate with any other parties
(e.g., consensuses, pledges with other protocols, or interfaces).
Manageability indicates that there is complete end-to-end
control in the NVE: network virtualization must modularize
network management tasks and introduce accountability at
every networking layer. Scalability indicates that the NVE
must scale to support an increasing number of coexisting VNs
without affecting their performance. Isolation indicates that
network virtualization must ensure isolation between coexisting
multiple networks to improve fault tolerance, security, and
privacy. Programmability indicates that customized protocols
and diverse services can be deployed on multiple networks
through network virtualization.
Up to this point, we have presented the essential references
that shaped our study of an overlay network system and its
components. The following sections describe the details of our
overlay network and its nodes. An overview of the overlay
network system and schematics of its architecture are presented
in Section 3.1. Then, a detailed explanation of the software
engineering aspects of the overlay node proposed in this paper
is given in Section 3.2, together with illustrations of the
workflow and architecture.
III. SYSTEM ARCHITECTURE
A. Overlay Network System
Before we present the architecture of the overlay node
proposed in this paper, it will be useful to discuss the basis of
the overlay node and the underlying overlay network system
used to deploy the customized policy. The overlay network
system uses a cloud foundation to offer the services requested
by clients and is composed of overlay nodes that together
comprise the global state. Fig. 1 shows a schematic of the
overlay network system. In Fig. 1, there are three components
that are split between the supervisor and service provider sides.
On the service provider side, the overlay network is based on
the Internet and provides a service network using overlay nodes
to offer a new service. The resources distributed across the
overlay nodes can be used to provide this new service.
The service network is composed of overlay nodes,
managed by the overlay control node using the underlying
overlay service control protocol (OSCP). The overlay control
node is the first node that clients communicate with to make
service requests, and its IP address represents the service
network to the client. The OSCP separates the overlay
communication flow of the specified service from the other
communication flows and routes it between the overlay nodes
in the service network using sequences of queries to maintain
the most appropriate state for the service. For example, the
OSCP manages the routing table based on amount of delay to
offer a real-time service.
ISSN 1947-5500

Figure 1. Overview of the overlay network system
On the supervisor side, the supervisor node manages all
communication from clients and the overlay nodes in the LAN
using the underlying overlay link control protocol (OLCP). The
supervisor node is the overlay node that is closest to the LAN’s
gateway router. The OLCP transparently separates overlay
communications from the overall communication flow in the
LAN and ensures the quality of the overlay communications
between the supervisor and service provider sides (e.g.,
manages the order of sequential data for the new service and
encrypted communications over transport layer security
(TLS)/IPSEC). Moreover, if a service network needs to extend
its scope to the LAN, the OLCP acts as a relay server, handling
address resolution between the internal and external overlay
nodes in the service network.
When clients receive services provided by the overlay
network system, they benefit from the work described so far.
The client can just see a simple client¬–server system
involving the overlay control node and cannot see the work
done by the supervisor node and the overlay nodes in the
service network. This overlay network system architecture
achieves the design goals previously described in Section 1.2,
namely, flexibility, manageability, scalability, isolation, and
programmability. The question asked in this paper is how to
ensure manageability and programmability over encrypted
communication links. The following subsection describes in
detail the use of an overlay node as a transparent proxy server
wherein communication quality is guaranteed by TLS.
B. Transparent Proxy System over TLS Communication
Proxy servers are well-known intermediaries between
endpoint devices such as personal computers and servers from
which the clients request services. The advantage of a proxy
server is that it can store frequently requested results in a cache,
from which they can be served to clients directly. For example,
when a proxy server receives a request for an Internet resource
(such as an HTTP request) from a client, it first looks in its
local cache of previously served pages. If it finds the requested
content, the proxy server can return it to the client without
needing to forward the request to the main server. If the page is
not in the cache, the proxy server, acting on behalf of the client,
uses one of its IP addresses to request the page from the main
server. When the page is returned by the server, the proxy
relates it to the original request and forwards it to the client.
A transparent proxy server is a particular type of proxy
server wherein clients are not aware of its presence [12, 13].
The proposed overlay node architecture is a type of transparent
proxy server over TLS, proposed as a function of the
supervisor node, thus providing an approach to engineering an
overlay node that forms part of the overlay network system
described previously in Section 3.1. Fig. 2 shows the
architecture of the proposed transparent proxy system.
In Fig. 2, the supervisor node lies immediately between the
LAN’s gateway router and its cluster of network devices. In
other words, the supervisor node handles all communication
from the network device cluster. The network device cluster is
composed of the clients and overlay nodes accessed using TLS.
Note that the supervisor node acts as a transparent proxy server
ISSN 1947-5500

over TLS. The purpose of this node is to transparently monitor
the communications of the given TLS service and manage its
content while understanding it semantically.
Figure 2. Architecture of the proposed transparent proxy system
The design comprises physical NICs (pNICs), VEBs,
virtual NIC (vNIC), and virtual client and server layers for the
TLS service. The pNIC to datalink layer (L2) switch accepts
communication requests for the L2 switch managing the
network device cluster. The pNIC to gateway router link
accepts communication requests for overlay node clusters on
external networks. The VEB for inbound communication
handles the TLS flow for inbound communication to the LAN
and connects it to the intermediate vNIC. Similarly, the VEB
for outbound communication handles the TLS flow for
outbound communication from the LAN and connects it to the
intermediate vNIC.
The intermediate vNIC’s IP address is that of the LAN and
represents the endpoint for the TLS service, providing the
virtual TLS server layer that actually accepts and handles TLS
communications from clients and the virtual TLS client layer
that connects to the overlay control node for the server (the
server node) in the TLS service network and requests content
from TLS service resources. The virtual TLS server layer
provides the upstream reader that receives the sequence of TLS
communications from the client and transmits the content
requested in the communication, together with its semantic
interpretation, to the intermediate vNIC. In the virtual TLS
server layer, the upstream reader receives the sequence of TLS
communication requests from the client and transmits the
requests to the upstream writer in the virtual TLS server layer.
Likewise, the downstream writer receives the content originally
requested by the client from the TLS service resources from the
downstream reader. In the virtual TLS client layer, the
upstream writer receives the client request from the upstream
reader and transmits the request to the server node, whereas the
downstream reader receives the requested content from the
server node and transmits it to the downstream writer in the
virtual server layer. Fig. 3 shows the detailed processing flow
for each of the components around the intermediate vNIC.
Fig. 3 shows the processes involved in one session for the
virtual TLS server and client. First, the client initiates the TLS
session with the TLS server node, and the virtual TLS server
handles it instead. If this TLS session initialization is successful,
the virtual TLS client initiates a TLS session with the TLS
server node. Second, after TLS session initialization, the client
sends the appropriate content request to the TLS server node.
The virtual TLS server receives the request packet instead,
extracts and decrypts it using the upper application header, and
then transfers it to the transmission buffer of the upstream
writer in the virtual TLS client. After that, the virtual TLS
client re-encapsulates the content request into a packet for the
TLS session between the virtual TLS client and the TLS server
and transmits the content request packet to the TLS server.
Third, after the content request has been transmitted, the virtual
TLS client receives the requested content packet from the
server, extracts, and decrypts the packet and then transfers it to
the transmission buffer of the downstream writer in the virtual
TLS client. Finally, the virtual TLS server transmits the
requested content to the client.
ISSN 1947-5500

Figure 3. Architecture of the transparent proxy system around the intermediate vNIC
What needs to be emphasized at this juncture is how the
virtual TLS server handles the process in place of the main
server and how we manage both the sessions of the virtual TLS
client and server. The virtual TLS server needs to rewrite the
destination IP address of the packet using the IP address of the
intermediate vNIC, which is handled by the VEB for inbound
communication. The supervisor node therefore needs to obtain
the IP address of the TLS server in advance. Care must be
taken while programming the management of the TLS session
between the virtual TLS server and client because subtle
dependency problems can creep in to both of them, causing
session errors. The essential management policy is to have one
virtual TLS client session for each virtual TLS server session.
The process sequence of first receiving a content request from
the client and transmitting it to the TLS server node and then
receiving the requested content from the TLS server and
transmitting it to the client must be used for both the
synchronized virtual TLS server and client sessions. Therefore,
the start and termination conditions of each session must be
maintained by a highly robust sequential process, which cannot
be handled using a concurrency control scheme such as
multithreaded programming or multi-processing.
The following section describes the experiment that we
conducted over an HTTPS service to evaluate our engineering
approach.
IV. EVALUATION
Our engineering approach, though simple in terms of
architecture and functionality, must prove that the complete
software model can function as a transparent proxy over TLS.
We therefore conducted an experiment wherein we used our
engineering approach for a client–server system over HTTPS
using general-purpose equipment. Table 1 and Fig. 4 show the
experimental setup of the supervisor node.
TABLE I. EXPERIMENT SETUP
Supervisor node PC TLS server PC
CPU Intel Core i7-4790 CPU at 3.60GHz Intel Core i5-6500 CPU at 3.20GHz
Memory 8GB DDR3 SDRAM
OS CentOS Linux release 7.3.1611 (core)
Networking
equipment
LUA3-U2-ATX (Buffalo) and
RTL 8111/8168/8411 (Realtek)
RTL 8111/8168/8411 (Realtek)
ISSN 1947-5500

Figure 4. Experimental topology
The client was a normal PC, which did not include any
additional components of our system and could use browsers
such as Firefox and Google Chrome. The TLS server was a PC
running CentOS with an HTTPS server implemented using
Apache and OpenSSL. The supervisor node included an
intermediate vNIC with local IP address 192.168.20.123 for
gateway router A, each VEB was implemented using the
specified vNIC with no IP address, and the virtual TLS client
and server in the supervisor node were connected to the
intermediate vNIC and developed using OpenSSL in the C
language. In the experiment, the supervisor node analyzed two
streams provided by the TLS server. Fig. 5 shows the HTTP
GET requests representing these streams, as decrypted by the
transparent proxy system.
Figure 5. The two streams used for the experiment, as decrypted by the transparent proxy
In Fig. 5, stream_1 requests “title.png,” which was 2218 kB
in size, and stream_2 requests “littlewitch.mp4,” which was 33
MB in size. The following subsection shows the results of this
experiment, wherein the performance of the supervisor node
was evaluated in the following terms: its usability as a software
model on general-purpose equipment; Round Trip Time (RTT),
representing the Quality of Experience (QoE) of the client; and
CPU utilization, to see how easily it could coexist with other
processes. The client measured the RTT as an endpoint of the
HTTPS service, whereas the supervisor node measured the
CPU utilization, accounting for the software model of our
transparent proxy system.
A. Results
Table 2 shows the results of the experiments described in the
previous section, which were conducted five times for each
measurement. We used the TCPDUMP CentOS command to
measure the RTT on the client, and the TOP CentOS command
to measure CPU utilization on the supervisor node. For
comparison, Table 3 shows the RTTs measured without the
ISSN 1947-5500

supervisor node. Fig. 6 compares the RTT results with and without the supervisor node.
TABLE II. RESULTS FOR THE HTTPS SERVICE WITH THE SUPERVISOR NODE
Number
of trials
Stream
type
RTT(s) CPU
utilization
(%/s)
Median Average Max Min
1 Stream_1 0.000120 0.000161 0.001393 0.000044 0.90
Stream_2 0.000096 0.000606 0.051331 0.000014
2 Stream_1 0.000081 0.000940 0.000446 0.000033 0.81
Stream_2 0.000098 0.000670 0.051136 0.000016
3 Stream_1 0.000080 0.000096 0.00038 0.000027 0.84
Stream_2 0.000096 0.000712 0.051237 0.000015
4 Stream_1 0.000091 0.000115 0.000790 0.000032 0.87
Stream_2 0.000096 0.000651 0.051663 0.000017
5 Stream_1 0.000116 0.000130 0.000514 0.000056 0.83
Stream_2 0.000098 0.000667 0.050910 0.000016
TABLE III. RESULTS FOR THE NORMAL HTTPS SERVICE WITHOUT THE SUPERVISOR NODE
Number of
trials
Stream
type
RTT(s)
Median Average Max Min
1 Stream_1 0.000129 0.000166 0.001291 0.000041
Stream_2 0.000102 0.000643 0.051330 0.000016
2 Stream_1 0.000132 0.000169 0.001341 0.000042
Stream_2 0.000106 0.000542 0.051868 0.000016
3 Stream_1 0.000121 0.000168 0.004285 0.000034
Stream_2 0.000103 0.000493 0.050956 0.000018
4 Stream_1 0.000123 0.000168 0.006150 0.000042
Stream_2 0.000110 0.000647 0.051421 0.000018
5 Stream_1 0.000127 0.000170 0.004688 0.000035
Stream_2 0.000113 0.000565 0.051489 0.000019
ISSN 1947-5500

Figure 6. Comparison showing the extent of the RTT change between the HTTPS flows with and without the supervisor node
In Tables 2 and 3, stream_2 always shows a very high
maximum RTT compared with stream_1 because its larger size
caused network bandwidth congestion. An interesting result is
that the RTT for stream_1 with the supervisor node is smaller
than that without the supervisor node. We believe that this is
because the small delay, which can be seen on the graph of the
HTTPS service with the supervisor node in Fig. 6, prevented
any significant congestion control from happening, which was
not the case without the supervisor node. While the change in
RTT for stream_1 with the supervisor node was very variable,
the RTT for stream_2 with the supervisor node was uniformly
higher by around 0.1 ms. These results indicate that there is no
difference from a QoE standpoint for long-term communication.
In addition, the CPU utilization results for the transparent
proxy show that it has very good coexistence characteristics.
V. CONCLUSION
We have proposed an approach to engineering a transparent
proxy over TLS. The purpose of this node is to transparently
monitor the communications of the TLS service and manage
and semantically interpret the content served by it. The
architecture of the transparent proxy benefits from the
effectiveness of the NFV/SDN architecture. The proposed
transparent proxy is a function of the supervisor node in the
overlay network, which is designed for manageability,
flexibility, scalability, isolation, and programmability. The
transparent proxy was evaluated in an experiment to measure
its performance as a software model on general-purpose
equipment, showing that the transparent proxy is preferable
over TLS. The experimental results show good performance
and ability to coexist with other processes.
VI. DISCUSSIN AND FUTURE WORK
From the standpoint of the transparent proxy server’s
caching and forwarding functionality, it is clear that it is
helpful for strategic management based on the content of the
service. It has various applications, such as securing the
confidentiality of the content, monitoring users’ traffic usage,
and adapting the routing strategy based on the content. In
particular, a content-adaptive routing strategy will be an
essential application for future content-based networking, such
as information-centric networking, content-centric networking,
and named data networking. There have been several
interesting discussions about content-based networking [14–16],
with the aim of implementing a robust content discovery
mechanism using a content cache system with the OpenFlow
architecture over SDN. We believe that our overlay network
system is a possible engineering solution for the content cache
system and will be helpful for deploying transparent content
cache systems using TLS-encrypted communication.
ACKNOWLEDGMENT
The authors would like to express their heathy thanks to the
referee who pointed our several typological errors and made a
very suggestive proposal to revise the manuscript of this paper.
REFERENCES
[1] Amy Babay, Claudiu Danilov, John Lane, Michal Miskin-Amir, Daniel
Obenshain, John Schultz, Jonathan Stanton, Thomas Tantillo, and Yair
Amir, “Structured Overlay Networks for a New Generation of Internet
Services,” International Conference on Distributed Computing Systems,
2017.
[2] Paolo Medagliani, Stefano Paris, Jérémie Leguay, Lorenzo Maggi, Xue
Chuangsong, and Haojun Zhou, “Overlay Routing for Fast Video
Transfers in CDN,” IFIP/IEEE International Symposium on Integrated
Network Management, 2017.
[3] Joe Touch, “Dynamic Internet Overlay Deployment and Management
Using the X-Bone,” International Conference on Network Protocols,
2000.
[4] N.M. Mosharaf Kabir Chowdhury and Raouf Boutaba, “Network
Virtualization: State of The Art and Research Challenges,” IEEE
Communication Magazines, Vol. 47, No. 7, 2009, pp.20–26.
[5] Bo Han, Vijay Gopalakrishnan, Lusheng Ji, and Seungjoon Lee,
“Network Function Virtualization: Challenges and Opportunities for
ISSN 1947-5500

Innovations,” IEEE Communications Magazine, Vol. 53, No. 11, 2015,
pp.90–97.
[6] Raj Jain and Subharthi Paul, “Network Virtualization and Software
Defined Networking for Cloud Computing: A Survey,” IEEE
Communications Magazine, Vol. 51, No. 11, 2013, pp.24–31.
[7] Stuart Clayman, Lefteris Mamatas, and Alex Galis, “Efficient
Management Solutions for Software Defined Infrastructures,” Network
Operations and Management Symposium (NOMS) IEEE/IFIP, 2016.
[8] Albert Greenberg, Gisil Hjalmtysson, David A. Maltz, Andy Myers,
Jennifer Rexford, Geoffrey Xie, Hong Yan, and Jibin Zhang, “A Clean
State 4D Approach to Network Control and Management,” ACM
SIGCOMM Computer Communication Review, Vol. 35, No. 5, 2005,
pp.41–54.
[9] Hyojoon Kim and Nick Feamster, “Improving Network Management
with Software Defined Network,” IEEE Communication Magazine, Vol.
51, No. 2, 2013, pp.114–119.
[10] Jon Matias, Jokin Garay, Nerea Toledo, Juanjo Unzilla, and Eduardo
Jacob, “Toward an SDN-Enabled NFV Architecture,” IEEE
Communication Magazine, Vol. 53, No. 4, 2015, pp.187–193.
[11] Myung-Ki Shin, Ki-Hyuk Nam, and Hyoung-Jun Kim, “Software-
Defined Networking (SDN): A Reference Architecture and Open APIs,”
International Conference on ICT Convergence (ICTC), 2012.
[12] Mark O'Neill, Scott Ruoti, Kent Seamons, and Daniel Zappala, “TLS
Proxies: Friend or Foe?,” Proceedings of the 2016 Internet Measurement
Conference, 2016.
[13] Jianxin Wang, Anupama Sundaresan, Vijaya Bharathi Kaza, and Dario
Calia, “Transparent Proxy of Encrypted Sessions,” US20080126794 A1,
2008.
[14] Abhishek Chanda and Cedric Westphal, “A Content Management Layer
for Software-Defined Information Centric Networks,” Proceedings of
the 3rd ACM SIGCOMM workshop on Information-centric networking,
2013.
[15] Alex F. R. Trajano and Marcial P. Fernandez, “ontentSDN: A Content-
Based Transparent Proxy Architecture in Software-Defined
Networking,” Advanced Information Networking and Applications
(AINA), 2016.
[16] Panagiotis Georgopoulos, Matthew Broadbent, Bernhard Plattner, and
Nicholas Race, “Cache as a Service: Leveraging SDN to Efficiently and
Transparently Support Video-on-Demand on the Last Mile,” Computer
Communication and Networks (ICCCN), 2014.
ISSN 1947-5500

Proposal of a Transparent Relay System with vNIC for Encrypted Overlay Networks

More Related Content

What's hot (20)

Similar to Proposal of a Transparent Relay System with vNIC for Encrypted Overlay Networks (20)

Recently uploaded (20)

Proposal of a Transparent Relay System with vNIC for Encrypted Overlay Networks