One document matched: draft-weniger-rota-00.txt
MobOpts Research Group K. Weniger
Internet-Draft T. Aramaki
Expires: January 12, 2006 Panasonic
July 11, 2005
Route Optimization and Location Privacy using Tunneling Agents (ROTA)
draft-weniger-rota-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Mobile IPv6 can either provide route optimization or location privacy
from CN by using Bi-directional Tunneling mode. Especially when
mobile node is far away from home or when correspondent node is
mobile as well, the route in Bi-directional Tunneling mode is far
from optimal. This memo describes an optional extension to Mobile
IPv6 providing location privacy and route optimization at the same
time. To achieve this, the overlay route in Mobile IPv6 Bi-
directional Tunneling mode is optimized by switching tunnel end-
Weniger & Aramaki Expires January 12, 2006 [Page 1]
Internet-Draft MIPv6 ROTA July 2005
points to so-called Tunneling Agents in an on-demand manner.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction and Problem Description . . . . . . . . . . . . . 5
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Problem Statement . . . . . . . . . . . . . . . . . . . . 5
2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of ROTA . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 The ROTA approach . . . . . . . . . . . . . . . . . . . . 7
3.2 Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
3.3 Exemplary Signaling Flow . . . . . . . . . . . . . . . . . 10
3.4 Security Issues . . . . . . . . . . . . . . . . . . . . . 12
3.4.1 Address Stealing . . . . . . . . . . . . . . . . . . . 12
3.4.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . 13
3.4.3 Denial of Service (DoS) Attacks . . . . . . . . . . . 13
3.4.4 Other Attacks on Sending Binding Information . . . . . 15
3.4.5 Attacks against Location Privacy . . . . . . . . . . . 15
3.4.6 Overlay Re-routing Attacks . . . . . . . . . . . . . . 15
3.5 Support of Stationary Correspondent Nodes . . . . . . . . 15
3.6 Comparison to other approaches . . . . . . . . . . . . . . 16
4. New Message Types . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Message Headers . . . . . . . . . . . . . . . . . . . . . 18
4.1.1 ROTA Request/Notification . . . . . . . . . . . . . . 18
4.1.2 ROTA Reply/Acknowledgement . . . . . . . . . . . . . . 20
4.1.3 ROTA Distance Information . . . . . . . . . . . . . . 22
5. Modified Mobile Node Operation . . . . . . . . . . . . . . . . 25
5.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 25
5.2 ROTA Initiation . . . . . . . . . . . . . . . . . . . . . 25
5.3 Sending Reverse Tunneled Packets . . . . . . . . . . . . . 25
5.4 Tunnel Management . . . . . . . . . . . . . . . . . . . . 25
6. Modified Home Agent Operation . . . . . . . . . . . . . . . . 27
6.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 27
6.2 ROTA Initiation . . . . . . . . . . . . . . . . . . . . . 28
6.3 Sending ROTA Request . . . . . . . . . . . . . . . . . . . 28
6.4 Receiving ROTA Request and Sending ROTA Reply . . . . . . 28
6.5 Receiving ROTA Reply . . . . . . . . . . . . . . . . . . . 29
6.6 Sending Binding Updates . . . . . . . . . . . . . . . . . 29
6.7 Receiving Binding Updates . . . . . . . . . . . . . . . . 29
6.8 Distance Measurements and TA selection . . . . . . . . . . 29
6.9 Tunnel Management . . . . . . . . . . . . . . . . . . . . 30
6.10 Intercepting Packets . . . . . . . . . . . . . . . . . . . 30
6.11 Sending and Receiving Reverse Tunneled Packets . . . . . . 30
6.12 Management of ROTA HA Cache Entries . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Weniger & Aramaki Expires January 12, 2006 [Page 2]
Internet-Draft MIPv6 ROTA July 2005
9.1 Normative References . . . . . . . . . . . . . . . . . . . 34
9.2 Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35
A. Discussion of Further Optimizations . . . . . . . . . . . . . 37
B. MN-controlled ROTA . . . . . . . . . . . . . . . . . . . . . . 39
B.1 Exemplary Signaling Flow . . . . . . . . . . . . . . . . . 39
B.2 Security Issues . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 42
Weniger & Aramaki Expires January 12, 2006 [Page 3]
Internet-Draft MIPv6 ROTA July 2005
1. Terminology
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 [1].
In addition to the terminology used in [4], the following acronyms
are used:
+---------------------------------+---------------------------------+
| Acronym | Meaning |
+---------------------------------+---------------------------------+
| MN | Mobile Node |
| | |
| CN | Correspondent Node |
| | |
| HA | Home Agent |
| | |
| HoA | Home Address |
| | |
| CoA | Care-of Address |
| | |
| BU | Binding Update |
| | |
| BA | Binding Acknowledgement |
| | |
| Tunneling Agent (TA) (of node | Logical entity that is a tunnel |
| X) | endpoint for node X on behalf |
| | of node X's HA, with node X's |
| | HoA matching a subnet prefix of |
| | node X's HA, but not matching a |
| | subnet prefix of the TA. Note |
| | that a TA and an HA are two |
| | different logical entities, but |
| | may be deployed in one physical |
| | box (with both entities serving |
| | different nodes). |
+---------------------------------+---------------------------------+
Weniger & Aramaki Expires January 12, 2006 [Page 4]
Internet-Draft MIPv6 ROTA July 2005
2. Introduction and Problem Description
2.1 Background
Location privacy is the ability to hide the location from others.
This is considered to be an important feature for mobile users, since
the disclosure of the location can have serious impacts on the user's
life. Since the routing in the Internet is hierarchical, globally
routable IP addresses contain location information. Moreover,
protocol extensions, e.g., to DNS as well as software tools exist
that can be used to derive the approximate geographic location from a
globally routable IP address [11][8].
In Mobile IPv6 [4], HoA and CoA represent identity and location of
the MN, respectively. Currently, two modes are defined in [4]: Bi-
directional Tunneling and Route Optimization. While the former mode
requires all data packets to be routed over the home agent of the MN,
the latter utilizes the direct path between MN and CN. As a
consequence, Route Optimization mode usually reduces the packet
delay, which is beneficial for interactive applications. However, it
does not provide location privacy, i.e., the CN knows the CoA and,
thus, the topological location of the MN. In contrast, Bi-
directional Tunneling mode does not reveal the CoA to CN, since BU
messages and data packets are sent to the HA. Thus, MN's location is
hidden from CN. However, Bi-directional Tunneling may lead to long
routes, especially if CN is mobile as well. Since interactive
communications between mobile nodes is considered to be a common case
in the future (e.g., VoIP), the utilization of Bi-directional
Tunneling mode for location privacy-enabled communication may be
inefficient and may delay packets to an extend that is harmful to
interactive communications. Hence, a mechanism that provides both
location privacy and route optimization, resulting in higher
efficiency and lower packet delays than Bi-directional Tunneling
mode, is desirable.
2.2 Problem Statement
The first part of the problem to be solved by the mechanism described
in this memo is to provide location privacy to mobile nodes. In the
context of location privacy for Mobile IPv6, two problems are
considered to be the most important: preventing the disclosure of the
CoA to CN and preventing the disclosure of the HoA to eavesdropper
[8]. While the majority of currently discussed mechanisms address
the second problem, ROTA addresses the first one, i.e., the
disclosure of the CoA to CN. Solutions for the second problem can
prevent profiling of users based on their IP address, e.g., by
replacing the HoA with a privacy label [9]. Other aspects of privacy
not directly related to Mobile IPv6 addresses, such as the profiling
Weniger & Aramaki Expires January 12, 2006 [Page 5]
Internet-Draft MIPv6 ROTA July 2005
based on lower- or upper-layer identities or based on protocol values
[10] are out of the scope of this document.
A second part of the problem is to provide route optimization also
for privacy-enabled communication sessions. In Mobile IPv6, the Bi-
directional Tunneling mode can provide location privacy, since it can
prevent the disclosure of the CoA to CN (see section 2.1 of [9]).
However, in many scenarios Bi-directional Tunneling mode results in
long routes and thus may be problematic for delay-sensitive
applications such as VoIP. This is becoming even worse if CN is a
mobile node too. The route optimization does not need to be optimal,
but it must be good enough to support interactive applications.
Another issue to be considered is deployment. If a solution requires
support from visited network infrastructure (e.g., ARs of MN and CN),
every visited network must support this solution. Otherwise either
the communication session itself or the privacy support between MNs
breaks when one of the MNs moves to a network without location
privacy support. However, global universal deployment is very
difficult to achieve. Hence, the ROTA approach does not rely on
visited network support, but is able to benefit from it if available.
In summary, the problem ROTA tackles is hiding MN's CoA from CN and
providing route optimization at the same time without requiring
support from visited networks. The solution shall not create any
significant new security problems in comparison to Mobile IPv6/IPv6.
2.3 Assumptions
In this version of ROTA, it is assumed that only MN's HA and CN's HA
may act as Tunnel Agent (TA) for MN or CN, respectively. MN's HA and
CN's HA exchange binding and distance information to determine the
TA(s) to be used as tunnel endpoints. The HAs act on behalf of MN
and CN to ensure location privacy and ease authentication and
authorization. However, if a mobile node is at home, it must be able
to reverse tunnel data packets to its HA in order to support ROTA.
Support for stationary CNs is discussed in Section 3.5
To allow a large scale deployment, no pre-established trust
relationship is required between MN/CN and TA or between MN and CN,
respectively. Also, no "global PKI" is assumed, i.e., MN and CN
shall not require public/private key pairs or host certificates.
Instead, only MN's HA and CN's HA and TAs require trust
relationships, e.g., indirectly established with public/private key
pairs and X.509v3 certificates [3]. Those can for instance be pre-
assigned by the corresponding Mobility Service Provider.
Weniger & Aramaki Expires January 12, 2006 [Page 6]
Internet-Draft MIPv6 ROTA July 2005
3. Overview of ROTA
3.1 The ROTA approach
ROTA is an extension to Mobile IPv6 that optimizes the path between
two mobile nodes in case of Bi-directional Tunneling mode in order to
achieve route optimization and location privacy (i.e., hiding the CoA
from CN) at the same time. The basic idea is to separate the packet
interception and Bi-directional Tunneling mode functionality of an HA
and allow the tunneling functionality for a specific node to reside
on external entities, such as other HAs. This external entity is
then serving as a Tunneling Agent (TA) for a node, whose HoA does not
match the subnet prefix of this HA. Most of the procedure is
controlled by MN's HA and CN's HA, e.g., they send and receive
binding and distance information to determine and configure the TA(s)
to be used as tunnel endpoints.
In this version of ROTA, only MN's HA and CN's HA may act as TA for
MN or CN, respectively. Thus, support from visited network
infrastructure is not required, which significantly eases deployment
of ROTA. However, the route becomes less optimal when both MN and CN
move far away from their home, respectively. Further route
optimization is possible by leveraging TAs in visited networks, if
available. The details of this issue are left for future work.
Establishing binding information and tunneling functionality between
MN and TA in a secure manner is required for ROTA to work securely.
However, it is not assumed that a pre-arranged trust relationship
between TA and MN exists. ROTA only requires HAs to maintain trust
relationships with other HAs and TAs. This can be achieved for
example by using private/public key pairs and certificates. No host
certificates and global PKI are required in this case, which is
considered more scalable in terms of deployment than requiring all
MNs and/or CNs to maintain trust relationships with each other.
ROTA provides further benefits over Route Optimization mode by being
able to utilize stronger authentication and authorization mechanisms
than the Return Routability procedure and by requiring those only to
be performed between entities within the network, i.e., not involving
MN or CN. Hence, longer binding lifetimes can be used, BU message
can be sent less often, and temporary unavailabilities of the HA
result in no or less loss of data packets. Moreover, since no end-
to-end signaling is necessary on every movement, the handover latency
as well as the signaling overhead over the air may be lower than in
Route Optimization mode.
Weniger & Aramaki Expires January 12, 2006 [Page 7]
Internet-Draft MIPv6 ROTA July 2005
3.2 Basic Operation
In the following it is assumed that a communication session between
MN and a mobile CN has already started, that Mobile IPv6 is in Bi-
directional Tunneling mode, and that MN and CN have different home
links. Figure 1 shows the data path between MN and CN with MN and CN
both being in a foreign network. The MN reverse tunnels all data
packets (addressed to CN's HoA) to its HA, which decapsulates and
forwards them. The routing infrastructure routes the packets to CN's
home network, where CN's HA intercepts and tunnels them to CN's CoA.
Data packets in the other direction are handled accordingly. It is
obvious that the route between MN and CN is far from optimal in this
case and in many other cases. In general, the further MN and/or CN
are away from home, the less optimal the route is.
------------ .. ... .. ------------
|Site 1 | . . . .. |Site 2 |
| |.. .| |
| MN's HA | | CN |
| /|\\\ | | /|\ |
----|||---\\ -///--------
||| .. \\ /// ..
----|||----- \\-------///-
| \|/ | | \\ \|/ |
| MN |.. | CN's HA |
| | . | | ||| tunneled
|Site 3 | .. |Site 4 | || not tunneled
------------ .------------
Figure 1: Data path between MN and CN in Bi-directional Tunneling
mode
The basic idea of ROTA is to switch tunnels to TAs to shorten the
route between MN and CN. Figure 2 shows the data path between MN and
CN when CN's HA and MN's HA act as TA for MN and CN, respectively.
As can be seen, the route is shorter than in Figure 1. A
disadvantage is that the route is asymmetric.
Weniger & Aramaki Expires January 12, 2006 [Page 8]
Internet-Draft MIPv6 ROTA July 2005
------------ .. ... .. ------------
|Site 1 | . . . .. |Site 2 |
| /--------------------- |
| MN's HA-------------------- CN |
| |||\---------------------/|\ |
----|||----- -///--------
||| .. /// ..
---|||----- --------///-
| \|/--------------\ /// |
| MN ------------CN's HA |
| --------------/ | ||| tunneled
|Site 3 | .. |Site 4 | || not tunneled
------------ .------------
Figure 2: Data path between MN and CN with CN's HA and MN's HA being
TA for MN and CN, respectively
The route is shorter and symmetric if only one of the HAs serves as
TA. In Figure 3 only CN's HA is TA, i.e., MN reverse tunnels all
data packets addressed to CN's HoA to CN's HA and CN's HA tunnels all
data packets addressed to MN's HoA to MN's CoA.
------------ .. ... .. ------------
|Site 1 | . . . .. |Site 2 |
| |.. .| |
| MN's HA | | CN |
| | | /|\ |
------------ -///--------
.. /// ..
----------- --------///-
| /-------------\ \|/ |
| MN ------------CN's HA |
| \-------------/ | ||| tunneled
|Site 3 | .. |Site 4 | || not tunneled
------------ .------------
Figure 3: Data path between MN and CN with only CN's HA being TA
Note that the TA only serves as a tunnel endpoint on behalf of MN's
HA. Proxy Neighbor Advertisements to intercept data packets from
other CNs are still only sent by MN's HA. Hence, the home link of MN
does not change.
In the following, the basic operation of the ROTA protocol is
described. The general procedure can be divided in the following
Weniger & Aramaki Expires January 12, 2006 [Page 9]
Internet-Draft MIPv6 ROTA July 2005
steps:
o Initiation of ROTA, which comprises requesting ROTA and, if not
already known, discovering CN's HA address.
o Exchanging binding information between MN's and CN's HA.
o Determining distances between MN's HA, CN's HA, MN, and CN.
o Selecting TA(s) that provide(s) the shortest route.
o Requesting tunnel establishment from new tunnel entry-point(s) and
notifying corresponding tunnel exit-point(s).
Additionally, some kind of security association between MN's HA and
CN's HA must be established to provide message authentication and
integrity protection of signaling messages.
3.3 Exemplary Signaling Flow
The basic operation of ROTA is explained by means of an exemplary
signaling flow (see Figure 4) resulting in the scenario shown in
Figure 3, i.e., CN's HA as TA for MN.
First, the MN may send an ROTA Initiation Request message containing
CN's and MN's HoA to its HA to trigger ROTA initiation.
Alternatively, ROTA initiation can also be triggered by the HA
itself, e.g., after first data packets from/to CN's HoA were
tunneled. MN's HA initiates ROTA by sending an ROTA Request message
to CN's HA. If CN's HA address is unknown, it first must be
discovered. This can for instance be done by utilizing a modified
DHAAD procedure, by the use of DNS, or by sending the ROTA Request
message to CN's HoA and enabling CN's HA to intercept the message.
If CN's HA supports and accepts ROTA, it sends an ROTA Initiation
Request to CN, which may accept or reject ROTA by sending a
corresponding ROTA Initiation Reply message. Then, CN's HA sends a
ROTA Reply message back to MN's HA. If there is no (or nearly
expiring) security association between MN's HA and CN's HA for
message authentication and integrity protection, additional steps or
embedded information elements may be needed to create (maintain) it,
e.g., using IKE/IKEv2 [17] [18]. This includes authentication and
authorization of both parties, e.g., using private/public key pairs
and certificates (see Section 3.4). Subsequently, both HAs exchange
BU messages, determine the distances to MN and CN, and exchange those
in Distance Information messages.
The metric for the distances could be hops or delay. The distances
Weniger & Aramaki Expires January 12, 2006 [Page 10]
Internet-Draft MIPv6 ROTA July 2005
in hops between CN's HA and CN as well as MN's HA and MN can
passively be acquired from the routing table, from previously
received signaling messages or tunneled data packets. Some distant
measurements might not be necessary if pre-assigned distance values,
e.g., between roaming partners exist. The distances between CN's HA
and MN as well as MN's HA and CN can be measured with active probing.
The specification of probe messages and a mechanism to securely
measure the distance with active probing is left for future work.
Subsequently, the HAs can determine the current route length between
MN and CN as well as the route length when MN's HA and/or CN's HA
were TA(s) and thus can select the best TA(s) in terms of route
optimization, if route optimization is necessary. Finally, Tunnel
Establishment Request messages are sent to the new tunnel entry-
point(s) (here: MN) to set up a tunnel. Additionally, Tunnel
Establishment Notification messages may need to be sent to inform new
tunnel exit-points about new tunnel entry-points to allow them to
perform a check on the source address of incoming tunneled data
packets as described in [4].
+--+ +-------+ +-------+ +--+
|MN| |MN's HA| |CN's HA| |CN|
+--+ +-------+ +-------+ +--+
| ROTA_init_req | | |
|-------------------->| ROTA_req | |
| |-------------------->| ROTA_init_req |
| | |-------------------->|
| | | ROTA_init_rep |
| | ROTA_rep |<--------------------|
| ROTA_init_rep |<--------------------| |
|<--------------------| BU | |
| |-------------------->| |
| | BA+BU | |
| |<--------------------| |
| | BA+dist_info | |
| |-------------------->| |
| | dist_ack+dist_info | |
| |<--------------------| |
| | dist_info_ack | |
| |<--------------------| |
| tun_estbl_req | | |
|<--------------------| | |
| tun_estbl_rep | | |
|-------------------->| | |
Figure 4: Example of signaling flow
Weniger & Aramaki Expires January 12, 2006 [Page 11]
Internet-Draft MIPv6 ROTA July 2005
To adapt the route after movements, the distance measurements SHOULD
be repeated, e.g., periodically or after every nth handover of MN or
CN. If the new distance information results in a new TA providing a
shorter route, Tunnel Establishment/Notification messages MAY be sent
to adapt the route. To minimize packet loss, new tunnels should be
set up before the old tunnels are deleted.
3.4 Security Issues
The major challenge is to provide a secure operation. Different
issues have to be considered here. Although the details of a
solution is left for future work, a short discussion of attacks and
possible countermeasures is given in the following. Most attacks are
taken from [19], which describes them in more detail in the context
of Mobile IPv6 Route Optimization mode.
3.4.1 Address Stealing
A serious attack is the injection of false binding information in a
correspondent node, since this allows an attacker to steal a victim's
traffic by redirecting it to itself or a node under its control,
e.g., to analyze or tamper the traffic. Note that this attack
affects mobile nodes as well as stationary node, since addresses used
by stationary nodes are not distinguishable from addressed used by
mobile nodes. This attack is especially serious in case of ROTA,
since binding information is sent to potential Internet router (here:
HA acting as TA). To prevent such attacks, data origin
authentication and integrity protection for BU messages are required
and the sender of a BU message must be authorized to inject a
specific binding.
Data origin authentication can be achieved with sender address
ownership proof, e.g., with public/private keys and X.509v3
certificates [3]: The certificate binds the public key to the sender
address. Alternatively, Cryptographically Generated Addresses (CGA)
[7] could be used to bind the public key to the sender address. BU
messages from MN's HA to CN's HA must be sent integrity protected,
e.g., by using a beforehand with IKE/IKEv2 [17] [18] established
IPsec ESP [16] SA.
Authentication of BU messages sent from MN to its HA and
authorization of MN to use a particular HoA in the BU message is
achieved by linking the HoA to a specific IPsec security association,
as described in [4]. However, the CoA in the BU message is not
checked for correctness. As discussed in [4], it is assume that "an
HA can always identify an ill-behaving MN", which "allows the
operator to discontinue MN's service" (see section 15.3 in [4]). An
option giving a higher level of security would be to conduct
Weniger & Aramaki Expires January 12, 2006 [Page 12]
Internet-Draft MIPv6 ROTA July 2005
additional CoA tests, e.g., as described in [20].
BU messages sent from HA to TA can be authenticated with IPsec as
well. The HoA in BU messages can be authorized with certificates:
every certificate contains the set of subnet prefixes that the
corresponding HA is allowed to serve (not as TA, but as HA), e.g., in
an IP address extension [5]. This is similar to the approach taken
by SEND [6], where certificates contain prefixes a router may
advertise. Besides verifying the signature, a TA receiving a BU from
an HA compares the prefix of the HoA in the BU message to the set of
home subnet prefixes contained in the certificate of the sender HA.
Only if the prefixes match, the BU is accepted by the TA. Note that
in contrast to SEND [6], MN and CN do not require additional pre-
configuration, such as a shared trusted anchors, since they are not
involved in the verification of digital signatures. The CoA cannot
be checked by certificates. Instead, an ill-behaving MN must be
identified as such and the corresponding HA must be notified, which
then can discontinue the service. Alternatively, CoA tests can be
introduced.
3.4.2 Replay Attacks
Even with the measures discussed above, an attacker could redirect
traffic by eavesdropping a valid BU message and re-sending it later.
Such replay attacks can be prevented when the freshness of received
signaling messages can be determined by the receiver, e.g., using
(integrity protected) nonces or sequence numbers. IPsec can provide
replay protection. For other cases, ROTA messages include 16-bit
sequence numbers.
3.4.3 Denial of Service (DoS) Attacks
3.4.3.1 Reflection
The introduction of false binding information in another node's
Binding Cache, either with false CoA or false HoA, also enables DoS
attacks. For instance, an attacker could mount a DoS attack by
redirecting traffic to a victim that cannot handle the amount of
traffic, e.g., because it has a low-bandwidth Internet connection or
because many traffic flows are redirected to one victim. Since the
node that redirects all the traffic acts as reflector, such attacks
are also called reflection attacks. Another related DoS attack
redirects all traffic to a non-existent address. Those attacks can
be prevented by the measures described in section Section 3.4.1.
3.4.3.2 Amplification
Amplification can make reflection attacks even more dangerous. If an
Weniger & Aramaki Expires January 12, 2006 [Page 13]
Internet-Draft MIPv6 ROTA July 2005
attacker sends protocol packets with a spoofed source address to a
node and this node answers with a higher amount of protocol packets
or larger protocol packets, a victim node having the spoofed source
address can be flooded with unwanted protocol packets. Thus, a well-
designed protocol should ensure that requests, especially those
without data origin authentication, are always replied with a single
packet of about the same or less size and are sent to the sender
address of the request.
3.4.3.3 Memory Exhaustion
Other DoS attacks which should be prevented are memory exhaustion
attacks, i.e., an attack achieving the consumption of all memory
resources of a victim by sending special sequences of protocol
packets. To prevent such kind of attacks, no state should be
established in HAs before the initiator of ROTA has proven to be
authorized to do so. If IKE is used to establish an IPsec SA between
HAs/TAs in the first place, this requirement can be achieved.
3.4.3.4 CPU Exhaustion
On the other hand, digital signature verification can require
significant CPU resources, which can be exploited for another type of
attack, the CPU exhaustions attack. Though this attack only affects
HAs, since MNs are not required to perform computationally expensive
operations in ROTA, the attack would be especially dangerous if one
attacker would send multiple signed ROTA Requests with spoofed source
address.
Data origin authentication without using computationally expensive
public key cryptography can alleviate this problem. Such a weak
"pre-authentication" is for instance be done by IKEv2 or in [21]
using cookies. If IKE is not used, another weak countermeasure could
be to first verify the certificate after receiving a positive ROTA
Initiation Reply from CN. CN additionally checks, whether it has an
active communication session with the MN's HoA contained in the ROTA
Request, e.g., by checking its IPv6 Destination Cache. This way, the
attacker needs to have knowledge about active communication sessions
of CN.
Additionally, a limit on the amount of resources used for
verifications should be set. This approach is also used as a
countermeasure for a similar attack ("Inducing unnecessary binding
updates") against the Mobile IPv6 Route Optimization mode (see
section 3.3.1 in [19]).
Weniger & Aramaki Expires January 12, 2006 [Page 14]
Internet-Draft MIPv6 ROTA July 2005
3.4.4 Other Attacks on Sending Binding Information
Other attacks are described [19] such as blocking of BU messages or
forcing non-optimized bindings are considered less severe and are
applicable to both ROTA and Route Optimization mode. Hence they are
not discussed in this memo.
3.4.5 Attacks against Location Privacy
To provide location privacy, an attacker MUST NOT be able to
successfully pretend to be a TA. Otherwise it could find out MN's
CoA and thus its location. For this reason, the receiver of the BU
message must prove to MN's HA that it is a valid TA, i.e., it must be
authorized to act as a TA. Also, the TA must be trustworthy, i.e.,
it may not be under control of an attacker. A simple solution would
be to maintain a list of addresses of trusted TAs in every HA. A
more convenient, secure and scalable solution would be to use
authorization certificates, which can be verified when a shared
trusted anchor exists. This approach is again similar to SEND [6],
where certificates are used to authorize routers to act as routers.
Note that MNs do not require a certificate. In contrast to SEND,
they even don't need to be configured with a shared trusted anchor.
Also note that hiding the HoA to eavesdroppers might be possible with
ROTA as well by encrypting signaling and data traffic on all IPsec
tunnel segments, as described in [9] for the MN-HA segment. However,
this approach is computationally expensive for the HAs since the
packet payload is encrypted as well. Other approaches, which only
replace the HoA with a privacy label [9] seem more appropriate and
can be combined with ROTA. Hence, this topic is for future study.
3.4.6 Overlay Re-routing Attacks
Since the optimized overlay route depends on information in Probe and
Distance Information messages, those messages must be sent
authenticated and integrity protected. Otherwise an attacker may be
able to change the overlay route in way that is of benefit for him,
e.g., to eavesdrop traffic.
3.5 Support of Stationary Correspondent Nodes
MN's HA and CN's HA exchange binding and distance information to
determine the TA(s) to be used as tunnel endpoints. They act on
behalf of MN and CN to ensure location privacy and thus can be called
Privacy Agents (PA) of MN and CN, respectively. However, a
stationary CN does usually not have a trust relationship to an HA.
ROTA-aware stationary CNs require a pre-arranged trust relationship
Weniger & Aramaki Expires January 12, 2006 [Page 15]
Internet-Draft MIPv6 ROTA July 2005
to a PA. Additionally, the PA must have a trust relationship with
other HAs, both established for example by means of certificate and
private/public key pair. Of course, a stationary CN does not require
a second address (i.e., CoA). Hence, the PA does not serve as an HA
and does not manage a binding or intercept any packets for the
stationary node. Instead, it executes the ROTA protocol with MN's HA
to prevent the disclosure of MN's CoA to the stationary CN.
Furthermore, the PA must be able to act as TA and the stationary CN
must be able to reverse tunnel data packets to its PA.
The PA service could, e.g., be provided by CN's ISP or by a dedicated
Privacy Service Provider. It could also be provided by a Mobility
Service Provider with the PA co-located with an HA. However,
topologically the PA should not be too far away from the stationary
node to support good route optimization. The details of supporting
stationary CNs is left for future work.
Note that in comparison to scenarios with mobile CNs, the route in
Bi-directional Tunneling mode in case of stationary CNs is usually
much shorter. Hence, standard Bi-directional Tunneling mode used
with ROTA-unaware CNs may provide short enough routes for supporting
interactive applications in many scenarios.
3.6 Comparison to other approaches
Various protocols have been proposed, which could be used to provide
route optimization and location privacy at the same time, e.g., [15]
[12] [13] [14]. Although similarities to ROTA exist, some of the
protocols have been developed for other purposes and have
deficiencies with respect to the given assumptions, such as requiring
universal deployment of modified (access) routers or only providing
uni-directional location privacy (i.e., only for MN or CN, not both)
or limited location privacy (i.e., a topological area is known, which
contains MN's location). Also, in contrast to [14], the home network
is not distributed in the Internet. Thus, the Neighbor Discovery
operation of HAs does not need to be modified or replaced and ROTA
has no impact on the routing system of the Internet. Furthermore, no
additional CoA is assigned to the MN and no "double encapsulation" is
required, as in [13].
With the bootstrapping approaches currently discussed in MIP6 WG,
route optimization and location privacy could be achieved as well by
Bi-directional Tunneling and the dynamic allocation of a new home
link to the MN, which is close to the current MN's location. But to
prevent communication sessions from being broken, a new home link can
only be assigned at the beginning of a new communication session.
Moreover, dynamic DNS updates might be necessary to ensure IP
reachability. In contrast, ROTA does not change the home link in
Weniger & Aramaki Expires January 12, 2006 [Page 16]
Internet-Draft MIPv6 ROTA July 2005
order to achieve route optimization. Hence it supports static HoAs
for the use as long-term identifiers over many subsequent
communication session regardless of the location of the MN and
dynamic DNS updates are not necessary. Moreover, route optimization
is possible during a communication session, which is especially
beneficial if MN/CN are traveling topological large distances during
a session, e.g., because of vertical handovers.
Weniger & Aramaki Expires January 12, 2006 [Page 17]
Internet-Draft MIPv6 ROTA July 2005
4. New Message Types
One possible realization of the ROTA protocol messages is to
introduce new Mobility Header Types. An example of this realization
is described in the following.
4.1 Message Headers
4.1.1 ROTA Request/Notification
The ROTA Request/Notification Message is the general request and
notification message of ROTA. It contains a Message Type field to
distinguish different ROTA Request/Notification messages. The MH
type is TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Msg Type
Weniger & Aramaki Expires January 12, 2006 [Page 18]
Internet-Draft MIPv6 ROTA July 2005
This field specifies the type of ROTA message. The following
types are currently registered:
0: ROTA Initiation Request
This message triggers ROTA initiation. It MUST be sent
authenticated and integrity protected, e.g., by using the
IPsec SA used for BU messages.
1: ROTA Request
The purpose of this message is to check whether CN's HA
supports ROTA and, optionally, to discover the address of
CN's HA. This message MAY be sent to CN's HoA, if CN's HA
address is unknown. It SHOULD be sent authenticated and
integrity protected.
2: ROTA Tunnel Establishment Request
This message requests a tunnel entry-point to establish a
new tunnel. It MUST be sent authenticated and integrity
protected.
3: ROTA Tunnel Establishment Notification
The purpose of this message is to notify a tunnel exit-point
about a new tunnel entry-point address. It MUST be sent
authenticated and integrity protected.
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
ROTA messages and by the sending node to match a returned
Acknowledgement with this message.
Acknowledge (A)
This flag is set when an Acknowledgement is requested upon receipt
of this message. It MUST be set if the message transport service
is considered unreliable.
Reserved
These fields are unused. They MUST be initialized to zero and
MUST be ignored by the receiver.
Target Address 1
Weniger & Aramaki Expires January 12, 2006 [Page 19]
Internet-Draft MIPv6 ROTA July 2005
The meaning of this field depends on the value of the Message Type
field:
If 0 or 1, target address 1 is MN's HoA.
If 2, the target address 1 is the address of the new tunnel
exit-point.
If 3, the target address is the address of the new tunnel
entry-point.
Target Address 2
The meaning of this field depends on the value of the Message Type
field:
If 0 or 1 target address 2 is CN's HoA.
If 2 or 3 and the message is sent to MN, the target address 2
is CN's HoA.
If 2 or 3 and the message is sent to CN, the target address 2
is MN's HoA.
4.1.2 ROTA Reply/Acknowledgement
The ROTA Reply/Acknowledgement Message is the general reply and
acknowledgement message of ROTA. It contains a Message Type field to
distinguish different ROTA Reply/Acknowledgement messages (see
below). The MH type is TBD.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Msg Type
Weniger & Aramaki Expires January 12, 2006 [Page 20]
Internet-Draft MIPv6 ROTA July 2005
This field specifies the type of ROTA message. The following
types are currently registered:
0: ROTA Initiation Reply
The purpose of this message is to indicate the outcome of
the ROTA Initiation Request. It MUST be sent authenticated
and integrity protected, e.g., by using the IPsec SA used
for BU messages.
1: ROTA Reply
The purpose of this message is to indicate whether CN's HA
and CN support and accept ROTA and to inform the sender
about the address of CN's HA. It SHOULD be sent
authenticated and integrity protected.
2: ROTA Tunnel Establishment Reply
The purpose of this message is to indicate the outcome of
the Tunnel Establishment Request. It MUST be sent
authenticated and integrity protected.
3: ROTA Tunnel Establishment Notification Acknowledgement
The purpose of this message is to acknowledge ROTA Tunnel
Establishment Notification Message. It MUST be sent
authenticated and integrity protected.
4: ROTA Distance Information Acknowledgement
The purpose of this message is to acknowledge the ROTA
Distance Information Message. It MUST be sent authenticated
and integrity protected.
Status Code
This field indicates the result of an request:
0: Request accepted
128: Request not accepted, reason unspecified
129: Request not accepted, ROTA not supported
Weniger & Aramaki Expires January 12, 2006 [Page 21]
Internet-Draft MIPv6 ROTA July 2005
130: Request not accepted, ROTA accepted
131: Request not accepted, Insufficient resources
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
ROTA messages and by the sending node to match a returned
Acknowledgement with this message.
Reserved
These fields are unused. They MUST be initialized to zero and
MUST be ignored by the receiver.
4.1.3 ROTA Distance Information
The ROTA Distance Information Message is used to notify other
entities about distances between the sender and other nodes. It MUST
be sent authenticated and integrity protected. The MH type is TBD.
Weniger & Aramaki Expires January 12, 2006 [Page 22]
Internet-Draft MIPv6 ROTA July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A| Reserved | # Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address of Target 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance to target 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address of Target 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance to target 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
ROTA messages and by the sending node to match a returned
Acknowledgement with this message.
Acknowledge (A)
Weniger & Aramaki Expires January 12, 2006 [Page 23]
Internet-Draft MIPv6 ROTA July 2005
This flag is set when an Acknowledgement is requested upon receipt
of this message. It MUST be set if the message transport service
is considered unreliable.
Reserved
These fields are unused. They MUST be initialized to zero and
MUST be ignored by the receiver.
# Entries
An 8-bit unsigned integer indicating the number of distance
information entries in this message.
Address of Target X
Address of target X.
Distance to target X
An 8-bit unsigned integer indicating the distance to target X
measured in hops.
Weniger & Aramaki Expires January 12, 2006 [Page 24]
Internet-Draft MIPv6 ROTA July 2005
5. Modified Mobile Node Operation
5.1 Conceptual Data Structures
A new flag is added to Binding Update List entries to indicate an
active ROTA session. Additionally, an ROTA MN Cache entry is
maintained for every ROTA session. ROTA Binding Update List entries
conceptually point to ROTA MN Cache entries.
Each ROTA MN Cache entry contains the following data
o CN's HoA
o Tunnel endpoint address
o ROTA protocol state, indicating, e.g., ROTA initiation requested
or acknowledged, tunnel establishment requested or acknowledged
etc.
o Sequence Number
5.2 ROTA Initiation
The MN MAY request ROTA initiation for a communication session with a
specific CN at any time by sending an ROTA Initiation Request to its
HA containing CN's HoA. The MN then adds a corresponding entry in
its ROTA MN Cache. It MAY set the A-bit to solicit an
acknowledgement message. The messages MUST be sent integrity
protected, e.g., over the MN-HA IPsec SA.
After receiving a positive reply, the corresponding protocol state
field is updated.
5.3 Sending Reverse Tunneled Packets
If an ROTA session for the destination address exists and the
protocol state entry in the ROTA MN Cache indicates that the tunnel
is established, data packets are reverse tunneled to the
corresponding current tunnel endpoint address.
5.4 Tunnel Management
On receipt of a Tunnel Establishment Request, the MN checks whether
the ROTA MN Cache contains a valid entry for CN's HoA contained in
the Tunnel Establishment Request. If this is not the case, the
request MUST be rejected. Otherwise, the sequence number in the
message is checked. If it is higher than the one in the ROTA MN
Weniger & Aramaki Expires January 12, 2006 [Page 25]
Internet-Draft MIPv6 ROTA July 2005
Cache, the protocol state field, the tunnel endpoint fields, and the
sequence number field in the corresponding ROTA MN Cache entry are
updated. The MN MUST return a Tunnel Establishment Reply indicating
the outcome of the check. The sequence number is set to the value of
the corresponding Request message.
On receipt of a Tunnel Establishment Notification, the same check
applies. If successful, the MN updates its protocol state field, the
sequence number field, and the tunnel endpoint fields in the
corresponding ROTA MN Cache entry. The MN MUST return a Tunnel
Establishment Notification Acknowledgement with the sequence number
set to the value of the corresponding Notification message.
Weniger & Aramaki Expires January 12, 2006 [Page 26]
Internet-Draft MIPv6 ROTA July 2005
6. Modified Home Agent Operation
6.1 Conceptual Data Structures
Each HA maintains an ROTA HA cache and a Binding Update List. The
latter is the same as specified for the MN in section 11.1 of [4],
but without the data required for the return routability procedure.
Binding Cache entries with home registration and Binding Update List
entries conceptually point to each other and to ROTA HA Cache
entries.
Each ROTA HA Cache entry of MN's HA contains the following data
o CN's HoA
o ROTA protocol state, indicating, e.g., ROTA initiation requested
or acknowledged, tunnel establishment requested or acknowledged
etc.
o CN's HA address
o Current TA address for MN
o Sequence number for signaling message exchange with TA
o Sequence number for signaling message exchange with MN
A Certificate Cache may be maintained, which contains recently
received public keys and certificates.
A Distance Information Cache is used to store distances to MNs, CNs
and TAs. It contains the following data
o Destination address
o Distance measured in hops
o Sequence number
o Lifetime
An HA acting as a TA additionally maintains an ROTA TA Cache.
Binding Cache entries are extended by a TA flag to distinguish TA
registrations from home registrations. TA registration entries
conceptually point to ROTA TA Cache entries.
Each ROTA TA Cache entry contains the following data
Weniger & Aramaki Expires January 12, 2006 [Page 27]
Internet-Draft MIPv6 ROTA July 2005
o MN's HA address
o ROTA protocol state, e.g., ROTA initiation requested or
acknowledged, tunnel establishment requested or acknowledged etc.
o Sequence Number
6.2 ROTA Initiation
The HA starts ROTA initiation for a specific MN-CN session on receipt
of an ROTA Initiation Request from an MN or on an internal trigger,
e.g., after the first received data packets from a specific CN. For
the latter it MUST be ensured that the preferences of MN comply with
HA's decision to initiate ROTA, e.g., from some prior arrangement.
If triggered by an ROTA Initiation Request sent by MN and the A-bit
is set, the HA MUST return an ROTA Initiation Reply indicating the
outcome of the initiation. The Sequence Number in the ROTA
Initiation Reply MUST match those in the corresponding Initiation
Request. During ROTA initiation, the HA creates a corresponding
entry in its ROTA HA Cache.
6.3 Sending ROTA Request
ROTA Request messages are only exchanged between MN's HA and CN's HA.
MN's HA sends an ROTA Request to CN's HA. If CN's HA address is
unknown, the Request may be sent to CN's HoA and intercepted by CN's
HA. The ROTA Request message MUST contain CN's HoA and a current
sequence number and SHOULD be sent authenticated and integrity
protected, e.g., over an IPsec ESP [16] SA, which can be established
before using IKE/IKEv2 [17] [18].
6.4 Receiving ROTA Request and Sending ROTA Reply
If an HA supports ROTA and receives a ROTA Request addressed to one
of the addresses associated to its network interfaces or to one of
its Binding Cache entries with home registration, it SHOULD send a
ROTA Initiation Request to CN in order to check if CN supports and
wants to execute ROTA. If such a message is not sent, the HA must
know the preferences of CN, e.g., from some prior arrangement. If a
valid and positive Initiation Reply is received, the ROTA Request
message is processed.
If CN does not have an active communication session with the address
contained in the ROTA Initiation Request message or does not want to
execute ROTA route optimization, the HA sends a negative reply and
MN's HA informs MN accordingly. Otherwise the HA sends a positive
ROTA Reply message to the sender address of the corresponding Request
Weniger & Aramaki Expires January 12, 2006 [Page 28]
Internet-Draft MIPv6 ROTA July 2005
message. The sequence number is set to the value of the
corresponding Request messages. The Reply message SHOULD be sent
authenticated and integrity protected. Additionally, the HA creates
or updates the corresponding entry in its ROTA HA Cache.
6.5 Receiving ROTA Reply
The receiver only processes the Reply message if it has sent a
corresponding Request to the sender address before, which can be
verified by consulting the ROTA HA Cache. If there is no
corresponding entry, the HA MAY return an ROTA Reply indicating the
rejection of ROTA. Otherwise it proceeds with sending a BU message.
6.6 Sending Binding Updates
A Binding Update may only be sent by an HA with a subnet prefix
matching the HoA in the binding to a TA. The Binding Update MUST be
sent authenticated and integrity protected. Additionally, the
Binding Update List MUST be updated as specified in [4].
6.7 Receiving Binding Updates
If an HA receives a BU from one of its MNs, it behaves according to
[4]. Additionally, it sends a corresponding BU to the current TA(s).
An HA acting as TA and receiving a Binding Update from an HA does not
necessarily reject a binding containing an HoA which is not an on-
link IPv6 address with respect to the HA's current prefix list, as
described in [4]. Instead, it checks whether the sender is
authorizes to act as an HA for the HoA contained in BU message. If
certificates are used, the HoA in the binding MUST match a prefix
contained in the IP address extension of the certificate of the
sender HA. If no match exists, the BU MUST be rejected.
If accepted, the TA adds the binding to its Binding Cache. The
lifetime of the entry is set according to the rules for Bi-
directional Tunneling mode as described in [4]. The TA MUST set the
TA registration flag of the corresponding entry. The home
registration bit MUST NOT be set. Additionally, it adds an entry in
its ROTA TA Cache with the address of the sender HA and a code
indicating the current protocol state. Finally, a pointer to this
entry is added in the corresponding Binding Cache entry. Regardless
of the A-bit in the binding, the TA MUST return a Binding
Acknowledgement to the sending HA as described in [4].
6.8 Distance Measurements and TA selection
After sending the binding information, the HAs measure the distances
Weniger & Aramaki Expires January 12, 2006 [Page 29]
Internet-Draft MIPv6 ROTA July 2005
to MN's and CN's CoA, respectively. The distance information can
passively be acquired from the routing table, from previously
received signaling messages or tunneled data packets or can actively
be measured with probe messages. Some distant measurements might not
be necessary if pre-assigned distance values, e.g., between roaming
partners exist. Subsequently, MN's HA and CN's HA exchange the
distance information by sending integrity protected Distance
Information messages. After receiving a Distance Information message
with a current sequence number, the information is stored in the
Distance Information Cache.
This cache is then used to determine the current route length between
MN and CN as well as the route length when MN's HA and/or CN's HA
were used as TA(s). The TA(s) providing the shortest route length
are selected by every HA independently and Tunnel Establishment
Request/Notification messages are sent accordingly. Additional
synchronization between both HAs regarding the TA selection may be
added in future versions of this document.
6.9 Tunnel Management
When a new TA has been selected and when it results in a new outgoing
tunnel endpoint for the MN, MN's HA sends a Tunnel Establishment
Request to MN containing the address of the new TA, CN's HoA as well
as a current sequence number. If the new TA results in a new
incoming tunnel endpoint, it sends a Tunnel Establishment
Notification message to its MN, again containing TA address, CN's HoA
as well as a current sequence number. All tunnel management messages
MUST be sent integrity protected.
6.10 Intercepting Packets
An TA MUST NOT intercept data packets for nodes having only TA
registration, i.e., it MUST NOT perform Proxy Neighbor Discovery for
those nodes. An HA may only perform packet interception for home
registrations as described in [4]
6.11 Sending and Receiving Reverse Tunneled Packets
Reverse tunneled packets are handled the same way as in [4]. E.g.,
the TA MUST verify that the Source Address in the tunnel IP header of
received data packets is equal to the CoA specified in the
corresponding entry in the Binding Cache, if IPsec ESP is not used
for those packets.
6.12 Management of ROTA HA Cache Entries
ROTA HA Cache entries are deleted when the corresponding Binding
Weniger & Aramaki Expires January 12, 2006 [Page 30]
Internet-Draft MIPv6 ROTA July 2005
Cache entries are deleted.
Weniger & Aramaki Expires January 12, 2006 [Page 31]
Internet-Draft MIPv6 ROTA July 2005
7. IANA Considerations
ROTA introduces three new Mobility Header Types (see section
Section 4).
Weniger & Aramaki Expires January 12, 2006 [Page 32]
Internet-Draft MIPv6 ROTA July 2005
8. Security Considerations
Security Considerations are addressed in Section 3.4.
Weniger & Aramaki Expires January 12, 2006 [Page 33]
Internet-Draft MIPv6 ROTA July 2005
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
9.2 Informative References
[6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[7] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[8] Koodli, R., "IP Address Location Privacy and IP Mobility",
draft-koodli-mip6-location-privacy-00 (work in progress),
February 2005.
[9] Koodli, R., "Solutions for IP Address Location Privacy in the
presence of IP Mobility",
draft-koodli-mip6-location-privacy-solutions-00 (work in
progress), February 2005.
[10] Haddad, W., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv
Problem Statement", draft-haddad-momipriv-problem-statement-01
(work in progress), February 2005.
[11] Haddad, W., "Privacy for Mobile and Multi-homed Nodes
(MoMiPriv): Formalizing the Threat Model",
draft-haddad-momipriv-threat-model-00 (work in progress),
February 2005.
[12] Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
draft-wakikawa-nemo-orc-01 (work in progress), November 2004.
Weniger & Aramaki Expires January 12, 2006 [Page 34]
Internet-Draft MIPv6 ROTA July 2005
[13] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004.
[14] Thubert, P., "Global HA to HA protocol",
draft-thubert-nemo-global-haha-00 (work in progress),
October 2004.
[15] Krishnamurthi, G., Chaskar, H., and R. Siren, "Providing End-
to-End Location Privacy in IP-based Mobile Communication", IEEE
WCNC 2004, March 2004.
[16] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[17] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[18] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[19] Nikander, P., "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-02 (work in
progress), October 2004.
[20] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using
a State Cookie", draft-dupont-mipv6-rrcookie-00 (work in
progress), January 2005.
[21] Bao, F., "Certificate-based Binding Update Protocol (CBU)",
draft-qiu-mip6-certificated-binding-update-03 (work in
progress), March 2005.
Authors' Addresses
Kilian A. Weniger
Panasonic R&D Center Germany
Monzastr. 4c
Langen 63225
Germany
Phone: +49 6103 766 137
Email: kilian.weniger@eu.panasonic.com
Weniger & Aramaki Expires January 12, 2006 [Page 35]
Internet-Draft MIPv6 ROTA July 2005
Takashi Aramaki
Matsushita Electric (Panasonic)
5-3 Hikarinooka
Yokosuka 239-0847
Japan
Phone: +81 46 840 5353
Email: aramaki.takashi@jp.panasonic.com
Weniger & Aramaki Expires January 12, 2006 [Page 36]
Internet-Draft MIPv6 ROTA July 2005
Appendix A. Discussion of Further Optimizations
Especially if both MN and CN are far away from home, neither MN's HA
nor CN's HA can provide good route optimization by acting as TA.
Another issue is that the scenario shown in Figure 3 may not achieve
complete location privacy, since MN knows that the path over CN's HA
must be shorter than over MN's HA, because otherwise CN's HA would
not have been selected as TA. Since MN can determine the distances
to MN's HA and CN's HA, it can conclude whether CN is closer to MN's
or CN's HA. Hence, it may be beneficial to consider other TAs as
well, if available, e.g., HAs, MAPs, ARs or dedicated servers
extended with TA functionality and located in or close to the visited
networks of MN and CN. Of course the disclosure of the prefix of
MN's visited network to CN and vice versa must be prevented, e.g., by
having more than one intermediate TA (e.g., a TA in MN's and CN's
visited networks as shown in Figure 5).
However, various issues have to be considered in such scenarios,
which are currently out of scope of this document. First, CN/MN's HA
and MN/CN's TA are not the same entity anymore. This may result in
new security issues. Also, a suitable TA must first be discovered.
In case of multiple TAs on the path, additional issues arise. For
instance the binding updates contain TA addresses instead of MN' CoA
or HoA and those addresses must somehow be verified by the receiver.
------------ .. ... .. ------------
|Site 1 | . . . .. |Site 2 |
| |.. .| |
| MN's HA | | CN's HA |
| | | |
------------ ------------
.. ..
|----------| |----------|
---\ /-------------\ /---
MN----TA1 --------------- TA2----CN
---/ \-------------/ \--- ||| tunneled
|Site 3 | .. |Site 4 | || not tunneled
------------ .------------
Figure 5: Data path between MN and CN with a TA in the visited
network of MN and CN, respectively
One drawback of the tunneling approach is the additional overhead due
to encapsulation of data packets. To alleviate this problem, header
compression schemes can be applied to all tunnel segments. Other
Weniger & Aramaki Expires January 12, 2006 [Page 37]
Internet-Draft MIPv6 ROTA July 2005
possible optimizations include an improved TA selection that
considers more parameters, e.g., privacy/route optimization
preferences, load factors or roaming agreements. In this case
additional negotiations between MN's and CN's HA may be necessary.
Also, the distance measurements can be improved, e.g., by running a
routing protocol in the overlay when many HAs are interconnected over
multiple active security associations. Moreover, QoS parameters can
be considered to find the optimal route for a specific communication
session. Finally, ROTA can be extended to support the registration
of network prefixes in order to support route optimization for mobile
networks as well.
All these optimization are currently out of the scope of this
document, but may be considered in future versions of ROTA.
Weniger & Aramaki Expires January 12, 2006 [Page 38]
Internet-Draft MIPv6 ROTA July 2005
Appendix B. MN-controlled ROTA
This section describes an alternative realization of ROTA, which
requires MNs (instead of HAs) to establish the bindings and tunneling
functionality in TAs. Authentication and authorization of BU
messages are done by utilizing the Return Routability procedure.
B.1 Exemplary Signaling Flow
Again, the operation is explained by means of an exemplary signaling
flow (see Figure 6), which results in the scenario shown in Figure 3.
In the MN-controlled variant, MN and CN's HA as well as CN and MN's
HA exchange ROTA signaling messages, respectively. First, the MN
sends an ROTA Request message to CN's HA (or to CN's HoA and
intercepted by CN's HA), tunneled over MN's HA and containing MN's
and CN's HoA. If CN's HA supports ROTA, it sends an ROTA Reply
message. This message contains a status code and, if certificates
are used, the certificates of CN's HA, which authorizes it to receive
MN's CoA. Before, CN's HA sends an ROTA Initiation Request message
to CN to trigger the ROTA procedure at CN. CN accepts or rejects
ROTA by sending an ROTA Initiation Reply message. Note that public/
private keys and certificates are only assigned to TAs and are only
contained in ROTA Reply messages. They are used to authorize a TA to
act as TA in order to prevent attacks against location privacy (see
Section 3.4.5). Authentication and authorization of BU messages sent
by the MN can be achieved by utilizing the Return Routability
procedure known from the Route Optimization mode of Mobile IPv6 [4].
Hence, MNs do not require certificates. However, in contrast to the
HA-controlled variant they must be pre-configured with a shared
trusted anchor for certificate verification.
After the session key kbm is derived from the Return Routability
procedure, MN can send integrity protected BU and Distance
Information messages to CN's HA containing the distance to MN's HA.
Additionally, MN sends a Distance Information message to MN's HA
containing the distance to CN's HA. In parallel, this procedure is
executed between CN and MN's HA.
Subsequently, both HAs have enough information to determine the
current route length as well as the route length when MN's and/or
CN's HA would be used as TA(s). The selection of TA(s) is done by
HAs, not MN, since information about CN's location is required for
this decision. Finally, the HAs informs their MN/CN about new tunnel
endpoints.
Note that any BU message sent by the MN must be sent to MN's HA and
TA.
Weniger & Aramaki Expires January 12, 2006 [Page 39]
Internet-Draft MIPv6 ROTA July 2005
+--+ +-------+ +-------+ +--+
|MN| |MN's HA| |CN's HA| |CN|
| | |CN's TA| |MN's TA| | |
+--+ +-------+ +-------+ +--+
| ROTA_req | ROTA_req | |
|--------------------->-------------------->| ROTA_init_req |
| ROTA_rep | ROTA_rep |-------------------->|
|<--------------------<---------------------| ROTA_init_rep |
| return routability |<--------------------|
|<----------------------------------------->| |
| BU+dist_info | |
|------------------------------------------>| |
| BA+dist_info_ack | |
|<------------------------------------------| |
| dist_info |
|-------------------->| ROTA_req | ROTA_req |
| dist_info_ack |<--------------------<---------------------|
|<--------------------| ROTA_rep | ROTA_rep |
| |--------------------->-------------------->|
| | return routability |
| |<----------------------------------------->|
| | BU+dist_info |
| |<------------------------------------------|
| | BA+dist_info_ack |
| |<----------------------------------------->|
| | | dist_info |
| | |<--------------------|
| | | dist_info_ack |
| tun_estbl_req | |-------------------->|
|<--------------------| | |
| tun_estbl_rep | | |
|-------------------->| | |
Figure 6: Example of signaling flow for MN-controlled ROTA
B.2 Security Issues
This solution requires a trust relationship for authentication and
authorization between MN and TA and utilizes the Return Routability
(RR) procedure targeted at TA for this purpose. However, it is well-
known that the return routability procedure in [4] is not resistant
against attackers that are able to eavesdrop on both MN-CN and HA-CN
path. This is especially an issue with ROTA, since routes are not
only injected in a host (e.g., CN), but in potential Internet routers
(here: HA acting as TA), which gives more options to an attacker.
Since messages sent on the path between MN and HA can be encrypted by
Weniger & Aramaki Expires January 12, 2006 [Page 40]
Internet-Draft MIPv6 ROTA July 2005
IPSec ESP, only the paths between HA and CN and between MN and CN are
critical. Furthermore, attackers are more likely on the edge of the
network, because the routing infrastructure is usually well secured
by the network operator. Thus the critical point for attacks is the
point of attachment of the CN. In contrast to [4], the Return
Routability procedure as applied here does not take place between MN
and CN, but between MN and TA. Since TA is not considered to be
located on the edge of the network, the Return Routability procedure
targeted at TA can be considered more secure than targeted at the CN.
However, due to the Return Routability procedure the MN-controlled
variant can not provide as strong protection as the HA-controlled
variant.
To prevent attacks against location privacy, the TA MUST be
authorized to receive location information. This can be achieved
with certificates in ROTA Reply messages.
Since HAs add an entry in their ROTA HA Cache after accepting ROTA
requests, memory exhaustion DoS attacks are in principle possible.
However, since this state is only created when an active
communication session with CN exists, the attacker has to initiate
many communication session before. Also, the HA may identify the
attacker and may stop the service for this node (see Section 3.4.1).
CPU exhaustion attacks against HAs are not an issue with the MN-
controlled variant, since they do not need to verify certificates or
signatures. However, due to the need for signature verification, CPU
exhaustion attacks can be mounted against MN and CN. Since
verification is only required after receiving ROTA Reply messages and
those messages should only be received if MN or CN have sent a
corresponding ROTA Request message before, this issue is considered
less severe. Reply message not matching recently sent Request
messages MUST be ignored.
Reflection attacks with amplification may be a problem in the MN-
controlled variant, if the ROTA Reply contains a certificate. This
could be exploited by an attacker that sends ROTA Request messages
with spoofed source address. As a countermeasure, the Request
message should be padded to the size of a Reply message.
Weniger & Aramaki Expires January 12, 2006 [Page 41]
Internet-Draft MIPv6 ROTA July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weniger & Aramaki Expires January 12, 2006 [Page 42]
| PAFTECH AB 2003-2026 | 2026-04-24 14:17:58 |