IP Mobility Support for Virtual Private Networks

2 CHAPTER 1. INTRODUCTION
the proposed solution. In this chapter it is possible to find a detailed de-
scription of issues introduced by the coexistence of the two services we need.
Furthermore the state of the art about the topic is investigated, showing the
main solutions already present. Finally we find the description of MoVPN
(Mobile VPN), the proposed architectural solution. “Architectural” refers to
the nature of the solution: Rather than introducing extensions to standards,
it relies on a smart configuration of existing facilities in order to obtain the
required functioning. The configuration does not have to be underestimated,
as it can lead to rough security weaknesses. Therefore all the system func-
tioning is analyzed in detail, and different alternatives are also provided. As
it does not introduce any additions to standards, MoVPN has the undeniable
advantage of being immediately installable with reduced costs. In particu-
lar, a testbed with minimal functioning has been implemented using only
free software.
Chapter 4 describes the testbed deployment and the results, in terms of
bandwidth reduction caused by MoVPN system.
Conclusions and future developments are reported in chapter 4.
This work has been developed in WirelessCabin ambit at Digital Net-
works department of Deutsches Zentrum fr Luft- und Raumfahrt (DLR) in
Oberpfaffenhofen. Several members take part to the WirelessCabin1 project
team, as Airbus Deutschland GmbH, Ericsson Telecomunicazioni SpA, ESYS
plc, Inmarsat Ltd., KID-Systeme GmbH, Siemens AG Austria, TriaGnoSys
GmbH, University of Bradford, and DLR as project leader. The project is
developing wireless access technologies for a aircraft cabin. Several access
technologies in the cabin are envisaged for passengers: UMTS for personal
telephony and packet data, Bluetooth and W-LAN for IP access. The Blue-
tooth interface will also be used for transport of UMTS services. The project
will define a system architecture for wireless access (UMTS, W-LAN and
Bluetooth) in an aircraft cabin. A passenger will have the possibility to use
his own personal equipment (mobile phone, laptop). For this, the project
will develop a service integrator that maps the cabin services on a satellite
bearer to be connected to the terrestrial infrastructure.
Among the envisaged services, passengers will have the possibility of set-
ting up a VPN to ground companies. This work focused in particular on this
topic. Another possible application of the problem discussed in this work is
the mobile management of several aircrafts as mobile nodes of a single ter-
restrial private network. This terrestrial network will allow the connection
of the “flying networks” to the common public networks: PSTN, Internet,
UMTS.
1
IST programme IST-2001-37466, http://www.wirelesscabin.com
Chapter 2
Technologies
In this chapter we will provide information on technologies used in the solu-
tion proposed by this work. The reader has to keep present that this chapter
is not intended to be an exhaustive description of the topics and in each
section it will be possible to find pointers to more detailed documentation.
3
4 CHAPTER 2. TECHNOLOGIES
2.1 Terminology
2.1.1 Incoming and outgoing sessions
In general it is possible to group packet flows to identify the traffic related
to a particular application or service. We will call session or communication
the traffic flow generated by a first “request” packet.
An host contacting another host sends a first packet requesting a com-
munication. Then the contacted host answers, beginning the data exchange.
Which data and how they are exchanged is application dependent. From the
direction of this first packet it is possible to distinguish between outgoing
(from internal to external) and incoming (from external to internal). Any-
way note that, in general, each session is composed by incoming as well as
outgoing packets. We can consider the example of a Web server. First an
host contacts the server requesting a resource, then the server answers with
the desired file. The complete traffic exchange is seen as an outgoing session
by the host or incoming session by the server, but the transaction has both
incoming and outgoing flows.
2.1.2 Tunnelling
One of the major concepts in networking is tunnelling, also refferred as en-
capsulation. This method in general refers to embedding a Protocol Data
Unit (PDU) as payload for another PDU without following the protocols
stack process. Normally a PDU is used as payload for the layer immedi-
ately below in the protocol stack. In tunnelling, a PDU becomes the payload
of a new PDU of the same or even above layer. An example could be the
frequently used IP-in-IP tunnelling (see Fig. 2.1).
Figure 2.1: Tunnelling
The embedded (tunnelled) packet is unaware of what happens outside, to
the external packet. One of the main usages of IP-in-IP tunnelling is packet
2.1. TERMINOLOGY 5
redirection. Without modifying the internal packet it is possible to make
it passing through fixed points. This is achieved by embedding the packet
in new packets directed to the fixed points. The name “tunnelling” comes
from this usage: The packet, like a car or a train, enters the tunnel from
a point and exits from another point, without knowing the exact path that
it followed. Another example that will be shown in this work is IP-in-UDP
tunnelling. In this case a complete IP packet is sent as the payload of another
UDP datagram (that has its own IP header).
6 CHAPTER 2. TECHNOLOGIES
2.2 Network Address Translation
Network Address Translation (NAT) attempts to provide a transparent rout-
ing solution for hosts trying to communicate from disparate address realms
with no compatible addressing. Since an IP address of one realm is not valid
within the other realm, this is achieved by modifying end node addresses
en-route and maintaining state for these changes.
A typical usage of NAT is the connection of a network with a private
addressing scheme1 to an external network with globally-routable addresses.
Using a NAT gateway in such a scenario, it is possible to achieve two main
advantages: Solving the public addresses shortage, a main problem in IPv4;
hiding the real network topology to increase the security.
One of the major characteristics is that both hosts in private and external
domain are unaware of the NAT presence: No changes are required for the
protocol stack of the communicating hosts, in order to be compatible with a
intervening NAT gateway. It has to be noted that this “unawareness” is not
always simply achievable or even possible.
Even if it introduces some complications, nowadays NAT devices are
widely used and this work can not leave out of consideration this element.
The purpose of this section is therefore to show the basics of the functioning
of a NAT router and analyze problems and limitations concerned with it.
Finally we want to outline that this section is a summary of [5] and the
reader interested in a more detailed information, can refer to this document.
2.2.1 How it works
To understand how NAT works, we can analyze a typical usage. We wish
to connect a private network, in which hosts are with no globally-routable
addresses, to a public network, in which instead hosts have globally-routable
addresses. We will call the private domain also internal realm and we will use
the adjectives internal or private to mean what is related with it; external
or public will be what is related with the outside (the public network).
A private host A, that is identified by A-PriAddr address in its realm,
wants to communicate with a public host B, that has B-PubAddr address
(see Fig. 2.2).
A-PriAddr is not valid within the public domain and therefore how can
B reply to A packets? Packets with A-PriAddr as destination can not be
routed within the public realm and thus A would not receive responses from
B. A frequently used method to solve this problem is the adoption of a NAT
1Please refer to [4] for more information about addressing private networks
2.2. NETWORK ADDRESS TRANSLATION 7
Figure 2.2: A NAT scenario
gateway. All the traffic incoming and outgoing from the private network
passes trough the NAT gateway N.
In Fig. 2.3 is shown the process applied to an outgoing packet. Here
follows the description.
1. While travelling within the internal realm the packet that A wants B
to receive has A-PriAddr as source and B-PubAddr as destination.
2. When the packet goes outside it can no more have A-PriAddr as source,
because this address is not valid in the external realm. Since N has a
pool of reserved public addresses that it can use, it takes one of these
addresses (we will call it A-PubAddr) and modifies A-PriAddr with
A-PubAddr.
Because of this change a recalculation of checksums is needed: NAT
has to recalculate both the IP and TCP2 header.
N also has to remember this just done binding between the traffic
flow that begins with the packet and the IP address A-PubAddr. This
address binding will be necessary later, to allow incoming packets.
3. Changed the source address, N throws the packet into the external
realm allowing it to reach B.
2From Request For Comments (RFC) 793, the RFC that specifies the TCP standard:
“The checksum also covers a 96 bit pseudo header conceptually prefixed to the
TCP header. This pseudo header contains the Source Address, the Destination
Address, the Protocol, and TCP length. This gives the TCP protection against
misrouted segments.”
8 CHAPTER 2. TECHNOLOGIES
Figure 2.3: Packet outgoing from the external realm
What happened?
Substantially the NAT gateway associated a public address to host A,
translating its private address with this new one. In this way packets from
A are now valid in the external realm, but what is more important is that
now B can reply to A.
B replies
The A-PriAddr assigned to this communication flow by the NAT is necessary
to allow B to respond. The process is shown in Fig. 2.4 and the description
follows.
Figure 2.4: Packet incoming to the internal realm
1. B replies to A using A-PubAddr, thus it creates a packet with A-
PubAddr as destination and B-PubAddr as source.
2. Since A-PubAddr is one of the addresses managed by NAT, routing in-
formation related with A-PubAddr identifies N as the router pertaining
to the private network: The packet from B to A reaches N.
3. When N receives this packet it sees that the packet has A-PubAddr
and understands that it is for A. N changes the destination address
with A-PriAddr, recalculate the checksums and throws the packet into
the internal realm.
2.2. NETWORK ADDRESS TRANSLATION 9
When A does not require to communicate with B anymore, or other
external hosts, after a timeout N sets A-PubAddr as free and it will be
possible to associate it with new connection.
By modifying addresses for incoming and outgoing packets, NAT per-
mits the otherwise impossible communication between the two realms. Each
translation has to be remembered in order to correctly modify all the subse-
quent traffic. But leveraging on address modification is also the main NAT
disadvantage, since it violates the end-to-end nature of the Internet con-
nectivity. Because of this, NAT disrupts protocols requiring or enforcing
end-to-end integrity of the packets, and the coexistence with such protocols
is not always painless.
2.2.2 Basic functionalities
There are different typologies of NAT but all the “flavors” should share the
following characteristics.
1. Transparent address assignment
NAT assigns addresses to internal hosts to let them communicate with
the extern. It is possible either a static or a dynamic assignment.
With the static the state of the NAT is a fixed “lookup table”. In the
dynamic assignment the address is assigned as soon as the host requires
a communication. The address is released when it is no more necessary
for the communication.
2. Transparent routing through address translation
Routing here refers to forwarding packets and not exchanging routing
information. A NAT routes a datagram between disparate address
realms, by modifying address content in the IP header to be valid in
the address realm into which the datagram is routed.
3. ICMP error packet payload translation
All ICMP error messages will need to be modified, when passed trough
NAT. Note that the modification involves all the message as it includes
many IP addresses dependent information. For a detailed list about
what is modified and what is not, please refer to section 3.3 of [5].
2.2.3 Application Level Gateway
The NAT function cannot by itself support all applications; if an application
uses IP addresses as a part of its protocol, NAT cannot simply be imple-
mented as is. It is necessary to support NAT work with an Application Level
10 CHAPTER 2. TECHNOLOGIES
Gateway (ALG). An ALG is an application specific translation agent that
allows an application on a host to transparently work with its counterpart
running on a host in a different IP realm. ALGs work “beside” the NAT to
smartly change not only addresses but also payloads.
A classic example about this situation is FTP. PORT command and PASV
response in FTP control session payload identify the IP address and TCP
port that must be used for the data session it supports. The arguments for
those commands are an IP address and a TCP port in ASCII. An FTP ALG
is required to monitor and update the FTP control session payload so that
information contained in the payload is relevant to end nodes.
2.2.4 NAT flavors
Figure 2.5: NAT flavors
In Fig. 2.5 you can find the summary of main typologies of NATs. There
are several different flavors of NAT but the majors can be described as follow.
1. Traditional NAT
Also called outbound NAT because it only permits outbound connec-
tion from the private network. There are two variations:
(a) Basic NAT
Block of external addresses are set aside for translating addresses
of hosts in a private domain as they originate session to external
domain.
(b) Network Address Port Translation (NAPT)
Extends the notion of translation also to transport identifier (e.g.
2.2. NETWORK ADDRESS TRANSLATION 11
TCP and UDP ports, ICMP query identifiers). An internal source
tuple
<private IP address, transport identifier X>
is mapped to
<public IP address, transport identifier Y>
This allows the transport identifiers of a number of private hosts to
be multiplexed into the transport identifiers of single external host:
NAPT allows a set of internal hosts to share the same external IP
address. Furthermore it is possible to use NAPT in combination
with Basic NAT.
2. Bi-directional NAT
With Bi-directional NAT sessions can be initiated from hosts in the
public network as well as hosts in the private network. Private ad-
dresses are bound to public addresses statically or dynamically with a
one-to-one mapping.
While in static address binding Domain Name System (DNS) service
can work as usual, alone, with a fixed lookup table, in dynamic address
binding DNS has an important role. The correspondence between a
name and an address changes during the time. DNS becomes a DNS-
ALG because it has to dialogue with the NAT before answering to
the requesting external host. Note that this applies only for inbound
connection, i.e. when an external host tries to reach an internal host.
For outbound session there is no need of an enhanced DNS.
3. Twice NAT
While variations of NAT so far discussed change only the source infor-
mation, Twice NAT modifies also destination address. This is necessary
when private and external realms have address collisions. For exam-
ple, the private network is improperly addressed with public addresses.
The key issue in such case is that an address of a host in the external
realm could be assigned to a host within the local site. If this address
appears in a packet, this packet is forwarded to the local node rather
than to the external.
Again the solution involves a DNS-ALG. When the internal host tries
communicate with an external host, first it sends a DNS request. Re-
ceiving the request DNS-ALG is smart enough to understand the poten-
tial mistake: It answers with a fictitious address and makes the NAT
knowing about this. When the packet goes through NAT, it trans-
12 CHAPTER 2. TECHNOLOGIES
lates the fictitious address with the real overloaded one and throws the
packet outside the private network.
In Fig. 2.5 is missing the last variation discussed in [5]: Multihomed-
NAT. We did not show it in the figure because it is not a really different
kind of NAT. Rather it is a method to repeat and partially distribute NAT
functionalities to more than one device for efficiency and reliability purposes.
2.2.5 NAT limitations
Unfortunately, NAT usage introduces some limitations and we can definitely
state that a private addressing scheme with a NAT gateway is just similar
to a globally-routable addressing scheme.
In [5] there is a detailed section about NAT limitations; here we want
to make a more general speech, communicating to the reader the concepts
behind the limitations and thus making him to fit these descriptions to his
possible problems.
As already said, the main problem with NAT is that it breaks the end-
to-end integrity typical of IP communication. There are several applications,
but also protocols, that are based on this end-to-end integrity assumption.
ALG programs can partially solve this situation, but don’t forget that
they modify the packet payload. This is clearly in contrast with all that
wants to guarantee authentication and integrity of a packet: One of the
worse NAT enemies is in fact IP Secure (IPsec). How is it possible to change
addresses and also checksum when they are checked for integrity or even
encrypted? It is clear that it is not a simple problem to solve. Someone
could suggest to break the secure link between to host in two different links
tied by the NAT. The first piece goes from a host to NAT and the second
starts from NAT and reaches the correspondent node. This could be, but in
such a case the NAT must be a trusted device.
The reader has to note that NAT and IPsec are not in generale incom-
patible: Obviously, it depends on how they are combined. It is possible,
for example, to use IPsec when one of the ends of the secure link is the
NAT server, since, in the end, it is an host. What is impossible, due to
the end-to-end integrity break, is the establishment of and end-to-end secure
communication between an internal and an external host. There is no way,
using a NAT with the eventual support of ALG, to set a secure tunnel that
crosses the two realms.
Finally, about NAT limitations, it is necessary to spend some words about
computational complexity. A NAT router is not only a simple router. Added
2.2. NETWORK ADDRESS TRANSLATION 13
to usual router functionalities, it has to operate binding, unbinding, trans-
lation, checksum calculation and ALG modification. These operations, de-
pending on the line throughput, could negative affect the global NAT router
throughput.
2.2.6 Security consideration
Many people view traditional NAT router as a one-way (session) traffic filter,
restricting sessions from external hosts into their machines. In addition, when
address assignment in NAT router is done dynamically, that makes it harder
for an attacker to point to any specific host in the NAT domain. NAT routers
may be used in conjunction with firewalls to filter unwanted traffic.
An important thing to remember is that if NAT devices and ALGs are
not in a trusted boundary, this is a major security problem, as ALGs could
snoop end user traffic payload. To avoid this situation, session level payload
could be encrypted end-to-end, but this only applies as long as the payload
does not contain IP addresses and/or transport identifiers that are valid in
only one of the realms.
One weakness of NAT router comes from UDP. UDP sessions are inher-
ently unsafe because responses to a datagram could come from an address
different from the target address used by sender. As a result, an incoming
UDP packet might match the outbound session of a traditional NAT router
only in part (the destination address and UDP port number of the packet
match, but the source address and port number may not). In such a case,
there is a potential security compromise for the NAT device in permitting
inbound packets with partial match. Note anyway that this UDP security
issue is also inherent to firewalls.
Finally, since NAT devices are Internet hosts, they can be the target of a
number of different attacks, such as SYN flood3 and ping flood4 attacks. NAT
devices should employ the same sort of protection techniques as Internet-
based servers do.
3A detailed description of this well known attack is in [6]
4This attack is performed by sending a huge number of ICMP echo request (ping
packets) by means of a fast connection, to a victim host that has a slow connection. To
respond to all the requests the victim could saturate its available bandwidth.