idnits 2.17.00 (12 Aug 2021) /tmp/idnits1288/draft-weniger-rota-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1881. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2005) is 6056 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3280 (ref. '2') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-01 == Outdated reference: A later version (-02) exists of draft-haddad-momipriv-threat-model-00 == Outdated reference: draft-ietf-mipshop-hmipv6 has been published as RFC 4140 == Outdated reference: A later version (-02) exists of draft-thubert-nemo-global-haha-00 -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '15') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '16') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 == Outdated reference: A later version (-06) exists of draft-dupont-mipv6-rrcookie-01 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-00 == Outdated reference: draft-ietf-mip6-bootstrapping-split has been published as RFC 5026 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Weniger 3 Internet-Draft T. Aramaki 4 Expires: April 24, 2006 Panasonic 5 October 21, 2005 7 Route Optimization and Location Privacy using Tunneling Agents (ROTA) 8 draft-weniger-rota-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 24, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 Mobile IPv6 in route optimization mode reveals mobile node's care-of 42 address to the correspondent node and hence cannot provide location 43 privacy. In contrast, Mobile IPv6 in bi-directional tunneling mode 44 can provide location privacy, but the resulting route may be far from 45 optimal, especially when correspondent node is mobile as well. This 46 may be an issue for conversational mobile-to-mobile communication 47 scenarios, e.g., using VoIP. The draft discusses the problem of 48 providing both location privacy and route optimization with Mobile 49 IPv6 and describes a solution in terms of an optional extension to 50 Mobile IPv6. The basic idea is that mobile nodes switch the reverse 51 tunnel endpoint in bi-directional tunneling mode from their home 52 agent to a so-called tunneling agent in an on-demand manner. To 53 ensure location privacy, the tunneling agent selection is done by the 54 home agents. The solution does not require the mobile node to change 55 its home address and does not rely on visited network support. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Introduction and Problem Description . . . . . . . . . . . . . 5 61 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 63 2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Overview of ROTA . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1 Assumptions about Trust Model . . . . . . . . . . . . . . 8 66 3.2 The ROTA Approach and its Benefits . . . . . . . . . . . . 8 67 3.3 ROTA in scenarios without visited network support . . . . 9 68 3.3.1 Signaling Flow . . . . . . . . . . . . . . . . . . . . 11 69 3.4 ROTA in scenarios with visited network support . . . . . . 13 70 3.4.1 Signaling Flow . . . . . . . . . . . . . . . . . . . . 14 71 4. New Message Types . . . . . . . . . . . . . . . . . . . . . . 18 72 4.1 Message Headers . . . . . . . . . . . . . . . . . . . . . 18 73 4.1.1 Binding Update and Acknowledgement Message . . . . . . 18 74 4.1.2 ROTA Request/Notification Message . . . . . . . . . . 18 75 4.1.3 ROTA Reply/Acknowledgement Message . . . . . . . . . . 22 76 4.1.4 ROTA Distance Information Message . . . . . . . . . . 24 77 4.2 Mobility Options . . . . . . . . . . . . . . . . . . . . . 25 78 4.2.1 Candidate TA Option . . . . . . . . . . . . . . . . . 25 79 5. Modified Mobile Node Operation . . . . . . . . . . . . . . . . 28 80 5.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 28 81 5.2 Using Security Associations . . . . . . . . . . . . . . . 28 82 5.3 Sending ROTA Initiation Request . . . . . . . . . . . . . 28 83 5.4 Receiving ROTA Initiation Reply . . . . . . . . . . . . . 28 84 5.5 Receiving ROTA Initiation Request . . . . . . . . . . . . 29 85 5.6 Sending ROTA Initiation Reply . . . . . . . . . . . . . . 29 86 5.7 Sending Reverse Tunneled Packets . . . . . . . . . . . . . 29 87 5.8 Receiving Reverse Tunneled Packets . . . . . . . . . . . . 29 88 5.9 Sending Binding Updates . . . . . . . . . . . . . . . . . 29 89 5.10 Receiving Tunnel Establishment Request messages . . . . . 29 90 5.11 Sending Tunnel Establishment Reply messages . . . . . . . 30 91 5.12 Receiving Tunnel Establishment Notification messages . . . 30 92 6. Modified Home Agent Operation . . . . . . . . . . . . . . . . 31 93 6.1 Conceptual Data Structures . . . . . . . . . . . . . . . . 31 94 6.2 Using Security Associations . . . . . . . . . . . . . . . 32 95 6.3 ROTA Initiation . . . . . . . . . . . . . . . . . . . . . 32 96 6.4 Sending ROTA Request . . . . . . . . . . . . . . . . . . . 32 97 6.5 Receiving ROTA Request . . . . . . . . . . . . . . . . . . 33 98 6.6 Sending ROTA Reply message . . . . . . . . . . . . . . . . 33 99 6.7 Receiving ROTA Reply . . . . . . . . . . . . . . . . . . . 33 100 6.8 Sending Binding Updates . . . . . . . . . . . . . . . . . 34 101 6.9 Receiving Binding Updates . . . . . . . . . . . . . . . . 34 102 6.10 Receiving Binding Acknowledgements . . . . . . . . . . . . 34 103 6.11 Sending Tunnel Establishment Notification message . . . . 34 104 6.12 Receiving Tunnel Establishment Notification message . . . 35 105 6.13 Receiving Tunnel Establishment Notification 106 Acknowledgement message . . . . . . . . . . . . . . . . . 35 107 6.14 Intercepting Data Packets . . . . . . . . . . . . . . . . 35 108 6.15 Sending and Receiving Reverse Tunneled Packets . . . . . . 35 109 6.16 Receiving a ROTA Abort Notification message . . . . . . . 35 110 6.17 Management of ROTA HA Cache Entries . . . . . . . . . . . 35 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 113 8.1 Address Stealing . . . . . . . . . . . . . . . . . . . . . 37 114 8.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 38 115 8.3 Denial of Service (DoS) Attacks . . . . . . . . . . . . . 38 116 8.3.1 Reflection . . . . . . . . . . . . . . . . . . . . . . 38 117 8.3.2 Amplification . . . . . . . . . . . . . . . . . . . . 39 118 8.3.3 Memory Exhaustion . . . . . . . . . . . . . . . . . . 39 119 8.3.4 CPU Exhaustion . . . . . . . . . . . . . . . . . . . . 39 120 8.4 Other Attacks on Sending Binding Information . . . . . . . 40 121 8.5 Attacks against Location Privacy . . . . . . . . . . . . . 40 122 8.6 Overlay Re-routing Attacks . . . . . . . . . . . . . . . . 40 123 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 124 9.1 Normative References . . . . . . . . . . . . . . . . . . . 42 125 9.2 Informative References . . . . . . . . . . . . . . . . . . 42 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 127 A. Recommendations for TA Selection . . . . . . . . . . . . . . . 45 128 B. Support of Stationary Correspondent Nodes . . . . . . . . . . 46 129 C. Discussion of Further Optimizations . . . . . . . . . . . . . 47 130 Intellectual Property and Copyright Statements . . . . . . . . 48 132 1. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [1]. 138 In addition to the terminology used in [3], the following acronyms 139 are used: 141 +---------------------------------+---------------------------------+ 142 | Acronym | Meaning | 143 +---------------------------------+---------------------------------+ 144 | MN | Mobile node | 145 | | | 146 | CN | Correspondent node | 147 | | | 148 | HA | Home agent | 149 | | | 150 | HoA | Home address | 151 | | | 152 | CoA | Care-of address | 153 | | | 154 | BU | Binding update | 155 | | | 156 | BA | Binding acknowledgement | 157 | | | 158 | TA (of node X) | A tunneling agent (TA) is a | 159 | | logical entity that is a tunnel | 160 | | endpoint for node X on behalf | 161 | | of node X's HA, with node X's | 162 | | HoA matching a subnet prefix of | 163 | | node X's HA, but not matching a | 164 | | subnet prefix of the TA. A TA | 165 | | can be co-located with an HA | 166 | | (with both entities serving | 167 | | different nodes) or MAP. | 168 +---------------------------------+---------------------------------+ 170 2. Introduction and Problem Description 172 2.1 Background 174 Location privacy is the ability to hide the location from others. 175 This is considered to be an important feature for mobile users, since 176 the disclosure of the location can have serious impacts on the user's 177 life. Because the routing in the Internet is hierarchical, IP 178 addresses used for global routing usually contain location 179 information. Moreover, protocol extensions, e.g., to DNS as well as 180 software tools exist that can be used to derive the approximate 181 geographic location from a globally routable IP address [10][7]. 183 In Mobile IPv6 [3], HoA and CoA usually represent identity and 184 location of the MN, respectively. Currently, two modes are defined 185 in [3]: bi-directional tunneling and route optimization. While the 186 former mode requires all data packets to be routed over the home 187 agent of the MN, the latter utilizes the direct path between MN and 188 CN. As a consequence, route optimization mode usually reduces the 189 packet delay, which is beneficial for interactive applications. 190 However, it does not provide location privacy, since the CN learns 191 MN's CoA and, thus, the topological location of the MN. In contrast, 192 bi-directional tunneling mode does not reveal MN's CoA to CN, since 193 BU messages containing MN's CoA and data packets with MN's CoA in the 194 IP header are terminated at MN's HA. Thus, MN's location can be 195 hidden from CN (see section 2.1 of [8]). However, bi-directional 196 tunneling may lead to long routes, especially if CN is mobile as 197 well. Since mobile-to-mobile communications with conversational 198 nature (e.g., with VoIP) is considered to be a common scenario in the 199 future, the utilization of standard Mobile IPv6 in bi-directional 200 tunneling mode for location privacy-enabled communication may be 201 inefficient and may delay packets to an extent that is harmful to the 202 communication. Hence, a mechanism that provides both location 203 privacy and route optimization, resulting in higher efficiency and 204 lower packet delays than bi-directional tunneling mode, is desirable. 206 2.2 Problem Statement 208 The first part of the problem is to provide location privacy to 209 mobile nodes. In the context of Mobile IPv6, two problems are 210 considered to be the most important: preventing the disclosure of 211 MN's CoA to CN and preventing the disclosure of MN's HoA to 212 eavesdropper [7]. While many currently discussed proposals address 213 the second problem, this document addresses the first one, i.e., the 214 disclosure of the CoA to CN. The solution shall support full and bi- 215 directional location privacy, meaning that the MN's location may not 216 be revealed to a mobile CN and vice versa and that disclosing the 217 location with lower resolution (e.g., MN's visited domain prefix is 218 disclosed instead of prefix of MN's AR) is not an acceptable level of 219 privacy. Profiling and tracking issues such as hiding MN's HoA from 220 eavesdroppers or other aspects of privacy not directly related to 221 Mobile IPv6 addresses, such as the profiling based on lower- or 222 upper-layer identities or based on protocol values [9] are out of the 223 scope of this document. However, it should be possible to combine 224 solutions for those problems with the solution proposed in this 225 document. 227 A second part of the problem is to provide route optimization also 228 for privacy-enabled communication sessions. In Mobile IPv6, the bi- 229 directional tunneling mode can provide location privacy. However, in 230 many scenarios bi-directional tunneling mode results in long routes 231 (see Figure 1) and thus may be problematic for delay-sensitive 232 applications such as VoIP. This is becoming even worse if CN is 233 mobile, too. Note that the terms route optimization as used in this 234 document means improved efficiency of routing by shortening the 235 route. The optimized route does not need to be optimal (i.e., equal 236 length than the direct route between MN and CN), but it must be good 237 enough, e.g., to support conversational communications. Further, 238 route optimization of active communication sessions shall be 239 possible. This is especially beneficial when a node travels large 240 topological distances during an active session, which is considered 241 to happen frequently in case of inter-domain and inter-technology 242 handovers. 244 Another issue to be considered is deployment. If a solution relies 245 on support from visited network infrastructure (e.g., modified ARs), 246 every visited network must support this solution. Otherwise either 247 the route optimization or the privacy support (or even the 248 communication session itself) breaks when the MN moves to a network 249 without support. However, global universal deployment is very 250 difficult to achieve. Hence, the solution should not rely on visited 251 network support, but should benefit from it if available. 253 In summary, the problem this document addresses is hiding MN's CoA 254 from CN and providing route optimization at the same time without 255 relying on support from visited networks. The solution shall not 256 create any significant new security problems in comparison to Mobile 257 IPv6/IPv6. Since the problem is especially severe if CN is mobile 258 and since mobile-to-mobile communication is expected to be very 259 common in the future (e.g., with VoIP), this is considered as the 260 main target scenario. However, stationary nodes shall be supported 261 as well. 263 2.3 Related Work 265 Various protocols have been proposed, which could be used to provide 266 both route optimization and location privacy to some extent [11] [12] 267 [13] [14]. Since most of the protocols have been developed for other 268 purposes, deficiencies exist and they do not meet the requirements 269 listed in Section 2.2. For instance, they require universal 270 deployment of modified (access) routers or only provide uni- 271 directional location privacy (i.e., only for MN or CN, not both) or 272 limited location privacy (i.e., only a topological area containing 273 MN's location is known). 275 It may seem that the Mobile IPv6 bootstrapping solution (see [22] for 276 split scenario) can provide both route optimization and location 277 privacy, since route optimization in bi-directional tunneling mode 278 can be achieved by reverse tunneling to dynamically allocated local 279 HAs or HAs of nearby networks. However, the problem is that in this 280 case the new HoA belongs to the visited network (or a nearby network) 281 and hence contains location information. The bootstrapping solution 282 provides means to update DNS with the new HoA, so that other nodes 283 are able to start communication sessions with MN using the new HoA. 284 But updating DNS with the new HoA or disclosing the new HoA by other 285 means (e.g., during a VoIP call setup) may reveal information about 286 MN's location. This is especially an issue if other nodes are able 287 to find out that the new HoA belongs to the MN's visited network (or 288 a nearby network), e.g., because MN's HA selection policy is known. 289 In contrast, if the new HoA is not disclosed, other nodes are not 290 aware of it and hence cannot initiate communication session with MN 291 using the optimized route. Consequently, route optimization and full 292 location privacy support cannot be provided at the same time. 293 Another disadvantage with respect to route optimization by 294 bootstrapping with local or nearby HAs is that route optimization of 295 active communication sessions is not possible in a manner transparent 296 for higher layers due to the need for changing the HoA. 298 3. Overview of ROTA 300 3.1 Assumptions about Trust Model 302 To allow a large scale applicability and deployment, no pre- 303 established trust relationship shall be required between MN and CN or 304 between MN/CN and HAs located outside the home link, respectively. 305 Also, no "global PKI" is assumed, i.e., MN and CN shall not require 306 public/private key pairs or host certificates. 308 3.2 The ROTA Approach and its Benefits 310 ROTA is an extension to Mobile IPv6 that optimizes the path in bi- 311 directional tunneling mode between two mobile nodes in order to 312 achieve both route optimization and full, bi-directional location 313 privacy in terms of hiding the CoA from CN. The basic idea is to 314 separate the packet interception and bi-directional tunneling mode 315 functionality of an HA and allow the tunneling functionality for a 316 specific node to reside on external entities, such as other HAs or 317 MAPs. This external entity is then serving as a TA for a node, whose 318 HoA does not match the subnet prefix of this HA. Consequently, the 319 route can be optimized without changing the HoA of the MN. To ensure 320 bi-directional location privacy, most of the procedure is controlled 321 by MN's HA and CN's HA, e.g., they determine and configure 322 appropriate TA(s) to be used as tunnel endpoints. 324 ROTA can operate with and without visited network support, which 325 significantly eases deployment of ROTA. In the latter case, only 326 MN's HA or CN's HA may act as TA for MN or CN, respectively. 327 However, the route becomes less optimal when both MN and CN move far 328 away from their home. Further route optimization is possible when 329 leveraging TAs in visited networks (e.g., co-located with local HAs 330 or MAPs), if available. 332 In contrast to the bootstrapping solution (see [22] for split 333 scenario), ROTA does not change the home link in order to achieve 334 route optimization. Hence, the HoA does not contain location 335 information and can be rather static, i.e., it can be used as long- 336 term identifiers regardless of the location of the MN and without 337 sacrificing efficient routing. Dynamic DNS updates are not necessary 338 as well. Furthermore, route optimization of active communication 339 sessions is supported, which is especially beneficial if MNs travel 340 topologically large distances during a session, e.g., because of 341 vertical handovers. 343 A nice side-effect of the ROTA approach is that it provides benefits 344 over route optimization mode beyond location privacy support by being 345 able to utilize stronger authentication and authorization mechanisms 346 than the Return Routability procedure. Hence, longer binding 347 lifetimes can be used, BU message can be sent less often, and 348 temporary unavailability of HAs result in no or less loss of data 349 packets. Since no end-to-end signaling is necessary on every 350 movement, the handover latency as well as the signaling overhead over 351 the air may be lower than in route optimization mode. 353 In the following, the operation of ROTA is described for scenarios 354 without and with visited network support, respectively. 356 3.3 ROTA in scenarios without visited network support 358 The following basic scenario is assumed: First, a communication 359 session between MN and a mobile CN has started and both nodes are in 360 bi-directional tunneling mode. It is assumed that MN and CN have 361 different home links. Figure 1 shows the data path between MN and CN 362 with MN and CN both being in a foreign network. The MN reverse 363 tunnels all data packets (addressed to CN's HoA) to its HA, which 364 decapsulates and forwards them. The routing infrastructure routes 365 the packets to CN's home network, where CN's HA intercepts and 366 tunnels them to CN's CoA. Data packets in the other direction are 367 handled accordingly. It is obvious that the route between MN and CN 368 is far from optimal in this case and in many other cases. In 369 general, the further MN and/or CN are away from home, the less 370 optimal is the route. 372 ------------ .. ... .. ------------ 373 |Site 1 | . . . .. |Site 2 | 374 | |.. .| | 375 | MN's HA | | CN | 376 | /|\\\ | | /|\ | 377 ----|||---\\ -///-------- 378 ||| .. \\ /// .. 379 ----|||----- \\-------///- 380 | \|/ | | \\ \|/ | 381 | MN |.. | CN's HA | 382 | | . | | ||| tunneled 383 |Site 3 | .. |Site 4 | || not tunneled 384 ------------ .------------ 386 Figure 1: Data path between MN and CN in bi-directional tunneling 387 mode 389 The basic idea of ROTA is to switch the reverse tunnel endpoint from 390 the HA to TAs to shorten the route between MN and CN. In this 391 section we assume no visited network support. Hence, we assume that 392 only MN's or CN's HA may serve as TA. Figure 2 shows the data path 393 between MN and CN when CN's HA is TA, i.e., MN reverse tunnels all 394 data packets addressed to CN's HoA to CN's HA and CN's HA tunnels all 395 data packets addressed to MN's HoA to MN's CoA. As can be seen, the 396 route is shorter than in Figure 1. Depending on the location of to 397 MN, CN and their HAs, the data path is shorter when MN's HA or CN's 398 HA acts as TA, respectively. For an optimal selection, ROTA can 399 determine the best TA location based on distance information. 401 ------------ .. ... .. ------------ 402 |Site 1 | . . . .. |Site 2 | 403 | |.. .| | 404 | MN's HA | | CN | 405 | | | /|\ | 406 ------------ -///-------- 407 .. /// .. 408 ----------- --------///- 409 | /-------------\ \|/ | 410 | MN ------------CN's HA | 411 | \-------------/ | ||| tunneled 412 |Site 3 | .. |Site 4 | || not tunneled 413 ------------ .------------ 415 Figure 2: Data path between MN and CN with only CN's HA being TA 417 In the following, the operation of ROTA in scenarios without visited 418 network support is described. The initial procedure can be divided 419 in the following steps: 421 o Initiation of ROTA, which comprises requesting ROTA, checking 422 whether CN and CN's HA support ROTA and, if not already known, 423 discovering CN's HA address. 425 o Collecting distance information for TA selection (optional). 427 o Selecting TA(s) that provide(s) the shortest route. 429 o Sending binding information to TAs. 431 o Requesting tunnel establishment from new tunnel entry-point(s) and 432 notifying corresponding tunnel exit-point(s). 434 Note that this is only the initial procedure. Once this is 435 completed, basically only binding updates must be sent after 436 handovers. It is assumed that some kind of security association 437 exists between MN's HA and CN's HA to provide message authentication 438 and integrity protection of signaling messages. This can be achieved 439 by IPsec SAs, which are dynamically established with IKE [16] [17]. 440 The signaling messages exchanged between MN/CN and HAs are sent over 441 the IPsec SAs, which exist for Mobile IPv6 signaling messages [3]. A 442 discussion of threats and possible countermeasures can be found in 443 Section 8. 445 3.3.1 Signaling Flow 447 The initial procedure of ROTA in a scenario without visited network 448 support is explained by means of the signaling flow shown in 449 Figure 3, resulting in the data path depicted in Figure 2, i.e., CN's 450 HA acts as TA for MN. See Section 5 and Section 6 for a detailed 451 description of the MN and HA operation, respectively, and Section 4 452 for new message types. 454 +--+ +-------+ +-------+ +--+ 455 |MN| |MN's HA| |CN's HA| |CN| 456 +--+ +-------+ +-------+ +--+ 457 | ROTA_init_req | | | 458 |-------------------->| ROTA_req | | 459 | |-------------------->| ROTA_init_req | 460 | | |-------------------->| 461 | | | ROTA_init_rep | 462 | | ROTA_rep |<--------------------| 463 | ROTA_init_rep |<--------------------| | 464 |<--------------------| BU | | 465 | |-------------------->| | 466 | | BA | | 467 | |<--------------------| | 468 | tun_estbl_req | | | 469 |<--------------------| | | 470 | tun_estbl_rep | | | 471 |-------------------->| | | 472 | +-------+ | 473 |<=====================================>|MN's TA|<===============>| 474 | tunneled data packets +-------+ | 476 Figure 3: Signaling flow for initial procedure without visited 477 network support 479 ROTA execution can either be triggered by MN or MN's HA. In the 480 first case, the MN sends an ROTA Initiation Request message 481 containing CN's and MN's HoA to its HA. In the latter case, the HA 482 starts ROTA, e.g., after first data packets from/to CN's HoA were 483 tunneled. Subsequently, MN's HA sends an ROTA Request message to 484 CN's HA. If CN's HA address is unknown, it first must be discovered. 485 This can for instance be done by utilizing a modified DHAAD procedure 486 and/or by the use of DNS, or by sending the ROTA Request message to 487 CN's HoA and enabling CN's HA to intercept the message. 489 If CN's HA supports and accepts ROTA, it sends an ROTA Initiation 490 Request to CN, which may accept or reject ROTA by sending a 491 corresponding ROTA Initiation Reply message. Then, CN's HA sends a 492 ROTA Reply message back to MN's HA. Subsequently, both HAs perform 493 an TA selection procedure, which among other things is based on 494 distance information. The distance metric can be hops or delay. 495 Although delay would be a more meaningful metric for determining the 496 best path to be used for conversational communications, it is less 497 stable and the distance in hops can easier be measured. Hence, it is 498 proposed to use hops as default metric. The distance can partly be 499 passively acquired from the routing table, from previously received 500 signaling messages or tunneled data packets. In the latter two 501 cases, the initial hop limit used by the sender must be known by the 502 receiver. Furthermore, some distance values might be pre-assigned, 503 e.g., between roaming partners. Otherwise, distances may be measured 504 by active probing (a specification of probe messages and a mechanism 505 to secure active probing is left for future work). 507 A simple TA selection strategy would be to select the HA that is 508 closer to its MN as TA, since this usually provides the shorter path. 509 In this case, the HAs can passively measure the distance to their 510 MN/CN, e.g., with the ROTA Initiation Request/Reply messages and 511 exchange them using the ROTA Request/Reply message with the own 512 address and the distance information contained in the Candidate TA 513 option. However, this strategy does not always select the better TA. 514 A more accurate, but also more expensive strategy is to measure all 515 distances needed to determine the current route length between MN and 516 CN as well as the route length when MN's HA and/or CN's HA were TA(s) 517 and, subsequently, select the best TA in terms of route optimization. 518 Therefore, both HAs have to exchange BU messages to be able to 519 measure the distance to MN's and CN's CoA. Note that a valid result 520 of the selection is that no route optimization is necessary (see 521 Appendix A for TA selection recommendations). 523 After an TA has been selected, binding information is introduced in 524 the TA and Tunnel Establishment Request messages are sent to the new 525 tunnel entry-point(s) (here: MN) to set up a tunnel. Additionally, 526 Tunnel Establishment Notification messages may need to be sent to 527 inform new tunnel exit-points about new tunnel entry-points to allow 528 them to perform a check on the source address of incoming tunneled 529 data packets as described in [3]. 531 Note that this signaling flow applies to the initial ROTA procedure 532 only. When MN moves to another subnet, basically only binding update 533 messages must be sent to MN's HA and to MN's TA (as long as the TAs 534 do not change). The latter can be sent by MN's HA or, to improve 535 handover signaling efficiency and delay, by the MN itself. In this 536 case the MN must be able to dynamically establish an SA to CN's HA. 537 This may require an interface between CN's HA and an AAA 538 infrastructure to transfer cryptographic material needed to establish 539 the SA to CN's HA. Such an interface is currently in development 540 (see [21]) and may be re-used by ROTA. 542 Furthermore, the optimal TA may change after movements. Hence, 543 distance measurements and the TA selection may be repeated after 544 movements. To reduce signaling, it is recommended to use passive 545 measurements as much as possible. Further, it is not recommended to 546 re-execute TA selection after every handover of MN or CN, but 547 instead, e.g., after every nth handover. If the new distance 548 information results in a new TA providing a shorter route, Tunnel 549 Establishment/Notification messages MAY be sent to adapt the route. 550 To minimize data packet loss, new tunnels should be set up before the 551 old tunnels are deleted ("make-before-break"). 553 3.4 ROTA in scenarios with visited network support 555 Especially if both MN and CN are far away from the home network, 556 neither MN's HA nor CN's HA can provide good route optimization by 557 acting as TA. The route can be further optimized by considering TAs 558 close to the direct path between MN and CN, e.g., local HAs or MAPs 559 with TA functionality, which are located in or close to the visited 560 networks of MN and CN. Another issue is that the scenario shown in 561 Figure 2 may not achieve complete location privacy, since MN can find 562 out that the path over CN's HA is shorter than over MN's HA, because 563 otherwise CN's HA would not have been selected as TA (assuming that 564 distance information is the dominant parameter in the TA selection). 565 Since MN can determine the distances to MN's HA and CN's HA, it can 566 conclude whether CN is closer to MN's or CN's HA. Although the 567 geographical area derivable from this information is considered to be 568 very large, it may be a reason to use other TA locations for improved 569 location privacy. Note that if local TAs are selected, the 570 disclosure of the MN's local TA prefix to CN and vice versa must be 571 prevented, if both MN and CN require location privacy. This can be 572 achieved by an HA-controlled TA selection and by routing of data 573 packets over two intermediate TAs, e.g., a local HA or MAP in MN's 574 and CN's visited networks as shown in Figure 4. 576 ------------ .. ... .. ------------ 577 |Site 1 | . . . .. |Site 2 | 578 | |.. .| | 579 | MN's HA | | CN's HA | 580 | | | | 581 ------------ ------------ 582 .. .. 583 |----------| |----------| 584 ---\loc./-------------\loc./--- 585 MN---- HA/--------------- HA/----CN 586 ---/ MAP\-------------/ MAP\--- ||| tunneled 587 |Site 3 | .. |Site 4 | || not tunneled 588 ------------ .------------ 590 Figure 4: Data path between MN and CN with a TA in the visited 591 network of MN and CN, respectively 593 New issues must be considered in such scenarios. First, a local 594 candidate TA must be discovered. This can, e.g., be done by DNS 595 using some location-dependent HA names, e.g., as mentioned in [22], 596 or by some local announcements, e.g., via DHCP or Router 597 Advertisements. The discovery can be done by the HAs or by MN/CN, 598 which then propose candidate TAs to their HAs. Furthermore, the HAs 599 must agree on the TAs to be used. MN and CN cannot be involved in 600 the TA selection, because this would reveal the prefix of CN's/MN's 601 visited network. 603 Another issue is that binding updates may need to be sent to multiple 604 TAs and that those must contain TA addresses as CoAs. E.g., in 605 Figure 4, TA1 must manage the bindings and for traffic directed to MN and CN, respectively. 607 Finally, it may be necessary for security reasons that a binding may 608 only be introduced in an TA by the HA that belongs to the 609 corresponding HoA. In this case, some co-ordination between MN's HA 610 and CN's HA is necessary to ensure that MN and CN first are notified 611 to switch their reverse tunnels after both HAs have introduced their 612 bindings in all TAs and the end-to-end tunnel is established. 614 3.4.1 Signaling Flow 616 Figure 5 shows the signaling flow for the initial procedure resulting 617 in the scenario shown in Figure 4, i.e., with local TAs in the 618 visited networks of MN and CN. See Section 5 and Section 6 for a 619 detailed description of the MN and HA operation, respectively, and 620 Section 4 for new message types. 622 +-------+ +-------+ 623 +--+ |localHA| +-------+ +-------+ |localHA| +--+ 624 |MN| | /MAP | |MN's HA| |CN's HA| | /MAP | |CN| 625 +--+ +-------+ +-------+ +-------+ +-------+ +--+ 626 | ROTA_init_req | | | | 627 |------------------------>| ROTA_req | | | 628 | | |------------>| ROTA_init_req | 629 | | | |------------------------>| 630 | | | | ROTA_init_rep | 631 | | | ROTA_rep |<------------------------| 632 | ROTA_init_rep |<------------| | | 633 |<------------------------| | BU | | 634 | | BU |-------------------------->| | 635 | |<------------| | BA | | 636 | | BA |<--------------------------| | 637 | |------------>| | | | 638 | | | tun_estbl | | | 639 | | |------------>| BU | | 640 | | BU | |------------>| | 641 | |<--------------------------| BA | | 642 | | BA | |<------------| | 643 | |-------------------------->| | | 644 | | |ack+tun_estbl| | | 645 | | |<------------| | | 646 | | | ack | | | 647 | tun_estbl_req |------------>| tun_estbl_req | 648 |<------------------------| |------------------------>| 649 | ack | | ack | 650 |------------------------>| |<------------------------| 651 | +-------+ +-------+ | 652 |<=====>|MN's TA|<===============================>|CN's TA|<=====>| 653 | +-------+ tunneled data packets +-------+ | 655 Figure 5: Signaling flow for the initial procedure with local TAs in 656 visited network 658 First, MN or HA initiate ROTA as described in Section 3.3.1. The MN 659 may propose candidate TA address(es) such as a local HA/MAP address 660 and the distances to those using a new Mobility Option, the Candidate 661 TA option, in ROTA Initiation Request or BU messages. The HA checks 662 the validity of those addresses and may delete or add candidate TAs 663 before sending them in a ROTA Request message with Candidate TA 664 option to CN's HA. Similarly, CN and CN's HA may add or delete TA 665 addresses. Note that both HAs should at least add their own address 666 to the candidate TA list for the case that no visited network 667 supports and hence no local TAs exists. If the distances in hops are 668 passively measured using ROTA messages, CN's HA already has the 669 distances , and 670 at this point in time. It also knows whether a local TA exist in 671 MN's and CN's visited network, respectively, and if both MN and CN 672 require location privacy (the latter is indicated by the P-flag in 673 ROTA Request messages). E.g., by using the recommendations described 674 in Appendix A, CN's HA can select TAs to be used and propose them to 675 MN's HA by setting the respective O-bits in the Candidate TA option 676 of the ROTA Reply message. Here, it is assumed that MN's HA agrees 677 with the proposal of CN's HA. Otherwise, another round of request 678 and reply messages may be needed. Note that MN's and CN's HA may 679 request distance measurements from candidate TAs using ROTA Distance 680 Information Request messages in order to find the best TAs providing 681 the shortest path. 683 After TAs have been selected, binding information about MN and CN 684 must be sent to them using BU messages with alternate CoA option. 685 Depending on the mechanisms used for authenticating and authorizing 686 of binding updates, this can be done by one HA only or by both HA 687 independently. Although many signaling messages could be saved if 688 done by only one HA, it is proposed that both HAs introduce bindings 689 independently for security reasons. It is assumed that an HA may 690 only introduce binding information into an TA, when its prefix 691 matches the HoA in the binding (see Section 8). The binding update 692 messages contain MN's or CN's HoA as HoA and MN's or CN's CoA or the 693 address of the corresponding TA as CoA. Finally, the HAs send Tunnel 694 Establishment Notification messages to each other to indicate the 695 successful establishment of bindings and notify MN and CN to switch 696 their reverse tunnels. 698 Note that this signaling flow applies to the initial ROTA procedure 699 only. When MN moves to another subnet, basically only binding update 700 messages must be sent to MN's HA and to MN's TA. The latter can be 701 sent by MN's HA or, to improve handover signaling efficiency and 702 delay, by the MN itself. In this case the MN must be able to 703 dynamically establish an SA to the local HA/MAP. This may require an 704 interface between TA and the AAA infrastructure to transfer 705 cryptographic material needed from the home network to establish the 706 SA. Such an interface is currently in development (see [21]) and may 707 be re-used by ROTA. Note that MN cannot send a binding update to 708 CN's TA if CN requires location privacy, because the address of CN's 709 TA can contain location information about CN and, hence, must be 710 hidden from MN. 712 Again, the optimal TAs may change after movements. MN and CN may 713 propose new local candidate TA addresses to their HAs after moving to 714 a new local HA/MAP area, e.g., with BU messages using the Candidate 715 TA option. The HAs then may decide to execute the TA selection 716 algorithm again (using ROTA Request/Reply messages) and switch the 717 tunnels to new TAs, if necessary. 719 4. New Message Types 721 The ROTA protocol messages are defined as new Mobility Header Types 722 and Mobility Options. 724 4.1 Message Headers 726 4.1.1 Binding Update and Acknowledgement Message 728 Binding Update and Acknowledgement messages are defined in [3]. The 729 only modification is a new "TA registration" flag to be used when a 730 binding shall be introduced in an TA. 732 4.1.2 ROTA Request/Notification Message 734 The ROTA Request/Notification Message is the general request and 735 notification message of ROTA. It contains a Message Type field to 736 distinguish different ROTA Request/Notification messages. The value 737 of the hop limit field in the IPv6 header MUST be set to 255 to 738 support passive distance measurements. The MH type is TBD. 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Msg Type |A|P|M| Rsrvd | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Message Sequence # | Reserved | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | | 748 + + 749 | | 750 + Target Address 1 + 751 | | 752 + + 753 | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | | 756 + + 757 | | 758 + Target Address 2 + 759 | | 760 + + 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | 764 . . 765 . Mobility options . 766 . . 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Msg Type 772 This field specifies the type of ROTA Request/Notification 773 message. The following types are currently registered: 775 0: ROTA Initiation Request 777 This message requests ROTA initiation. 779 1: ROTA Request 781 The purpose of this message is to check whether CN's HA 782 supports ROTA and, optionally, to discover the address of 783 CN's HA. This message MAY be sent to CN's HoA, if CN's HA 784 address is unknown. In conjunction with the Candidate TA 785 option it can be used to negotiate TA address(es). 787 2: ROTA Abort Notification 789 The purpose of this message is to abort an ROTA session and 790 switch back to standard bi-directional tunneling mode. 792 3: ROTA Tunnel Establishment Notification 794 The purpose of this message is to notify about an 795 established tunnel and to inform about a new tunnel entry- 796 point address. 798 4: ROTA Tunnel Establishment Request 800 This message requests from a tunnel entry-point the 801 establishment of a new tunnel. 803 5: ROTA Distance Information Request 805 The purpose of this message is to request distance 806 information from an TA. The corresponding reply message is 807 the ROTA Distance Information message. The candidate TA 808 mobility option may be used to request the distance to 809 multiple candidate TAs. 811 Message Sequence # 813 A 16-bit unsigned integer used by the receiving node to sequence 814 ROTA messages and by the sending node to match a returned 815 acknowledgement with this message. 817 Acknowledge (A) 819 This flag is set when an acknowledgement is requested upon receipt 820 of a notification message. It MUST be set if the message 821 transport service is considered unreliable. The flag can be 822 ignored in request messages, since they are acknowledged by a 823 reply message anyway. 825 Privacy (P) 827 This flag is used to inform the receiver of the message about the 828 privacy requirements of the sender. If set, location privacy is 829 required by the sender. MN and CN can inform their HAs about 830 privacy requirements in ROTA Initiation Request messages, HAs can 831 inform each other about privacy requirements of their MN/CN in 832 ROTA Request messages. 834 Metric (M) 835 The flag has only meaning for ROTA Distance Information Request 836 messages. It indicates the metric to be used for requested 837 distance measurements. If set to 0 the metric is hops, otherwise 838 it is delay. Note that all nodes involved in a ROTA session MUST 839 use the same metric. 841 Reserved 843 These fields are unused. They MUST be initialized to zero and 844 MUST be ignored by the receiver. 846 Target Address 1 848 The meaning of this field depends on the value of the Message Type 849 field: 851 If 0, 1 or 2 target address 1 is MN's HoA. 853 If 3 and the message is sent to/received by an HA, the target 854 address 1 is the address of MN's HoA. 856 If 3 and the message is sent to/received by MN or CN, the 857 target address 1 is the address of the new tunnel entry-point. 859 If 4, the target address 1 is the address of the new tunnel 860 exit-point. 862 If 5, the target address 1 is an address, to which the 863 receiving TA shall determine the distance (e.g., MN's CoA or 864 correspondent TA). 866 Target Address 2 868 The meaning of this field depends on the value of the Message Type 869 field: 871 If 0, 1 or 2 target address 2 is CN's HoA. 873 If 3 and the message is sent to/received by an HA, the target 874 address 2 is the address of CN's HoA. 876 If 3 or 4 and the message is sent to/received by MN, the target 877 address 2 is CN's HoA. 879 If 3 or 4 and the message is sent to/received by CN, the target 880 address 2 is MN's HoA. 882 If 5, the target address 2 is an address, to which the 883 receiving TA shall determine the distance (e.g., CN's CoA or 884 correspondent TA). 886 4.1.3 ROTA Reply/Acknowledgement Message 888 The ROTA Reply/Acknowledgement Message is the general reply and 889 acknowledgement message of ROTA. It contains a Message Type field to 890 distinguish different ROTA Reply/Acknowledgement messages. The value 891 of the hop limit field in the IPv6 header MUST be set to 255 to 892 enable passive distance measurements. The MH type is TBD. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Msg Type | Status Code | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Message Sequence # | Reserved | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | | 902 . . 903 . Mobility options . 904 . . 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Msg Type 910 This field specifies the type of ROTA message. The following 911 types are currently registered: 913 0: ROTA Initiation Reply 915 The purpose of this message is to indicate the outcome of 916 the ROTA Initiation Request. 918 1: ROTA Reply 920 The purpose of this message is to indicate whether CN's HA 921 and CN support and accept ROTA and to inform the sender 922 about the address of CN's HA. In conjunction with the 923 Candidate TA option it can be used to negotiate TA 924 address(es). 926 2: ROTA Abort Acknowledgement 928 The purpose of this message is to acknowledge the abort of 929 an ROTA session. 931 3: ROTA Tunnel Establishment Reply 933 The purpose of this message is to indicate the outcome of 934 the Tunnel Establishment Request. 936 4: ROTA Tunnel Establishment Notification Acknowledgement 938 The purpose of this message is to acknowledge ROTA Tunnel 939 Establishment Notification Message. 941 5: ROTA Distance Information Acknowledgement 943 The purpose of this message is to acknowledge the ROTA 944 Distance Information Message. 946 Status Code 948 This field indicates the result of an request: 950 0: Request accepted 952 128: Request not accepted, reason unspecified 954 129: Request not accepted, ROTA not supported 956 130: Request not accepted, insufficient resources 958 131: Request not accepted, candidate TAs not accepted 960 Message Sequence # 962 A 16-bit unsigned integer used by the receiving node to sequence 963 ROTA messages and by the sending node to match a returned 964 Acknowledgement with this message. 966 Reserved 968 These fields are unused. They MUST be initialized to zero and 969 MUST be ignored by the receiver. 971 4.1.4 ROTA Distance Information Message 973 The ROTA Distance Information Message is used to notify other 974 entities about distances between two nodes. The MH type is TBD. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Reserved | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Message Sequence # |A| Reserved | # Entries | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | | 984 + + 985 | | 986 + Address of Source 1 + 987 | | 988 + + 989 | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | | 992 + + 993 | | 994 + Address of Target 1 + 995 | | 996 + + 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 |Distance S1-T1 |M| Reserved | Distance Sequence # | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 . . 1002 . .... . 1003 . . 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | | 1006 . . 1007 . Mobility options . 1008 . . 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Message Sequence # 1014 A 16-bit unsigned integer used by the receiving node to sequence 1015 ROTA messages and by the sending node to match a returned 1016 Acknowledgement with this message. 1018 Acknowledge (A) 1019 This flag is set when an Acknowledgement is requested upon receipt 1020 of this message. It MUST be set if the message transport service 1021 is considered unreliable. 1023 Reserved 1025 These fields are unused. They MUST be initialized to zero and 1026 MUST be ignored by the receiver. 1028 # Entries 1030 An 8-bit unsigned integer indicating the number of distance 1031 information entries in this message. 1033 Address of Source X 1035 Address of source X. 1037 Address of Target X 1039 Address of target X. 1041 Distance SY-TY 1043 An 8-bit unsigned integer indicating the measured distance between 1044 source X and target X. If the metric is delay, the value of this 1045 field is the delay divided by 10ms. Any delay higher than 2550ms 1046 is represented by 255. 1048 Metric (M) 1050 The flag indicates the metric of the distances. If set to 0 the 1051 metric is hops, otherwise it is delay. 1053 Distance Sequence # 1055 A 16-bit unsigned integer indicating the freshness of the distance 1056 information. It must always be provided by the node that measured 1057 the distance. 1059 4.2 Mobility Options 1061 4.2.1 Candidate TA Option 1063 This option can be used to propose candidate TA addresses. Type is 1064 TBD. 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type | Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | | 1072 + + 1073 | | 1074 + Address of Candidate TA 1 + 1075 | | 1076 + + 1077 | | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 |Distance to TA1|M|O|T|Reserved | Distance Sequence # | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 . . 1082 . .... . 1083 . . 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Reserved 1088 These fields are unused. They MUST be initialized to zero and 1089 MUST be ignored by the receiver. 1091 Address of Candidate TA X 1093 Address of candidate TA X. 1095 Distance TA1 1097 An 8-bit unsigned integer indicating the distance between the MN 1098 belonging to the sender and the candidate TA. The distance can be 1099 omitted by setting it to 0, meaning "unknown distance". If metric 1100 is delay, the value of this field is the delay divided by 10ms. 1101 Any delay higher than 2550ms is represented by 255. 1103 Metric (M) 1105 The flag indicates the metric of the distances. If set to 0 the 1106 metric is hops, otherwise it is delay. 1108 Proposed TA (O) 1110 The entries which have the P-flag set represent the set of TAs 1111 proposed by the sender. Other entries are alternative TAs. 1113 TA proposal modified (T) 1114 If this flag is set, the O-flag of this TA has been changed, 1115 compared to the Candidate TA Option of the last Request/Reply 1116 message. If the entry is new and the O-flag is set, the T-flag 1117 MUST be set as well. 1119 Distance Sequence # 1121 A 16-bit unsigned integer indicating the freshness of the distance 1122 information. It must always be provided by the node that measured 1123 the distance. 1125 5. Modified Mobile Node Operation 1127 5.1 Conceptual Data Structures 1129 A new flag is added to Binding Update List entries to indicate an 1130 active ROTA session. Additionally, an ROTA MN Cache entry is 1131 maintained for every ROTA session. A ROTA session identification is 1132 implicitly given by the tuple . ROTA Binding 1133 Update List entries conceptually point to ROTA MN Cache entries. 1135 Each ROTA MN Cache entry contains the following data 1137 o CN's HoA 1139 o TA address(es) for incoming data packets 1141 o TA address for outgoing data packets 1143 o Message Sequence Number 1145 A Candidate TA Cache may be maintained, which contains addresses of 1146 known candidate TAs and the distance to those. 1148 5.2 Using Security Associations 1150 All ROTA messages MUST be sent authenticated and integrity protected, 1151 e.g., over the MN-HA IPsec SAs required for Mobile IPv6 signaling 1152 messages. 1154 5.3 Sending ROTA Initiation Request 1156 The MN MAY request ROTA initiation for a communication session with a 1157 specific CN at any time by sending an ROTA Initiation Request to its 1158 HA. This message must contain CN's HoA. It MUST set the P-bit if it 1159 requires privacy and it MAY propose candidate TA address(es) and the 1160 corresponding distances. The message sequence number field in the 1161 message as well as in the ROTA MN Cache is increased for every 1162 Request message sent. The MN updates the corresponding entry in its 1163 ROTA MN Cache. 1165 5.4 Receiving ROTA Initiation Reply 1167 After receiving a positive reply with a sequence number matching the 1168 corresponding request message, the ROTA MN Cache is updated 1169 accordingly. 1171 5.5 Receiving ROTA Initiation Request 1173 When receiving a ROTA Initiation Request, the MN is acting as CN. It 1174 MUST reply with a ROTA Initiation Reply. 1176 5.6 Sending ROTA Initiation Reply 1178 The ROTA Initiation Reply message contains a status code indicating 1179 that ROTA is either accepted or rejected. The sequence number must 1180 be set to the value of the corresponding request message. If 1181 accepted, a ROTA MN Cache entry must be created. The P-bit is set 1182 according to the privacy requirements. TA addresses may be proposed 1183 in a Candidate TA option. 1185 5.7 Sending Reverse Tunneled Packets 1187 If an ROTA session for the destination address exists and the ROTA MN 1188 Cache indicates that the tunnel is established, data packets are 1189 reverse tunneled to the corresponding outgoing tunnel endpoint 1190 address. 1192 5.8 Receiving Reverse Tunneled Packets 1194 Incoming data packets are accepted if the IP source address of the IP 1195 tunnel header matches one of the TA addresses for incoming data 1196 packets in the ROTA MN Cache entry corresponding to the IP source 1197 address in the inner IP header. 1199 5.9 Sending Binding Updates 1201 Binding Updates to MN's HA are sent as described in [3], i.e., over 1202 the MN-HA IPsec SA. Binding Updates sent to MN's TA MAY be sent by 1203 MN. In this case it must be able to dynamically establish an SA to 1204 the TA. This may require an interface to an AAA infrastructure to 1205 transfer cryptographic material needed to establish the SA. Such an 1206 interface is currently in development (see [21]) and may be re-used 1207 by ROTA. 1209 5.10 Receiving Tunnel Establishment Request messages 1211 The MN checks whether the ROTA MN Cache contains a valid entry for 1212 CN's HoA contained in the Tunnel Establishment Request. If this is 1213 not the case, the request MUST be rejected. Otherwise, the sequence 1214 number in the message is checked. If it is higher than the one in 1215 the ROTA MN Cache, the MN sets up the tunnel. The corresponding 1216 fields, such as the tunnel endpoint fields, and the sequence number 1217 field in the corresponding ROTA MN Cache entry are updated 1218 accordingly. The MN MUST return a Tunnel Establishment Reply 1219 indicating the outcome of the check. 1221 5.11 Sending Tunnel Establishment Reply messages 1223 The message must contain a status code indicating the outcome of the 1224 check. The sequence number is set to the value of the corresponding 1225 Request message. 1227 5.12 Receiving Tunnel Establishment Notification messages 1229 On receipt of a Tunnel Establishment Notification, the same checks as 1230 described in the last section apply. If successful, the MN updates 1231 the corresponding fields, such as the sequence number field, and the 1232 tunnel endpoint fields in the corresponding ROTA MN Cache entry. The 1233 MN MUST return a Tunnel Establishment Notification Acknowledgement 1234 with the sequence number set to the value of the corresponding 1235 Notification message. 1237 6. Modified Home Agent Operation 1239 6.1 Conceptual Data Structures 1241 Each HA maintains an ROTA HA cache and a Binding Update List. The 1242 latter is the same as specified for the MN in section 11.1 of [3], 1243 but without the data required for the return routability procedure. 1244 Binding Cache entries with home registration and Binding Update List 1245 entries conceptually point to each other and to ROTA HA Cache 1246 entries. 1248 Each ROTA HA Cache entry of MN's HA contains the following data 1250 o CN's HoA 1252 o MN's privacy requirements 1254 o CN's privacy requirements 1256 o CN's HA address 1258 o Current TA address(es) of MN 1260 o Message Sequence number 1262 o A Candidate TA Cache, which contains addresses of known candidate 1263 TAs and their distance to MN/CN. 1265 A Certificate Cache may be maintained, which contains recently 1266 received public keys and certificates. 1268 A Distance Information Cache is used to store distances between MN/CN 1269 and TAs. It contains entries with the following data 1271 o Source address 1273 o Destination address 1275 o Distance measured in hops and/or delay 1277 o Distance Sequence Number 1279 o Lifetime 1281 An HA acting as a TA additionally maintains an ROTA TA Cache. 1282 Binding Cache entries are extended by a TA registration flag to 1283 distinguish TA registrations from home registrations. TA 1284 registration entries conceptually point to ROTA TA Cache entries. 1286 Each ROTA TA Cache entry contains the following data 1288 o MN's HA address 1290 o Message Sequence Number 1292 6.2 Using Security Associations 1294 All ROTA messages sent between MN's HA and MN and CN's HA and CN MUST 1295 be sent authenticated and integrity protected over the MN-HA IPsec 1296 SAs required for Mobile IPv6 signaling messages. All ROTA messages 1297 sent between MN's HA and CN's HA or MN's/CN's HA and TA MUST be sent 1298 authenticated and integrity protected over beforehand (e.g., with 1299 IKE/IKEv2 [16] [17]) established IPsec SAs. 1301 6.3 ROTA Initiation 1303 The HA starts ROTA initiation for a specific MN-CN session on receipt 1304 of an ROTA Initiation Request from an MN or on an internal trigger, 1305 e.g., after the first received data packets from a specific CN. For 1306 the latter it MUST be ensured that the preferences of MN comply with 1307 HA's decision to initiate ROTA, e.g., from some prior arrangement. 1308 If triggered by an ROTA Initiation Request sent by MN, the HA MUST 1309 return an ROTA Initiation Reply indicating the outcome of the 1310 initiation. The Message Sequence Number in the ROTA Initiation Reply 1311 MUST match those in the corresponding Initiation Request. During 1312 ROTA initiation, the HA creates the corresponding entries in its ROTA 1313 HA Cache. If the message contains a Candidate TA Mobility Option, 1314 the HA must check whether a trust relationship exists to those TAs. 1315 New valid TAs may be added to the Candidate TA Cache. 1317 6.4 Sending ROTA Request 1319 ROTA Request messages are only exchanged between MN's HA and CN's HA. 1320 MN's HA sends an ROTA Request to CN's HA. If CN's HA address is 1321 unknown, the Request may be sent to CN's HoA and intercepted by CN's 1322 HA. The ROTA Request message MUST contain CN's HoA and a current 1323 message sequence number. The P-flag in the message MUST be set to 1324 the value set by the MN in the corresponding ROTA Initiation Request 1325 message. If the HA has triggered ROTA, it must know MN's privacy 1326 requirements from some prior arrangement. The HA MUST propose at 1327 least its own address as candidate TA address in the Candidate TA 1328 Mobility Option and MAY include more candidate TAs, e.g., proposed by 1329 MN in the Candidate TA option. It MAY set the O-flag to propose one 1330 or multiple of the candidates as TA. If no reply is received after 1331 sending multiple Request messages, it can be concluded that CN's HA 1332 does not support ROTA and ROTA must be aborted. 1334 6.5 Receiving ROTA Request 1336 If an HA supports ROTA and receives a ROTA Request addressed to one 1337 of the addresses associated to its network interfaces or to one of 1338 its Binding Cache entries with home registration, it SHOULD send a 1339 ROTA Initiation Request to CN in order to check if CN supports and 1340 accepts to execute ROTA. This message may not contain the candidate 1341 TAs proposed by MN in a Candidate TA option, since they may reveal 1342 location information. If such an Initiation message is not sent, the 1343 HA must know the preferences of CN, e.g., from some prior 1344 arrangement. If a valid and positive Initiation Reply is received, 1345 the ROTA Request message is processed. Before a ROTA Reply message 1346 is sent, the HA creates or updates the corresponding entry in its 1347 ROTA HA Cache. 1349 6.6 Sending ROTA Reply message 1351 If CN does not have an active communication session with the address 1352 contained in the ROTA Initiation Request message or does not accept 1353 to execute ROTA route optimization, the HA sends a negative reply and 1354 MN's HA informs MN accordingly. Otherwise the HA sends a positive 1355 ROTA Reply message to the sender address of the corresponding Request 1356 message. The message sequence number is set to the value of the 1357 corresponding Request messages. The P-flag in the message MUST be 1358 set to the value set by the CN in the corresponding ROTA Initiation 1359 Reply message sent by CN or known from some prior arrangement. The 1360 HA MUST propose at least its own address as candidate TA address in 1361 the Candidate TA Mobility Option and MAY include more candidate TAs, 1362 e.g., proposed by CN in a Candidate TA option. It also adds the 1363 agreed candidate TAs that were proposed by MN's HA in the ROTA 1364 Request message. It MUST set the O-flags in the Candidate TA option 1365 to propose a set of TAs to be used. 1367 6.7 Receiving ROTA Reply 1369 The receiver only processes the Reply message if it has sent a 1370 corresponding Request with the same sequence number to the sender 1371 address before. If this is not the case, the HA MAY return an ROTA 1372 Reply indicating the rejection of ROTA. The HA checks the proposed 1373 TAs in the Candidate TA option. If the HA does not accept the set of 1374 TAs proposed by CN's HA, it MUST sent a new Request message with a 1375 modified list of candidate TAs and new set of TAs marked with the 1376 O-flag. In this case, the T-flag MUST be set in the corresponding 1377 entries in the Candidate TA Option. The TA selection may be 1378 supported by additional distance measurements, which may require MN's 1379 and CN's HA to exchange BU messages for being able to measure the 1380 distance to MN's and CN's CoA. Furthermore, Distance Information 1381 messages may be exchanged to report measured distances. If both HAs 1382 have agreed on a set of TAs, the HAs may proceed with sending BU 1383 messages to those. 1385 6.8 Sending Binding Updates 1387 A Binding Update may only be sent to a TA by an HA with a subnet 1388 prefix matching the HoA in the binding. The newly defined TA 1389 registration flag must be set and the alternate CoA option MUST 1390 contain MN's/CN's CoA or an TA address. Additionally, the Binding 1391 Update List MUST be updated as specified in [3]. 1393 6.9 Receiving Binding Updates 1395 If an HA receives a BU from one of its MNs, it processes it as 1396 described in [3]. Additionally, it sends a corresponding BU to the 1397 current TA(s). 1399 An HA acting as TA may receive a Binding Update from an HA with TA 1400 registration flag set. It does not necessarily reject a binding 1401 containing an HoA which is not an on-link IPv6 address with respect 1402 to the HA's current prefix list, as described in [3]. Instead, it 1403 checks whether the sender is authorizes to act as an HA for the HoA 1404 contained in BU message (this could, e.g., be realized with 1405 certificates by comparing the HoA in the binding with the prefixes 1406 contained in an IP address extension of the certificate of the sender 1407 HA. See Section 8 for details). If the sender is not authorized, 1408 the BU MUST be rejected. 1410 If accepted, the TA adds the binding to its Binding Cache. The 1411 lifetime of the entry is set according to the rules for bi- 1412 directional tunneling mode as described in [3]. The TA MUST set the 1413 TA registration flag of the corresponding entry. The home 1414 registration bit MUST NOT be set. Additionally, it adds an entry in 1415 its ROTA TA Cache with the address of the sender HA. Finally, a 1416 pointer to this entry is added in the corresponding Binding Cache 1417 entry. Regardless of the A-bit in the binding, the TA MUST return a 1418 Binding Acknowledgement to the sending HA as described in [3]. 1420 6.10 Receiving Binding Acknowledgements 1422 The checks described in [3] apply. If the HA has sent BUs to TAs 1423 different from CN's HA and all corresponding BAs has been received, a 1424 Tunnel Establishment Notification message is sent to CN's HA. 1426 6.11 Sending Tunnel Establishment Notification message 1428 After the BAs from all TAs have been received, a Tunnel Establishment 1429 Notification message is sent to the CN's HA. 1431 6.12 Receiving Tunnel Establishment Notification message 1433 After the Tunnel Establishment Notification message has been received 1434 by CN's HA and BAs from all TAs have been received, a Tunnel 1435 Establishment Notification Acknowledgement message is sent to the 1436 CN's HA. Furthermore, a Tunnel Establishment Request message is sent 1437 to CN. 1439 If no Tunnel Establishment Notification message is received by CN's 1440 HA, this might be an indication that the ROTA Reply message got lost. 1441 In this case, CN's HA may resend the ROTA Reply message. 1443 6.13 Receiving Tunnel Establishment Notification Acknowledgement 1444 message 1446 On receipt of a Tunnel Establishment Notification Acknowledgement 1447 message from CN's HA, a Tunnel Establishment Request message is sent 1448 to MN. 1450 6.14 Intercepting Data Packets 1452 An TA MUST NOT intercept data packets for nodes with TA registration, 1453 i.e., it MUST NOT perform Proxy Neighbor Discovery for those nodes. 1454 An HA may only perform packet interception for home registrations as 1455 described in [3] 1457 6.15 Sending and Receiving Reverse Tunneled Packets 1459 Reverse tunneled packets are handled the same way as in [3]. E.g., 1460 the TA MUST verify that the Source Address in the tunnel IP header of 1461 received data packets is equal to the CoA specified in the 1462 corresponding entry in the Binding Cache, if IPsec ESP is not used 1463 for those packets. 1465 6.16 Receiving a ROTA Abort Notification message 1467 MNs can abort a ROTA session and switch to standard Mobile IPv6 bi- 1468 directional tunneling mode by sending a ROTA Abort Notification 1469 message to its HA. The Abort message MUST set the A-flag. The HA 1470 then sends a corresponding message to all active TAs and to CN's HA, 1471 which then will send an abort notification to CN. The corresponding 1472 ROTA HA and MN Cache entries may first be deleted after the 1473 corresponding acknowledgements have been received. 1475 6.17 Management of ROTA HA Cache Entries 1477 ROTA HA Cache entries are deleted when the corresponding Binding 1478 Cache entries are deleted or the ROTA session is aborted. 1480 7. IANA Considerations 1482 ROTA introduces new Mobility Header Types and Mobility Options (see 1483 Section 4). 1485 8. Security Considerations 1487 Different issues have to be considered to ensure that ROTA does not 1488 introduce new security leaks. For instance, a trust relationship 1489 between MN's and CN's HA and between MN's/CN's HA and TAs must exist. 1490 Since multiple ways of establishing and managing trust relationships 1491 exist and the choice depends on deployment scenarios, we only give a 1492 short discussion of attacks and possible countermeasures in this 1493 section. A detailed specification of the security solution is left 1494 for future work. Most attacks are taken from [18], which describes 1495 them in more detail in the context of an analysis of the Mobile IPv6 1496 route optimization mode. 1498 8.1 Address Stealing 1500 A serious attack is the injection of false binding information in a 1501 correspondent node, since this allows an attacker to steal a victim's 1502 traffic by redirecting it to itself or a node under its control, 1503 e.g., to analyze or tamper the traffic. Note that the victim may be 1504 a mobile node as well as a stationary node, since addresses used by 1505 stationary nodes are not distinguishable from addressed used by 1506 mobile nodes. This attack is especially serious in case of ROTA, 1507 since binding information is sent to potential Internet router (here: 1508 HA acting as TA). To prevent such attacks, data origin 1509 authentication and integrity protection for BU messages are required 1510 and the sender of a BU message must be authorized to inject a 1511 specific binding. 1513 Data origin authentication can be achieved with sender address 1514 ownership proof, e.g., with public/private keys and X.509v3 1515 certificates [2]: The certificate binds the public key to the sender 1516 address. Alternatively, Cryptographically Generated Addresses (CGA) 1517 [6] could be used to bind the public key to the sender address. BU 1518 messages from MN's HA to CN's HA must be sent integrity protected, 1519 e.g., by using a beforehand with IKE/IKEv2 [16] [17] established 1520 IPsec ESP [15] SA. 1522 In Mobile IPv6 authentication of BU messages sent from MN to its HA 1523 and authorization of MN to use a particular HoA in the BU message is 1524 achieved by linking the HoA to a specific IPsec security association 1525 [3]. However, the CoA in the BU message is not checked for 1526 correctness. As discussed in [3], it is assume that "an HA can 1527 always identify an ill-behaving MN", which "allows the operator to 1528 discontinue MN's service" (see section 15.3 in [3]). An option 1529 giving a higher level of security would be to conduct additional CoA 1530 reachability tests, e.g., as described in [19]. 1532 BU messages sent from HA to TA can be authenticated with IPsec as 1533 well. The HoA in BU messages can be authorized with certificates: 1534 every certificate contains the set of subnet prefixes that the 1535 corresponding HA is allowed to serve (for home registrations, not for 1536 TA registrations), e.g., in an IP address extension [4]. This is 1537 similar to the approach taken by SEND [5], where certificates contain 1538 prefixes a router may advertise. Besides verifying the signature, a 1539 TA receiving a BU from an HA compares the prefix of the HoA in the BU 1540 message to the set of home subnet prefixes contained in the 1541 certificate of the sender HA. Only if the prefixes match, the BU is 1542 accepted by the TA. Note that in contrast to SEND [5], MN and CN do 1543 not require additional pre-configuration, such as a shared trusted 1544 anchors, since they are not involved in the verification of digital 1545 signatures. The CoA cannot be checked by certificates. Instead, an 1546 ill-behaving MN must be identified as such as described above and the 1547 corresponding HA must be notified, which then can discontinue the 1548 service. Alternatively, CoA reachability tests can be introduced. 1550 If BUs are sent from MN/CN to TAs directly, an SA must exist. This 1551 can be dynamically established using an interface to an AAA 1552 infrastructure (to transfer cryptographic material needed to 1553 establish the SA). Such an interface is currently in development 1554 (see [21]) and may be re-used by ROTA. 1556 8.2 Replay Attacks 1558 Even with the measures discussed above, an attacker could redirect 1559 traffic by eavesdropping a valid BU message and re-sending it later 1560 to an TA. Such replay attacks can be prevented when the freshness of 1561 received signaling messages can be determined by the receiver, e.g., 1562 using (integrity protected) nonces or sequence numbers. IPsec can 1563 provide replay protection. For other cases, ROTA messages include 1564 16-bit message sequence numbers. 1566 8.3 Denial of Service (DoS) Attacks 1568 8.3.1 Reflection 1570 The introduction of false binding information in another node's 1571 Binding Cache, either with false CoA or false HoA, enables DoS 1572 attacks. For instance, an attacker could mount a DoS attack by 1573 redirecting traffic to a victim that cannot handle the amount of 1574 traffic, e.g., because it has a low-bandwidth Internet connection or 1575 because many traffic flows are redirected to one victim. Since the 1576 node that redirects all the traffic acts as reflector, such attacks 1577 are also called reflection attacks. Another related DoS attack 1578 redirects all traffic to a non-existent address. Those attacks can 1579 be prevented by the measures described in Section 8.1. 1581 8.3.2 Amplification 1583 Amplification can make reflection attacks even more dangerous. If an 1584 attacker sends protocol packets with a spoofed source address to a 1585 node and this node answers with a higher amount of protocol packets 1586 or larger protocol packets, a victim node having the spoofed source 1587 address can be flooded with unwanted protocol packets. Thus, a well- 1588 designed protocol should ensure that requests, especially those 1589 without data origin authentication, are always replied with a single 1590 packet of about the same or less size and are sent to the sender 1591 address of the request. Although ROTA follows this guideline, the 1592 Candidate TA option may result in reply messages bigger than the 1593 corresponding requests. Hence, data origin authentication is very 1594 important here: Requests may only be replied if their origin is 1595 authenticated and if received from trusted nodes. This can, e.g., be 1596 achieved if ROTA Request/Reply messages are only sent over IPsec SAs. 1598 8.3.3 Memory Exhaustion 1600 Other DoS attacks which should be prevented are memory exhaustion 1601 attacks, i.e., an attack achieving the consumption of all memory 1602 resources of a victim by sending special sequences of protocol 1603 packets. To prevent such kind of attacks, no state should be 1604 established in HAs before the initiator of ROTA has proven to be 1605 authorized to do so. If IKE is used to establish an IPsec SA in the 1606 first place, this requirement can be achieved. Between MN and its HA 1607 as well as between CN and its HA IPsec SAs are required for Mobile 1608 IPv6 signaling anyway [3]. 1610 8.3.4 CPU Exhaustion 1612 Verification (e.g., digital signature verification) can require 1613 significant CPU resources, which can be exploited for another type of 1614 attack, the CPU exhaustions attack. Though this attack only affects 1615 HAs, since MNs are not required to perform computationally expensive 1616 operations in ROTA, the attack would be especially dangerous if one 1617 attacker would send multiple signed ROTA Requests with spoofed source 1618 address. 1620 Data origin authentication without using computationally expensive 1621 public key cryptography can alleviate this problem. Such a weak 1622 "pre-authentication" is for instance be done by IKEv2 or in [20] 1623 using cookies. Hence, the use of IKEv2 to establish IPsec SAs 1624 between HAs and TAs can alleviate this problem. 1626 If IKEv2 is not used, another weak countermeasure could be to first 1627 start verification after receiving a positive ROTA Initiation Reply 1628 from CN. CN additionally checks, whether it has an active 1629 communication session with the MN's HoA contained in the ROTA 1630 Request, e.g., by checking its IPv6 Destination Cache. This way, the 1631 attacker needs to have knowledge about active communication sessions 1632 of CN or first has to start a communication session with CN. 1634 Additionally, a limit on the amount of resources used for 1635 verifications should be set. This approach is also used as a 1636 countermeasure for a similar attack ("Inducing unnecessary binding 1637 updates") against the Mobile IPv6 route optimization mode (see 1638 section 3.3.1 in [18]). 1640 8.4 Other Attacks on Sending Binding Information 1642 Other attacks are described [18] such as blocking of BU messages or 1643 forcing non-optimized bindings are considered less severe and are 1644 applicable to both ROTA and route optimization mode. Hence they are 1645 not discussed in this memo. 1647 8.5 Attacks against Location Privacy 1649 To ensure location privacy, an attacker MUST NOT be able to 1650 successfully pretend to be a TA. Otherwise it could find out MN's 1651 CoA and thus its location. For this reason, the intended receiver of 1652 a BU message must prove to MN's HA that it is a valid TA, i.e., it 1653 must be authorized to act as a TA. Also, the TA must be trustworthy 1654 and it may not be under control of an attacker. This can, e.g., be 1655 achieved by using authorization certificates, which can be verified 1656 when a shared trusted anchor exists. This approach is again similar 1657 to SEND [5], where certificates are used to authorize routers to act 1658 as routers. 1660 Note that partial protection against profiling attacks by hiding the 1661 HoA from eavesdroppers might be possible with ROTA as well by 1662 encrypting signaling and data traffic on all IPsec tunnel segments, 1663 as described in [8] for the MN-HA segment. However, this approach is 1664 considered computationally expensive for the HAs since the data 1665 packet payload is unnecessarily encrypted as well. Other approaches, 1666 which only replace the HoA with a privacy label [8] seem more 1667 appropriate and may be combined with ROTA. 1669 8.6 Overlay Re-routing Attacks 1671 Since the optimized route depends on distance information obtained 1672 from Probe and Distance Information messages, those messages must be 1673 sent authenticated and integrity protected. Otherwise an attacker 1674 may be able to change the overlay route in way that is of benefit for 1675 him, e.g., to eavesdrop traffic. All ROTA messages including 1676 Distance Information messages are required to be sent authenticated 1677 and integrity protected. However, the format of active probe 1678 messages and their protection is not yet specified. This is left for 1679 future work. 1681 9. References 1683 9.1 Normative References 1685 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1686 Levels", BCP 14, RFC 2119, March 1997. 1688 [2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1689 Public Key Infrastructure Certificate and Certificate Revocation 1690 List (CRL) Profile", RFC 3280, April 2002. 1692 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1693 IPv6", RFC 3775, June 2004. 1695 [4] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 1696 Addresses and AS Identifiers", RFC 3779, June 2004. 1698 9.2 Informative References 1700 [5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1701 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1703 [6] Aura, T., "Cryptographically Generated Addresses (CGA)", 1704 RFC 3972, March 2005. 1706 [7] Koodli, R., "IP Address Location Privacy and IP Mobility", 1707 draft-koodli-mip6-location-privacy-00 (work in progress), 1708 February 2005. 1710 [8] Koodli, R., "Solutions for IP Address Location Privacy in the 1711 presence of IP Mobility", 1712 draft-koodli-mip6-location-privacy-solutions-00 (work in 1713 progress), February 2005. 1715 [9] Haddad, W., "Privacy for Mobile and Multi-homed Nodes: MoMiPriv 1716 Problem Statement", draft-haddad-momipriv-problem-statement-01 1717 (work in progress), February 2005. 1719 [10] Haddad, W., "Privacy for Mobile and Multi-homed Nodes 1720 (MoMiPriv): Formalizing the Threat Model", 1721 draft-haddad-momipriv-threat-model-00 (work in progress), 1722 February 2005. 1724 [11] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", 1725 draft-wakikawa-nemo-orc-01 (work in progress), November 2004. 1727 [12] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier, 1728 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 1729 draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. 1731 [13] Thubert, P., "Global HA to HA protocol", 1732 draft-thubert-nemo-global-haha-00 (work in progress), 1733 October 2004. 1735 [14] Krishnamurthi, G., Chaskar, H., and R. Siren, "Providing End- 1736 to-End Location Privacy in IP-based Mobile Communication", IEEE 1737 WCNC 2004, March 2004. 1739 [15] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 1740 (ESP)", RFC 2406, November 1998. 1742 [16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 1743 RFC 2409, November 1998. 1745 [17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1746 draft-ietf-ipsec-ikev2-17 (work in progress), October 2004. 1748 [18] Nikander, P., "Mobile IP version 6 Route Optimization Security 1749 Design Background", draft-ietf-mip6-ro-sec-03 (work in 1750 progress), May 2005. 1752 [19] Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using 1753 a State Cookie", draft-dupont-mipv6-rrcookie-01 (work in 1754 progress), June 2005. 1756 [20] Bao, F., "Certificate-based Binding Update Protocol (CBU)", 1757 draft-qiu-mip6-certificated-binding-update-03 (work in 1758 progress), March 2005. 1760 [21] Giaretta, G., "Goals for AAA-HA interface", 1761 draft-ietf-mip6-aaa-ha-goals-00 (work in progress), May 2005. 1763 [22] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1764 draft-ietf-mip6-bootstrapping-split-00 (work in progress), 1765 June 2005. 1767 Authors' Addresses 1769 Kilian A. Weniger 1770 Panasonic R&D Center Germany 1771 Monzastr. 4c 1772 Langen 63225 1773 Germany 1775 Phone: +49 6103 766 137 1776 Email: kilian.weniger@eu.panasonic.com 1778 Takashi Aramaki 1779 Matsushita Electric (Panasonic) 1780 5-3 Hikarinooka 1781 Yokosuka 239-0847 1782 Japan 1784 Phone: +81 46 840 5353 1785 Email: aramaki.takashi@jp.panasonic.com 1787 Appendix A. Recommendations for TA Selection 1789 The TA selection algorithm must meet the privacy requirements of MN 1790 and CN, should provide good route optimization and should minimize 1791 the signaling traffic. The input parameters of the algorithm are at 1792 least the privacy requirements of MN and CN (as indicated with the 1793 P-flag in ROTA Initiation Request/Reply messages), a list of 1794 candidate TAs (provided by MN, CN, MN's HA and CN's HA), and 1795 optionally distance information. The candidate TA list should 1796 contain the addresses of MN's HA and CN's HA and may contain local 1797 HAs or other external HAs that may act as TA. However, the list may 1798 only contain TAs that are trusted by MN's and CN's HA. Untrusted TA 1799 addresses must be deleted from the list by MN's and CN's HA. 1801 In order to minimize the signaling traffic, ROTA should be aborted if 1802 the route is already short enough without using any TAs or if the 1803 benefit of route optimization is small. Otherwise, it should be 1804 checked whether the route is short enough when ROTA without visited 1805 network support is used, i.e., either MN's or CN's HA serves as TA. 1806 If true and if the privacy requirements allow it, either of both HAs 1807 should be preferred as TA, since establishing tunnels over local HAs/ 1808 MAPs requires more signaling traffic and is only possible if the 1809 visited networks support ROTA. A single local TA may only be used, 1810 if the respective MN/CN does not require location privacy, whereas 1811 two local TAs can provide location privacy for both MN and CN. 1813 Note that if MN's and CN's HA cannot agree on TAs in a first round of 1814 Request/Reply messages, multiple rounds of Request/Reply messages may 1815 be necessary. If the proposed set of TAs is modified, corresponding 1816 entries in the Candidate TA Option MUST be marked with the T-flag. 1817 Further, it must be ensured that the TA selection eventually 1818 terminates, e.g., by counting the additional rounds and aborting 1819 after a certain number of rounds. 1821 Appendix B. Support of Stationary Correspondent Nodes 1823 ROTA targets mobile-to-mobile communication scenarios, but can also 1824 be used for communication with stationary nodes. If CN is mobile, 1825 MN's HA and CN's HA perform the ROTA initiation and TA selection on 1826 behalf of MN and CN to ensure location privacy and thus can be called 1827 Privacy Agents (PA) of MN and CN, respectively. ROTA-aware 1828 stationary CNs require a similar pre-arranged trust relationship to 1829 an PA. Additionally, the PA should be able to act as TA and the PA 1830 must have a trust relationship with other HAs. Of course, a 1831 stationary CN does not require a CoA. Hence, the PA does not serve 1832 as an HA and does not manage a binding or intercept any packets for 1833 the stationary node. Note that either the TA to be used by CN is 1834 always on the path (e.g., because it is co-located with a gateway 1835 router) or the stationary CN must be adapted to be able to reverse 1836 tunnel data packets to the TA. 1838 The PA service could, e.g., be provided by CN's ISP or by a dedicated 1839 Privacy Service Provider. It could also be provided by a Mobility 1840 Service Provider with the PA co-located with an HA. However, 1841 topologically the PA should not be too far away from the stationary 1842 node for good route optimization and location privacy support. 1844 Appendix C. Discussion of Further Optimizations 1846 One drawback of ROTA is the additional overhead due to encapsulation 1847 of data packets. To alleviate this problem, header compression 1848 schemes can be applied to all tunnel segments. Other possible 1849 optimizations include support for an improved TA selection that 1850 considers more parameters, e.g., more detailed privacy requirements 1851 (e.g., location privacy is required, but disclosing location in 1852 country size-like resolution is o.k.), application requirements for 1853 the route length/delay or load factors. Additional features to be 1854 considered in future version is the support for mobile networks and 1855 an interface to an AAA infrastructure, which may be required for 1856 service authorization and charging. Such an interface is currently 1857 in development (see [21]) and may be re-used by ROTA. 1859 Intellectual Property Statement 1861 The IETF takes no position regarding the validity or scope of any 1862 Intellectual Property Rights or other rights that might be claimed to 1863 pertain to the implementation or use of the technology described in 1864 this document or the extent to which any license under such rights 1865 might or might not be available; nor does it represent that it has 1866 made any independent effort to identify any such rights. Information 1867 on the procedures with respect to rights in RFC documents can be 1868 found in BCP 78 and BCP 79. 1870 Copies of IPR disclosures made to the IETF Secretariat and any 1871 assurances of licenses to be made available, or the result of an 1872 attempt made to obtain a general license or permission for the use of 1873 such proprietary rights by implementers or users of this 1874 specification can be obtained from the IETF on-line IPR repository at 1875 http://www.ietf.org/ipr. 1877 The IETF invites any interested party to bring to its attention any 1878 copyrights, patents or patent applications, or other proprietary 1879 rights that may cover technology that may be required to implement 1880 this standard. Please address the information to the IETF at 1881 ietf-ipr@ietf.org. 1883 Disclaimer of Validity 1885 This document and the information contained herein are provided on an 1886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1888 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1889 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1890 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1893 Copyright Statement 1895 Copyright (C) The Internet Society (2005). This document is subject 1896 to the rights, licenses and restrictions contained in BCP 78, and 1897 except as set forth therein, the authors retain all their rights. 1899 Acknowledgment 1901 Funding for the RFC Editor function is currently provided by the 1902 Internet Society.