MIPSHOP WG W. Haddad
Internet-Draft
Intended status: Standards Track M. Naslund
Expires: September 10, 2009 Ericsson Research
P. Nikander
Ericsson Research Nomadic Lab
March 9, 2009
IP Tunneling Optimization in a Mobile Environment
draft-haddad-mipshop-tunneling-optimization-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Haddad, et al. Expires September 10, 2009 [Page 1]
Internet-Draft IP Tunneling Optimization March 2009
Abstract
This memo introduces a simple tunneling optimization mechanism, which
removes the need for inserting an additional header in the IP packet.
The main goals are to minimize the packet size, provide a simpler
protocol design and a better efficiency.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Tunneling Optimization for BT mode and HMIPv6 . . . . . . . . 7
5. Tunneling Optimization for RO mode . . . . . . . . . . . . . . 11
6. Tunneling Optimization for DSMIPv6 . . . . . . . . . . . . . . 12
7. Bit and Options Formats . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Haddad, et al. Expires September 10, 2009 [Page 2]
Internet-Draft IP Tunneling Optimization March 2009
1. Introduction
IP tunneling is a mechanism widely used for different purposes. For
example, it enables relying on a dedicated third party to modify the
IP packet header, in order to re-route the packets to their new
destination. This is mainly the case in a mobile environment where
IP tunneling is used in most protocols. In fact, the mobile IPv6
bidirectional tunneling (BT) mode described in [MIPv6]) uses IP
tunneling to route data through the home agent (HA). The same
mechanism is applied between the mobility anchor point (MAP) and the
mobile node (MN) in the hierarchical mobile IPv6 (HMIPv6) protocol
(described in [HMIPv6]). A modified IP tunneling version is also
used in MIPv6 route optimization (RO) mode.
This memo introduces a simple tunneling optimization (TO) mechanism,
which virtualizes the IP tunnel concept often used in traffic
exchange. TO mechanism is based on securely exchanging a "pad
translator" (PaT) between both sides of the (supposed) tunnel.
The PaT main role is to translate incoming/outgoing packet header to
another one before injecting it inside/outside the tunnel. TO main
goals include a reduced packet size, a simpler protocol design and a
better efficiency.
Haddad, et al. Expires September 10, 2009 [Page 3]
Internet-Draft IP Tunneling Optimization March 2009
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [TERM].
Haddad, et al. Expires September 10, 2009 [Page 4]
Internet-Draft IP Tunneling Optimization March 2009
3. Motivation
The motivation behind this work is the widespread use of different
forms of IP tunneling mechanisms in mobile environment and their
negative impact on the protocol efficiency as translated in the data
packet size, bandwidth usage and battery power consumption.
In the following, we consider IPv6 mobility protocols only and start
with a brief description of the IP tunneling mechanism used in both
MIPv6 BT mode and HMIPv6 protocol. Next, we describe the MIPv6 RO
mode tunneling mechanism, then show in the next section how the TO
mechanism completely eliminates the need for IP tunneling in these
mobility protocols in a simple and elegant way.
Other mobility related protocols, e.g., Fast MIPv6 described in
[FMIPv6] and the ongoing work on proxy MIPv6 ([PMIPv6]) can also
benefit from using TO mechanism, especially when the path between
access routers (ARs) and/or between the HA and a PMIPv6 node(s)
includes a wireless medium.
A closer look on the tunneling mechanism used in the BT mode (i.e.,
between the HA and the MN) and HMIPv6 protocol (i.e., between the MAP
and the MN) highlights different issues that need to be addressed. A
first one is the expansion of the packet size due to the addition of
a new IP header. In the two protocols, such expansion is mainly
equal to two IP addresses. This means that the MN has to send at
least an additional 256 bits each time it transmits a data packet to
the CN. The impact of such addition is very significant on the
battery life. In fact, it has been shown in [EALDC] that wireless
transmission of a single bit can require over 1000 times more energy
than a single 32-bit computation.
Consequently, it would be more beneficial for the MN to avoid
transmitting extra bits over the air interface in exchange for some
additional computation only.
A second issue is the impact of packet size on the available
bandwidth. In fact, as wireless bandwidths have gained the solid
reputation of being always scarce, it would be of great importance to
monitor carefully how they are managed, especially when real time
multimedia applications are introduced on a larger scale.
Consequently, eliminating the extra bits added to each IP packet
header would also be highly beneficial for the network access
provider.
A third issue is related to privacy aspects. In fact, when
exchanging data traffic with the HA, the MN has to include its IPv6
home address (HoA) in each data packet sent to the HA, in addition to
its care-of address (CoA) (or its regional care-of address (RCoA)
when sending data packets to the MAP in addition to the on-link CoA
Haddad, et al. Expires September 10, 2009 [Page 5]
Internet-Draft IP Tunneling Optimization March 2009
(LCoA)). Similarly, the HA has to disclose the MN's HoA and CoA in
each data packet sent to the MN (or the RCoA and LCoA in each data
packet sent by the MAP to the MN). It follows that having the two
MN's addresses disclosed in the same data packet enables a malicious
node located on path between the MN and the HA or between the MN and
the MAP to easily identify, link and trace the MN's movements. Note
that the MN's privacy can be better protected if the traffic is
encrypted, which may not be always possible for various reasons.
When the RO mode is used, the tunneling mechanism applied between the
MN and the CN differs from the one used in the BT mode and HMIPv6
protocol in the fact that it adds only one additional IP address,
i.e., the MN's HoA, in each data packet exchanged between the two
endpoints. This means that each data packet sent/received by the MN
MUST carry three IP addresses instead of four: the MN's CoA, the CN's
address and the MN's HoA. For this purpose, the MN uses a Home
Address Option (HAO) to carry its HoA in each data packet sent to the
CN and the CN uses a Routing Header (RH) to carry the MN's HoA in
each data packet sent to the MN. The use of HAO and RH are in fact
degenerated tunnels as shown in [TUN]. This form of tunneling is
mandated as long as the MN's corresponding binding lifetime has not
expired.
The impact of the RO tunneling on the MN's privacy is the same as
described earlier in the BT mode and HMIPv6 protocol. The fact that
each data packet discloses the MN's HoA and CoA enables a malicious
node located on path between the two endpoints to identify, link and
trace the MN's movements across the Internet.
Note that using a PaT does not completely solve the privacy problem.
However, it offers a significant advantage in the fact that it
narrows the problem to the critical signaling messages, i.e., Binding
Update and Acknowledgment (BU/BA) in the case of BT and RO modes and
the Local BU (LBU) in the HMIPv6 case, where applying security
measures is not just an option. It follows that hiding/replacing the
HoA in and encrypting the PaT sent in the BU message are two measures
which can provide privacy protection for the MN against eavesdroppers
located on path between the MN and the CN/HA/MAP.
Haddad, et al. Expires September 10, 2009 [Page 6]
Internet-Draft IP Tunneling Optimization March 2009
4. Tunneling Optimization for BT mode and HMIPv6
TO mechanism addresses tunneling issues described earlier by keeping
the original packet size unmodified and removing the need for an
additional IP header.
TO mechanism is based on using a PaT to easily translate IP packets
headers to new ones which reflect the topologies of the new chosen
origin and destination. We limit the scope of the PaT in this
document to IPv6 addresses only but it is important to note that its
usefulness can also be expanded to translate content(s) of other
particular field(s). Another way to describe the PaT functionality
is to consider it as a mechanism which virtualizes the need for
explicit tunneling.
In order to better describe the suggested mechanism, we apply it to
the BT mode and describes the different steps required between the MN
and the HA to implement it. In case of HMIPv6 protocol, we note that
the same approach can be applied but with HMIPv6 specific signaling
messages and IPv6 addresses. After that, we apply the suggested
mechanism in the RO mode.
The BT mode starts after the MN switches to a foreign network. In
this case, the MN configures a new CoA and notifies its HA by
securely exchanging a BU and BA messages. After creating the binding
between the two MN's addresses, both nodes start tunneling data
packets between them. From the MN side, IP tunneling is applied on
each data packet sent to the HA by attaching an outer IP header which
contains the MN's CoA as source address and the HA's IP address as
destination address. The inner IP header carries the MN's HoA as
source address and the CN's address as destination address.
On the HA side, IP tunneling is applied on incoming data packets
(i.e., sent by the CN to the MN's HoA) by attaching to each packet an
outer which carries the MN and the HA IP addresses i.e., the source
address becomes the HA's address and the destination address is the
MN's CoA.
The data packet tunneling format on the MN and HA sides is as
follows:
<-- outer IPv6 header -> <-- inner IPv6 header ->
+----+--------+--------+ +----+--------+--------+ +------------
| | | | | | | | |
|oNAF| oSRC | oDEST | |iNAF| iSRC | iDEST | | iPAYLOAD
| | | | | | | | |
+----+--------+--------+ +----+--------+--------+ +------------
where:
Haddad, et al. Expires September 10, 2009 [Page 7]
Internet-Draft IP Tunneling Optimization March 2009
- NAF represents the non-address fields of an IPv6 header (I.e., the
first 8 octets of an IPv6 header)
- SRC is an IPv6 source address
- DEST is an IPv6 destination address
- EXT is zero or more IPv6 extension headers
- the prefix "o" means "outer"
In the HMIPv6 case, the MN attaches an outer header which contains
its LCoA as source address and the selected MAP's IP address as
destination address. The inner header contains the MN's RCoA as
source address and the CN's IP address as destination address.
Similarly, the MAP attaches an outer header to all data packets sent
by the CN to the MN's RCoA. The outer header is the same as the one
used by the MN but with the two addresses inverted.
The first step towards implementing the TO mechanism consists on
building the PaT at the MN's side. Since we limit the PaT
functionality in this document to the IP addresses only, the PaT will
consist on two different 128-bit translator parameters (TPs):
PaT = {TP_Source (TPS) , TP_Destination (TPD)}
In the BT mode, TPS and TPD are computed in the following way:
- TPS = oSrc_Addr XOR iSrc_Addr
Where:
- oSrc_Addr is the Outer header Source Address (CoA)
- iSrc_Addr is the Inner header Source Address (HoA)
- TPD = oDst_Addr XOR iDst_Addr
Where:
- oDst_Addr is the Outer header Destination Address (HA's IP address)
- iDst_Addr is the Inner header Destination Address (CN's IP address)
In HMIPv6 protocol, the PaT is computed in the same way as in the BT
mode but with using the appropriate IP addresses defined in HMIPv6:
- CoA = LCoA
- HoA = RCoA
- HA's IP address = MAP's IP address
The next step after building the PaT is to securely share it with the
HA or the MAP (i.e., HMIPv6 case). This is done by inserting the PaT
Haddad, et al. Expires September 10, 2009 [Page 8]
Internet-Draft IP Tunneling Optimization March 2009
components in two new options (called PaT Source (PaTS) and PaT
Destination (PaTD)) carried by the BU message. The two options MUST
be sent encrypted.
Another way to share the PaT would consist on using the BU message
(e.g., by setting a new bit) to request the HA to build the PaT. In
such case, the MN has to send the CN's IP address(es) in the BU
message. For privacy purpose, the CN's address SHOULD be sent
encrypted.
It follows from the above description, that each time the MN
configures a new CoA, it has to build a new PaT and send it in a BU/
LBU (i.e., with the new CoA/LCoA) to the HA/MAP.
If the MN is communicating with multiple CNs, then it SHOULD
configure one CoA per CN and build the corresponding PaT before
sending it to the HA. Such step is required in order to avoid any
confusion over which PaT to apply at the HA side on data packets sent
by the MN. The same requirement arises in the HMIPv6 case which
means that the MN has to configure one LCoA per CN, build the
corresponding PaT then send it to the MAP.
Consequently, the HA/MAP SHOULD create one entry in its BCE for each
MN's CoA/LCoA and SHOULD add the corresponding CN's IP address
together with the corresponding PaT.
Upon receiving a BU message carrying a PaT, the HA creates first a
binding between the two MN's addresses and stores them together with
the PaT in its binding cache entries (BCE) table. Then, the HA sends
back a BA message to the MN.
It follows that, when the MN has multiple CoAs, then the HA SHOULD
create one entry in its BCE for each MN's CoA and SHOULD add the
corresponding CN's IP address to the MN's addresses and the
corresponding PaT.
Similarly, in an HMIPv6 domain, the MN sends the PaT encrypted in the
LBU message to its MAP and waits for the BA message before applying
the PaT on data packets.
After creating the binding and sharing the PaT with the HA/MAP, the
MN applies it on each data packet sent to the CN (i.e., via the HA/
MAP) and on each data packet received from the HA/MAP. The HA/MAP
applies the PaT on each data packet received from the MN before
sending it to the CN and on each data packet sent by the CN to the
MN's HoA/RCoA before sending it to the MN.
When the MN needs to send a data packet to the CN, it applies the PaT
on the IP header in the following way (Eq. 1):
- Src_Addr = iSrc_Addr XOR TPS
- Dst_Addr = iDst_Addr XOR TPD
Haddad, et al. Expires September 10, 2009 [Page 9]
Internet-Draft IP Tunneling Optimization March 2009
Where Src_Addr is the source address disclosed in the IP header and
Dst_Addr is the destination address used in the IP header. It
becomes obvious at this stage that the Src_Addr is the MN's CoA (or
LCoA in HMIPv6) and the Dst_Addr is the HA's IP address (or MAP's IP
address in HMIPv6).
When the HA/MAP receives a data packet from the MN, it retrieves the
corresponding PaT on the IP header and translates the IP addresses to
new ones. Since the PaT used by the HA is the same as the one used
by the MN and the required operation is only a XOR, then the
resulting IP addresses are the ones used as iSrc_Addr and iDst_Addr
in (Eq. 1). This means:
- nSrc_Addr = Src_Addr XOR TPS (= iSrc_Addr)
- nDst_Addr = Dst_Addr XOR TPD (= iDst_Addr)
Where the nSrc_Addr is the new IP source address and nDst_Addr is the
new IP destination address used in the data packet sent by the HA to
the CN.
Similarly, when the CN sends a data packet to the MN's HoA, the HA/
MAP applies the MN's corresponding PaT to the IP packet header and
translates the two IP addresses to new ones before sending the data
packet to the MN.
Finally, when the MN gets a data packet from its HA/MAP, it checks
first if the data packet is encapsulated or not. In the latter case,
the MN applies the PaT to the IP packet header. Otherwise, the MN
follows the BT mode to process the packet.
Note that in the current design, the HA SHOULD always tunnel any new
data packet sent by a new CN according to the BT mode rules and
SHOULD NOT apply any PaT until it receives one from the MN. However,
further optimizations are possible and will be introduced in future
version of this document.
Haddad, et al. Expires September 10, 2009 [Page 10]
Internet-Draft IP Tunneling Optimization March 2009
5. Tunneling Optimization for RO mode
As mentioned earlier, MIPv6 RO mode uses a different form of IP
tunnel between the two endpoints (i.e., MN and CN) than the one used
in the BT mode (i.e., between the MN and its HA). The modified IP
tunnel discloses three IP addresses to the receiver and is used by
both sides when exchanging data packets. Consequently, the TO
mechanism requires a slight modification in order to adapt it to the
degenerated tunnel used in the RO mode.
For this purpose, when the RO mode is used, the PaT components SHOULD
be computed by both endpoints in the following way:
- TPS = CoA XOR HoA
- TPD = 0000:0000:0000:0000:0000:0000:0000:0000
Where the CoA and HoA are the MN's IP addresses. Note that when the
RO mode is used, the MN does not need to send the PaT in the BU
message since the CN can build it. However, the MN SHOULD send an
explicit request to the CN to check if both endpoints can use the PaT
when exchanging data packets. For this purpose, the request consists
on setting a new bit in the BU message sent by the MN to the CN and
getting an explicit acknowledgment to the request from the CN in the
BA message. If the CN is able to use the PaT, then it SHOULD set a
new bit in the BA message. Otherwise, it can only send the BA
message without any further action.
It follows from the above, that each time the MN needs to send a data
packet to the CN following the RO mode rules, it SHOULD apply the PaT
to the IP packet header in order to translate it to the right IP
address, i.e., the MN's CoA. The same rule applies when receiving a
data packet from the CN (i.e., sent to the MN's CoA). On the CN
side, the PaT is applied each time a data packet needs to be sent to
the MN or each time a data packet is received from the MN.
It should be noted that when the RO mode is in use, the PaT can be
applied only as long as the MN's CoA binding lifetime has not
expired. In addition, the MN SHOULD set the PaT bit in each BU
message sent to the CN as long as it prefers to use the TO mechanism
during the ongoing session. This also means that a new PaT needs to
be built after each BU message carrying a new CoA.
Haddad, et al. Expires September 10, 2009 [Page 11]
Internet-Draft IP Tunneling Optimization March 2009
6. Tunneling Optimization for DSMIPv6
TBD
Haddad, et al. Expires September 10, 2009 [Page 12]
Internet-Draft IP Tunneling Optimization March 2009
7. Bit and Options Formats
TBD
Haddad, et al. Expires September 10, 2009 [Page 13]
Internet-Draft IP Tunneling Optimization March 2009
8. Security Considerations
This memo describes a TO mechanism which is mainly used to avoid
explicit IP tunneling in mobility protocols.
The proposed mechanism enhances the MN's privacy by removing the need
to disclose the MN's two IP addresses in the same data packet.
Consequently, it simplifies and narrows the privacy problem in a
mobile environment.
In the current memo, the PaT is only applied on the IPv6 addresses
and as such it does not create nor amplify any new or existing
threats.
Haddad, et al. Expires September 10, 2009 [Page 14]
Internet-Draft IP Tunneling Optimization March 2009
9. Acknowledgments
The authors would like to thank Laurent Marchand, Conny Larsson,
Shinta Sugimoto, Suresh Krishnan, Hesham Soliman and George Tsirtsis
for their valuable comments.
Haddad, et al. Expires September 10, 2009 [Page 15]
Internet-Draft IP Tunneling Optimization March 2009
10. References
10.1. Normative References
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
for IPv6", RFC 3775, June 2004.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
10.2. Informative References
[EALDC] Barr, K. and K. Asanovic, "Energy-Aware Lossless Data
Compression", ACM Transactions Computer Systems,
August 2006.
[FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 5268,
March 2007.
[HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier,
"Hierarchical Mobile IPv6", RFC 5380, October 2008.
[PMIPv6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[TUN] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", Internet
Draft, draft-deering-ipv6-encap-addr-deletion-00.txt,
November 2001.
Haddad, et al. Expires September 10, 2009 [Page 16]
Internet-Draft IP Tunneling Optimization March 2009
Authors' Addresses
Wassim Haddad
USA
Phone: +1 646 2568041
Email: wmhaddad@gmail.com
Mats Naslund
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 58533739
Email: Mats.Naslund@ericsson.com
Pekka Nikander
Ericsson Research Nomadic Lab
Jorvas FI-02420
Finland
Phone: +358 9 299 1
Email: Pekka.Nikander@nomadiclab.com
Haddad, et al. Expires September 10, 2009 [Page 17]