idnits 2.17.1 draft-bauer-mext-aero-solspace-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 120: '...ws, an RO scheme MUST support configur...' RFC 2119 keyword, line 125: '..." An RO solution MUST support an MR ha...' RFC 2119 keyword, line 126: '... interfaces, and MUST allow a given do...' RFC 2119 keyword, line 127: '...c interface. It MUST be possible to u...' RFC 2119 keyword, line 132: '...ng, packets of specified flows MUST be...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2009) is 5342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3963' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC4225' is defined on line 612, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-bauer-mext-aero-topology-00 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group C. Bauer 3 Internet-Draft S. Ayaz 4 Intended status: Informational DLR 5 Expires: March 13, 2010 A. Ebalard 6 EADS 7 September 9, 2009 9 Solution Space for Aeronautical NEMO RO 10 draft-bauer-mext-aero-solspace-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 March 13, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Many potential solutions have been proposed for NEMO Route 49 Optimization, although none has been adopted up to now. This draft 50 aims on evaluating the different approaches for the aeronautical use 51 case. At the end, a recommendation for the next steps is given. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Correspondent Router . . . . . . . . . . . . . . . . . . . 6 59 3.2. Global HA to HA . . . . . . . . . . . . . . . . . . . . . 9 60 4. Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5. Considerations for PIES . . . . . . . . . . . . . . . . . . . 13 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 67 Appendix A. Short Overview of all RO Solutions . . . . . . . . . 19 68 A.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 A.2. Applicability to the Aeronautical Environment . . . . . . 27 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 72 1. Introduction 74 An extensive overview of NEMO Route Optimization (RO) solution 75 candidates has been provided in [RFC4889]. The options are manifold 76 and obviously the solution has to be adopted based on the operational 77 environment. The task of this draft is to investigate the solutions 78 in more detail and highlight the deficiencies of the protocols that 79 should be addressed in the future. 81 A document listing the requirements that have to be fulfilled by a 82 potential aeronautical NEMO RO solution has already been compiled 83 [I-D.ietf-mext-aero-reqs]. In addition, another document 84 [I-D.bauer-mext-aero-topology] provides information on the 85 aeronautical network environment. We will rely on both to perform 86 the investigation. 88 It is expected that the reader is familiar with the NEMO Support 89 Terminology [RFC4885] and the three above mentioned documents. 91 2. Overview 93 The focus of our investigations is on RO for the ATS/AOS service 94 classes (cf. [I-D.ietf-mext-aero-reqs]). As defined in 95 [I-D.ietf-mext-aero-reqs], the problem of nested MRs is not a 96 requirement and merely desired and can therefore be ignored in the 97 first step. Its only use case is that of a MANET of aircraft, where 98 other solutions to the problem can be found, e.g. within the MANET 99 (routing) itself, that are transparent to NEMO. Support for VMNs is 100 also not required for the ATS/AOS domain. 102 Hence the applicable NEMO RO solutions can be categorized as follows, 103 listing those nodes that are involved in mobility related signaling: 105 1. MNN to CN: RO is performed between the end systems. 107 2. MR to CN: The Mobile Router performs RO on behalf of the MNN with 108 the CN. 110 3. MR to CR: The MR performs RO with a Correspondent Router that is 111 located close to the CN and that can forward traffic from and to 112 the CN. 114 4. MR to HA: The MR binds to a topologically closer Home Agent. 116 The requirements from [I-D.ietf-mext-aero-reqs] play an important 117 role for the analysis. We list them here for ease of reading: 119 1. Req1 - Separability: "Since RO may be inappropriate for some 120 flows, an RO scheme MUST support configuration by a per-domain 121 dynamic RO policy database [...]". The rationale for this 122 requirement is to trigger RO only for flows that really require 123 it. 125 2. Req2 - Multihoming: " An RO solution MUST support an MR having 126 multiple interfaces, and MUST allow a given domain to be bound 127 to a specific interface. It MUST be possible to use different 128 MNPs for different domains". Multihoming itself is supposed to 129 allow segregation of traffic flows over different interfaces. 131 3. Req3 - Latency: "While an RO solution is in the process of 132 setting up or reconfiguring, packets of specified flows MUST be 133 capable of using the MRHA tunnel". 135 4. Req4 - Availability: "An RO solution MUST be compatible with 136 network redundancy mechanisms and MUST NOT prevent fall-back to 137 the MRHA tunnel if an element in an optimized path fails. An RO 138 mechanism MUST NOT add any new single point of failure for 139 communications in general". Redundancy mechanisms do not have 140 to be considered for the RO mechanism itself; this requirement 141 merely tries to ensure that RO does not interfere with any 142 existing redundancy mechanism. 144 5. Req5 - Packet Loss: "An RO scheme SHOULD NOT cause either loss 145 or duplication of data packets during RO path establishment, 146 usage, or transition, above that caused in the NEMO basic 147 support case. An RO scheme MUST NOT itself create non-transient 148 losses and duplications within a packet stream". 150 6. Req6 - Scalability: "An RO scheme MUST be simultaneously usable 151 by the MNNs on hundreds of thousands of craft without 152 overloading the ground network or routing system. This 153 explicitly forbids injection of BGP routes into the global 154 Internet for purposes of RO". 156 7. Req7 - Efficient Signaling: "An RO scheme MUST be capable of 157 efficient signaling in terms of both size and number of 158 individual signaling messages and the ensemble of signaling 159 messages that may simultaneously be triggered by concurrent 160 flows". 162 8. Req8 - Security #1 (for ATS): "The RO scheme MUST NOT further 163 expose MNPs on the wireless link than already is the case for 164 NEMO basic support". 166 9. Req8 - Security #2 (for ATS): "The RO scheme MUST permit the 167 receiver of a BU to validate an MR's ownership of the CoAs 168 claimed by an MR" and "the RO scheme MUST ensure that only 169 explicitly authorized MRs are able to perform a binding update 170 for a specific MNP". 172 10. Req9 - Adaptability: "Applications using new transport 173 protocols, IPsec, or new IP options MUST be possible within an 174 RO scheme". In particular, the RO scheme should not fail on the 175 use of previously unknown higher layer protocols. 177 In the first stage we have performed a short analysis of all the four 178 possible approaches outlined above. We came to the conclusion that 179 only two of these, namely "MR to CR" and "MR to HA", are of interest 180 to the aeronautical environment. We therefore focus on these in 181 Section 3 below. Nevertheless, for completeness, we have added the 182 short analysis of all four categories in Appendix A. 184 3. Discussion 186 This section discusses the "MR to CR" and "MR to HA" proposals in 187 detail. 189 3.1. Correspondent Router 191 The CR approach was first introduced in [I-D.orc] and later a 192 proposal specifically targeted at the aeronautical requirements has 193 been specified in [I-D.draft-bernardos-mext-nemo-ro-cr]. Another 194 document [I-D.draft-wakikawa-mext-cr-consideration] discusses 195 possible issues and provides considerations for the CR protocol. 197 Req1 - Separability: at the moment, the only obvious way how 198 separation could work is on a per address/prefix basis and not 199 traffic type or application. The major problem is related to the CR 200 relying on IGP advertisements within its network to attract traffic 201 destined for the MR. In that case, the separability of different 202 flows can only be achieved based on addresses/prefixes, but not on 203 traffic type on the CR side. The CR specifications (either [I-D.orc] 204 or [I-D.draft-bernardos-mext-nemo-ro-cr]) do not discuss the 205 compatibility with [I-D.draft-ietf-monami6-multiplecoa] and 206 [I-D.draft-ietf-mext-flow-binding] in order to dispatch flows between 207 the MN and its CR via different interfaces (CoA) on the MR. However, 208 whether it is really necessary to direct certain flows, destined to 209 the same CN, over the RO path and others over the MR-HA tunnel is not 210 obvious. At least for the ATS domain, it could be considered 211 sufficient to have separability on a per-address basis. 213 Req2 - Multihoming has, to a certain degree, already been addressed 214 above. Nevertheless, when taking a more detailed look at MCoA, its 215 implementation within the CR protocol comes at the expense of the MR 216 having to register each CoA separatly (no bulk registration). The 217 signaling overhead for the registration grows linearly with the 218 number of CRs the MR is binding with. At least for the ATS domain, 219 this might not be considered as problematic given that only one or at 220 most two CR bindings are probably active at a certain point in time 221 (cf. [I-D.bauer-mext-aero-topology]). 223 Req3 - Latency: the delay of establishing RO with the CR is the sum 224 of the discovery and the registration procedures. Appendix A.3 of 225 [I-D.draft-bernardos-mext-nemo-ro-cr]) states that these steps may be 226 done while the MR-HA tunnel is still used for sending user data. The 227 signaling during a handover is equivalent to that of standard MIPv6 228 RO for [I-D.orc] and an IKEv2 and BU/BA exchange for 229 [I-D.draft-bernardos-mext-nemo-ro-cr]. For as long as this signaling 230 is performed, it could be expected to rely on the (updated) MR-HA 231 tunnel for as long as the binding with the CR has not been renewed. 233 This behaviour depends though on which of the MR-CR and MR-HA 234 bindings has been first successfully updated. A change of the CoA 235 will trigger the same series of events, except for the discovery 236 procedure that is not needed anymore. 238 Req4 - Availability: the MR maintains a communication path with a 239 unique and static HA and also has direct routing paths (RO paths) 240 with its correspondents, via the various CRs located near those final 241 correspondents. In case of failure of the CR, the MR could switch 242 back to the MR-HA tunnel, given that the failure is detected. 243 However, it is difficult to assess whether the probability for a CR 244 failure is larger then for a HA failure. On the other hand, a CR 245 could also increase the availability in case of HA failure if 246 credentials between MR and CR are available and RO can therefore be 247 established in a different way compared to MIPv6 RO. In terms of 248 routing path characteristics, the shorter path used by the MR-CR 249 tunnel might have a lower probability of failure than the "longer" 250 MR-HA path. 252 Req5 - Packet loss: as already mentioned for Req3, while performing 253 signaling for setting up the RO state, the MR-HA tunnel could be used 254 for user data and no packet loss would therefore be induced. For as 255 long as the mobility binding at the CR has not been re-established, 256 packets can flow from the MR via the HA (if already available) 257 directly to the CN, but on the reverse path packets will be sent to 258 the old CoA of the MR and therefore be lost. 260 Req6 - Scalability: if the number of CNs and, most importantly, the 261 number of networks in which they are hosted increases, more CRs will 262 be needed. Appendix A.6 of [I-D.draft-bernardos-mext-nemo-ro-cr] 263 does not discuss the fact that the more CRs a MR has a binding with, 264 the more signaling it needs to send after a handover (change of CoA). 265 It is therefore important to consider the number of nodes within the 266 ATS and AOS domains. Taking into account the ATS communication model 267 (cf. [I-D.bauer-mext-aero-topology]), the number of CRs that the MR 268 should have an active binding with might be limited to two. 270 Req7 - Efficient Signaling: signaling is required for each binding 271 with a CR. If MCoA/flow-binding should be supported, the amount of 272 signaling might increase. An aspect that is not discussed in 273 Appendix A.7 of [I-D.draft-bernardos-mext-nemo-ro-cr] is the 274 signaling that may be required for the detection of the CR, required 275 once at the time RO is initiated. 277 Req8 - Security: a main requirement is that the authenticity of the 278 MNP of the MR has to be verified. [I-D.orc] relies on the well known 279 Return Routability method of Mobile IPv6 and therefore inherits its 280 security weaknesses. [I-D.draft-bernardos-mext-nemo-ro-cr] proposes 281 to use IKEv2/IPsec to secure the BU/BA exchange with the assumption 282 that "certificates are used to prove ownership of prefixes by MRs and 283 CRs". The location, domain and associated authority under which the 284 CR is deployed can make the deployment difficult, depending on the 285 availability of those credentials. 287 Req9 - Adaptability: for as long as generic packet tunneling is used 288 between MR and CR, no problems can be expected wrt security protocols 289 within the inner tunnel. This is similar to NEMO Basic Support. The 290 discussion related to Req1 and Req2 already mentioned that using 291 certain traffic types (e.g. specific transport protocol) for either 292 flow-specific RO or flow-bindings management could be regarded as 293 problematic. 295 The following paragraphs are not directly related to the requirements 296 anymore, but are from a more general perspective. 298 A critical item, that is not directly covered by the requirements, is 299 the discovery of the CR: it is difficult for the MR to know the 300 anycast address for a particual CR, as needed for the discovery 301 request message. Deriving it from the CN address, as originally 302 proposed in [I-D.orc], can not work if both CN and CR do not share 303 the same 64bit prefix. 305 A CR could be regarded as an entity that is close to the CN but 306 already has a trust relationship with the MR. Taking a closer look 307 at the topology of the aeronautical environment, presented in 308 [I-D.bauer-mext-aero-topology], reveals that the following two 309 options for deployment of CRs are possible for ATS: 311 1. CR in ANSP network: while the topological location is excellent 312 for RO purposes, the CR can not be considered to have a trust 313 relationship anymore. If the CR would have, then a trust- 314 relationship would also be possible with the CN, as both are 315 within the same operational domain. 317 2. CR in the neighbouring gACSP network: having a trust relationship 318 between MR and the gACSP domain is very likely, but the 319 topological location is not ideal anymore. The CR can, in 320 general, not be on-path anymore. In fact, it is located in a 321 completely different domain, a situation that will cause 322 operational problems, especially if the network of the CN is 323 multi-homed and peering with several gACSPs. 325 These deployment options are dependent on the credentials mentioned 326 in the discussion of Req8 above. 328 3.2. Global HA to HA 330 The Global Home Agent to Home Agent protocol is specified in 331 [I-D.draft-wakikawa-mext-global-haha-spec] and makes use of the HA 332 reliability protocol [I-D.draft-ietf-mip6-hareliability]. 334 Req1 - Separability: in Global HAHA, instead of having RO triggered 335 on a per-flow or per-destination basis, the MR/MN's position dictates 336 the HA instance used by the MN/MR (usually the topologically closest 337 one). From this perspective, HAHA does not directly provide a way to 338 support this requirement. Whether this requirement is applicable to 339 HAHA is a different question though. Nevertheless, while not 340 explicitly discussed in HAHA at the time of writing, compatibility 341 with MCoA [I-D.draft-ietf-monami6-multiplecoa] and flow-binding 342 [I-D.draft-ietf-mext-flow-binding] specifications could address this 343 issue. 345 Req2 - Multihoming: compatibility with the MCoA/flow-binding 346 specifications needs to be discussed, as already shortly mentioned 347 above in Req1. From a more general point of view, Global HAHA does 348 not fundamentally modify the relationship with the HA, therefore 349 making these protocol extension applicable to it. But due to the way 350 the primary HA of a MN/MR is selected (the topologically closest 351 instance of the first active CoA is used), the addition of new CoA 352 raises questions. If two CoAs have different HA attractors, how 353 should the protocol behave: should it manage to keep a single primary 354 HA for all CoAs (considering one is a primary) or be extended to 355 support bindings for different CoAs with different HAs? Because the 356 binding cache has to be shared between the HA instances, adding 357 support for MCoA/flow-binding to Global HAHA may require additional 358 synchronization and complicates the protocol. 360 Req3 - Latency: the overall latency is composed of the BU/BA exchange 361 between the MR and the HA. In case the MR moves to a different 362 location that attracts a different HA, the MR will receive a HA 363 Switch Message that forces him to establish a binding with the new 364 HA. This requires an additional IKEv2/IPsec and BU/BA exchange. In 365 general, the latency is therefore equivalent to the standard NEMO 366 protocol and several additional RTTs if the MR binds to a new HA 367 after handover events (change of CoA). 369 Req4 - Availability: the operation of HAHA is based on the HA 370 reliability protocol [I-D.draft-ietf-mip6-hareliability] that 371 describes how failovers are performed between local instances. Due 372 to this, a local HA failure can be overcome and this part of the 373 requirement be therefore fulfilled due to the additional local HA 374 instances. When looking at the MR-HA path, if the routing to the 375 home network is broken (not the physical link the MR is using but an 376 element along the path), current behavior is unknown (both for Global 377 HAHA and NEMO Basic Support). Depending on the precise nature of the 378 routing failure, it might be possible within the context of Global 379 HAHA that another HA island starts attracting traffic (this however 380 will also be dependendent on the BGP convergence time of the anycast 381 prefix advertised by the "new" HA island). 383 Req5 - Packet loss: Global HAHA shows the same behaviour as standard 384 MIPv6/NEMO Basic Support. For as long as the MN/MR has not finished 385 mobility signaling for updating the tunnel with the new CoA, the HA 386 will send packets to the old CoA that will therefore be lost. After 387 this signaling has been finished, the MR could be informed by its 388 current HA to switch to another, closer HA. While this adds latency 389 for setting up the RO path (shorter route due to closer HA), it is a 390 "soft" movement and will not cause packet loss as long as the binding 391 with the old HA is kept active while the new binding has not yet been 392 succesfully established. 394 Req6 - Scalability: with Global HAHA, a given MR being handled by the 395 closest HA instance leads to a natural distribution of the traffic 396 between all the HAs. The traffic load at the ground network is 397 dependent on the location of the MRs and the HA islands. From a 398 routing table perspective, Global HAHA deployment puts some load on 399 the BGP routing system, as prefixes have to be advertised. The 400 number of BGP advertised prefixes is dependent on the number of 401 anycast prefixes and HA islands, but should at least be constant and 402 not show any frequent advertise/withdrawal behaviour. Another 403 critical aspect is the network traffic caused by synchronizing the 404 binding caches between the various HA instances (cf. 405 [I-D.draft-ietf-mip6-hareliability]) if the number of HAs is very 406 large. 408 Req7 - Efficient Signaling: in Global HAHA the amount of signaling 409 between the MR and its HA is roughly the same as in NEMO Basic 410 Support. This number is increased by the HA switch operation and 411 therefore depending on the number of HAs. Most importantly, the 412 amount of signaling is constant - it does not depend on the number of 413 correspondent nodes the MR is currently communicating with. 414 Considering that MCoA/flow-bindings will work with Global HAHA in the 415 future, the expected amount of signaling will still remain minimal, 416 for as long as it is performed with only a single HA. As already 417 discussed for Req2 - Multihoming, sychronizing flow-bindings among 418 different HAs will induce more overhead. 420 Req8 - Security: as in Global HAHA bindings are only performed with 421 the HAs of the home network (within a single administrative domain), 422 meeting the security requirements is much easier to fulfill. IKEv2/ 423 IPsec protects the BU/BA message exchanges between the MR and the HA 424 instances. Consecutively, due to the use of IKEv2, the problem of 425 MNP authentication is directly addressed. 427 Req9 - Adaptability: As Global HAHA does not modify the operation of 428 the MR-HA tunnel (apart from having it with the closest HA instance), 429 no limitations are introduced when compared to NEMO Basic Support. 431 The following paragraphs are not directly related to the requirements 432 anymore, but are from a more general perspective. 434 Global HA to HA does not have the problems of the CR protocol wrt 435 security and credentials, as its scope is restricted to the MR and 436 the Mobility Service Provider (MSP) operating the HAs. Its 437 disadvantage is that the level of provided RO depends on the global 438 network presence of the MSP. gACSPs (cf. 439 [I-D.bauer-mext-aero-topology]) can achieve this goal, whether this 440 also holds for airlines acting as their own MSP is unclear. This is 441 in fact a critical aspect for HAHA, as a home network without a 442 distributed global presence can not meet the original goal of 443 providing an adequate, short latency RO path. 445 As mentioned in Section 3.3.1 of [I-D.bauer-mext-aero-topology], the 446 MR could actually be attached to the same network as the CN. 447 Failures within the home network or with the routing path between the 448 visited and the home network breaks connectivity to the HAs and would 449 then prevent communications although both nodes (MR and CN) are in 450 close topological proximity. 452 4. Next steps 454 The investigation showed that both protocols have advantages and 455 disadvantages, although open questions remain for both of them. 457 The CR protocol has issues related to its discovery procedure, but 458 can support multihoming, although at the expense of having to 459 register each CoA separately. The deployment options are restricted 460 by the availability of credentials and by the location of the CNs. 462 Global HA to HA has the advantage of restricting the mobility 463 signaling to the MR and home network only. How multihoming can be 464 addressed is not yet clear; in addition, the overhead caused in the 465 ground network might become an issue with a growing number of HAs. 467 We therefore think that additional work and investigations in the 468 following areas are required: 470 For CR: 472 1. Discovery procedure. 474 2. A more detailed specification of the mobility signaling between 475 MR and CR, including mutual authentication between MR and CR. 477 For HAHA: 479 1. Overhead caused by binding cache synchronizations between HAs. 481 2. Support for multihoming as in 482 [I-D.draft-ietf-monami6-multiplecoa] and 483 [I-D.draft-ietf-mext-flow-binding]. 485 Aftewards, the solution space investgation can be revisited and the 486 proper solution be selected. 488 5. Considerations for PIES 490 All discussion up to now have been focussed on the ATS/AOS traffic 491 classes. Passenger communications, especially for passenger owned 492 devices, has been ignored. 494 We think though that the number of options is severly limited for 495 this scenario: 497 1. RO signaling involving the CNs is unrealistic as those nodes are 498 usually within the public Internet and will most like not 499 implement any mobility functionality. 501 2. Deployment of special infrastructure in the Internet, e.g. CRs, 502 just for the purpose of RO seems unlikely. 504 3. Forcing passengers to install software for mobility functionality 505 might be regarded as problematic. 507 As a consequence, Route Optimization has to be limited to the MR and 508 the MSP network. This implies Global HA to HA is a reasonable 509 solution for the PIES domain. This would also allow to reuse the 510 protocol for the ATS/AOS environment. 512 6. Security Considerations 514 This document only presents information related to the aeronautical 515 NEMO RO solution space. There are no security issues in this 516 document. 518 7. Acknowledgements 520 Christian Bauer and Serkan Ayaz have been partially supported by the 521 European Commission through the NEWSKY project. The views and 522 conclusions contained herein are those of the authors and should not 523 be interpreted as necessarily representing the official policies or 524 endorsements, either expressed or implied, of the NEWSKY project or 525 the European Commission. 527 8. References 529 8.1. Normative References 531 [I-D.bauer-mext-aero-topology] 532 Bauer, C. and S. Ayaz, "ATN Topology Considerations for 533 Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00 534 (work in progress), July 2008. 536 [I-D.ietf-mext-aero-reqs] 537 Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 538 Route Optimization Requirements for Operational Use in 539 Aeronautics and Space Exploration Mobile Networks", 540 draft-ietf-mext-aero-reqs-04 (work in progress), 541 August 2009. 543 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 544 in IPv6", RFC 3775, June 2004. 546 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 547 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 548 RFC 3963, January 2005. 550 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 551 Mobility Route Optimization Solution Space Analysis", 552 RFC 4889, July 2007. 554 8.2. Informative References 556 [I-D.bernardos-nemo-miron] 557 Bernardos, C., "Mobile IPv6 Route Optimisation for Network 558 Mobility (MIRON)", draft-bernardos-nemo-miron-01 (work in 559 progress), July 2007. 561 [I-D.draft-bernardos-mext-nemo-ro-cr] 562 Bernardos, C., Calderon, M., and I. Soto, "Correspondent 563 Router based Route Optimisation for NEMO (CRON)", 564 July 2008, . 567 [I-D.draft-ietf-mext-flow-binding] 568 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 569 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 570 Basic Support", July 2009, . 573 [I-D.draft-ietf-mip6-hareliability] 574 Wakikawa, R., "Home Agent Reliability Protocol", 575 July 2009, 576 . 579 [I-D.draft-ietf-monami6-multiplecoa] 580 Wakikawa, R., Tsirtsis, G., Ernst, T., and K. Nagami, 581 "Multiple Care-of Addresses Registration", May 2009, . 584 [I-D.draft-wakikawa-mext-cr-consideration] 585 Wakikawa, R., "The Design Consideration of Correspondent 586 Router", July 2008, . 589 [I-D.draft-wakikawa-mext-global-haha-spec] 590 Wakikawa, R., Zhu, Z., and L. Zhang, "Global HA to HA 591 Protocol Specification", July 2009, . 594 [I-D.ndproxy] 595 Lee, K., Jeong, J., Park, J., and H. Kim, "ND-Proxy based 596 Route and DNS Optimizations for Mobile Nodes in Mobile 597 Network", February 2004, 598 . 600 [I-D.orc] Wakikawa, R. and M. Watari, "Optimized Route Cache 601 Protocol (ORC)", October 2004, 602 . 604 [I-D.pd] Lee, K., Jeong, J., Park, J., and H. Kim, "Route 605 Optimization for Mobile Nodes in Mobile Network based on 606 Prefix Delegation", February 2004, 607 . 609 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 610 Neighbor Discovery (SEND)", RFC 3971, March 2005. 612 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 613 Nordmark, "Mobile IP Version 6 Route Optimization Security 614 Design Background", RFC 4225, December 2005. 616 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 617 Address Autoconfiguration", RFC 4862, September 2007. 619 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 620 Terminology", RFC 4885, July 2007. 622 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 623 "Mobility Header Home Agent Switch Message", RFC 5142, 624 January 2008. 626 Appendix A. Short Overview of all RO Solutions 628 This Appendix covers all four approaches (MNN to CN, MR to CN, MR to 629 CR, MR to HA) to the RO problem with a short analysis. 631 A.1. Analysis 633 For each solution class, a specific draft is shortly summarized 634 before the analysis is performed. 636 A.1.1. MNN to CN 638 In general, for this solution class information related to the MRs 639 access network and access routers (ARs) is exposed to the MNNs. 640 Based on this information, the MNNs can perform RO by themselves 641 directly with the CN. The MR is therefore only in a supporting role. 643 A.1.1.1. Proposal(s) 645 The MR is attached to a subnet with an appropriate AR. The draft 646 [I-D.ndproxy] describes how the MR relays the subnet prefix of the AR 647 inside the mobile network to the MNNs, that in turn use 648 Autoconfiguration [RFC4862] to configure their IP addresses. The MR 649 then acts as a ND proxy. 651 Another, similar approach relies on prefix delegation between MR and 652 AR [I-D.pd] where the AR receives a complete proper prefix that can 653 be used inside the NEMO mobile network. 655 Packets sent over the RO path use the Type 2 Routing Header and Home 656 Destination Option as specified for RO in [RFC3775]. 658 A.1.1.2. Analysis 660 This approach might face problems in the presence of Secure Neighbor 661 Discovery in the access network [RFC3971] when using the MR as ND 662 proxy. MNNs have to implement MIPv6 [RFC3775] for performing RO 663 themselves and the MR has to be upgraded as well. 665 Verifying the requirements against this solution approach, we come to 666 the following conclusions: 668 1. Req1: Fulfilled. MNNs can decide by themselves to perform RO. 670 2. Req2: To be discussed. MNNs can configure one address per 671 advertised (access network) prefix. The disadvantage is that 672 the access network has to accept every MNN address as source 673 address for packets, something that may not be supported if the 674 egress interface supports having only a single IP address. 676 3. Req3: Fulfilled. Can rely on standard MIPv6 RO; MR-HA tunnel 677 therefore used for as long as RO has not been completed. 679 4. Req4: Fulfilled. RO is performed between the end systems - no 680 additional single-point of failure for communication added. 682 5. Req5: Fulfilled. As long as the RO path has not been 683 established, packets can be sent over the MR-HA tunnel. 685 6. Req6: Problematic. Signaling overhead will be per MNN/CoA/home 686 network prefix/CN. BGP not relevant. 688 7. Req7: Problematic. The signaling for RO is equal to that of 689 standard MIPv6. Several messages and RTTs are needed for every 690 MNN that is performing RO. 692 8. Req8 #1: To be discussed. While the MNP itself is not part of 693 the RO signaling, the addresses of the individual end systems 694 within the RO signaling is in cleartext. This is also the case 695 for NEMO Basic support though, if no IPsec confidentiality 696 protection is used for user data traffic. 698 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA 699 verification can be broken. 701 10. Req9: To be discussed. 703 As conclusion, while this approach allows for high granularity of RO 704 triggering and setup due to the fact that the MNN is in charge, this 705 approach has problems related to scalability and security if standard 706 MIPv6 RO is used at the MNNs. 708 A.1.2. MR to CN 710 In general, within this solution class the MR performs RO on behalf 711 of the MNN. 713 A.1.2.1. Proposal(s) 715 The MR acts as a transparent MIPv6-MN-proxy by performing standard 716 MIPv6 RO signaling on behalf of the MNN/LFN with the CN. The draft 717 [I-D.bernardos-nemo-miron] describes the detailed operation where the 718 MR performs the Return Routability procedure with its own CoA and the 719 MNN address as HoA. Packets protected by IPsec AH between LFN and CN 720 can not be supported in RO mode, but instead have to be routed via 721 the MR-HA tunnel. 723 Packets sent over the RO path use the Type 2 Routing Header and Home 724 Destination Option as specified for RO in [RFC3775]. 726 A.1.2.2. Analysis 728 The basic problem of this approach is the MR acting transparently 729 between MNN and CN and performing the RO as MN from the CN 730 perspective. This can cause problems for security related protocols, 731 as the MR actions can be regarded as man-in-the-middle attacks. This 732 is particularly the case for IPsec AH. 734 Verifying the requirements against this solution approach, we come to 735 the following conclusions: 737 1. Req1: To be discussed. MR has to be configured with policies 738 and has to perform packet inspection. Whether RO can be 739 specifically triggered for certain flows, depending on the 740 traffic type, remains to be clarified though (esp. wrt IPsec). 742 2. Req2: Basically fulfilled. The MR could register several CoAs 743 for the MNN with the help of 744 [I-D.draft-ietf-monami6-multiplecoa], although no bulk 745 registration is available in this case. 747 3. Req3: Fulfilled. Can rely on standard MIPv6 RO; MR-HA tunnel 748 therefore used for as long as RO has not been completed. 750 4. Req4: Fulfilled. RO is performed with the correspondent node - 751 no additional single-point of failure for communication added. 753 5. Req5: Fulfilled. As long as the RO path has not been 754 established, packets can be sent over the MR-HA tunnel. 756 6. Req6: Problematic. Signaling overhead will be per MNN/CoA/home 757 network prefix/CN. BGP not relevant. 759 7. Req7: Problematic. The signaling for RO is equal to that of 760 standard MIPv6. Several messages and RTTs are needed for every 761 MNN-CN pair for which RO is performed. 763 8. Req8 #1: To be discussed. While the MNP itself is not part of 764 the RO signaling, the addresses of the individual end systems 765 within the RO signaling is in cleartext. This is also the case 766 for NEMO Basic support though, if no IPsec confidentiality 767 protection is used for user data traffic. 769 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA 770 verification can be broken. 772 10. Req9: Problematic. IPsec AH not supported for reverse path from 773 MNN/LFN to CN. 775 This approach allows to use simple LFNs as MNNs, but introduces 776 problems due to the middlebox operation at the MR. Security concerns 777 with respect to the RO procedure itself are existing if standard 778 MIPv6 RO is used. Scalability is similar to the approaches in 779 Appendix A.1.1. 781 A.1.3. MR to CR 783 For this approach, a new mobility entity called Correspondent Router 784 (CR) is introduced. The MR performs RO with the CR that forwards 785 traffic from/to the CN/MNN. 787 A.1.3.1. Proposal(s) 789 The CR approach was first introduced in [I-D.orc] as a possible 790 solution to the NEMO RO problem. Later, a proposal based on the CR 791 idea which specifically targeted the aeronautical requirements has 792 been specified in [I-D.draft-bernardos-mext-nemo-ro-cr]. A third 793 document [I-D.draft-wakikawa-mext-cr-consideration] has then been 794 issued by the main author of [I-D.orc] for discussing possible issues 795 and for providing considerations for the CR protocol. 797 The MR performs a discovery procedure to detect the CR that should be 798 located either 1) on the routing-path to the CN or 2) within the 799 network of the CN where it can announce proxy-routes via an IGP for 800 the MNP(s) of the MR. Once the mobility binding has been 801 established, the CR can intercept traffic (e.g. based on routes 802 advertised via IGP) and tunnel it to the MR. Similarly, in the 803 reverse direction the MR tunnels traffic destined to the prefix(es) 804 served by the CR directly to this router. This is shown in Figure 1. 806 The discovery procedure is a critical part of the overall protocol 807 and while the original document [I-D.orc] did propose a solution, 808 issues related to this approach are discussed in 809 [I-D.draft-bernardos-mext-nemo-ro-cr]. Hence, this topic has to be 810 regarded as work in progress. 812 The authentication of the MNP in [I-D.orc] is achieved by adding a 813 prefix sub-option containing the MNP(s) of the MR to the Home Test 814 Init (HoTI) message. The HA only forwards the message to the CR if 815 the originator of the message (MR) is also the owner of the prefix 816 contained with the HoTI message. 818 CR Discovery is achieved by an ICMP-based mechanism similar to 819 Dynamic Home Agent Address Discovery (DHAAD), based on the 820 Correspondent Nodes 64bit prefix. 822 The operation of a CR is more complicated if it is located in a 823 multihomed site: asymmetric routing could result if the CR serving 824 the MR on the forward path can not ensure to also intercept and 825 foward packets to the MR on the reverse path. 827 +----+ 828 | MR | <--+ 829 +----+ | 830 v 831 +----------------+ 832 | Access Network | 833 +----------------+ 834 ^ 835 | +----------+ 836 | | +----+ | 837 +---|--+ | CN | | 838 | | +----+ | 839 | | ^ | 840 | v | | 841 | +----+ | | 842 | | CR | <--+ | 843 | +----+ | 844 | ANSP Network | 845 +-----------------+ 847 Figure 1: CR-based NEMO RO. 849 A.1.3.2. Analysis 851 The CR approach has both advantages and disadvantages. 853 1. Req1: To be discussed. MR has to be configured with policies 854 and has to perform packet inspection. Whether RO can be 855 specifically triggered for certain flows, depending on the 856 traffic type, remains to be clarified though (esp. wrt IPsec). 858 2. Req2: Basically fulfilled. The MR could register several CoAs 859 for its MNP(s) with the help of 860 [I-D.draft-ietf-monami6-multiplecoa], although no bulk 861 registration is available in this case. 863 3. Req3: Fulfilled. Similar to standard MIPv6 RO; MR-HA tunnel 864 therefore used for as long as RO has not been completed. 866 4. Req4: To be discussed. The CR itself could be regarded as a new 867 single point of failure, but if CR failure can be detected the 868 MR-HA tunnel could be used again. 870 5. Req5: Fulfilled. As long as the RO path has not been 871 established, packets can be sent over the MR-HA tunnel. When 872 the MR performs a transition to a new access network and an RO 873 state has been established with the CR, packets will be lost as 874 the CR will send them to the old CoA of the MR. This is also 875 true for NEMO Basic Support though, where the HA will send 876 packets to the old CoA of the MR for as long as the mobility 877 binding has not been updated. 879 6. Req6: To be discussed. Signaling overhead is per CoA/MNP/CR. 880 BGP not relevant, IGP advertisements and routing table size at 881 the CR grows with the number of registered MNPs though. 883 7. Req7: To be discussed. CNs within the same network can be 884 served by a single CR, mobility signaling is therefore only 885 performed for new CoAs. The overall signaling overhead is 886 directly related to the distribution of CNs and CRs. An 887 additional overhead is caused by the discovery procedure. 889 8. Req8 #1: To be discussed. The MNP itself is part of the RO 890 signaling and could be sent in cleartext. 892 9. Req8 #2: Problematic. If relying on standard MIPv6 RO, MNP/HoA 893 verification can be broken. 895 10. Req9: Fulfilled. The tunneling between MR and CR preserves 896 inner packet characteristics. 898 An advantage of CR is that RO is scalable wrt the number of CNs as 899 mobility signaling is performed per network or at least per grouped 900 list of prefixes served by the CR (under the assumption that the CNs 901 are located within those prefixes). 903 Another problem is the authentication between MR and CR: [I-D.orc] 904 relies on the standard MIPv6 Return Routability procedure that has 905 security weaknesses. In addition, the authentication of the CR to 906 the MR is not taken into account in the original draft, but has to be 907 considered as a potential threat. 909 A.1.4. MR to HA 911 For this approach a new home network architecture is introduced where 912 Home Agent functionality is shared among a set of instances that is 913 geographically spread. At a given moment, based on the current 914 topological location, the MR uses the closest HA instance. 916 A.1.4.1. Proposal 918 The Global Home Agent to Home Agent protocol 919 [I-D.draft-wakikawa-mext-global-haha-spec] extends the original 920 MIPv6/NEMO model, where only a single HA is available per MN, to an 921 architecture where HAs are geographically distributed. MNs can bind 922 to the closest HA to achieve a certain level of RO. 924 The Home Network relies on advertising a large common prefix via EGP 925 that inflicts anycast routing. The traffic of a CN will be attracted 926 by the topologically closest HA, just as mobility signaling from the 927 MN will always be attracted by the topologically closest HA as well. 928 In the latter case, the closer HA will inform the MNs current primary 929 HA of the suboptimal routing. The primary HA will send a HA switch 930 message that orders the MN to bind with the closer HA, based on 931 signaling specified in [RFC5142]. This way, by reducing the distance 932 between the MR and its HA, a certain degree of RO is achieved. 933 Signaling between HAs is based on 934 [I-D.draft-ietf-mip6-hareliability]. 936 A graphical illustration is shown in Figure 2. 938 +----+ 939 | MR | <-----+ 940 +----+ | 941 v 942 +----------------+ 943 | Access Network | 944 +----------------+ 945 | 946 +------------|------------------+ 947 | | 948 | +----+ +----+ +----+ | 949 | | HA | | HA | | HA | | 950 | +----+ +----+ +----+ | 951 | Mobility | Service Provider | 952 +------------|------------------+ 953 | 954 v 955 +--------------+ 956 | +----+ | 957 | | CN | | 958 | +----+ | 959 | ANSP Network | 960 +--------------+ 962 Figure 2: Global HA to HA. 964 A.1.4.2. Analysis 966 HAHA is significantly different from the other approaches as it does 967 not require any mobility functionality in the CN or within the CN 968 network. Mobility signaling, apart from the MR and its current 969 primary HA, is performed within the various instances of the HAs in 970 the ground network only. 972 1. Req1: To be discussed. RO is always implicitly provided by 973 switching to a closer HA. Packet inspection at the MR would 974 have to be introduced to identitfy the different flows. This 975 requirement could only be discussed within the context of 976 multihoming extensions, namely 977 [I-D.draft-ietf-monami6-multiplecoa] and 978 [I-D.draft-ietf-mext-flow-binding]. 980 2. Req2: To be discussed. Given compatability to 981 [I-D.draft-ietf-monami6-multiplecoa] is provided, the MR could 982 register several CoAs for its MNP(s). It is unclear though how 983 the protocol could support simultaneous mobility signaling with 984 two HAs if each one is considered to be close to each 985 respective, active interface at the MR. 987 3. Req3: Fulfilled. As long as the MR has not registered to the 988 new HA, the old MR-HA tunnel should be preserved. 990 4. Req4: Fulfilled. HAHA adds availability mechanisms to the home 991 network as it is based on [I-D.draft-ietf-mip6-hareliability]. 993 5. Req5: Fulfilled. As long as the binding with the new HA has not 994 been completed, packets can be sent over the MR-previous HA 995 tunnel. 997 6. Req6: To be discussed. Signaling overhead is per CoA/HA. HAHA 998 relies on BGP advertisements to achieve anycast routing. The 999 scale of the advertisements should only be per HA island/anycast 1000 prefix and not per MR/MNP. 1002 7. Req7: Fulfilled. Mobility signaling is similar to MIPv6/NEMO 1003 and performed per MR and HA. 1005 8. Req8 #1: Fulfilled. No exposure on the wireless link to what 1006 already happens for NEMO. 1008 9. Req8 #2: Fulfilled. Security is on the same level as in NEMO. 1010 10. Req9: Fulfilled. The tunneling between MR and HA preserves 1011 inner packet characteristics. 1013 While the level of RO provided by HAHA is not as good as for the 1014 previous approaches, it can help eliminate continental round-trip 1015 times in the aviation scenario. 1017 A large advantage are the strong security properties as mobility 1018 signaling is restricted to the MR and the HA (mobility service 1019 provider). 1021 A.2. Applicability to the Aeronautical Environment 1023 A.2.1. Overview 1025 Table 1 provides a summary of the fulfillment of the individual 1026 requirements by each solution. Certain requirements turned out to be 1027 difficult to assess within the context of the solution - in that case 1028 the "D" categorization has been used to indicate that a more detailed 1029 investigation is needed on that subject. 1031 As can be seen the first two approaches "MNN to CN" and "MR to CN" 1032 have problems related to scalability and efficient signaling, as RO 1033 signaling is always performed on a per CN basis. The latter, in 1034 addition, has problems related to the security (address 1035 authentication) and adaptility requirements. The "MNN to CN" 1036 approach is mostly interesting from the nesting problem perspective 1037 only. 1039 The rationale for Requirement 8 - Security (Section 3.8.1 in 1040 [I-D.ietf-mext-aero-reqs]) mentions that it is "reasonable to assume 1041 trust relationships between each MR and a number of mobility anchor 1042 points topologically near to its CNs". The rationale says that this 1043 trust relationship equates on having credentials for the 1044 authentication of the MNP between the mobility entities (MR, HA, CR). 1045 This statement actually rules out all "X to CN" approaches (under the 1046 assumption that standard MIPv6 Return Routability signaling should 1047 not be accepted due to its security limitations). 1049 More promising solutions are the CR and the HAHA protocols and we 1050 have therefore focussed on these two approaches in more detail in 1051 Section 3. 1053 +-------------+-----------+----------+----------+----------+ 1054 | Requirement | MNN to CN | MR to CN | MR to CR | MR to HA | 1055 +-------------+-----------+----------+----------+----------+ 1056 | 1 | F | D | D | D | 1057 | | | | | | 1058 | 2 | D | F | F | D | 1059 | | | | | | 1060 | 3 | F | F | F | F | 1061 | | | | | | 1062 | 4 | F | F | D | F | 1063 | | | | | | 1064 | 5 | F | F | F | F | 1065 | | | | | | 1066 | 6 | P | P | D | D | 1067 | | | | | | 1068 | 7 | P | P | D | F | 1069 | | | | | | 1070 | 8-1 | D | D | D | F | 1071 | | | | | | 1072 | 8-2 | P | P | P | F | 1073 | | | | | | 1074 | 9 | D | P | F | F | 1075 +-------------+-----------+----------+----------+----------+ 1077 Abbreviations: F... Fulfilled, P... Problematic, D... To be 1078 discussed 1080 Table 1: Overview of solution characteristics 1082 Authors' Addresses 1084 Christian Bauer 1085 German Aerospace Center (DLR) 1087 Email: Christian.Bauer@dlr.de 1089 Serkan Ayaz 1090 German Aerospace Center (DLR) 1092 Email: Serkan.Ayaz@dlr.de 1094 Arnauld Ebalard 1095 EADS Innovation Works 1097 Email: arnaud.ebalard@eads.net