Network Working Group K. Weniger Internet-Draft T. Aramaki Expires: April 24, 2006 Panasonic October 21, 2005 Route Optimization and Location Privacy using Tunneling Agents (ROTA) draft-weniger-rota-01 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 April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Mobile IPv6 in route optimization mode reveals mobile node's care-of address to the correspondent node and hence cannot provide location privacy. In contrast, Mobile IPv6 in bi-directional tunneling mode can provide location privacy, but the resulting route may be far from optimal, especially when correspondent node is mobile as well. This may be an issue for conversational mobile-to-mobile communication scenarios, e.g., using VoIP. The draft discusses the problem of providing both location privacy and route optimization with Mobile Weniger & Aramaki Expires April 24, 2006 [Page 1] Internet-Draft MIPv6 ROTA October 2005 IPv6 and describes a solution in terms of an optional extension to Mobile IPv6. The basic idea is that mobile nodes switch the reverse tunnel endpoint in bi-directional tunneling mode from their home agent to a so-called tunneling agent in an on-demand manner. To ensure location privacy, the tunneling agent selection is done by the home agents. The solution does not require the mobile node to change its home address and does not rely on visited network support. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction and Problem Description . . . . . . . . . . . . . 5 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview of ROTA . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Assumptions about Trust Model . . . . . . . . . . . . . . 8 3.2 The ROTA Approach and its Benefits . . . . . . . . . . . . 8 3.3 ROTA in scenarios without visited network support . . . . 9 3.3.1 Signaling Flow . . . . . . . . . . . . . . . . . . . . 11 3.4 ROTA in scenarios with visited network support . . . . . . 13 3.4.1 Signaling Flow . . . . . . . . . . . . . . . . . . . . 14 4. New Message Types . . . . . . . . . . . . . . . . . . . . . . 18 4.1 Message Headers . . . . . . . . . . . . . . . . . . . . . 18 4.1.1 Binding Update and Acknowledgement Message . . . . . . 18 4.1.2 ROTA Request/Notification Message . . . . . . . . . . 18 4.1.3 ROTA Reply/Acknowledgement Message . . . . . . . . . . 22 4.1.4 ROTA Distance Information Message . . . . . . . . . . 24 4.2 Mobility Options . . . . . . . . . . . . . . . . . . . . . 25 4.2.1 Candidate TA Option . . . . . . . . . . . . . . . . . 25 5. Modified Mobile Node Operation . . . . . . . . . . . . . . . . 28 5.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 28 5.2 Using Security Associations . . . . . . . . . . . . . . . 28 5.3 Sending ROTA Initiation Request . . . . . . . . . . . . . 28 5.4 Receiving ROTA Initiation Reply . . . . . . . . . . . . . 28 5.5 Receiving ROTA Initiation Request . . . . . . . . . . . . 29 5.6 Sending ROTA Initiation Reply . . . . . . . . . . . . . . 29 5.7 Sending Reverse Tunneled Packets . . . . . . . . . . . . . 29 5.8 Receiving Reverse Tunneled Packets . . . . . . . . . . . . 29 5.9 Sending Binding Updates . . . . . . . . . . . . . . . . . 29 5.10 Receiving Tunnel Establishment Request messages . . . . . 29 5.11 Sending Tunnel Establishment Reply messages . . . . . . . 30 5.12 Receiving Tunnel Establishment Notification messages . . . 30 6. Modified Home Agent Operation . . . . . . . . . . . . . . . . 31 6.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 31 6.2 Using Security Associations . . . . . . . . . . . . . . . 32 6.3 ROTA Initiation . . . . . . . . . . . . . . . . . . . . . 32 6.4 Sending ROTA Request . . . . . . . . . . . . . . . . . . . 32 Weniger & Aramaki Expires April 24, 2006 [Page 2] Internet-Draft MIPv6 ROTA October 2005 6.5 Receiving ROTA Request . . . . . . . . . . . . . . . . . . 33 6.6 Sending ROTA Reply message . . . . . . . . . . . . . . . . 33 6.7 Receiving ROTA Reply . . . . . . . . . . . . . . . . . . . 33 6.8 Sending Binding Updates . . . . . . . . . . . . . . . . . 34 6.9 Receiving Binding Updates . . . . . . . . . . . . . . . . 34 6.10 Receiving Binding Acknowledgements . . . . . . . . . . . . 34 6.11 Sending Tunnel Establishment Notification message . . . . 34 6.12 Receiving Tunnel Establishment Notification message . . . 35 6.13 Receiving Tunnel Establishment Notification Acknowledgement message . . . . . . . . . . . . . . . . . 35 6.14 Intercepting Data Packets . . . . . . . . . . . . . . . . 35 6.15 Sending and Receiving Reverse Tunneled Packets . . . . . . 35 6.16 Receiving a ROTA Abort Notification message . . . . . . . 35 6.17 Management of ROTA HA Cache Entries . . . . . . . . . . . 35 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8.1 Address Stealing . . . . . . . . . . . . . . . . . . . . . 37 8.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 38 8.3 Denial of Service (DoS) Attacks . . . . . . . . . . . . . 38 8.3.1 Reflection . . . . . . . . . . . . . . . . . . . . . . 38 8.3.2 Amplification . . . . . . . . . . . . . . . . . . . . 39 8.3.3 Memory Exhaustion . . . . . . . . . . . . . . . . . . 39 8.3.4 CPU Exhaustion . . . . . . . . . . . . . . . . . . . . 39 8.4 Other Attacks on Sending Binding Information . . . . . . . 40 8.5 Attacks against Location Privacy . . . . . . . . . . . . . 40 8.6 Overlay Re-routing Attacks . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1 Normative References . . . . . . . . . . . . . . . . . . . 42 9.2 Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 A. Recommendations for TA Selection . . . . . . . . . . . . . . . 45 B. Support of Stationary Correspondent Nodes . . . . . . . . . . 46 C. Discussion of Further Optimizations . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . 48 Weniger & Aramaki Expires April 24, 2006 [Page 3] Internet-Draft MIPv6 ROTA October 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 [3], 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 | | | | | TA (of node X) | A tunneling agent (TA) is a | | | logical entity that is a tunnel | | | 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. A TA | | | can be co-located with an HA | | | (with both entities serving | | | different nodes) or MAP. | +---------------------------------+---------------------------------+ Weniger & Aramaki Expires April 24, 2006 [Page 4] Internet-Draft MIPv6 ROTA October 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. Because the routing in the Internet is hierarchical, IP addresses used for global routing usually 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 [10][7]. In Mobile IPv6 [3], HoA and CoA usually represent identity and location of the MN, respectively. Currently, two modes are defined in [3]: 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, since the CN learns MN's CoA and, thus, the topological location of the MN. In contrast, bi-directional tunneling mode does not reveal MN's CoA to CN, since BU messages containing MN's CoA and data packets with MN's CoA in the IP header are terminated at MN's HA. Thus, MN's location can be hidden from CN (see section 2.1 of [8]). However, bi-directional tunneling may lead to long routes, especially if CN is mobile as well. Since mobile-to-mobile communications with conversational nature (e.g., with VoIP) is considered to be a common scenario in the future, the utilization of standard Mobile IPv6 in bi-directional tunneling mode for location privacy-enabled communication may be inefficient and may delay packets to an extent that is harmful to the communication. 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 is to provide location privacy to mobile nodes. In the context of Mobile IPv6, two problems are considered to be the most important: preventing the disclosure of MN's CoA to CN and preventing the disclosure of MN's HoA to eavesdropper [7]. While many currently discussed proposals address the second problem, this document addresses the first one, i.e., the disclosure of the CoA to CN. The solution shall support full and bi- directional location privacy, meaning that the MN's location may not be revealed to a mobile CN and vice versa and that disclosing the location with lower resolution (e.g., MN's visited domain prefix is Weniger & Aramaki Expires April 24, 2006 [Page 5] Internet-Draft MIPv6 ROTA October 2005 disclosed instead of prefix of MN's AR) is not an acceptable level of privacy. Profiling and tracking issues such as hiding MN's HoA from eavesdroppers or other aspects of privacy not directly related to Mobile IPv6 addresses, such as the profiling based on lower- or upper-layer identities or based on protocol values [9] are out of the scope of this document. However, it should be possible to combine solutions for those problems with the solution proposed in 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. However, in many scenarios bi-directional tunneling mode results in long routes (see Figure 1) and thus may be problematic for delay-sensitive applications such as VoIP. This is becoming even worse if CN is mobile, too. Note that the terms route optimization as used in this document means improved efficiency of routing by shortening the route. The optimized route does not need to be optimal (i.e., equal length than the direct route between MN and CN), but it must be good enough, e.g., to support conversational communications. Further, route optimization of active communication sessions shall be possible. This is especially beneficial when a node travels large topological distances during an active session, which is considered to happen frequently in case of inter-domain and inter-technology handovers. Another issue to be considered is deployment. If a solution relies on support from visited network infrastructure (e.g., modified ARs), every visited network must support this solution. Otherwise either the route optimization or the privacy support (or even the communication session itself) breaks when the MN moves to a network without support. However, global universal deployment is very difficult to achieve. Hence, the solution should not rely on visited network support, but should benefit from it if available. In summary, the problem this document addresses is hiding MN's CoA from CN and providing route optimization at the same time without relying on support from visited networks. The solution shall not create any significant new security problems in comparison to Mobile IPv6/IPv6. Since the problem is especially severe if CN is mobile and since mobile-to-mobile communication is expected to be very common in the future (e.g., with VoIP), this is considered as the main target scenario. However, stationary nodes shall be supported as well. 2.3 Related Work Various protocols have been proposed, which could be used to provide Weniger & Aramaki Expires April 24, 2006 [Page 6] Internet-Draft MIPv6 ROTA October 2005 both route optimization and location privacy to some extent [11] [12] [13] [14]. Since most of the protocols have been developed for other purposes, deficiencies exist and they do not meet the requirements listed in Section 2.2. For instance, they require universal deployment of modified (access) routers or only provide uni- directional location privacy (i.e., only for MN or CN, not both) or limited location privacy (i.e., only a topological area containing MN's location is known). It may seem that the Mobile IPv6 bootstrapping solution (see [22] for split scenario) can provide both route optimization and location privacy, since route optimization in bi-directional tunneling mode can be achieved by reverse tunneling to dynamically allocated local HAs or HAs of nearby networks. However, the problem is that in this case the new HoA belongs to the visited network (or a nearby network) and hence contains location information. The bootstrapping solution provides means to update DNS with the new HoA, so that other nodes are able to start communication sessions with MN using the new HoA. But updating DNS with the new HoA or disclosing the new HoA by other means (e.g., during a VoIP call setup) may reveal information about MN's location. This is especially an issue if other nodes are able to find out that the new HoA belongs to the MN's visited network (or a nearby network), e.g., because MN's HA selection policy is known. In contrast, if the new HoA is not disclosed, other nodes are not aware of it and hence cannot initiate communication session with MN using the optimized route. Consequently, route optimization and full location privacy support cannot be provided at the same time. Another disadvantage with respect to route optimization by bootstrapping with local or nearby HAs is that route optimization of active communication sessions is not possible in a manner transparent for higher layers due to the need for changing the HoA. Weniger & Aramaki Expires April 24, 2006 [Page 7] Internet-Draft MIPv6 ROTA October 2005 3. Overview of ROTA 3.1 Assumptions about Trust Model To allow a large scale applicability and deployment, no pre- established trust relationship shall be required between MN and CN or between MN/CN and HAs located outside the home link, respectively. Also, no "global PKI" is assumed, i.e., MN and CN shall not require public/private key pairs or host certificates. 3.2 The ROTA Approach and its Benefits ROTA is an extension to Mobile IPv6 that optimizes the path in bi- directional tunneling mode between two mobile nodes in order to achieve both route optimization and full, bi-directional location privacy in terms of hiding the CoA from CN. 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 or MAPs. This external entity is then serving as a TA for a node, whose HoA does not match the subnet prefix of this HA. Consequently, the route can be optimized without changing the HoA of the MN. To ensure bi-directional location privacy, most of the procedure is controlled by MN's HA and CN's HA, e.g., they determine and configure appropriate TA(s) to be used as tunnel endpoints. ROTA can operate with and without visited network support, which significantly eases deployment of ROTA. In the latter case, only MN's HA or CN's HA may act as TA for MN or CN, respectively. However, the route becomes less optimal when both MN and CN move far away from their home. Further route optimization is possible when leveraging TAs in visited networks (e.g., co-located with local HAs or MAPs), if available. In contrast to the bootstrapping solution (see [22] for split scenario), ROTA does not change the home link in order to achieve route optimization. Hence, the HoA does not contain location information and can be rather static, i.e., it can be used as long- term identifiers regardless of the location of the MN and without sacrificing efficient routing. Dynamic DNS updates are not necessary as well. Furthermore, route optimization of active communication sessions is supported, which is especially beneficial if MNs travel topologically large distances during a session, e.g., because of vertical handovers. A nice side-effect of the ROTA approach is that it provides benefits over route optimization mode beyond location privacy support by being able to utilize stronger authentication and authorization mechanisms Weniger & Aramaki Expires April 24, 2006 [Page 8] Internet-Draft MIPv6 ROTA October 2005 than the Return Routability procedure. Hence, longer binding lifetimes can be used, BU message can be sent less often, and temporary unavailability of HAs result in no or less loss of data packets. 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. In the following, the operation of ROTA is described for scenarios without and with visited network support, respectively. 3.3 ROTA in scenarios without visited network support The following basic scenario is assumed: First, a communication session between MN and a mobile CN has started and both nodes are in bi-directional tunneling mode. It is assumed 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 is the route. ------------ .. ... .. ------------ |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 the reverse tunnel endpoint from the HA to TAs to shorten the route between MN and CN. In this Weniger & Aramaki Expires April 24, 2006 [Page 9] Internet-Draft MIPv6 ROTA October 2005 section we assume no visited network support. Hence, we assume that only MN's or CN's HA may serve as TA. Figure 2 shows the data path between MN and CN when 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. As can be seen, the route is shorter than in Figure 1. Depending on the location of to MN, CN and their HAs, the data path is shorter when MN's HA or CN's HA acts as TA, respectively. For an optimal selection, ROTA can determine the best TA location based on distance information. ------------ .. ... .. ------------ |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 only CN's HA being TA In the following, the operation of ROTA in scenarios without visited network support is described. The initial procedure can be divided in the following steps: o Initiation of ROTA, which comprises requesting ROTA, checking whether CN and CN's HA support ROTA and, if not already known, discovering CN's HA address. o Collecting distance information for TA selection (optional). o Selecting TA(s) that provide(s) the shortest route. o Sending binding information to TAs. o Requesting tunnel establishment from new tunnel entry-point(s) and notifying corresponding tunnel exit-point(s). Note that this is only the initial procedure. Once this is completed, basically only binding updates must be sent after handovers. It is assumed that some kind of security association Weniger & Aramaki Expires April 24, 2006 [Page 10] Internet-Draft MIPv6 ROTA October 2005 exists between MN's HA and CN's HA to provide message authentication and integrity protection of signaling messages. This can be achieved by IPsec SAs, which are dynamically established with IKE [16] [17]. The signaling messages exchanged between MN/CN and HAs are sent over the IPsec SAs, which exist for Mobile IPv6 signaling messages [3]. A discussion of threats and possible countermeasures can be found in Section 8. 3.3.1 Signaling Flow The initial procedure of ROTA in a scenario without visited network support is explained by means of the signaling flow shown in Figure 3, resulting in the data path depicted in Figure 2, i.e., CN's HA acts as TA for MN. See Section 5 and Section 6 for a detailed description of the MN and HA operation, respectively, and Section 4 for new message types. +--+ +-------+ +-------+ +--+ |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 | | | |<--------------------| | | tun_estbl_req | | | |<--------------------| | | | tun_estbl_rep | | | |-------------------->| | | | +-------+ | |<=====================================>|MN's TA|<===============>| | tunneled data packets +-------+ | Figure 3: Signaling flow for initial procedure without visited network support ROTA execution can either be triggered by MN or MN's HA. In the first case, the MN sends an ROTA Initiation Request message containing CN's and MN's HoA to its HA. In the latter case, the HA starts ROTA, e.g., after first data packets from/to CN's HoA were Weniger & Aramaki Expires April 24, 2006 [Page 11] Internet-Draft MIPv6 ROTA October 2005 tunneled. Subsequently, MN's HA sends 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 and/or 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. Subsequently, both HAs perform an TA selection procedure, which among other things is based on distance information. The distance metric can be hops or delay. Although delay would be a more meaningful metric for determining the best path to be used for conversational communications, it is less stable and the distance in hops can easier be measured. Hence, it is proposed to use hops as default metric. The distance can partly be passively acquired from the routing table, from previously received signaling messages or tunneled data packets. In the latter two cases, the initial hop limit used by the sender must be known by the receiver. Furthermore, some distance values might be pre-assigned, e.g., between roaming partners. Otherwise, distances may be measured by active probing (a specification of probe messages and a mechanism to secure active probing is left for future work). A simple TA selection strategy would be to select the HA that is closer to its MN as TA, since this usually provides the shorter path. In this case, the HAs can passively measure the distance to their MN/CN, e.g., with the ROTA Initiation Request/Reply messages and exchange them using the ROTA Request/Reply message with the own address and the distance information contained in the Candidate TA option. However, this strategy does not always select the better TA. A more accurate, but also more expensive strategy is to measure all distances needed 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 TA(s) and, subsequently, select the best TA in terms of route optimization. Therefore, both HAs have to exchange BU messages to be able to measure the distance to MN's and CN's CoA. Note that a valid result of the selection is that no route optimization is necessary (see Appendix A for TA selection recommendations). After an TA has been selected, binding information is introduced in the TA and 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 [3]. Weniger & Aramaki Expires April 24, 2006 [Page 12] Internet-Draft MIPv6 ROTA October 2005 Note that this signaling flow applies to the initial ROTA procedure only. When MN moves to another subnet, basically only binding update messages must be sent to MN's HA and to MN's TA (as long as the TAs do not change). The latter can be sent by MN's HA or, to improve handover signaling efficiency and delay, by the MN itself. In this case the MN must be able to dynamically establish an SA to CN's HA. This may require an interface between CN's HA and an AAA infrastructure to transfer cryptographic material needed to establish the SA to CN's HA. Such an interface is currently in development (see [21]) and may be re-used by ROTA. Furthermore, the optimal TA may change after movements. Hence, distance measurements and the TA selection may be repeated after movements. To reduce signaling, it is recommended to use passive measurements as much as possible. Further, it is not recommended to re-execute TA selection after every handover of MN or CN, but instead, e.g., after every nth handover. 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 data packet loss, new tunnels should be set up before the old tunnels are deleted ("make-before-break"). 3.4 ROTA in scenarios with visited network support Especially if both MN and CN are far away from the home network, neither MN's HA nor CN's HA can provide good route optimization by acting as TA. The route can be further optimized by considering TAs close to the direct path between MN and CN, e.g., local HAs or MAPs with TA functionality, which are located in or close to the visited networks of MN and CN. Another issue is that the scenario shown in Figure 2 may not achieve complete location privacy, since MN can find out that the path over CN's HA is shorter than over MN's HA, because otherwise CN's HA would not have been selected as TA (assuming that distance information is the dominant parameter in the TA selection). 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. Although the geographical area derivable from this information is considered to be very large, it may be a reason to use other TA locations for improved location privacy. Note that if local TAs are selected, the disclosure of the MN's local TA prefix to CN and vice versa must be prevented, if both MN and CN require location privacy. This can be achieved by an HA-controlled TA selection and by routing of data packets over two intermediate TAs, e.g., a local HA or MAP in MN's and CN's visited networks as shown in Figure 4. Weniger & Aramaki Expires April 24, 2006 [Page 13] Internet-Draft MIPv6 ROTA October 2005 ------------ .. ... .. ------------ |Site 1 | . . . .. |Site 2 | | |.. .| | | MN's HA | | CN's HA | | | | | ------------ ------------ .. .. |----------| |----------| ---\loc./-------------\loc./--- MN---- HA/--------------- HA/----CN ---/ MAP\-------------/ MAP\--- ||| tunneled |Site 3 | .. |Site 4 | || not tunneled ------------ .------------ Figure 4: Data path between MN and CN with a TA in the visited network of MN and CN, respectively New issues must be considered in such scenarios. First, a local candidate TA must be discovered. This can, e.g., be done by DNS using some location-dependent HA names, e.g., as mentioned in [22], or by some local announcements, e.g., via DHCP or Router Advertisements. The discovery can be done by the HAs or by MN/CN, which then propose candidate TAs to their HAs. Furthermore, the HAs must agree on the TAs to be used. MN and CN cannot be involved in the TA selection, because this would reveal the prefix of CN's/MN's visited network. Another issue is that binding updates may need to be sent to multiple TAs and that those must contain TA addresses as CoAs. E.g., in Figure 4, TA1 must manage the bindings and for traffic directed to MN and CN, respectively. Finally, it may be necessary for security reasons that a binding may only be introduced in an TA by the HA that belongs to the corresponding HoA. In this case, some co-ordination between MN's HA and CN's HA is necessary to ensure that MN and CN first are notified to switch their reverse tunnels after both HAs have introduced their bindings in all TAs and the end-to-end tunnel is established. 3.4.1 Signaling Flow Figure 5 shows the signaling flow for the initial procedure resulting in the scenario shown in Figure 4, i.e., with local TAs in the visited networks of MN and CN. See Section 5 and Section 6 for a detailed description of the MN and HA operation, respectively, and Section 4 for new message types. Weniger & Aramaki Expires April 24, 2006 [Page 14] Internet-Draft MIPv6 ROTA October 2005 +-------+ +-------+ +--+ |localHA| +-------+ +-------+ |localHA| +--+ |MN| | /MAP | |MN's HA| |CN's HA| | /MAP | |CN| +--+ +-------+ +-------+ +-------+ +-------+ +--+ | ROTA_init_req | | | | |------------------------>| ROTA_req | | | | | |------------>| ROTA_init_req | | | | |------------------------>| | | | | ROTA_init_rep | | | | ROTA_rep |<------------------------| | ROTA_init_rep |<------------| | | |<------------------------| | BU | | | | BU |-------------------------->| | | |<------------| | BA | | | | BA |<--------------------------| | | |------------>| | | | | | | tun_estbl | | | | | |------------>| BU | | | | BU | |------------>| | | |<--------------------------| BA | | | | BA | |<------------| | | |-------------------------->| | | | | |ack+tun_estbl| | | | | |<------------| | | | | | ack | | | | tun_estbl_req |------------>| tun_estbl_req | |<------------------------| |------------------------>| | ack | | ack | |------------------------>| |<------------------------| | +-------+ +-------+ | |<=====>|MN's TA|<===============================>|CN's TA|<=====>| | +-------+ tunneled data packets +-------+ | Figure 5: Signaling flow for the initial procedure with local TAs in visited network First, MN or HA initiate ROTA as described in Section 3.3.1. The MN may propose candidate TA address(es) such as a local HA/MAP address and the distances to those using a new Mobility Option, the Candidate TA option, in ROTA Initiation Request or BU messages. The HA checks the validity of those addresses and may delete or add candidate TAs before sending them in a ROTA Request message with Candidate TA option to CN's HA. Similarly, CN and CN's HA may add or delete TA addresses. Note that both HAs should at least add their own address to the candidate TA list for the case that no visited network supports and hence no local TAs exists. If the distances in hops are passively measured using ROTA messages, CN's HA already has the Weniger & Aramaki Expires April 24, 2006 [Page 15] Internet-Draft MIPv6 ROTA October 2005 distances , and at this point in time. It also knows whether a local TA exist in MN's and CN's visited network, respectively, and if both MN and CN require location privacy (the latter is indicated by the P-flag in ROTA Request messages). E.g., by using the recommendations described in Appendix A, CN's HA can select TAs to be used and propose them to MN's HA by setting the respective O-bits in the Candidate TA option of the ROTA Reply message. Here, it is assumed that MN's HA agrees with the proposal of CN's HA. Otherwise, another round of request and reply messages may be needed. Note that MN's and CN's HA may request distance measurements from candidate TAs using ROTA Distance Information Request messages in order to find the best TAs providing the shortest path. After TAs have been selected, binding information about MN and CN must be sent to them using BU messages with alternate CoA option. Depending on the mechanisms used for authenticating and authorizing of binding updates, this can be done by one HA only or by both HA independently. Although many signaling messages could be saved if done by only one HA, it is proposed that both HAs introduce bindings independently for security reasons. It is assumed that an HA may only introduce binding information into an TA, when its prefix matches the HoA in the binding (see Section 8). The binding update messages contain MN's or CN's HoA as HoA and MN's or CN's CoA or the address of the corresponding TA as CoA. Finally, the HAs send Tunnel Establishment Notification messages to each other to indicate the successful establishment of bindings and notify MN and CN to switch their reverse tunnels. Note that this signaling flow applies to the initial ROTA procedure only. When MN moves to another subnet, basically only binding update messages must be sent to MN's HA and to MN's TA. The latter can be sent by MN's HA or, to improve handover signaling efficiency and delay, by the MN itself. In this case the MN must be able to dynamically establish an SA to the local HA/MAP. This may require an interface between TA and the AAA infrastructure to transfer cryptographic material needed from the home network to establish the SA. Such an interface is currently in development (see [21]) and may be re-used by ROTA. Note that MN cannot send a binding update to CN's TA if CN requires location privacy, because the address of CN's TA can contain location information about CN and, hence, must be hidden from MN. Again, the optimal TAs may change after movements. MN and CN may propose new local candidate TA addresses to their HAs after moving to a new local HA/MAP area, e.g., with BU messages using the Candidate TA option. The HAs then may decide to execute the TA selection algorithm again (using ROTA Request/Reply messages) and switch the Weniger & Aramaki Expires April 24, 2006 [Page 16] Internet-Draft MIPv6 ROTA October 2005 tunnels to new TAs, if necessary. Weniger & Aramaki Expires April 24, 2006 [Page 17] Internet-Draft MIPv6 ROTA October 2005 4. New Message Types The ROTA protocol messages are defined as new Mobility Header Types and Mobility Options. 4.1 Message Headers 4.1.1 Binding Update and Acknowledgement Message Binding Update and Acknowledgement messages are defined in [3]. The only modification is a new "TA registration" flag to be used when a binding shall be introduced in an TA. 4.1.2 ROTA Request/Notification Message 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 value of the hop limit field in the IPv6 header MUST be set to 255 to support passive distance measurements. The MH type is TBD. Weniger & Aramaki Expires April 24, 2006 [Page 18] Internet-Draft MIPv6 ROTA October 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type |A|P|M| Rsrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Target Address 2 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type This field specifies the type of ROTA Request/Notification message. The following types are currently registered: 0: ROTA Initiation Request This message requests ROTA initiation. 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. In conjunction with the Candidate TA option it can be used to negotiate TA address(es). Weniger & Aramaki Expires April 24, 2006 [Page 19] Internet-Draft MIPv6 ROTA October 2005 2: ROTA Abort Notification The purpose of this message is to abort an ROTA session and switch back to standard bi-directional tunneling mode. 3: ROTA Tunnel Establishment Notification The purpose of this message is to notify about an established tunnel and to inform about a new tunnel entry- point address. 4: ROTA Tunnel Establishment Request This message requests from a tunnel entry-point the establishment of a new tunnel. 5: ROTA Distance Information Request The purpose of this message is to request distance information from an TA. The corresponding reply message is the ROTA Distance Information message. The candidate TA mobility option may be used to request the distance to multiple candidate TAs. Message 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 a notification message. It MUST be set if the message transport service is considered unreliable. The flag can be ignored in request messages, since they are acknowledged by a reply message anyway. Privacy (P) This flag is used to inform the receiver of the message about the privacy requirements of the sender. If set, location privacy is required by the sender. MN and CN can inform their HAs about privacy requirements in ROTA Initiation Request messages, HAs can inform each other about privacy requirements of their MN/CN in ROTA Request messages. Metric (M) Weniger & Aramaki Expires April 24, 2006 [Page 20] Internet-Draft MIPv6 ROTA October 2005 The flag has only meaning for ROTA Distance Information Request messages. It indicates the metric to be used for requested distance measurements. If set to 0 the metric is hops, otherwise it is delay. Note that all nodes involved in a ROTA session MUST use the same metric. Reserved These fields are unused. They MUST be initialized to zero and MUST be ignored by the receiver. Target Address 1 The meaning of this field depends on the value of the Message Type field: If 0, 1 or 2 target address 1 is MN's HoA. If 3 and the message is sent to/received by an HA, the target address 1 is the address of MN's HoA. If 3 and the message is sent to/received by MN or CN, the target address 1 is the address of the new tunnel entry-point. If 4, the target address 1 is the address of the new tunnel exit-point. If 5, the target address 1 is an address, to which the receiving TA shall determine the distance (e.g., MN's CoA or correspondent TA). Target Address 2 The meaning of this field depends on the value of the Message Type field: If 0, 1 or 2 target address 2 is CN's HoA. If 3 and the message is sent to/received by an HA, the target address 2 is the address of CN's HoA. If 3 or 4 and the message is sent to/received by MN, the target address 2 is CN's HoA. If 3 or 4 and the message is sent to/received by CN, the target address 2 is MN's HoA. Weniger & Aramaki Expires April 24, 2006 [Page 21] Internet-Draft MIPv6 ROTA October 2005 If 5, the target address 2 is an address, to which the receiving TA shall determine the distance (e.g., CN's CoA or correspondent TA). 4.1.3 ROTA Reply/Acknowledgement Message 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. The value of the hop limit field in the IPv6 header MUST be set to 255 to enable passive distance measurements. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Msg Type 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. 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. In conjunction with the Candidate TA option it can be used to negotiate TA address(es). Weniger & Aramaki Expires April 24, 2006 [Page 22] Internet-Draft MIPv6 ROTA October 2005 2: ROTA Abort Acknowledgement The purpose of this message is to acknowledge the abort of an ROTA session. 3: ROTA Tunnel Establishment Reply The purpose of this message is to indicate the outcome of the Tunnel Establishment Request. 4: ROTA Tunnel Establishment Notification Acknowledgement The purpose of this message is to acknowledge ROTA Tunnel Establishment Notification Message. 5: ROTA Distance Information Acknowledgement The purpose of this message is to acknowledge the ROTA Distance Information Message. 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 130: Request not accepted, insufficient resources 131: Request not accepted, candidate TAs not accepted Message 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. Weniger & Aramaki Expires April 24, 2006 [Page 23] Internet-Draft MIPv6 ROTA October 2005 4.1.4 ROTA Distance Information Message The ROTA Distance Information Message is used to notify other entities about distances between two nodes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence # |A| Reserved | # Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address of Source 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address of Target 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Distance S1-T1 |M| Reserved | Distance Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . .... . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message 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 April 24, 2006 [Page 24] Internet-Draft MIPv6 ROTA October 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 Source X Address of source X. Address of Target X Address of target X. Distance SY-TY An 8-bit unsigned integer indicating the measured distance between source X and target X. If the metric is delay, the value of this field is the delay divided by 10ms. Any delay higher than 2550ms is represented by 255. Metric (M) The flag indicates the metric of the distances. If set to 0 the metric is hops, otherwise it is delay. Distance Sequence # A 16-bit unsigned integer indicating the freshness of the distance information. It must always be provided by the node that measured the distance. 4.2 Mobility Options 4.2.1 Candidate TA Option This option can be used to propose candidate TA addresses. Type is TBD. Weniger & Aramaki Expires April 24, 2006 [Page 25] Internet-Draft MIPv6 ROTA October 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address of Candidate TA 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Distance to TA1|M|O|T|Reserved | Distance Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . .... . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved These fields are unused. They MUST be initialized to zero and MUST be ignored by the receiver. Address of Candidate TA X Address of candidate TA X. Distance TA1 An 8-bit unsigned integer indicating the distance between the MN belonging to the sender and the candidate TA. The distance can be omitted by setting it to 0, meaning "unknown distance". If metric is delay, the value of this field is the delay divided by 10ms. Any delay higher than 2550ms is represented by 255. Metric (M) The flag indicates the metric of the distances. If set to 0 the metric is hops, otherwise it is delay. Proposed TA (O) The entries which have the P-flag set represent the set of TAs proposed by the sender. Other entries are alternative TAs. TA proposal modified (T) Weniger & Aramaki Expires April 24, 2006 [Page 26] Internet-Draft MIPv6 ROTA October 2005 If this flag is set, the O-flag of this TA has been changed, compared to the Candidate TA Option of the last Request/Reply message. If the entry is new and the O-flag is set, the T-flag MUST be set as well. Distance Sequence # A 16-bit unsigned integer indicating the freshness of the distance information. It must always be provided by the node that measured the distance. Weniger & Aramaki Expires April 24, 2006 [Page 27] Internet-Draft MIPv6 ROTA October 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. A ROTA session identification is implicitly given by the tuple . 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 TA address(es) for incoming data packets o TA address for outgoing data packets o Message Sequence Number A Candidate TA Cache may be maintained, which contains addresses of known candidate TAs and the distance to those. 5.2 Using Security Associations All ROTA messages MUST be sent authenticated and integrity protected, e.g., over the MN-HA IPsec SAs required for Mobile IPv6 signaling messages. 5.3 Sending ROTA Initiation Request 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. This message must contain CN's HoA. It MUST set the P-bit if it requires privacy and it MAY propose candidate TA address(es) and the corresponding distances. The message sequence number field in the message as well as in the ROTA MN Cache is increased for every Request message sent. The MN updates the corresponding entry in its ROTA MN Cache. 5.4 Receiving ROTA Initiation Reply After receiving a positive reply with a sequence number matching the corresponding request message, the ROTA MN Cache is updated accordingly. Weniger & Aramaki Expires April 24, 2006 [Page 28] Internet-Draft MIPv6 ROTA October 2005 5.5 Receiving ROTA Initiation Request When receiving a ROTA Initiation Request, the MN is acting as CN. It MUST reply with a ROTA Initiation Reply. 5.6 Sending ROTA Initiation Reply The ROTA Initiation Reply message contains a status code indicating that ROTA is either accepted or rejected. The sequence number must be set to the value of the corresponding request message. If accepted, a ROTA MN Cache entry must be created. The P-bit is set according to the privacy requirements. TA addresses may be proposed in a Candidate TA option. 5.7 Sending Reverse Tunneled Packets If an ROTA session for the destination address exists and the ROTA MN Cache indicates that the tunnel is established, data packets are reverse tunneled to the corresponding outgoing tunnel endpoint address. 5.8 Receiving Reverse Tunneled Packets Incoming data packets are accepted if the IP source address of the IP tunnel header matches one of the TA addresses for incoming data packets in the ROTA MN Cache entry corresponding to the IP source address in the inner IP header. 5.9 Sending Binding Updates Binding Updates to MN's HA are sent as described in [3], i.e., over the MN-HA IPsec SA. Binding Updates sent to MN's TA MAY be sent by MN. In this case it must be able to dynamically establish an SA to the TA. This may require an interface to an AAA infrastructure to transfer cryptographic material needed to establish the SA. Such an interface is currently in development (see [21]) and may be re-used by ROTA. 5.10 Receiving Tunnel Establishment Request messages 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 Cache, the MN sets up the tunnel. The corresponding fields, such as the tunnel endpoint fields, and the sequence number field in the corresponding ROTA MN Cache entry are updated accordingly. The MN MUST return a Tunnel Establishment Reply Weniger & Aramaki Expires April 24, 2006 [Page 29] Internet-Draft MIPv6 ROTA October 2005 indicating the outcome of the check. 5.11 Sending Tunnel Establishment Reply messages The message must contain a status code indicating the outcome of the check. The sequence number is set to the value of the corresponding Request message. 5.12 Receiving Tunnel Establishment Notification messages On receipt of a Tunnel Establishment Notification, the same checks as described in the last section apply. If successful, the MN updates the corresponding fields, such as 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 April 24, 2006 [Page 30] Internet-Draft MIPv6 ROTA October 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 [3], 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 MN's privacy requirements o CN's privacy requirements o CN's HA address o Current TA address(es) of MN o Message Sequence number o A Candidate TA Cache, which contains addresses of known candidate TAs and their distance to MN/CN. A Certificate Cache may be maintained, which contains recently received public keys and certificates. A Distance Information Cache is used to store distances between MN/CN and TAs. It contains entries with the following data o Source address o Destination address o Distance measured in hops and/or delay o Distance Sequence Number o Lifetime An HA acting as a TA additionally maintains an ROTA TA Cache. Binding Cache entries are extended by a TA registration flag to distinguish TA registrations from home registrations. TA registration entries conceptually point to ROTA TA Cache entries. Weniger & Aramaki Expires April 24, 2006 [Page 31] Internet-Draft MIPv6 ROTA October 2005 Each ROTA TA Cache entry contains the following data o MN's HA address o Message Sequence Number 6.2 Using Security Associations All ROTA messages sent between MN's HA and MN and CN's HA and CN MUST be sent authenticated and integrity protected over the MN-HA IPsec SAs required for Mobile IPv6 signaling messages. All ROTA messages sent between MN's HA and CN's HA or MN's/CN's HA and TA MUST be sent authenticated and integrity protected over beforehand (e.g., with IKE/IKEv2 [16] [17]) established IPsec SAs. 6.3 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, the HA MUST return an ROTA Initiation Reply indicating the outcome of the initiation. The Message Sequence Number in the ROTA Initiation Reply MUST match those in the corresponding Initiation Request. During ROTA initiation, the HA creates the corresponding entries in its ROTA HA Cache. If the message contains a Candidate TA Mobility Option, the HA must check whether a trust relationship exists to those TAs. New valid TAs may be added to the Candidate TA Cache. 6.4 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 message sequence number. The P-flag in the message MUST be set to the value set by the MN in the corresponding ROTA Initiation Request message. If the HA has triggered ROTA, it must know MN's privacy requirements from some prior arrangement. The HA MUST propose at least its own address as candidate TA address in the Candidate TA Mobility Option and MAY include more candidate TAs, e.g., proposed by MN in the Candidate TA option. It MAY set the O-flag to propose one or multiple of the candidates as TA. If no reply is received after sending multiple Request messages, it can be concluded that CN's HA does not support ROTA and ROTA must be aborted. Weniger & Aramaki Expires April 24, 2006 [Page 32] Internet-Draft MIPv6 ROTA October 2005 6.5 Receiving ROTA Request 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 accepts to execute ROTA. This message may not contain the candidate TAs proposed by MN in a Candidate TA option, since they may reveal location information. If such an Initiation 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. Before a ROTA Reply message is sent, the HA creates or updates the corresponding entry in its ROTA HA Cache. 6.6 Sending ROTA Reply message If CN does not have an active communication session with the address contained in the ROTA Initiation Request message or does not accept 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 message. The message sequence number is set to the value of the corresponding Request messages. The P-flag in the message MUST be set to the value set by the CN in the corresponding ROTA Initiation Reply message sent by CN or known from some prior arrangement. The HA MUST propose at least its own address as candidate TA address in the Candidate TA Mobility Option and MAY include more candidate TAs, e.g., proposed by CN in a Candidate TA option. It also adds the agreed candidate TAs that were proposed by MN's HA in the ROTA Request message. It MUST set the O-flags in the Candidate TA option to propose a set of TAs to be used. 6.7 Receiving ROTA Reply The receiver only processes the Reply message if it has sent a corresponding Request with the same sequence number to the sender address before. If this is not the case, the HA MAY return an ROTA Reply indicating the rejection of ROTA. The HA checks the proposed TAs in the Candidate TA option. If the HA does not accept the set of TAs proposed by CN's HA, it MUST sent a new Request message with a modified list of candidate TAs and new set of TAs marked with the O-flag. In this case, the T-flag MUST be set in the corresponding entries in the Candidate TA Option. The TA selection may be supported by additional distance measurements, which may require MN's and CN's HA to exchange BU messages for being able to measure the distance to MN's and CN's CoA. Furthermore, Distance Information messages may be exchanged to report measured distances. If both HAs Weniger & Aramaki Expires April 24, 2006 [Page 33] Internet-Draft MIPv6 ROTA October 2005 have agreed on a set of TAs, the HAs may proceed with sending BU messages to those. 6.8 Sending Binding Updates A Binding Update may only be sent to a TA by an HA with a subnet prefix matching the HoA in the binding. The newly defined TA registration flag must be set and the alternate CoA option MUST contain MN's/CN's CoA or an TA address. Additionally, the Binding Update List MUST be updated as specified in [3]. 6.9 Receiving Binding Updates If an HA receives a BU from one of its MNs, it processes it as described in [3]. Additionally, it sends a corresponding BU to the current TA(s). An HA acting as TA may receive a Binding Update from an HA with TA registration flag set. It 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 [3]. Instead, it checks whether the sender is authorizes to act as an HA for the HoA contained in BU message (this could, e.g., be realized with certificates by comparing the HoA in the binding with the prefixes contained in an IP address extension of the certificate of the sender HA. See Section 8 for details). If the sender is not authorized, 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 [3]. 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. 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 [3]. 6.10 Receiving Binding Acknowledgements The checks described in [3] apply. If the HA has sent BUs to TAs different from CN's HA and all corresponding BAs has been received, a Tunnel Establishment Notification message is sent to CN's HA. 6.11 Sending Tunnel Establishment Notification message After the BAs from all TAs have been received, a Tunnel Establishment Notification message is sent to the CN's HA. Weniger & Aramaki Expires April 24, 2006 [Page 34] Internet-Draft MIPv6 ROTA October 2005 6.12 Receiving Tunnel Establishment Notification message After the Tunnel Establishment Notification message has been received by CN's HA and BAs from all TAs have been received, a Tunnel Establishment Notification Acknowledgement message is sent to the CN's HA. Furthermore, a Tunnel Establishment Request message is sent to CN. If no Tunnel Establishment Notification message is received by CN's HA, this might be an indication that the ROTA Reply message got lost. In this case, CN's HA may resend the ROTA Reply message. 6.13 Receiving Tunnel Establishment Notification Acknowledgement message On receipt of a Tunnel Establishment Notification Acknowledgement message from CN's HA, a Tunnel Establishment Request message is sent to MN. 6.14 Intercepting Data Packets An TA MUST NOT intercept data packets for nodes with 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 [3] 6.15 Sending and Receiving Reverse Tunneled Packets Reverse tunneled packets are handled the same way as in [3]. 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.16 Receiving a ROTA Abort Notification message MNs can abort a ROTA session and switch to standard Mobile IPv6 bi- directional tunneling mode by sending a ROTA Abort Notification message to its HA. The Abort message MUST set the A-flag. The HA then sends a corresponding message to all active TAs and to CN's HA, which then will send an abort notification to CN. The corresponding ROTA HA and MN Cache entries may first be deleted after the corresponding acknowledgements have been received. 6.17 Management of ROTA HA Cache Entries ROTA HA Cache entries are deleted when the corresponding Binding Cache entries are deleted or the ROTA session is aborted. Weniger & Aramaki Expires April 24, 2006 [Page 35] Internet-Draft MIPv6 ROTA October 2005 7. IANA Considerations ROTA introduces new Mobility Header Types and Mobility Options (see Section 4). Weniger & Aramaki Expires April 24, 2006 [Page 36] Internet-Draft MIPv6 ROTA October 2005 8. Security Considerations Different issues have to be considered to ensure that ROTA does not introduce new security leaks. For instance, a trust relationship between MN's and CN's HA and between MN's/CN's HA and TAs must exist. Since multiple ways of establishing and managing trust relationships exist and the choice depends on deployment scenarios, we only give a short discussion of attacks and possible countermeasures in this section. A detailed specification of the security solution is left for future work. Most attacks are taken from [18], which describes them in more detail in the context of an analysis of the Mobile IPv6 route optimization mode. 8.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 the victim may be a mobile node as well as a 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 [2]: The certificate binds the public key to the sender address. Alternatively, Cryptographically Generated Addresses (CGA) [6] 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 [16] [17] established IPsec ESP [15] SA. In Mobile IPv6 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 [3]. However, the CoA in the BU message is not checked for correctness. As discussed in [3], 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 [3]). An option giving a higher level of security would be to conduct additional CoA reachability tests, e.g., as described in [19]. BU messages sent from HA to TA can be authenticated with IPsec as Weniger & Aramaki Expires April 24, 2006 [Page 37] Internet-Draft MIPv6 ROTA October 2005 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 (for home registrations, not for TA registrations), e.g., in an IP address extension [4]. This is similar to the approach taken by SEND [5], 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 [5], 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 as described above and the corresponding HA must be notified, which then can discontinue the service. Alternatively, CoA reachability tests can be introduced. If BUs are sent from MN/CN to TAs directly, an SA must exist. This can be dynamically established using an interface to an AAA infrastructure (to transfer cryptographic material needed to establish the SA). Such an interface is currently in development (see [21]) and may be re-used by ROTA. 8.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 to an TA. 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 message sequence numbers. 8.3 Denial of Service (DoS) Attacks 8.3.1 Reflection The introduction of false binding information in another node's Binding Cache, either with false CoA or false HoA, 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 8.1. Weniger & Aramaki Expires April 24, 2006 [Page 38] Internet-Draft MIPv6 ROTA October 2005 8.3.2 Amplification Amplification can make reflection attacks even more dangerous. If an 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. Although ROTA follows this guideline, the Candidate TA option may result in reply messages bigger than the corresponding requests. Hence, data origin authentication is very important here: Requests may only be replied if their origin is authenticated and if received from trusted nodes. This can, e.g., be achieved if ROTA Request/Reply messages are only sent over IPsec SAs. 8.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 in the first place, this requirement can be achieved. Between MN and its HA as well as between CN and its HA IPsec SAs are required for Mobile IPv6 signaling anyway [3]. 8.3.4 CPU Exhaustion Verification (e.g., 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 [20] using cookies. Hence, the use of IKEv2 to establish IPsec SAs between HAs and TAs can alleviate this problem. If IKEv2 is not used, another weak countermeasure could be to first start verification after receiving a positive ROTA Initiation Reply from CN. CN additionally checks, whether it has an active Weniger & Aramaki Expires April 24, 2006 [Page 39] Internet-Draft MIPv6 ROTA October 2005 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 or first has to start a communication session with 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 [18]). 8.4 Other Attacks on Sending Binding Information Other attacks are described [18] 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. 8.5 Attacks against Location Privacy To ensure 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 intended receiver of a 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 and it may not be under control of an attacker. This can, e.g., be achieved by using authorization certificates, which can be verified when a shared trusted anchor exists. This approach is again similar to SEND [5], where certificates are used to authorize routers to act as routers. Note that partial protection against profiling attacks by hiding the HoA from eavesdroppers might be possible with ROTA as well by encrypting signaling and data traffic on all IPsec tunnel segments, as described in [8] for the MN-HA segment. However, this approach is considered computationally expensive for the HAs since the data packet payload is unnecessarily encrypted as well. Other approaches, which only replace the HoA with a privacy label [8] seem more appropriate and may be combined with ROTA. 8.6 Overlay Re-routing Attacks Since the optimized route depends on distance information obtained from 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. All ROTA messages including Distance Information messages are required to be sent authenticated Weniger & Aramaki Expires April 24, 2006 [Page 40] Internet-Draft MIPv6 ROTA October 2005 and integrity protected. However, the format of active probe messages and their protection is not yet specified. This is left for future work. Weniger & Aramaki Expires April 24, 2006 [Page 41] Internet-Draft MIPv6 ROTA October 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] 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. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. 9.2 Informative References [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [6] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [7] Koodli, R., "IP Address Location Privacy and IP Mobility", draft-koodli-mip6-location-privacy-00 (work in progress), February 2005. [8] 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. [9] Haddad, W., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement", draft-haddad-momipriv-problem-statement-01 (work in progress), February 2005. [10] 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. [11] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", draft-wakikawa-nemo-orc-01 (work in progress), November 2004. [12] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", Weniger & Aramaki Expires April 24, 2006 [Page 42] Internet-Draft MIPv6 ROTA October 2005 draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. [13] Thubert, P., "Global HA to HA protocol", draft-thubert-nemo-global-haha-00 (work in progress), October 2004. [14] Krishnamurthi, G., Chaskar, H., and R. Siren, "Providing End- to-End Location Privacy in IP-based Mobile Communication", IEEE WCNC 2004, March 2004. [15] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. [18] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. [19] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using a State Cookie", draft-dupont-mipv6-rrcookie-01 (work in progress), June 2005. [20] Bao, F., "Certificate-based Binding Update Protocol (CBU)", draft-qiu-mip6-certificated-binding-update-03 (work in progress), March 2005. [21] Giaretta, G., "Goals for AAA-HA interface", draft-ietf-mip6-aaa-ha-goals-00 (work in progress), May 2005. [22] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-00 (work in progress), June 2005. Weniger & Aramaki Expires April 24, 2006 [Page 43] Internet-Draft MIPv6 ROTA October 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 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 April 24, 2006 [Page 44] Internet-Draft MIPv6 ROTA October 2005 Appendix A. Recommendations for TA Selection The TA selection algorithm must meet the privacy requirements of MN and CN, should provide good route optimization and should minimize the signaling traffic. The input parameters of the algorithm are at least the privacy requirements of MN and CN (as indicated with the P-flag in ROTA Initiation Request/Reply messages), a list of candidate TAs (provided by MN, CN, MN's HA and CN's HA), and optionally distance information. The candidate TA list should contain the addresses of MN's HA and CN's HA and may contain local HAs or other external HAs that may act as TA. However, the list may only contain TAs that are trusted by MN's and CN's HA. Untrusted TA addresses must be deleted from the list by MN's and CN's HA. In order to minimize the signaling traffic, ROTA should be aborted if the route is already short enough without using any TAs or if the benefit of route optimization is small. Otherwise, it should be checked whether the route is short enough when ROTA without visited network support is used, i.e., either MN's or CN's HA serves as TA. If true and if the privacy requirements allow it, either of both HAs should be preferred as TA, since establishing tunnels over local HAs/ MAPs requires more signaling traffic and is only possible if the visited networks support ROTA. A single local TA may only be used, if the respective MN/CN does not require location privacy, whereas two local TAs can provide location privacy for both MN and CN. Note that if MN's and CN's HA cannot agree on TAs in a first round of Request/Reply messages, multiple rounds of Request/Reply messages may be necessary. If the proposed set of TAs is modified, corresponding entries in the Candidate TA Option MUST be marked with the T-flag. Further, it must be ensured that the TA selection eventually terminates, e.g., by counting the additional rounds and aborting after a certain number of rounds. Weniger & Aramaki Expires April 24, 2006 [Page 45] Internet-Draft MIPv6 ROTA October 2005 Appendix B. Support of Stationary Correspondent Nodes ROTA targets mobile-to-mobile communication scenarios, but can also be used for communication with stationary nodes. If CN is mobile, MN's HA and CN's HA perform the ROTA initiation and TA selection on behalf of MN and CN to ensure location privacy and thus can be called Privacy Agents (PA) of MN and CN, respectively. ROTA-aware stationary CNs require a similar pre-arranged trust relationship to an PA. Additionally, the PA should be able to act as TA and the PA must have a trust relationship with other HAs. Of course, a stationary CN does not require a CoA. Hence, the PA does not serve as an HA and does not manage a binding or intercept any packets for the stationary node. Note that either the TA to be used by CN is always on the path (e.g., because it is co-located with a gateway router) or the stationary CN must be adapted to be able to reverse tunnel data packets to the TA. 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 for good route optimization and location privacy support. Weniger & Aramaki Expires April 24, 2006 [Page 46] Internet-Draft MIPv6 ROTA October 2005 Appendix C. Discussion of Further Optimizations One drawback of ROTA 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 possible optimizations include support for an improved TA selection that considers more parameters, e.g., more detailed privacy requirements (e.g., location privacy is required, but disclosing location in country size-like resolution is o.k.), application requirements for the route length/delay or load factors. Additional features to be considered in future version is the support for mobile networks and an interface to an AAA infrastructure, which may be required for service authorization and charging. Such an interface is currently in development (see [21]) and may be re-used by ROTA. Weniger & Aramaki Expires April 24, 2006 [Page 47] Internet-Draft MIPv6 ROTA October 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 April 24, 2006 [Page 48]