Commit 50f4ba66 authored by Otto Jonassen Wittner's avatar Otto Jonassen Wittner
Browse files

Version submitted to TNC 2016

parent 71113041
......@@ -39,3 +39,23 @@
year = 2000,
note = {Visited 2015-11-30}}
@Misc{ristic2011ssl,
author = {Ivan Ristic and Michael Small},
title = {A Study of What Really Breaks SSL},
howpublished = {Presentation at HITB Sec Conf 2011, Amsterdam},
month = {May},
year = 2011}
@Misc{startssl,
title = {StartSSL},
howpublished = {https://www.startssl.com/},
note = {Visited 2015-11-30}}
@Misc{lundquist2015sniproxy,
author = {Dustin Lundquist},
title = {SNI Proxy},
howpublished = {https://github.com/dlundquist/sniproxy},
note = {Visited 2015-11-30}}
File added
......@@ -19,8 +19,12 @@
\title{SNIP: TLS based IPv6 transition proxy }
\author{Yorin Anne de Jong, UNINETT\\
Otto Jonassen Wittner, UNINETT}
\author{
\IEEEauthorblockN{Yorin Anne de Jong\IEEEauthorrefmark{1}, Otto Jonassen Wittner\IEEEauthorrefmark{2}}
\\\IEEEauthorblockA{UNINETT
\\\{yorn\IEEEauthorrefmark{1}, wittner\IEEEauthorrefmark{2}\}@uninett.no}
\\+47 95361017\IEEEauthorrefmark{1}, +47 99550566\IEEEauthorrefmark{2},
}
\maketitle
%\begin{abstract}
%<summarize everything>
......@@ -41,7 +45,7 @@ IPv6 transition, Proxy, HTTPS, DNS, IPv6 only servers
\section*{Extended abstract}
Four year has passed since the last blocks of IPv4 address where handed out by the Internet Assigned Numbers Authority (IANA).
Four years has passed since the last blocks of IPv4 address where handed out by the Internet Assigned Numbers Authority (IANA).
Still only less than 12\% of web sites in the world support IPv6 \cite{vyncke2015ip6stats} and the amount of IPv6 enable users is below 10\%.
Hence a full transition from ``legacy'' IPv4 to modern IPv6 addressing cannot be claimed to yet have taken place.
......@@ -55,7 +59,7 @@ However alternatives to NAT44 has been around for a while, NAT64 \cite{bagnulo20
On the server side, however, there has not been as much development.
The use of VHosts (running multiple similar services on a single server, e.g. \cite{apache2vhost} ) has successfully kept the need for IPv4 server addresses low, similar to what NAT44 has done for clients.
In modern models, where services run on containers, there is usually a proxy server which exposes all services on a single IP address, similar to the way VHosts work.
In modern models, where services run in containers, there is usually a proxy server which exposes all services on a single IP address, similar to the way VHosts work.
In an future ``IPv6-only'' world, VHosts and container proxies may become obsolete as every service can simply claim its own IPv6 address.
One immediate advantages of this is the improved ability to build service specific access control lists (ACLs) based on addresses in lower layers of the network stack, for example in a router.
......@@ -66,10 +70,12 @@ It also simplifies the stack, because application level routing is no longer req
% Because of this, running servers IPv6-only seems like an impossible task.
% Clients must be able to connect from their IPv4-only phones, routers, ISPs to your servers; you will lose business and money if you don't.
\subsection*{SNIP}
This extended abstract presents an alternative server side IPv4 to IPv6 transition technology named {\em Server Name Indication Proxy } (SNIP).
The core concept is still based on placing a proxy server between the application server and the clients.
To keep the complexity down and avoid the need for an traditional address translation table,
SNIP exploits the fact that a majority of all web based services are available over HTTPS \cite{}, i.e. encrypted HTTP connections.
But to keep the complexity down and avoid the need for a traditional address translation table,
SNIP utilizes the fact that a significant number web based services are available over HTTPS, i.e. encrypted HTTP connections.
According to \cite{ristic2011ssl} already in 2011 more than 30\% of the 1 million most visited web sites applied HTTPS.
Embedded in the underlying Transport Layer Security connections (which provide the S in modern HTTPS connections) is a Server Name Indication (SNI) value, i.e. the domain name of the destination application server.
Hence the mapping required to perform address translation can be configured in the Domain Name System (DNS).
......@@ -80,24 +86,24 @@ connection setup.}
Figure \ref{fig:snip-session} illustrate the SNIP architecture and two session examples, one Ipv6 only and one with IPv4-to-IPv6 translation.
Traffic from IPv6 clients are routed (via dual stack routing components) directly to the relevant IPv6 only server as DNS reports the native IPv6 address of the server (AAAA DNS entry).
However When IPv4 clients enquired DNS for server addresses (A entries) the IPv4 address of the SNIP proxy is returned.
Traffic is hence routed to the proxy which is ready listning to port 443 (HTTPS).
The proxy renquires the DNS service for IPv6 address information (AAAA entries) based on the SNI value extracted from the TLS header.
However when IPv4 clients enquired DNS for server addresses (A entries) the IPv4 address of the SNIP proxy is returned.
Traffic is hence routed to the proxy which is ready listening to port 443 (HTTPS).
The proxy enquires the DNS service for IPv6 address information (AAAA entries) based on the SNI value extracted from the TLS header.
The returned IPv6 address as well as the incoming IPv4 based client connection is applied by the SNIP proxy to establish two TCP connections,
one towards client and one towards server.
All payload of TCP data packets are forwarded (in both directions) by the SNIP proxy until one of TCP connections are teared down.
All payload of TCP data packets are forwarded (in both directions) by the SNIP proxy until one of the TCP connections are teared down.
%When a client connects to an HTTPS server, it will send an SNI-value.
%This is the hostname of the server the client thinks it's contacting.
Core assumtions made by the SNIP proxy is that all traffic applies HTTPS with TLS and that clients (browsers) support SNI values.
A browser not supporting SNI but still with a relevant relevant market is Internet Explorer 6 (IE6).
However IE6 is typically only appieled in intranets (due to security challenges),
hence browser on the public internet may be assumed to support SNI.
Core assumptions made by the SNIP proxy is that all traffic applies HTTPS with TLS and that clients (browsers) support SNI values.
A browser not supporting SNI but still with a relevant market share is Internet Explorer 6 (IE6).
However IE6 is typically only applied in intranets (due to security challenges),
hence browsers on the public internet may be assumed to support SNI.
Today any well configured HTTP-server will support HTTPS.
Recent initiative to offer free certificates \cite{} (required by TLS) will enable any server to support trusted TLS session at no or limited cost.
Recent initiatives to offer free certificates (required by TLS), e.g. \cite{startssl} will enable any server to support trusted TLS session at no or limited cost.
The remaining (low) fraction of none-HTTPS traffic may be handle by either dual stacks in servers or by an TCP proxy, e.g. through HAProxy \cite{tarreau2000haproxy}.
The remaining fraction of none-HTTPS traffic may be handle by either dual stacks in servers or by an TCP proxy, e.g. through HAProxy \cite{tarreau2000haproxy}.
%By utilising the facts that (1) virtually all communication happens over HTTPS and (2) all reasonably up to date clients support SNI, this documents proposed SNIP, an auto-configuring proxy that uses the SNI value.
......@@ -113,75 +119,71 @@ The remaining (low) fraction of none-HTTPS traffic may be handle by either dual
%This can either be done directly on the server (requires infrastructure that supports IPv4),
%or the proxy server can run a TCP proxy, for example through HAproxy (existing software).
Some none-HTTPS services there will only exist one of in an organisation, for example mail (e.g. IMAP, SMTP), chat (e.g. XMPP), VPN (e.g. OpenVPN).
Some none-HTTPS services will only exist as single instances in an organisation, for example mail (IMAP, SMTP), chat (XMPP) and VPN (OpenVPN).
These can still share the same IPv4 address as they run on different ports.
A port based mapping to different IPv6 addresses can be applied.
A security concern with SNIP may be that the proxy can be exploided for source address anonymisation.
The avoid this a SNIP proxy may be deligated a /32 IPv6 address range which enables embedding of original IPv4 source address in the IPv6 source address applied to contact the HTTPS server.
A security concern with SNIP may be that the proxy can be exploited for source address anonymization.
To avoid this a SNIP proxy may be delegated a /32 IPv6 address range which enables embedding of original IPv4 source address in the IPv6 source address applied to contact the HTTPS server.
%\section{Evaluation}
A proof of concept of SNIP is implemented in the NodeJS language.
This language allows fairly complex operations to be done with small amounts of code.
%The version that has been benchmarked for this extended abstract has been field-tested against some small, personal, websites.
%It shows that the concept works; IPv4 and IPv6 users get the same experience.
\subsection*{Evaluation}
%What should go here? I have been running it for some sites, it runs stable.
\begin{figure}
\includegraphics[scale=0.5]{performance.pdf}\caption{\label{fig:snip-perf}Perormance on a single SNIP instance running on single CPU virtulized server.}
\includegraphics[scale=0.5]{performance.pdf}\caption{\label{fig:snip-perf}Performance on a single SNIP instance running on single CPU virtualized server.}
\end{figure}
Figure \ref{fig:snip-perf} shows the results of some preliminary performance measurements of SNIP.
A single Ubuntu 14.04 configured Intel Core i7 based laptop with gigabit network inteface was applied to generate client request with the {\em Curl} command line browser. A SNIP proxy running in an virtual machine with a single 2.0 Ghz CPU and 768MB of memory was perpared.
A single Ubuntu 14.04 configured Intel Core i7 based laptop with gigabit network interface was applied to generate client request with the {\em Curl} command line browser. A SNIP proxy running in an virtual machine with a single 2.0 Ghz CPU and 768MB of memory was prepared.
A 16 core 2.4Ghz server with 32GB memory running {\em Apache2} was applied as HTTPS server.
The bottelneck link in the setup supported 1Gbps.
The bottleneck link in the setup supported 1Gbps.
A number of concurrently running Curl clients where executed to download a 1GB file from the Apache server.
The maximum number of client where chosen to match the number of parallell sessions handled (before they are queued) by Apache with a default configuration, i.e. 150.
The maximum number of client where chosen to match the number of parallel sessions handled (before they are queued) by Apache with a default configuration, i.e. 150.
As is readly seen in Figure \ref{fig:snip-perf}, a single instance of SNIP coupes with around 100 clients.
As CPU load reaches 85\% the VM running SNIP struggels to offer enough resources.
At 140 clients the VM also starts swapping memory, hence perfomances drops further.
As is readily seen in Figure \ref{fig:snip-perf}, a single instance of SNIP coupes with around 100 clients.
As CPU load reaches 85\% the VM running SNIP struggles to offer enough resources and througput drops.
At 140 clients the VM also starts swapping memory, hence throughput drops further.
%<<<<<<< Updated upstream
\section{Related Work}
\subsection*{Related Work}
%\heading{HAproxy}
HAproxy is an open source high availability HTTP, HTTPS and TCP proxy.
For HTTP and HTTPS, it uses the incoming socket (IP address and port) and hostname provided in the HTTP header to provide VHost-capabilities.
HAProxy \cite{tarreau2000haproxy} is an open source high availability HTTP, HTTPS and TCP proxy.
For HTTP and HTTPS, it uses the incoming socket (IP address and port) and host-name provided in the HTTP header to provide VHost-capabilities.
In the case of HTTPS, this means that it needs to decrypt the traffic and therefore needs a private key.
The TCP proxy uses only the incoming socket.
There is currently no possibility to use the SNI value.
HAproxy is configured by defining front-ends (which an end-user connects to) and back-ends (which )
%There is currently no possibility to use the SNI value.
There is currently no support for utilizing SNI values.
%HAproxy is configured by defining front-ends (which an end-user connects to) and back-ends.
%\heading{SNI Proxy}
SNI Proxy is an open source TCP proxy that uses the SNI value to provide VHost-capabilities.
SNI Proxy \cite{lundquist2015sniproxy} is an open source TCP proxy that uses the SNI value to provide VHost-capabilities.
It uses a configuration file which maps the SNI value to an IP address.
This is very similar to the behaviour of SNIP, except that SNIP uses DNS instead of a config file.
%\heading{NAT64}
NAT64 is a transition technology in order to make external IPv4-only servers available to local IPv6 clients.
NAT64 \cite{bagnulo2011rfc6146} is a transition technology in order to make external IPv4-only servers available to local IPv6 clients.
It is typically employed by a network administrator that has IPv6-only clients.
The goal is the counterpart of SNIP, where SNIP makes local IPv6 servers available to external IPv4-only clients.
In a setup with IPv6-only servers, it is possible to use both SNIP and NAT64 in tandem, in order to make the servers available for IPv4-only hosts, and to allow the servers to use external IPv4-only APIs.
\section{Implementation details}
A proof of concept of SNIP is implemented in the NodeJS language.
This language allows fairly complex operations to be done with small amounts of code.
The version that has been benchmarked for this extended abstract has been field-tested against some small, personal, websites.
It shows that the concept works; IPv4 and IPv6 users get the same experience.
The current implementation has stability issues when it needs to handle a lot of connections at the same time.
A small-scale experiment on location suggests that the current connection limit for SNIP lies close to the limit for Apache,
but code optimalization could improve this.
\section{Conclusion}
The concept of SNIP has been proven, when a more stable version is available,
SNIP will be a step towards the IPv6-only server park.
=======
With limited resources a single
%\section{Related Work}
%\section{Conclusion}
%>>>>>>> Stashed changes
\subsection*{Conclusion and Future work}
SNIP provides a proof of concept for a NodeJS implemented IPv4-to-IPv6 transition mechanism enabling IPv6 only servers to be reached by IPv4 clients. The current implementation has stability issues when it needs to handle a lot of connections at the same time. A framework is under development to control maximum load on a single instance of SNIP, i.e. a SNIP proxy load balancer, and hence improve stability significantly. Despite its current limitations SNIP seems to coupe well with respect to a typical default web server configuration, and may be viewed as an valuable step towards the IPv6-only server park.
\bibliographystyle{ieeetr}
\bibliography{refs}
\section*{Vitae}
\begin{description}
\item[Yorin Anne de Jong] \hfill \\
has a Msc in telematic from the Norwegian University of Science and Technology (NTNU). He has a full time position at UNINETT's systems department, and works with software development in many different activities.
\item[Otto J Wittner] \hfill \\
has a PhD in Network Management from Norwegian University of Science and Technology (NTNU). He is currently engaged full time in UNINETT's innovation program where he explores upcoming internet networking and multimedia technologies. He also holds a part time adjunct professorship at NTNU.
\end{description}
\end{document}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment