Commit 71113041 authored by Otto Jonassen Wittner's avatar Otto Jonassen Wittner
Browse files

Still more to be done...

parent b7e0d2f7
File added
......@@ -32,3 +32,10 @@
howpublished = {https://httpd.apache.org/docs/2.2/vhosts/},
note = {Visited 2015-11-11}}
@Misc{tarreau2000haproxy,
author = {Willy Tarreau},
title = {HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer},
howpublished = {http://www.haproxy.org/},
year = 2000,
note = {Visited 2015-11-30}}
#!/bin/bash
# Load testing of SNIP
if [ $# -lt 2 ]
then
echo "Usage `basename $0` <4/6> <tot no of sessions>"
exit 1
fi
N=$2
IP=$1
i=0
let n=N/2
while [ $i -lt $n ]
do
if [ $IP -eq 4 ]
then
# SNIP1
( curl -4 --resolve streamer.uninett.no:443:158.38.212.139 https://streamer.uninett.no/bin/1000M > /dev/null 2>&1 & )
( curl -4 --resolve cat.eduroam.no:443:158.38.212.139 https://cat.eduroam.no/bin/1000M > /dev/null 2>&1 & )
# SNIP2
# ( curl -4 --resolve streamer.uninett.no:443:158.38.152.64 https://streamer.uninett.no/bin/1000M > /dev/null 2>&1 & )
else
( curl -6 https://streamer.uninett.no/bin/1000M > /dev/null 2>&1 & )
( curl -6 https://cat.eduroam.no/bin/1000M > /dev/null 2>&1 & )
fi
#( curl -$IP https://jornane.no/bin/1000M > /dev/null 2>&1 & )
let i=i+1
done
sleep 5
while [ 1 ]
do
pgrep curl | wc -l
sleep 1
done
......@@ -22,13 +22,14 @@
\author{Yorin Anne de Jong, UNINETT\\
Otto Jonassen Wittner, UNINETT}
\maketitle
\begin{abstract}
<summarize everything> \end{abstract}
%\begin{abstract}
%<summarize everything>
%\end{abstract}
\begin{IEEEkeywords}
IPv6 transition, Proxy, HTTPS, DNS, IPv6 only servers
\end{IEEEkeywords}
\section{Introduction}
%\section{Introduction}
%\begin{itemize}
%\item Most transition technology focus on clients.
......@@ -38,7 +39,9 @@ IPv6 transition, Proxy, HTTPS, DNS, IPv6 only servers
%\item Related work
%\end{itemize}
Four year has passed since the last blocks of IPv4 addresse where handed out by the Internet Assigned Numbers Authority (IANA).
\section*{Extended abstract}
Four year 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.
......@@ -51,7 +54,7 @@ Usage scale varies from small (a few nodes) home networks to WANs applying carri
However alternatives to NAT44 has been around for a while, NAT64 \cite{bagnulo2011rfc6146} and CLAT (based on 464XLAT \cite{mawatari2013rfc6877}) being two well known options.
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 succesfully kept the need for IPv4 server addresses low, similar to what NAT44 has done for clients.
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 an future ``IPv6-only'' world, VHosts and container proxies may become obsolete as every service can simply claim its own IPv6 address.
......@@ -63,55 +66,81 @@ 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.
This extended abstract presentes an alternative server side IPv4 to IPv6 transtion technology named S... N... IPv6 (SNIP).
The core concept is still based on a placing a proxy server between the application server and the clients.
To keep the complexity down and avoid the need for a classic address translation table,
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.
Embedded in the underlying Transport Layer Security connections (which provide the S in HTTPS) 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).
The rest of this extended abstract is organized as follows. Section \ref{sec:snip} describes SNIP in detail. Section \ref{sec:eval} prestents results from evaluating SNIP in a realistic environment. Section \ref{sec:related} presents related work, and Section \ref{sec:concl} summarizes and indicate future work.
\section{\label{sec:snip}SNIP}
Figure \ref{fig:snip-session} illustrate how SNIP operates....
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).
\begin{figure}
\includegraphics[scale=0.5]{snip.pdf}\caption{\label{fig:snip-session}The SNIP architecture including a SNIP session
\includegraphics[scale=0.48]{snip.pdf}\caption{\label{fig:snip-session}The SNIP architecture including a SNIP session
connection setup.}
\end{figure}
% Otto stopped here....
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.
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.
%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.
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.
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}.
%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.
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.
%This proxy will listen on TCP4 port 443 and read the SNI value on incoming requests.
%It will then lookup the hostname on IPv6 and forward the request there.
The oldest browser today that still has some market share that doesn't support SNI is Internet Explorer 6.
It is still in use in some intranets, but on the public internet the browser is as good as unsupported now.
%This allows the servers to run IPv6-only and let the proxy handle the IPv4 clients.
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.
%There are some problems this proxy doesn't solve, namely non-HTTPS services.
This proxy will listen on TCP4 port 443 and read the SNI value on incoming requests.
It will then lookup the hostname on IPv6 and forward the request there.
This allows the servers to run IPv6-only and let the proxy handle the IPv4 clients.
The proxy can use an IPv6-mapped IPv4-address to contact the server,
so that the proxy cannot be used as an anonimiser.
%Typically, there will be a low amount of these services on a network, compared to the amount of web services.
%It is therefore possible to assign these services their own IPv4 address.
%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).
There are some problems this proxy doesn't solve, namely non-HTTPS services.
Typically, there will be a low amount of these services on a network, compared to the amount of web services.
It is therefore possible to assign these services their own IPv4 address.
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).
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.
Some services there will only exist one of in an organisation, for example mail, chat, VPN.
These can share the same IPv4 address while having different IPv6 addresses.
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.
\section{Evaluation}
What should go here? I have been running it for some sites, it runs stable.
%\section{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.}
\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 16 core 2.4Ghz server with 32GB memory running {\em Apache2} was applied as HTTPS server.
The bottelneck 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.
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.
%<<<<<<< Updated upstream
\section{Related Work}
\heading{HAproxy}
%\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.
In the case of HTTPS, this means that it needs to decrypt the traffic and therefore needs a private key.
......@@ -119,12 +148,12 @@ 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 )
\heading{SNI Proxy}
%\heading{SNI Proxy}
SNI Proxy 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}
%\heading{NAT64}
NAT64 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.
......@@ -143,6 +172,13 @@ 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
\bibliographystyle{ieeetr}
......
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