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]