idnits 2.17.1 draft-ebalard-mext-ipsec-ro-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 21, 2009) is 5444 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) == Outdated reference: A later version (-01) exists of draft-ebalard-mext-pfkey-enhanced-migrate-00 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ebalard 3 Internet-Draft EADS 4 Intended status: Informational May 21, 2009 5 Expires: November 22, 2009 7 Mobile IPv6 IPsec Route Optimization (IRO) 8 draft-ebalard-mext-ipsec-ro-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 22, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo specifies an improved alternate route optimization 47 procedure for Mobile IPv6 designed specifically for environments 48 where IPsec is used between peers (most probably with IKE). The 49 replacement of the complex Return Routability procedure for a simple 50 mechanism and the removal of HAO and RH2 extensions from exchanged 51 packets result in performance and security improvements. 53 Table of Contents 55 1. Disclaimer and conventions . . . . . . . . . . . . . . . . . . 4 56 1.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Conventions used in this document . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Current situation . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Characteristics of IRO . . . . . . . . . . . . . . . . . . 5 61 2.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.4. Notes to the reader . . . . . . . . . . . . . . . . . . . 8 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. The big picture . . . . . . . . . . . . . . . . . . . . . 9 65 3.2. Pre-binding steps . . . . . . . . . . . . . . . . . . . . 9 66 3.3. BU emission . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.4. Proof of CoA ownership . . . . . . . . . . . . . . . . . . 11 68 3.5. BA emission . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.6. Post-bindings steps . . . . . . . . . . . . . . . . . . . 12 70 4. Proof of CoA ownership . . . . . . . . . . . . . . . . . . . . 13 71 4.1. Position of the problem . . . . . . . . . . . . . . . . . 13 72 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 14 74 4.3.1. Nonce option . . . . . . . . . . . . . . . . . . . . . 14 75 4.4. IRO Messages . . . . . . . . . . . . . . . . . . . . . . . 14 76 4.4.1. Address Ownership Test Offer (AOTO) . . . . . . . . . 14 77 4.4.2. Address Ownership Test Challenge (AOTC) . . . . . . . 15 78 4.4.3. Address Ownership Test Response (AOTR) . . . . . . . . 16 79 4.4.4. Address Ownership Test Status (AOTS) . . . . . . . . . 16 80 4.5. Concrete uses of AOT* Messages . . . . . . . . . . . . . . 17 81 4.5.1. Registration with a CN . . . . . . . . . . . . . . . . 17 82 4.5.2. Early test of CoA ownership . . . . . . . . . . . . . 18 83 4.5.3. Test of HoA ownership . . . . . . . . . . . . . . . . 19 84 5. Remapping rules . . . . . . . . . . . . . . . . . . . . . . . 19 85 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.1.1. On-wire addresses access from userland . . . . . . . . 19 87 5.1.2. Non-MH traffic (data traffic) . . . . . . . . . . . . 20 88 5.1.2.1. Compatibility with traffic using RH2 and HAO . . . 20 89 5.1.2.2. Incoming traffic . . . . . . . . . . . . . . . . . 20 90 5.1.2.3. Outgoing traffic . . . . . . . . . . . . . . . . . 20 91 5.1.2.4. Related traffic (ICMPv6 error traffic, 92 fragments) . . . . . . . . . . . . . . . . . . . . 21 93 5.1.3. MH traffic . . . . . . . . . . . . . . . . . . . . . . 21 94 5.1.3.1. Incoming traffic . . . . . . . . . . . . . . . . . 21 95 5.2. Rules syntax . . . . . . . . . . . . . . . . . . . . . . . 22 96 5.2.1. Remapping rules content . . . . . . . . . . . . . . . 22 97 5.2.2. Remapping rules simple syntax . . . . . . . . . . . . 23 98 6. Tracking SPI changes . . . . . . . . . . . . . . . . . . . . . 23 99 6.1. Initial collect ? . . . . . . . . . . . . . . . . . . . . 24 100 6.2. SADB related PF_KEY events . . . . . . . . . . . . . . . . 25 101 6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 102 6.2.2. Reception of a PF_KEY SADB_GETSPI message . . . . . . 25 103 6.2.3. Reception of a PF_KEY SADB_UPDATE message . . . . . . 26 104 6.2.4. Reception of a PF_KEY SADB_ADD message . . . . . . . . 26 105 6.2.5. Reception of a PF_KEY SADB_DELETE message . . . . . . 26 106 6.2.6. Reception of a PF_KEY SADB_EXPIRE message . . . . . . 26 107 6.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 6.3.1. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 26 109 7. Extending advantages of IRO to the HA . . . . . . . . . . . . 27 110 7.1. Rationale and expected advantages . . . . . . . . . . . . 27 111 7.2. Changes to HA processing . . . . . . . . . . . . . . . . . 27 112 7.3. Changes to MN processing . . . . . . . . . . . . . . . . . 28 113 8. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 28 114 8.1. Nested SA . . . . . . . . . . . . . . . . . . . . . . . . 28 115 8.2. Having IKE traffic flow via the IPsec tunnel to the HA . . 29 116 8.3. Remapping rules and old IPsec architecture . . . . . . . . 31 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 118 9.1. Proof of address ownership . . . . . . . . . . . . . . . . 31 119 9.1.1. Position of the problem . . . . . . . . . . . . . . . 31 120 9.1.2. Home Address ownership . . . . . . . . . . . . . . . . 32 121 9.1.3. Care-of Address ownership . . . . . . . . . . . . . . 32 122 9.2. Remapping (comparison with explicit HAO/RH2 inclusion) . . 33 123 9.3. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 33 124 9.4. Limiting attack surface . . . . . . . . . . . . . . . . . 33 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 126 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 127 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 128 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 129 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 130 Appendix A. Ability to send does not prove CoA ownership . . . . 35 131 Appendix B. IKE exchanges use the HoA and the tunnel to the HA . 36 132 Appendix C. Arguments for no regular check of HoA ownership . . . 37 133 Appendix D. Lack of encryption between MN and HA . . . . . . . . 38 134 Appendix E. What if I don't need protection? . . . . . . . . . . 39 135 Appendix F. MTU Gains . . . . . . . . . . . . . . . . . . . . . . 40 136 Appendix G. Compatibility with static keying . . . . . . . . . . 41 137 Appendix H. Compatibility with the use of CoA in SP/SA . . . . . 42 138 Appendix I. Rationale for not specifying a new BU . . . . . . . . 42 139 Appendix J. Anonymity . . . . . . . . . . . . . . . . . . . . . . 44 140 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 142 1. Disclaimer and conventions 144 1.1. Disclaimer 146 This memo covers MIPv6 Route Optimization in IPsec/IKE environments. 147 For that reasons it is expected that the reader be familiar with the 148 main reference documents associated with those topics. 150 This includes the main MIPv6 reference documents ([RFC3775], 151 [RFC3776], [RFC4877], ...) and main IPsec/IKE reference documents 152 ([RFC4301], [RFC4303], [RFC4306] and their previous versions). 154 For the discussions regarding the security of route optimization 155 (proof of address ownership, mainly) [RFC4225] is a must read and 156 [RFC4651] provides a good summary of the issues and previous work on 157 possible solutions. 159 The Security Considerations section (section 6) of [RFC4866] also 160 provides a good security-oriented introduction to the address 161 ownership problem. 163 1.2. Conventions used in this document 165 In this document, except otherwise specified: 167 o "IKE" is used as a placeholder for both IKEv1 [RFC2409] and IKEv2 168 [RFC4306]. 169 o "Peer" is used as a placeholder for a MIPv6 end entity, i.e. a CN 170 or a MN. 171 o "HAO" is used as a placeholder for Destination Options Header 172 carrying a Home Address Option. When the address in a HAO is 173 considered, it denotes the address found in the Home Address field 174 of the Home Address option carried in the Destination Options 175 Header. 176 o When "tunnel" is used to designate the IPv6-in-IPv6 path between 177 the MN and its HA, IPsec in tunnel mode is assumed to be in place. 178 o When "MN-CN" is used it also obviously includes the MN-MN case 179 where the second MN acts as a CN for the first MN. 180 o When "IPsec flow" applies to a MN-MN or MN-CN communication, the 181 address of the MN considered for the associated SP is the HoA. 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 2. Introduction 189 2.1. Current situation 191 Mobile IPv6 specification [RFC3775] mandates the use of IPsec for 192 protection of communications (control and optionally data) between a 193 Mobile Node and its Home Agent. Support for static keying is made 194 mandatory, and dynamic keying optional. The protection is made 195 possible by the trust relationship that preexists between the HA and 196 the MN: they belong to a common trust domain (the same network, a 197 PKI). Interactions between MIPv6 and IPsec/IKE for MN and HA 198 exchanges are partly covered in [RFC3776] and [RFC4877]. 200 For implementation reasons outside the scope of previous reference 201 documents, some additional changes to IPsec/IKE are required to 202 support Mobile IPv6. [MIGRATE] specifies a way to implement those 203 changes by extending PF_KEY framework. 205 [RFC3775] also specifies a Route Optimization procedure which allows 206 direct communications to occur between a Mobile Node (MN) and a 207 Correspondent Node (CN), without suffering the delay associated with 208 the routing through the MN's Home Agent. The setup of this optimized 209 routing is based on a mechanism called Return Routability Procedure 210 (RRP). 212 One of the main hypothesis behind the design of Return Routability 213 Procedure is the lack of trust relationship between the MN and its 214 CN. This results in a complete lack of security in terms of privacy 215 and authentication of data: the procedure mainly provides a limited 216 proof of MN's HoA and CoA addresses ownership to the CN. 218 In trust domains (networks with an underlying PKI infrastructure) 219 where Mobile IPv6 gets deployed using dynamic keying (IKE or IKEv2) 220 for negotiating Security Associations, Mobile Nodes are already 221 provisioned with credentials (X.509 certificates). In those 222 environments, the initial hypothesis that led to the design of RRP 223 and its associated limited security abilities does not hold anymore. 225 At the moment, [CNIPsec] only describes how IPsec can be used to 226 protect signaling traffic between the Mobile Node and the 227 Correspondent Node but only provides a limited coverage of the 228 problem. 230 2.2. Characteristics of IRO 232 This document defines an extension of Mobile IPv6 protocol that aims 233 at replacing common RRP and RO procedures by a mechanism called IPsec 234 Route Optimization (IRO) in environments where IPsec and IKE are 235 used. 237 It allows MN to mount and maintain direct IPsec-protected 238 communications with CN and other MN with which they share some trust 239 relationship, in a completely transparent fashion for upper layer 240 protocols. 242 IRO is not a detailed set of requirements for IPsec to work between 243 MN and CN but a new mechanism resulting from the tight integration 244 and joint efforts of MIPv6, IKE and IPsec to provide a secure and 245 scalable mobility service. 247 The main functional and security advantages that best describe IRO 248 are: 250 o Protected MN-CN binding using IKE-negotiated IPsec SAs. 251 o Complete transparency for IKE (negotiation, rekeying, movement, 252 ...) and other upper layers, including layer 14 (the user). 253 o Compatibility with both tunnel and transport mode IPsec protection 254 between peers. 255 o Compatibility with static keying (See Appendix G). 256 o In MN-CN case, non-disclosure of MN's HoA on its foreign link. 257 o No additional changes to IPsec or IKE protocols and limited 258 changes to MIPv6 via four simple messages and an option resulting 259 in simple and generic integration within IPsec and Mobile IPv6 260 stacks. 261 o Improved and more generic proof of address ownership mechanism. 262 o Safe by default behavior avoiding direct unprotected traffic 263 flows. 264 o Complete removal of RH2 and HAO, resulting in simplified packet 265 handling on both sides and possibly better compatibility with 266 filtering implemented in the network. 267 o Per packet MTU gains between 24 and 48 bytes in comparison with 268 equivalent uses of IPsec in standard RO context. Details are 269 provided in Appendix F. 271 The main prerequisites of IRO are: 273 o Existence of a trust relationship between peers (i.e. shared 274 secret or ability to use IKE). 275 o Required protection of peers' exchanges (i.e. IPsec is used 276 between peers). IRO does not apply to direct unprotected 277 communications between peers. More precisely, IRO prevents them. 278 o To fully benefit from IRO improvements, data traffic between the 279 MN and its HA must be exchanged through an IKE-negotiated movement 280 resistant IPsec tunnel. If this hypothesis is not fulfilled, IRO 281 will still be usable but some security features listed previously 282 will be lost (Appendix D). 284 2.3. Motivation 286 The motivation behind this work is the direct need for both efficient 287 and secure communications in Mobile IPv6 environments already 288 benefiting from an underlying trust domain. 290 The first intended target of the mechanism described in this memo is 291 the growing number of corporate networks where PKI are now 292 widespread. This is generally due to the increasing number of 293 services (802.1X, SSL/IPsec VPN, TLS Web portal, S/MIME, ...) that 294 use them on a daily basis as the root of their security and to 295 provide logical segregation. It is also suitable for other kinds of 296 communities. 298 In environments where data confidentiality and privacy do matter 299 (IPsec is used for the protection of data between the MN and its HA), 300 current RRP and RO between peers of the trust domain are usually 301 deactivated: 303 o to prevent direct unprotected communications between peers that 304 would bypass protected tunneling through the Home Network. 305 o because their implementation and setup with IPsec/IKE does not 306 work out of the box and is not trivial even if [CNIPsec] helps for 307 signaling. 309 This results in heavy constraints on the HA (which handles all the 310 traffic to/from its MN) and the de-facto inability to get direct end- 311 to-end IPsec-protected MN-CN and MN-MN communications. 313 The ability to reduce the number of communications performed by the 314 Mobile Node that get tunneled through the HA is both an improvement 315 in term of upload bandwidth consumption on the link to the HA, 316 cryptographic processing requirements on the HA and also in term of 317 latency for applications that directly benefit from end-to-end 318 connections, like Chat, VoIP, Videoconferencing or direct file 319 exchanges. 321 In a sense, there is a kind of vicious circle regarding the use of 322 IPsec/IKE with various protocols, including MIPv6: because dynamic 323 keying and IPsec are not considered the common case, they are not 324 fully covered in specifications (static keying for simple modes). 325 The net effect is that their implementation and deployment is then 326 complicated, which results in limited use. In a sense, IRO tries to 327 break that circle. Simply put, this specification considers IKE- 328 enabled environments as the first target and then covers static 329 keying cases. 331 2.4. Notes to the reader 333 The mechanism described in this memo is very simple from a design 334 perspective. To keep this apparent simplicity and the reading of the 335 document pleasant, all design decisions and main justifications are 336 provided in the numerous appendices (around 10 pages). This allows 337 to focus on the details of the mechanism in the body of the document 338 (around 20 pages). 340 For previous reason, the reading of the document can be performed 341 linearly. The not so curious reader can skip over the appendices 342 which are only a must read for developers and security people to 343 acquire a deep understanding of the mechanism and how security has 344 been taken into account in its design. 346 Unlike many other IETF documents, this memo voluntarily provides a 347 practical implementation feedback geared towards developers. Even if 348 the associated section does not mandate an implementation design, it 349 might be of interest anyway. 351 3. Overview 353 The whole document is geared towards improved security between MIPv6 354 nodes and also improved usability of IPsec/IKE with MIPv6. This 355 section provides to the reader a quick non-normative overview of how 356 IRO works, before entering the details of the mechanism in next 357 sections. The reader is expected to be familiar with the vocabulary 358 used in [RFC3775]. We do not consider in this section the 359 relationship between the MN and its HA, only the relationship between 360 a MN and its CNs. In the whole document, IKE is considered as the 361 default mechanism used for SA setup. 363 This section provides a quick and non-normative overview of IRO and 364 introduces next sections that contain normative details. The first 365 subsection provides a rough outline of IRO. It is followed by 5 366 small subsections that cover the steps of IRO processing, in the 367 order they occur: 369 o Pre-binding steps: installation of remapping rules, which IRO uses 370 to prevent the use of RH2 and HAO in incoming and outgoing 371 signaling packets (MH traffic). 372 o BU emission: description of the steps that apply to the emission 373 of the BU by the MN in the context of IRO. 374 o Proof of CoA ownership: description of the steps that occur when a 375 proof of CoA ownership is requested by the peer. 377 o BA emission: description of the steps that apply to the emission 378 of the BA to the MN in the context of IRO. 379 o Post-binding steps: installation of additional remapping rules, 380 which IRO uses to prevent the use of RH2 and HAO in incoming and 381 outgoing data packets. 383 3.1. The big picture 385 This section simply lists the key ideas and design concepts behind 386 IRO. 388 When IPsec is used between two peers, every packet de facto contains 389 a simple piece of information (the SPI) that gives access to many 390 parameters. Among those parameters synchronized between the two 391 IPsec stacks are address information for both peers. Unlike IPsec, 392 MIPv6 uses specific extensions (RH2 and HAO) to explicitly carry 393 address information. When both protocols are used together and the 394 IPsec SA/SP make use of HoA (i.e. not CoA), the RH2 and HAO 395 extensions in packets carry the HoA. It could easily be deduced from 396 the SPI. Based on this observation, IRO removes RH2 and HAO 397 extensions from packets and replace them by simple additional steps 398 on the sender and the receiver: remapping rules for address based on 399 the SPI. 401 Previous removal of HAO and RH2 extensions from traffic between peers 402 is also perfectly applicable to the traffic between a MN and its HA. 403 This specification extend the remapping rules to the traffic between 404 a MN and its HA. When IRO is used, RH2 and HAO extensions are simply 405 not seen on the wire. 407 As stated previously, the hypothesis on which common RO and RRP are 408 based simply do not hold when peers are able to use IPsec/IKE between 409 them. For that reason, even if some proof of address ownership is 410 still required, a more suitable (read simple) mechanism is defined 411 for that purpose. 413 To sum it up (simplistic vision): 415 o IRO simplifies packets format by removing HAO and RH2 extensions. 416 o IRO fully replaces RRP by a more suitable and simple mechanism 417 taking into account the use of IPsec/IKE between peers. 418 o IRO defines how this can be extended to MN-HA exchanges. 420 3.2. Pre-binding steps 422 Before any direct communication can take place between a MN and a CN, 423 the CN must accept a binding between the CoA and the HoA of the MN. 424 For that to happen, the CN must have acquired the proof of both HoA 425 and CoA addresses ownership by the MN. 427 In RRP, the MN proves to the CN its ability to both send and receive 428 traffic from and at those addresses by a four messages exchange 429 combining both direct and HA-tunneled packets. 431 In the context of IRO, the binding registration between peers is 432 IPsec protected. It is expected that IKE be used for negotiating an 433 initial pair of ESP transport mode IPsec SAs between the HoA of the 434 MN and the address of the CN for protecting this registration (static 435 keying is covered later in the document). IKE negotiation occurs 436 using the tunnel between the MN and its HA, i.e. the MN uses the HoA 437 for that purpose. This provides the CN the initial proof of HoA 438 ownership by the MN. 440 On both entities, the specific IPsec ESP transport mode SAs 441 (protecting MH traffic) created between the peers are taken into 442 account by IRO code in Mobile IPv6 stack. This triggers the setup of 443 specific "remapping rules" on both entities, that will be applied to 444 incoming and outgoing IPsec packets whose SPI matches the one of 445 tracked SAs: 447 1. On the MN, the outgoing IPsec traffic matching the SPI of the 448 associated SA to the CN has its source address remapped to the 449 address stored (by MIPv6 process) in the ancillary data of the 450 packet (the CoA). 451 2. On the CN, the incoming IPsec traffic matching the SPI of the 452 associated SA with the MN has its source address remapped to the 453 specific source address in the SA (the HoA of the MN). The 454 remapped address is kept as an ancillary data in the local packet 455 structure for further processing. The packet is then naturally 456 handled by the IPsec stack. 457 3. On the CN, the outgoing IPsec traffic matching the SPI of the 458 associated SA to the MN has its destination address remapped to 459 the address stored in the ancillary data of the packet, if not 460 null. 461 4. On the MN, the incoming IPsec traffic matching the SPI of the 462 associated SA to the CN has its destination address compared with 463 the CoA the MN is asking a binding for to the CN. On match, the 464 destination address of the IPsec packet is remapped to the 465 destination address in the SA (the HoA of the MN). The packet is 466 then naturally handled by the IPsec stack. 468 Simply stated, rules 1 and 3 will end up performing a remapping of 469 HoA used in outgoing IPsec packets in their CoA counterparts and 470 rules 2 and 4 will do the opposite on the other side for incoming 471 IPsec packets. 473 Note that these rules apply only to IPsec packets associated with SA 474 that protect MH traffic. They are used before any data packet is 475 received or sent by the entities using a direct path. 477 3.3. BU emission 479 The MIPv6 stack on the MN emits a Binding Update packet containing a 480 Mobility Header AltCoA option which carries the CoA it is proposing a 481 binding for to the CN. This packet is sent from the HoA of the MN to 482 the address of the peer. The CoA is put as an ancillary data in the 483 local packet structure for further processing. As it matches the 484 IPsec SA put in place between the MN and the peer, it gets handled by 485 the IPsec stack to be ESP protected. Before leaving the MN, it 486 passes the set of MIPv6 rules for the MN; a match is found against 487 rule 1, so that the source address of the packet is remapped to the 488 address available as an ancillary data in the packet, the CoA of the 489 MN. 491 When the IPsec protected BU hits the MN, it passes the set of MIPv6 492 rules for the CN. It matches rule 2 so that its source address is 493 remapped to the source address of the SA (the HoA of the MN). The 494 source address found in the packet is stored as ancillary data. The 495 packet is handled by the IPsec module, matches the SA, is decrypted 496 and passed to the upper layer, the MIPv6 process. 498 During parsing, the CN compares the content of the AltCoA option with 499 the address previously stored as ancillary data. 501 3.4. Proof of CoA ownership 503 At that point, before accepting the binding and replying with a BA, 504 the CN must have the proof of CoA ownership from the MN. If one is 505 already available, it simply goes on and sends a BA, as described in 506 3.4. Otherwise, it first performs following steps. 508 It sends a newly defined MH message (AOTC, Address Ownership Test 509 Challenge) to the MN, providing the CoA as ancillary data, so that 510 the remapping rules will make the packet use the CoA for the address 511 found in the IPv6 header destination field. This packets carries a 512 freshly generated nonce. 514 On the MN, the packet follows the reverse remapping process, the CoA 515 being remapped to the HoA and passed as ancillary data. The MIPv6 516 stack replies with an IPsec protected MH message to the CN (AOTR, 517 Address Ownership Test Request), using the HoA as local source but 518 providing the CoA as ancillary data. The remapping rule makes the 519 CoA the on-wire address of the packet. This packets carries the 520 nonce sent by the CN. 522 The CN receives the packet and after having checked the source 523 address and the nonce against the one previously sent, the MIPv6 524 stack records the address ownership of the CoA for that MN, and 525 continues with the steps described in Section 3.5 527 3.5. BA emission 529 The CN constructs a Binding Acknowledgement packet to be sent to the 530 HoA of the MN. The CoA of the MN is put as an ancillary data in the 531 local packet structure for further processing. Now, as the BA 532 matches the SA, it is ESP-protected and passes the set of MIPv6 rules 533 for the CN. It matches rule 3 and the HoA is replaced with the 534 address available in the ancillary data of the packet (MN's CoA). 535 The packet is then sent. At that moment, if the status code in the 536 BA is 0 (Binding Update Accepted), the binding is effective on the 537 CN. 539 On the MN, the IPsec protected BA is received, it passes through the 540 set of MIPv6 rules for the MN and matches rule 4. The destination 541 address is changed to the destination address of the SA (HoA of the 542 MN). It is then handled by the IPsec module, and then to the MIPv6 543 process. If the status code in the BA is 0, the binding is effective 544 on the MN. 546 For the rest of this section, we consider the binding is effective on 547 both sides. Other scenarios are covered in details in Section 3. 549 3.6. Post-bindings steps 551 In [RFC3775], when the RRP has completed successfully, routing of 552 traffic between the MN and the CN is automatically modified to follow 553 a direct path. With IRO, on the contrary, a successful binding 554 between a MN and a CN does not trigger any change in routing of 555 _regular_ traffic between the MN and the CN. It still flows using 556 the IPsec tunnel through the MN's HA. Only IPsec traffic is 557 optimized. 559 This design decision provides a "safe by default" behavior and avoid 560 a successful binding to lead to unprotected direct communications. 562 Furthermore, only IPsec flows will be able to take advantage of the 563 direct path between the MN and the CN. Arguments for this design are 564 provided in Appendix E. 566 So, if existing IPsec SAs protecting non-signaling traffic (data) are 567 already available on both sides, that have the HoA and the address of 568 the MN as address selectors, remapping rules are put in place to 569 perform the same kind of address changes presented in four previous 570 rules. Those rules are static ones (they do not use any ancillary 571 data) that remap CoA to HoA and HoA to CoA (after some checks), 572 respectively before and after IPsec processing. 574 They simply replace the HAO and RH2 headers inclusion and parsing on 575 both sides by using the SPI information as an opaque multiplexing/ 576 demultiplexing value available on both ends. 578 4. Proof of CoA ownership 580 4.1. Position of the problem 582 A CN accepting a binding for the CoA of a peer is not something 583 harmless. In the context of IRO, this decision is based on: 585 o a proof of HoA ownership by the MN at the time the SA is 586 negotiated. 587 o a proof of CoA ownership by the MN. 589 The existence of a strong trust relationship between the two (pairs 590 of SA) and an easy proof of emission capability from the CoA are 591 unfortunately insufficient proofs of CoA ownership. As covered in 592 Appendix A, a proof of the ability for the MN to receive traffic at 593 its asserted CoA is required to workaround the lack of ingress- 594 filtering at the scale of Internet: it avoids the CN to involuntarily 595 take part in a DoS against the provided CoA. 597 4.2. Overview 599 As the proof of HoA ownership is only required to occur once in the 600 context of IRO, the mechanism focuses on the proof of CoA ownership. 601 Instead of reusing the complicated RRP, IRO directly benefits from 602 the available IPsec protection between the MN and its CN to simplify 603 things. 605 Furthermore, in the context of IRO, the lifetime of the provided 606 proof is no longer limited and generally de-correlated from 607 registration steps. This already reduces the amount of transferred 608 data and leaves room for further optimizations (nodes with multiple 609 simultaneous connections, nodes with limited numbers of foreign 610 networks, ...) 612 As CoTI and CoT messages have some associated requirements, options 613 and semantic, and also lacks some expressiveness, they are not reused 614 for IRO proof of address ownership. It is based on four new 615 extremely simple messages: 617 o AOTO: Sent by a MN to a CN to offer to prove address ownership. 618 o AOTC: Sent by a CN to the MN at the address to be tested, with a 619 Nonce option that will be returned in an AOTR message. 620 o AOTR: Sent by the MN as a response to an AOTC, with the received 621 Nonce option. 622 o AOTS: Sent by the CN to the MN to provide a status on ongoing 623 address ownership test. 625 4.3. Mobility Options 627 4.3.1. Nonce option 629 The Nonce option has type XX and an alignment requirement of 8n+6. 630 Its format is as follows: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type = XX | Length = 8 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 + Nonce + 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 The content of the Nonce field MUST always be filled with a freshly 643 generated 64-bit random value. 645 XXX For testing purposes, the Nonce option has type value 88. 647 4.4. IRO Messages 649 All the normative information associated with the four new messages 650 specified by IRO are provided in this subsection. This includes 651 their format, associated constants, security related information and 652 processing requirements. 654 Note that the messages defined below are used for proof of ownership 655 of the CoA. They are not used to prove ownership of the HoA: this is 656 either not done (static keying) or the result of the ability to 657 negotiate SA using IKE. 659 4.4.1. Address Ownership Test Offer (AOTO) 661 This message is sent by a MN to a CN to offer to prove its ownership 662 of the CoA the packet was sent from. An AOTO message MUST NOT be 663 sent by a MN if it is not already registered with the CN. If that 664 happens, the CN simply drops the message without further processing. 666 Reception of this message can trigger the emission of either: 668 o an AOTC containing a Nonce option, sent back to the source address 669 of the AOTO. 670 o an AOTS with status 0, indicating that the peer does not allow the 671 peer to pre-register CoA ownership information. 672 o an AOTS with status 1, indicating to the peer that the proof of 673 Address ownership is still valid. 674 o nothing if it is invalid or sent by an unregistered MN. 676 The format of the message is as follows: 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Reserved | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Reserved field is not used yet but might be for future need. It 685 currently serves padding requirements. It should be set to null on 686 emission and ignored on reception by peers complying with this 687 specification. 689 AOTO messages do not carry options. MH Type field in Mobility Header 690 takes value XX when carrying an AOTO message. 692 XXX For test purposes, MH Type field should use value 30 694 4.4.2. Address Ownership Test Challenge (AOTC) 696 The purpose of this message is to provide a nonce to an MN at the 697 address the MN wants to provide proof of ownership for. The ability 698 for the MN to return the nonce to the CN (in an AOTR) provides a live 699 proof of its ability to receive traffic at that address. This 700 message is possibly sent by a CN to a MN in two situations: 702 o After receiving a Binding Update message that the CN is willing to 703 accept but for which it does not already has a proof of address 704 ownership for the originating CoA the packet was sent from 705 (correlated with the content of the AltCoA option). 706 o After receiving an AOTO from a MN that wants to perform a proof of 707 address ownership for the source address of the packet. 709 The format of the message is as follows: 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Reserved | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | | 717 . . 718 . Mobility Options . 719 . . 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 The Mobility Options field must always contain a Nonce option. The 724 nonce must be stored locally by the CN for that MN, along with the 725 address being tested. The nonce will be compared with the content of 726 the nonce option found in the AOTR messages. 728 MH Type field in Mobility Header takes value XX when carrying an AOTC 729 message. 731 XXX For test purposes, MH Type field should be set to 31 733 4.4.3. Address Ownership Test Response (AOTR) 735 This message is sent by the MN as a result of receiving an AOTC 736 (resulting from an initial action, BU or AOTO). It contains the same 737 nonce, in a Nonce option, the peer had included in its AOTC. The 738 AOTR message is sent from the address to be tested (the on-wire 739 destination address of the AOTC). 741 When received by the CN, on-wire source address is used to access the 742 stored nonce previously sent in an AOTC message and compare it with 743 the one in the Nonce option found in the message. On match, the 744 address ownership by the peer is considered proved. 746 The format of the message is the same as the AOTC message except for 747 MH Type field in Mobility Header which takes value XX when carrying 748 an AOTR message. 750 XXX For test purposes, MH Type field should be set to 32 752 4.4.4. Address Ownership Test Status (AOTS) 754 This message is sent by the CN with a status regarding a proof of 755 address ownership. The status can be generic (not associated to an 756 address whose ownership is being proved), for instance if this CN 757 does not allow MN initiated Address Ownership Tests to occur. It can 758 also be specific to an ongoing or already performed Test of Address 759 Ownership, for instance to explicitly acknowledge the result of the 760 test. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Code | Reserved | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 MH Type field in Mobility Header takes value XX when carrying an AOTS 769 message. Code field provides the status code the message carries. 770 The list of status codes is provided below: 772 AOTS status codes: 774 o 0 AOTO not allowed 775 o 1 Proof of Address Ownership is valid 777 XXX For test purposes, MH Type field should be set to value 33 779 4.5. Concrete uses of AOT* Messages 781 4.5.1. Registration with a CN 783 The registration process between a MN and its HA is simple and 784 efficient, being made of a simple BU [/BA] exchange. This is because 785 the proof of CoA ownership is not required by the HA from the MN. 787 Like with other route optimization procedures, with IRO, the CN is 788 required to have a proof of CoA ownership available for the MN before 789 accepting a binding and replying with a Binding Ack. More precisely, 790 the proof is needed only before sending traffic to the CoA of the MN 791 but does not impact the reception of traffic from the CoA. This is 792 of particular importance in the rest of the discussion. 794 Unlike in other more common environments where the proof has to be 795 made at every binding, or "renewed", IRO uses proofs with unlimited 796 lifetimes. This does not mean that once the ownership has been 797 proved to a CN the CoA will indefinitely belong to a MN. The 798 decision is always left to the CN, with the expectation that some 799 sufficient temporary storage will make it capable to keep the binding 800 for a while. 802 This means that if a proof of CoA ownership for a MN is available 803 locally on its CN, no live proof is required and a simple BU [/BA] 804 exchange is sufficient for the registration to occur. This also 805 means that inside small or medium communities, where MN move between 806 few locations, the number of potential CoA remains quite low and 807 stable, and can be kept locally on nodes acting as CN. 809 For instance, without limiting the possible uses, a typical scenario 810 for a daily use includes an address at home (wifi, ...), another on a 811 mobile network (3G, ...) and another at work (wifi, Ethernet, ...). 813 With IRO, when a MN sends a BU to a CN for registration or 814 reregistration purposes, it starts directing its traffic instantly 815 after the emission of the BU to the address of the CN. Then, the CN 816 will either ask for proof of CoA ownership if it has none available 817 from that MN for that CoA or send a BA to the peer. In all cases, it 818 puts in place the remapping rules for accepting traffic from the CoA 819 (and not the one for emission). That way, there is no disruption of 820 traffic from the MN to the CN. 822 If the CN replies with an AOTC message sent to the CoA of the MN, the 823 MN replies with an AOTR, proving its complete ownership. The CN then 824 replies with the expected BA and puts in place the required remapping 825 rules for the traffic to flow to the MN at its CoA. 827 Regarding re-emission, if the MN has no reply from the CN (i.e. no BA 828 or AOTC), common re-emission rules apply. Then, if the CN has sent 829 an AOTC, but receives no reply, it can keep things that way or 830 garbage collect the remapping rule (i.e. remove it after some time). 831 If the MN receives no BA from the CN, it performs re-emission of the 832 AOTR (This implies that the Nonce must be kept locally on the CN even 833 after the emission of the BA). 835 4.5.2. Early test of CoA ownership 837 There are cases where a MN will be willing to perform early proof of 838 address ownership, allowing it to avoid the delay during movement. 839 In that case, the MN sends an AOTO message to the CN, and receives 840 either and AOTC or an AOTS. If the received message is an AOTS, the 841 exchange is over. If the message is an AOTC, it replies with an AOTR 842 and waits for an AOTS. 844 A possible use of that early test of CoA ownership is by multi-homed 845 nodes that already have a list of possible CoAs they will switch to 846 if they lose their primary connectivity mean. Note that: 848 o this is only a possible optimization allowed by the AOT* framework 849 introduced in this document, not a requirement. 850 o it still requires the MN to be registered with the CN. 851 o it requires the MN to exchange AOT* messages using the address 852 whose ownership is to be proved. 854 4.5.3. Test of HoA ownership 856 IRO does not mandate regular proofs of HoA ownership, for the reasons 857 covered in Appendix C. For those who have the need, and can afford 858 to lose the associated bits on a regular basis, the AOT* messages can 859 be used for that purpose. 861 If a CN wants to get a live proof of HoA ownership from a MN, it 862 simply emits an AOTC message (with a fresh Nonce option) to the HoA 863 of the MN for which it has already accepted a registration. The MN 864 MUST reply with an AOTR message containing the received Nonce option. 865 The exchange occurs using respectively the HoA as on-wire destination 866 and source address. This implies that the packets are tunneled 867 through MN's HA. In the MN-MN case, this mainly results in packets 868 never following a direct path. 870 Note that this specification does not define the action taken by a CN 871 if it does not receive AOTR messages as response to its AOTC messages 872 sent to the HoA. 874 5. Remapping rules 876 This section covers the heart of IRO processing, the remapping rules 877 that are applied to incoming and outgoing IPsec protected traffic. 879 5.1. Requirements 881 5.1.1. On-wire addresses access from userland 883 With IRO, there is a need for the MIPv6 processing engine to both 884 pass and get on-wire source and destination addresses of received and 885 emitted IPsec protected MH packets. This need is mainly associated 886 with the proof of address ownership and binding exchanges. The need 887 is simply the same as the one associated with the ability to set and 888 get HAO/RH2 for a common MIPv6 process. Instead of having explicit 889 information in the packet, an ancillary path is required. 891 This requirement is limited only to MH traffic in general and some 892 specific MH types in particular. 894 For incoming IPsec protected MH packets, this means that during the 895 handling by remapping rules, the remapped on-wire address must be 896 kept in the local packet structure as an ancillary data that the 897 MIPv6 process will be able to access. 899 For outgoing MH packets, this means that the addresses MUST be made 900 available as ancillary data in the local packet structures by the 901 MIPv6 process and then be used, if available, by the remapping rules. 903 For all incoming IPsec packets associated with a coarse or fine 904 grained SA for MH traffic, if a remapping rule is applied to the 905 traffic, the on-wire source and destination addresses MUST be made 906 available as ancillary data to the userland process that will process 907 the packet (i.e. at socket level). In all cases (remapping rule 908 being applied or not), if an on-wire source or destination address is 909 not changed, the associated ancillary data MUST contain the 910 unspecified address (::). 912 5.1.2. Non-MH traffic (data traffic) 914 Data traffic exchanged between MN and CN using IRO has simple 915 requirements in term of remapping. We consider here only IPsec 916 packets that are not associated with a transport mode IPsec SA 917 protecting MH traffic. 919 5.1.2.1. Compatibility with traffic using RH2 and HAO 921 This specification is compatible with RH2 and HAO extensions even if 922 some care is obviously required in the order in which they are 923 handled. This is generally an implementation dependent issue outside 924 the scope of this specification. 926 In practice, it is expected (except otherwise specified) that IRO 927 module handles incoming traffic after RH* or HAO processing and 928 outgoing traffic just before emission, i.e. with expected-on wire 929 address w.r.t. to RH* and HAO. 931 5.1.2.2. Incoming traffic 933 When an incoming IPsec packet is handled by IRO, as the last step 934 before being processed by the IPsec module, the SPI is used as the 935 main key to find existing source and destination addresses remapping 936 rules for that traffic (at most one for each). 938 Each rule has an expected on-wire address. The expected address is 939 checked against the on-wire one found in the packet. If it matches, 940 the remapping occurs. Note that the remapping rules for source and 941 destination addresses are applied in an independent fashion. 943 5.1.2.3. Outgoing traffic 945 When an outgoing IPsec protected packet is handled by IRO, the SPI is 946 used as the main key to find existing source and destination 947 addresses remapping rules for that traffic (at most one for each). 948 The expected address is checked against the one found in the IPv6 949 header of the packet. If it matches, the remapping occurs. Note 950 that the remapping rules for source and destination addresses are 951 applied in an independent fashion. 953 5.1.2.4. Related traffic (ICMPv6 error traffic, fragments) 955 5.1.3. MH traffic 957 MH traffic emitted and received by a MIPv6 entity using IRO has 958 specific additional requirements compared to common data traffic 959 exchanged between those MIPv6 entities. 961 Basically, the checks and settings on source and destination 962 addresses are relaxed to allow IPsec-protected traffic sent from a 963 new non-registered CoA to pass through. In the MIPv6 stack of the 964 CN, checks are done using an ancillary path that allows the on-wire 965 address to be passed for verification. 967 Here, we only consider IPsec-protected traffic associated with 968 transport mode SAs whose selectors provide protection of MH traffic. 969 Granularity considerations are covered below. 971 The search for remapping rules is done in the same fashion as 972 previously described for data traffic. Only checks and application 973 of the rules are changed as described below. 975 5.1.3.1. Incoming traffic 977 If a remapping rule is found for source address, which contains the 978 unspecified address as check, the remapping is performed without 979 checking the source address of the packet. The unspecified address 980 is used as a wildcard. 982 In source rule case, the on-wire address found in the packet is 983 stored as an ancillary data for further processing and decision by 984 the MIPv6 stack (commonly in userland). 986 Note that this specification does not explicitly mandate when the 987 unspecified address should be used in the source remapping rule, and 988 leave that to implementors, as it is highly dependent of following 989 facts: 991 o if the system does not support fine-grained SP/SA or simply does 992 not use them for MH traffic with a peer, then the use of the 993 unspecified address will be required. 994 o if fine-grained SA are used, the MIPv6 stack will use the 995 unspecified address if the traffic received protected by that SA 996 can't be reliably mapped to a specific CoA for the peer, i.e. if 997 it is expected and authorized that the peer sends traffic from 998 another [possibly to be registered] CoA. This is the case for BU, 999 AOTO, AOTR traffic for instance. 1000 o if the MIPv6 stack supports extensions to [RFC3775]-defined MH 1001 messages, the use of IRO will still remain possible with those 1002 extensions. 1004 Note that this decision is not expected to create interoperability 1005 issues, as the use of the unspecified address is based on non- 1006 ambiguous criteria defined in the documents specifying the purpose of 1007 MH traffic. 1009 Also note that the use of the unspecified address for checks and the 1010 passing of the on-wire address to the MIPv6 stack for further 1011 processing is equivalent from a security standpoint to the decision 1012 that occurs in common MIPv6 processing of HAO extension. 1014 5.2. Rules syntax 1016 To avoid long descriptive sentences in following section, a simple 1017 syntax for expressing remapping rules is provided here. 1019 5.2.1. Remapping rules content 1021 A remapping rule is made of: 1023 o a direction, describing the kind of traffic it will potentially be 1024 applied to. Possible values are "incoming" or "outgoing" 1025 o an SPI value, distinguishing the IPsec packets, encountered in 1026 that direction, to which the rules might apply. 1027 o a value for expected source address or destination address, that 1028 will be respectively compared with the content of the source or 1029 destination address field in the IPv6 header. 1030 o For a source address, the unspecified address (::) is used as a 1031 wildcard, in which cases all addresses are allowed. 1032 o a value for source or destination address, that will be used for 1033 remapping the associated address in the packet. If a single 1034 address is provided, it is used for remapping after checks have 1035 been performed. 1037 If the special keyword "ancillary" is used for remapping a source 1038 address, the address to be used is found as an ancillary data in 1039 the packet. 1041 If the keyword "(ancillary)" appears next to the address to be 1042 used for remapping a destination, the remapped address should be 1043 copied as ancillary data in the packet (see example 4 in next 1044 subsection). 1046 5.2.2. Remapping rules simple syntax 1048 This subsection defines a simple syntax for providing the content 1049 described in previous subsection. Those are given as a set of 1050 examples with few comments. 1052 1. A typical set of remapping rules found on a MN (HoA, CoA) for a 1053 protected data flow with a CN available at address A: 1055 dir: out, SPI: 42, exp. src: HoA, remap. src: CoA 1056 dir: in , SPI: 43, exp. dst: CoA, remap. dst: HoA 1058 2. A typical set of remapping rules found on a MN (HoA, CoA) for 1059 protected MH flows with a CN available at address A: 1061 dir: out, SPI: 44, exp. src: HoA, remap. src: CoA 1062 dir: in , SPI: 45, exp. dst: CoA, remap. dst: HoA 1064 3. A typical set of remapping rules found on a MN (HoA1, CoA1) for a 1065 protected data flow with another MN (HoA2, CoA2): 1067 dir: out, SPI: 46, exp. src: HoA1, remap. src: CoA1 1068 dir: in , SPI: 47, exp. dst: CoA1, remap. dst: HoA1 1069 dir: out, SPI: 46, exp. dst: HoA2, remap. dst: CoA2 1070 dir: in , SPI: 47, exp. src: CoA2, remap. src: HoA2 1072 4. A typical set of remapping rules found on a MN (HoA1, CoA1) for 1073 protected MH flows with another MN (HoA2, CoA2): 1075 dir: out, SPI: 48, exp. src: HoA1, remap. src: ancillary 1076 dir: in , SPI: 49, exp. dst: CoA1, remap. dst: HoA1 1077 dir: out, SPI: 50, exp. dst: HoA2, remap. dst: CoA2 1078 dir: in , SPI: 51, exp. src: ::, remap. src: HoA2 (ancillary) 1080 Note that in example 4, last rule expresses the "blind" remapping of 1081 source address to HoA2; the remapped address is passed as ancillary 1082 data for further check by the MIPv6 process. 1084 6. Tracking SPI changes 1086 [ Following discussions are only geared towards unicast traffic and 1087 the whole section will certainly get more accurate/interesting 1088 information during implementation of the mechanism ] 1090 With IRO, the SPI values referencing SAs are of primary importance: 1091 their correct collect and tracking in the time is a requirement to 1092 allow remapping rules to be kept in sync with the changes that can 1093 occur in the IPsec stack or MIPv6 stack. One important remark is 1094 that the actions performed by the IRO part of the MIPv6 stack on 1095 incoming and outgoing IPsec protected packets is completely 1096 transparent for the IPsec stack. There is no initial requirement for 1097 the IPsec stack associated with the use of IRO (even if having IRO 1098 implemented in the IPsec stack might be beneficial). 1100 IRO acts at the lowest possible level, theoretically just outside the 1101 IPsec stack, directly on the IPsec protected packets, and only 1102 requires access to three pieces of information to track and filter 1103 that packets: SPI, source and destination addresses. 1105 This section covers that tracking and associated actions based on the 1106 availability of PF_KEYv2 API [RFC2367]. The intent is to base the 1107 discussion on a standard interface but it generally apply in a system 1108 dependent fashion to other interfaces (Netlink/XFRM, ...). It 1109 obviously rely on the synchronisation between the two IPsec stacks on 1110 peers (SADB mainly, expected to be done by IKE). 1112 6.1. Initial collect ? 1114 [The need for initial collect _clearly_ depends on the location of 1115 IRO engine is implemented and how remapping rules are pushed/changed] 1117 The way remapping rules are put in place and maintained on the system 1118 implementing IRO is a local matter. The only requirement is that the 1119 externally understood behavior be in sync with the description 1120 provided in the document. This is especially important with changes 1121 associated with registration/deregistration and movement. 1123 In that context, if IRO engine is running in userland, there might be 1124 a need for maintaining a limited local version of system's SADB to be 1125 able to efficiently manage changes (removal, addition, CoA change) 1126 against a set of SA. For instance, when an IRO registration is 1127 accepted for a peer, remapping rules are put in place to have its HoA 1128 remapped to the CoA for incoming IPsec traffic (and the reverse for 1129 outgoing IPsec traffic). Upon movement, all those remapping rules 1130 must be updated to reflect the change of CoA. 1132 In that case, the use of PF_KEY SADB_DUMP message is possible to get 1133 access to the whole SADB content, filter interesting SA, load 1134 required remapping rules for those SA (as described for PF_KEY 1135 SADB_UPDATE message in 6.2.1) and initially populate some initial IRO 1136 SA state table. 1138 Then, if used, this table could be updated when receiving PF_KEY 1139 messages described in following subsection (addition or removal of 1140 entries), during movement (access to all impacted SA whose remapping 1141 rules should be remapped), or during registration/deregistration 1142 (addition/removal of associated remapping rules). 1144 6.2. SADB related PF_KEY events 1146 This subsection covers the actions performed by IRO when receiving SA 1147 related PF_KEY events. Those actions deal with the filtering of 1148 interesting SAs and installation/removal of associated remapping 1149 rules. If another interface than PF_KEY is used to track SA related 1150 events (or IRO logic is not implemented in userland), the behavior of 1151 IRO must remain the same with regard to the addition/removal of 1152 remapping rules. 1154 6.2.1. Overview 1156 A fundamental need of IRO is associated with the ability to setup 1157 remapping rules _before_ traffic that use those rules is emitted. A 1158 direct impact of this requirement is the need to access the SPI of 1159 the SA that will protect the traffic _before_ that SA is used. In 1160 practice, when dynamic keying is used, this creates an interesting 1161 challenge: because SA negotiation is usually triggered by a packet 1162 matching a SP, and IRO does not modifies IKE processing, some care is 1163 required in the implementation to ensure that the SPI information is 1164 gathered and the associated remapping rule installed _before_ the 1165 triggering packets is IPsec- and then IRO-processed. 1167 When dynamic keying is implemented using PF_KEY framework, the 1168 sequence of events performed by the key manager allows to implement 1169 that behavior, basically by monitoring SADB_GETSPI messages from the 1170 kernel in order to access SPI value and install the remapping rule 1171 while the SA is being negotiated. 1173 It is an implementation issue to ensure that IRO will be able to 1174 access the SPI and install the remapping rules before they are used. 1175 This highly depends on the location of IRO implementation (userland, 1176 kernel space), framework (PF_KEY, ...), ... 1178 6.2.2. Reception of a PF_KEY SADB_GETSPI message 1180 When the kernel returns a PF_KEY SADB_GETSPI message to all listening 1181 processes, IRO processing engine considers this kernel message. 1182 After validation (kernel emitted, errno not set, ...), it extracts 1183 the interesting information from the message (SA, Addresses, SPI) in 1184 order to decide if remapping rules are needed for this SPI. 1186 6.2.3. Reception of a PF_KEY SADB_UPDATE message 1188 When the kernel returns a PF_KEY SADB_UPDATE message to all 1189 listeners, following reception of the message from a key manager, IRO 1190 processing engine considers this kernel message. After validation 1191 (kernel emitted, errno not set, ...), it extracts from it the Source 1192 and Destination address extensions along with the direction and the 1193 SPI value found in the association header. 1195 Direction allows to decide if the remapping rule is an incoming or 1196 outgoing one. proto values (should match) allow to decide if wildcard 1197 rules are required (MH case). As there is more granularity available 1198 with IKEv2 selectors, this implies more cases and more specific rules 1199 (based on MH Type). [This part will get the required level of 1200 precision during the implementation]. Addresses allow to decide if 1201 an address is our HoA for which a peer has registered our CoA, or the 1202 HoA of a peer for which we have registered its CoA. 1204 6.2.4. Reception of a PF_KEY SADB_ADD message 1206 From IRO standpoint, SADB_ADD message is processed in the same 1207 fashion as SADB_UPDATE message. The message returned by the kernel 1208 to all listening processes contains the required SPI (in association 1209 header) along with the source and destination address extensions. 1211 6.2.5. Reception of a PF_KEY SADB_DELETE message 1213 The reception of a PF_KEY SADB_DELETE message from the kernel must 1214 trigger the removal of associated remapping rules for the SA if any 1215 (i.e. having that SPI). 1217 6.2.6. Reception of a PF_KEY SADB_EXPIRE message 1219 When IRO engine receives a PF_KEY SADB_EXPIRE message from the kernel 1220 for a SA for which it has loaded some remapping rules, the associated 1221 action depends on the kind of expiration (hard or soft limit): 1223 o In soft case, nothing is done as the SA is still valid. 1224 o In hard case, the SA may already have been deleted from the SADB 1225 and IRO engine must remove associated remapping rules. 1227 6.3. Rekeying 1229 6.3.1. Phase 2 1231 When dynamic keying is used, negotiated IPsec SA have limited 1232 lifetime. With IKEv1, the lifetime is negotiated and the rekeying is 1233 performed by the initiator. In the context of MIPv6, this is 1234 expected to be the peer. 1236 As stated in Section 2.8 of [RFC4306], a "difference between IKEv1 1237 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, 1238 each end of the SA is responsible for enforcing its own lifetime 1239 policy on the SA and rekeying the SA when necessary. If the two ends 1240 have different lifetime policies, the end with the shorter lifetime 1241 will end up always being the one to request the rekeying". Again, in 1242 the context of MIPv6, it is expected that the MN will be the 1243 initiator that will perform the rekeying (i.e. having the shortest 1244 lifetime). 1246 In both cases, independently of the specific details of rekeying 1247 process, new SA will be put in place with new SPI values. When this 1248 event occurs on one side, IRO implementation will get _live_ 1249 information regarding the installation of new SAs by receiving PF_KEY 1250 SADB_ADD messages. It will be followed after some time by the 1251 reception of PF_KEY SADB_EXPIRE messages indicating the expiration of 1252 a "hard lifetime" for old SAs. 1254 From IRO's perspective, IPsec SA rekeying process is only seen 1255 through the reception of specific PF_KEY messages for which 1256 associated actions have previously been described. 1258 7. Extending advantages of IRO to the HA 1260 7.1. Rationale and expected advantages 1262 IRO's primary purpose is to improve security and efficiency of MIPv6 1263 communications in IPsec environments. Because most of them are 1264 expected to occur directly between peers, IRO is oriented towards 1265 MN-CN and MN-MN flows. 1267 But the flows between a MN and its HA can also benefit from the 1268 improvements: using the SPI information available on both sides to 1269 perform the remapping of incoming and outgoing IPsec traffic, the 1270 need of RH2 and HAO extensions between the MN and its HA simply 1271 disappears. This provides anonymity (See Appendix J) of the MN on a 1272 foreign link by hiding its HoA to eavesdropper on the path (if IKE 1273 does not leak that information). It also makes the MN fully capable 1274 in networks were only IPsec is allowed to flow (500/udp is required 1275 for the initial negotiation of SA and infrequently for rekeying). 1277 7.2. Changes to HA processing 1279 IRO does not mandates a detection mechanism (Appendix I) and 1280 transparently reuses most of [RFC3775]-defined messages. For that 1281 reason, MN and HA must be explicitly configured to use IRO. 1283 The changes to HA processing for the peer, required by the use of 1284 IRO, are simply the use of remapping rules instead of HAO and RH2 1285 extensions. 1287 With IRO, the relationship between a MN and one of its CN is 1288 basically the same as the relationship between the MN and its HA, 1289 with the following simple differences: 1291 o HA and MN never exchange AOT* messages as the MN is always trusted 1292 regarding the CoA information it provides in its BU. 1293 o HA and MN have a larger set of possible messages they can 1294 exchange. Remapping rules should be able to handle that. 1295 o Chances are high that an IPsec tunnel be used for protecting 1296 traffic relayed through the HA. Remapping rules do not interfere 1297 with that as the associated SA is not tracked. This is due to the 1298 fact that the SA references the CoA of the MN as the source (on- 1299 wire) address of the communication and not the HoA. 1301 7.3. Changes to MN processing 1303 The changes to MN processing for IRO to be used with its HA are quite 1304 comparable to the one previously described for the MN, i.e. they are 1305 naturally deduced from the basic requirement that RH2 and HAO must be 1306 replaced by the use of remapping rules. 1308 8. Implementation Notes 1310 The content of this section is not meant to be normative but only 1311 informative. 1313 This section provides some explicit feedback associated with the 1314 implementation of IRO on Linux (Linux kernel, UMIP mobility daemon 1315 and racoon IKE daemon). Based on the specific targeted system, some 1316 of the points discussed in this section may be completely irrelevant. 1318 8.1. Nested SA 1320 8.1.1. Problem 1322 The main purpose of IRO is to route optimize IPsec traffic exchanged 1323 between the MN (from its HoA) and its CN. Before that optimization 1324 takes places (i.e. before the AOT* exchanges), that traffic is 1325 expected to follow the natural path, i.e. be routed via the tunnel to 1326 the HA. 1328 In IPsec environments, chances are high the data path to the HA will 1329 be IPsec protected, using IPsec in tunnel mode as (optionally) 1330 expected by MIPv6 specifications. In that case, before the 1331 optimization is effective, traffic sent by the MN to the remote IPsec 1332 peer will have to undergo both the protection of the specific SA 1333 protecting the end-to-end traffic with the peer and the tunnel one 1334 protecting the data traffic to the HA. This is required (at least 1335 for topological reasons) because the HoA is only valid as an inner 1336 address for tunneled traffic. This is basically the kind of setup 1337 described in Appendix E of [RFC4301]. 1339 Supporting that kind of nested IPsec configuration, even temporarily 1340 before the route optimization is in place, is not straightforward. 1341 Obviously, this usually does not require anything specific on the HA 1342 or the CN, but the MN case may be trickier. 1344 In the specific context of IRO, there may be a need for both 1345 previously described IPsec SP/SA to exist separately. The main 1346 reason is that, even if the traffic to the CN initially needs to 1347 undergo both SP (and in the end protection provided by associated 1348 SAs), this need disappears when the optimization is in place. At 1349 that moment, the traffic only undergo the end-to-end SP and the 1350 protection of associated SA. 1352 8.1.2. Selected solution 1354 XXX FIXME 1356 8.2. Having IKE traffic flow via the IPsec tunnel to the HA 1358 8.2.1. Problem 1360 Traffic generated by an IKE daemon needs to bypass the system's 1361 security policies in order to avoid chicken and eggs issues. Unix 1362 IKE daemons implementation usually achieve that using a specific 1363 IPsec bypass setsockopt() call on their sockets. 1365 In common situations, previous method works just fine. But when an 1366 IPsec data tunnel already exist on the system as it is usually the 1367 case for corporate VPN clients, this method prevents the use of the 1368 inner tunnel address for IKE negotiation with remote peers accessible 1369 only via the remote security gateway (e.g. hosts in the corporate 1370 network). Stated differently, this prevents the setup of end-to-end 1371 IPsec protection via the IPsec tunnel. 1373 More precisely, if the IKE daemon tries and use the inner address for 1374 negotiation with a peer, the IPsec bypass setsockopt() call on 1375 associated socket prevents associated IKE traffic to flow correctly. 1377 This is because, from a topological standpoint, the only valid path 1378 for traffic originating from that address is via the IPsec tunnel. 1380 When MIPv6 data traffic between the MN and its HA is required by 1381 policy to undergo IPsec tunnel protection, the same limitation as 1382 described above exists. For the specific needs of IRO, this is an 1383 issue because the HoA is used for the IKE negotiation with the CN 1384 (whose side effect is also to prove HoA ownership to the peer). 1386 8.2.2. Selected solution 1388 For the sake of the discussion, we consider the existence of some 1389 wide IPsec SP requiring protection of all traffic from the HoA to a 1390 given peer behind the HA. To make things clear, IKE traffic (500/ 1391 udp) between the HoA and the address of the peer matches this SP's 1392 selectors. 1394 Obviously, the simple removal of the IPsec bypass setsockopt() on the 1395 socket associated with the HoA is not sufficient to make things work. 1396 This would have initially been sufficient to have associated IKE 1397 traffic undergo the IPsec tunnel mode SP (protecting data traffic 1398 between the MN and its HA). But the existence of the additional SP 1399 creates a chicken and eggs situation and prevents things to work that 1400 easily. 1402 But once the IPsec bypass setsockopt() call is removed for the IKE 1403 socket associated with the HoA, associated traffic basically undergo 1404 the system security policies. Then, the addition of a high priority 1405 SP with selectors specifically suited for IKE traffic from the HoA to 1406 the address of the peer is sufficient to have the IKE traffic be 1407 IPsec tunneled using the existing SA already protecting MIPv6 data 1408 traffic. 1410 From an implementation perspective, the removal of the IPsec bypass 1411 setsockopt() call has been implemented by adding a simple option 1412 ('no_bypass') to the racoon IKE daemon allowing the user to specify 1413 an address for which associated socket should not undergo the 1414 setsockopt() call. 1416 With regard to the addition of the high priority IPsec security 1417 policy matching IKE traffic between the HoA and the address of the 1418 peer, it was easier to have that job done inside UMIP. This is 1419 basically because UMIP is already the one handling the installation 1420 of other security policies for MIPv6 and data traffic. Another 1421 reason is that UMIP will need to update the tunnel mode SP after a 1422 handover. (via [MIGRATE]). 1424 8.3. Remapping rules and old IPsec architecture 1426 8.3.1. Problem 1428 XXX FIXME: the old IPsec architecture expected SAD lookups to be 1429 performed by SPI and destination address. If an IPsec stack only 1430 implements such kind of lookups when handling IPsec traffic, this may 1431 require additional work to support the implementation of IRO 1432 remapping rules. [RFC4301] changed that behavior and now expects SAD 1433 lookups for unicast SA to be performed by SPI, which is expected to 1434 simplify the implementation of IRO remapping process. 1436 8.3.2. Selected solution 1438 XXX FIXME 1440 9. Security Considerations 1442 9.1. Proof of address ownership 1444 9.1.1. Position of the problem 1446 As a CN, registering a binding between a CoA and a HoA is not 1447 something harmless. This can be seen as a modification of local 1448 routing table, like an order from a peer to direct traffic to a 1449 specific address. For that reason, the CN needs some proof regarding 1450 this binding. In MIPv6, RRP has been designed with the hypothesis 1451 that there is no initial trust relationship between a MN and its CN. 1452 The solution to provide confidence to the CN in the HoA and CoA 1453 binding has consisted in showing the ability for the MN to send _and_ 1454 receive traffic both at the HoA and CoA. 1456 With IRO, there is an initial trust relationship between a MN and the 1457 CN it will contact. This is expected to take the form of 1458 cryptographic credentials (X.509 certificates, ...) that will allow 1459 an IKE negotiation to occur to setup SAs to protect the binding. 1460 Static keying case is covered in Appendix G. Those SA only 1461 references the HoA of the MN and not at all its CoA. 1463 The point here is that the existence of SAs does not directly provide 1464 to the CN any _live_ proof of address ownership as it occurs with 1465 RRP. 1467 Furthermore, as summarized in section 6.2 of [RFC4866] paragraph 4, 1468 the trust relationship between a HA and its MN is very different from 1469 the one between a MN and a CN, even if both use IPsec/IKE to 1470 authenticate. 1472 9.1.2. Home Address ownership 1474 The proof of HoA ownership to the CN is one of the reason behind the 1475 design decision to have MN and CN perform the IKE negotiation via the 1476 tunnel to the HA (i.e. using the HoA). That way, the existence of 1477 the SAs gets bound to a successful initial exchange between the CN 1478 and the MN. This proves to the CN the ability for the MN to send/ 1479 receive traffic from/at that address. 1481 Nonetheless, as IKE basically allows negotiation to be performed from 1482 a different address than the one the SA contain ([MIGRATE] has such 1483 an use), this behavior MUST be prevented on the CN for the purpose of 1484 negotiations of the initial SAs that will protect MH traffic for 1485 IRO's binding between the MN and the CN. 1487 While MN and CN are able to perform an IKE exchange between them 1488 using a set of credentials, there are many possible reasons for which 1489 those credentials might in fact be invalid at the time the 1490 negotiation occur. This might for instance be the case if the CN has 1491 not up to date revocation information. This can also result from the 1492 use by the MN of a different set of credentials for the purpose of 1493 protecting its HA registration and the registration with its CN. 1495 Mandating the IKE negotiation to be routed through the tunnel to the 1496 HA provides the proof that the MN is still granted ownership of the 1497 address by the network it belongs to at the time of negotiation. It 1498 should be noted that the proof of HoA ownership occurs at SA setup 1499 time and remains valid till the SA is rekeyed, i.e. each rekeying 1500 providing a new live proof. This specification does not mandates 1501 regular check of HoA ownership between rekeying. Appendix C provides 1502 arguments on that topic. 1504 The case of static keying is covered in Appendix G. 1506 9.1.3. Care-of Address ownership 1508 The proof of CoA ownership by the CN is an especially important point 1509 in the security of large scale deployments of IRO. As stated in the 1510 introduction of this section, the acceptance of a binding by a CN for 1511 a CoA is a local modification of local routing table to send current 1512 and future traffic to that address when it is destined to the HoA. 1514 The proof by the MN that it is able to both send and receive traffic 1515 at this address is a primary concern in the security of the protocol. 1516 Appendix A covers the reasons why the only ability to send is an 1517 insufficient proof of CoA ownership, even in the context of IRO. 1519 9.2. Remapping (comparison with explicit HAO/RH2 inclusion) 1521 For every remapping, the practical impact is the same as the explicit 1522 one resulting from the inclusion of a RH2 or HAO. 1524 9.3. Anonymity 1526 At the moment, this section is empty. See Appendix J. 1528 9.4. Limiting attack surface 1530 IRO can provide the ability to have port 500/udp open for remote 1531 negotiations on the HoA for the purpose of the inbound contacts and 1532 not on the CoA. CoA is only used for the discussion between the MN 1533 and its HoA, which allow to put some specific firewalling rules in 1534 place for that purpose. 1536 10. IANA Considerations 1538 The values for following mobility header messages MUST be assigned by 1539 IANA: 1541 o Address Ownership Test Offer message (AOTO, see Section 4.4.1) 1542 o Address Ownership Test Challenge message (AOTC, see Section 4.4.2) 1543 o Address Ownership Test Response message (AOTR, see Section 4.4.3) 1544 o Address Ownership Test Status message (AOTS, see Section 4.4.4) 1546 The values for following mobility option MUST be assigned by IANA: 1548 o Nonce Option (see Section 4.3.1) 1550 11. Acknowledgements 1552 The author acknowledge the comments and correction of Guillaume 1553 Valadon on the initial version of the document. 1555 This document was generated by xml2rfc. 1557 12. References 1559 12.1. Normative References 1561 [RFC2119] Bradner, S., ""Key Words for Use in RFCs to Indicate 1562 Requirement Levels"", RFC 2119, March 1997. 1564 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1565 Management API, Version 2", RFC 2367, July 1998. 1567 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1568 (IKE)", RFC 2409, November 1998. 1570 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1571 in IPv6", RFC 3775, June 2004. 1573 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1574 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1575 Home Agents", RFC 3776, June 2004. 1577 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1578 Internet Protocol", RFC 4301, December 2005. 1580 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1581 RFC 4303, December 2005. 1583 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1584 RFC 4306, December 2005. 1586 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 1587 Requirements for Encapsulating Security Payload (ESP) and 1588 Authentication Header (AH)", RFC 4835, April 2007. 1590 [RFC4877] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the 1591 Revised IPsec Architecture", RFC 4877, April 2007. 1593 12.2. Informative References 1595 [CNIPsec] Dupont, F. and JM. Combes, "Using IPsec between Mobile and 1596 Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-08 1597 (work in progress), August 2008. 1599 [MIGRATE] Ebalard, A. and S. Decugis, "PF_KEY Extension as an 1600 Interface between Mobile IPv6 and IPsec/IKE", 1601 draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in 1602 progress), August 2008. 1604 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1605 Nordmark, "Mobile IP Version 6 Route Optimization Security 1606 Design Background", RFC 4225, December 2005. 1608 [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of 1609 Enhancements to Mobile IPv6 Route Optimization", RFC 4651, 1610 February 2007. 1612 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1613 Optimization for Mobile IPv6", RFC 4866, May 2007. 1615 [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1616 Problem Statement", RFC 4882, May 2007. 1618 Appendix A. Ability to send does not prove CoA ownership 1620 With IRO, negotiation of the protection for the registration traffic 1621 between the peers is done using the tunnel to the Home Agent (i.e. 1622 the HoA). Then, the protected Binding Update message is emitted by 1623 the MN. It locally uses the HoA but a remapping process makes the 1624 CoA the address appearing on the wire for this packet. When the CN 1625 receives that packet, the address is remapped to the HoA of the MN by 1626 the MIPv6 stack. The remapped address appearing as source of the 1627 packet is passed as ancillary data to the MIPv6 process where a check 1628 will be performed during parsing against the content of the required 1629 Alternate Care-of Address option. 1631 This process proves the CN that the MN is able to _send_ traffic 1632 using the CoA. 1634 Then, IRO requires additional steps for the MN to prove its ability 1635 to receive traffic at that address. This appendix covers the threats 1636 prevented by the addition of this proof of reception capability in 1637 IRO. 1639 The trust model between the MN and its HA is based on the existence 1640 of the IPsec protection between the two. The only requirement for 1641 the update of the tunnel endpoint when a movement occur is the 1642 reception by the HA of a protected Binding Update message containing 1643 the new CoA in the Alternate CoA option. The use of the new CoA as 1644 source of the packet is not even mandatory. 1646 One would argue that the same kind of trust relationship exists 1647 between the MN and its CN as they already have an established trust 1648 relationship, materialized by the pair of SA protecting MH traffic. 1649 Nonetheless there are many difference between the two situations. 1651 The first and main one is that all the traffic emitted by the HA to 1652 the CoA provided by the MN has a traceable source: the address of the 1653 HA, which belongs to the home network. It allows to track the source 1654 of the traffic emitted to the CoA back to the Home Network. In the 1655 context of the flow from the CN to the MN, the source address might 1656 possibly be that of a foreign network (if the CN is also acting as a 1657 MN) and the destination is the one that would be provided by the MN. 1659 Now consider the following, still in the context of a proof of 1660 address ownership based solely on the ability of the MN to emit 1661 traffic from the CoA. A MN has been compromised by an attacker that 1662 has the ability to emit traffic with the address of a target (no 1663 ingress-filtering by its provider). The attacker would now be able 1664 to mount connections with the HA and then, using IRO, with all the 1665 peers that trust the MN. At the moment, it still uses some valid 1666 address where it can emit/receive traffic from/to. After having some 1667 traffic intensive connection running with a peer, it simply warns the 1668 peer of a change of CoA by advertising the address of the target. As 1669 the CN does not require a proof of reception capability, all the 1670 IPsec traffic gets redirected to the target. This might not be a 1671 problem with a single peer and some connected protocol but it is 1672 expected that the protocol be used in vast trust domains where the 1673 number of peer is not directly limited. 1675 In the end, requiring that the proof of CoA ownership includes a 1676 proof of reception capability by the MN at the CoA prevents that 1677 compromise of a MN by an attacker provides her with a potentially 1678 unlimited number of anonymous and unwilling "bots" to DoS a target 1679 other than herself. 1681 In the design of IRO, to maintain the efficiency of the protocol in 1682 term of latency associated with movement, the proof of reception 1683 capability is not required to occur before the CN can emit traffic to 1684 the CoA. 1686 Appendix B. IKE exchanges use the HoA and the tunnel to the HA 1688 Remainder: in this appendix, we still consider that the data tunnel 1689 between the HA and the MN is IPsec protected. Some security 1690 arguments in this appendix should be modulated if this hypothesis is 1691 known to be invalid. 1693 We provide here some arguments regarding the use of the HoA for 1694 performing the IKE exchanges with the peers, using the tunnel through 1695 the HA. 1697 The first simple rule which always applies with IRO is that no 1698 connection happens directly if it is not IPsec-protected. No 1699 difference is made for IKE exchanges even if those flows have 1700 intrinsic protection mechanisms. 1702 The need for performing IRO to get direct routing between the peers 1703 is motivated by the net performance impact in terms of bandwidth, 1704 delay and jitter by avoiding triangular routing and the bottleneck of 1705 HA. This is of interest for specific flows like VoIP, direct file 1706 exchanges, ... but are mainly useless for infrequent flows like IKE 1707 negotiations. When a MN performs IKE negotiation with a peer, having 1708 IKE_SA (or ISAKMP SA for IKEv1) set up is only a matter of few 1709 packets (IKEv1 Main mode exchange uses six). Then, all next CHILD_SA 1710 (or IPsec SA for IKEv1) will reuse the same IKE_SA and generally 1711 complete after a three packet exchange. As rekeying is supposed to 1712 occur extremely infrequently and does not need the advantage of 1713 direct routing, this is unneeded. The argument regarding the loss 1714 associated by the routing through the tunnel gets the same answer: 1715 the impact is very limited given the amount of traffic. Furthermore, 1716 when certificates are used, IKE packets already get fragmented even 1717 with a full 1500 bytes PMTU. 1719 In fact, the advantage of using the HoA and the IPsec tunnel to the 1720 HA for performing IKE negotiation with peers is the stability 1721 guaranteed by the migration process when movement occurs. MIPv6 1722 simply makes things transparent for all IKE daemon connections from 1723 the HoA. 1725 To conclude and after all previous functional arguments, there are 1726 also some security advantages in performing IKE negotiations with 1727 peers using the protected IPsec tunnel to the HA. 1729 The most important one is anonymity. A positive side effect of 1730 having the negotiation performed through the IPsec tunnel to the HA 1731 (ESP with meaningful encryption is assumed) is that it hides 1732 everything to people in MN's network. IKE traffic is only accessible 1733 on the path between the HA and the peer. In fact, in the MN-MN 1734 situation eavesdroppers on both foreign networks are unable to get 1735 the HoA of the peer on the other network. It requires being on the 1736 path between the two HA. The same is also true for the identity 1737 information that might appear during the IKE negotiation depending on 1738 the modes peers use. 1740 Another security advantage with that policy is that a peer is able to 1741 statefully filter 500/udp traffic received on its CoA and allow only 1742 outbound initiated connections addressed to the HoA. This policy 1743 simply allows reducing the network attack surface of the node in the 1744 foreign network. 1746 Appendix C. Arguments for no regular check of HoA ownership 1748 As presented in Section 9.1.2, when dynamic keying is used, the 1749 initial IKE negotiation protecting the registration traffic between 1750 the MN and the CN provides to the CN the proof of HoA ownership by 1751 the MN. This proof remains valid till this SA is rekeyed. This is 1752 also true for further SA negotiated between the MN and the CN. 1754 The initial proof of HoA ownership is easily obtained as it results 1755 from a positive information: packets exchanged with the MN at this 1756 address. Note that the inability for the MN or the CN to get traffic 1757 routed to the HA at that moment results in the inability to get 1758 direct connectivity as the IKE negotiation cannot be performed. In 1759 the same fashion, after the initial proof, there is no defined way to 1760 track a loss of HoA ownership through a positive event: the CN is 1761 simply not warned that the MN has been removed ownership of its HoA 1762 by its home network (resulting from a compromise, change of network 1763 prefix, ...). Discovery of a loss of HoA ownership cannot be tracked 1764 by a negative event either, such as the inability to exchange traffic 1765 with the MN at a specific moment. In fact, a crash of the HA, the 1766 loss of connectivity between the MN and its HA, or between the CN and 1767 the HA are to be expected. In that context, such a mechanism would 1768 simply amplify the existence of points of failure or allow DoS to 1769 occur. Avoiding that provides resilience and allow direct 1770 communications to survive previous failure conditions related to the 1771 HA. 1773 Another reason to prevent regular proof of HoA ownership is the use 1774 of the HoA in IRO. It acts as a local identifier on both peers. It 1775 allows the MN to acquire movement independence and can be seen as a 1776 convenience in the relationship between the peers, to find themselves 1777 initially, no matter where they are located. With IRO, the HoA never 1778 appears anymore in packet exchanged directly between the peers (due 1779 to removal of HAO and RH2). It is only understood locally in the 1780 context of ongoing IPsec communications between the peers. 1782 The last argument for not including this requirement (capability is 1783 provided, see Section 4.5.3) in the protocol is that different CN or 1784 MN might have different more efficient methods for performing that 1785 tracking. For instance, inside a home network, instead of using a 1786 constant regular polling by all MNs, an administrator revoking the 1787 credentials of a MN will easily be able to request all MNs to update 1788 their revocation information, before shutting down communications 1789 with associated MN (i.e. replacing polling by push). 1791 In the context of IRO, no mechanism to perform regular checks of HoA 1792 ownership is included. This capability is outside the scope of this 1793 specification. 1795 Appendix D. Lack of encryption between MN and HA 1797 In this specification, the use of IPsec tunnel protection of data 1798 traffic is expected. Note that section 5.5 of [RFC3775] only 1799 specifies that: 1801 For traffic tunneled via the home agent, additional IPsec ESP 1802 encapsulation MAY be supported and used. If multicast group 1803 membership control protocols or stateful address 1804 autoconfiguration protocols are supported, payload data 1805 protection MUST be supported. 1807 The logic behind previous expectation is associated with the 1808 availability of credentials between the MN and HA, and also the kind 1809 of environment in which it will get deployed. 1811 However, the lack of IPsec protection of tunneled data does not 1812 prevent IRO; it only removes some security advantages of this 1813 protection. This loss is covered in this appendix. 1815 When negotiating IRO, the MN uses the tunnel to its HA for routing 1816 IKE negotiation with the peer. As IKE is designed for robustness, 1817 the advantage of the privacy when IPsec is used for protecting the 1818 data tunnel (i.e. non NULL encryption) is the insurance that the 1819 address of the peer or its cryptographic credentials are not 1820 disclosed on MN's network. Note that MN's HoA and associated 1821 identity are expected to be disclosed to eavesdroppers during 1822 registration of the MN to its HA (if IRO is not extended to HA-MN 1823 exchanges). 1825 As a conclusion, removing the hypothesis of privacy for data tunneled 1826 to the HA removes the anonymity provided to peer's identity (HoA or 1827 CoA, and possibly cryptographic identity appearing during IKE 1828 exchange). 1830 Appendix E. What if I don't need protection? 1832 IRO mandates the use of IPsec for all direct communications between 1833 MIPv6 peers. As IPsec is only a framework, the level of protection 1834 might vary, along with the additional requirements, environments and 1835 capabilities of end devices. 1837 There will certainly be some very specific and limited cases where 1838 people will see a need in downgrading the security for performance or 1839 other reasons. To be fair, except in some very specific conditions, 1840 achieving performance while still keeping security is possible. For 1841 instance, if authentication is a real requirement but privacy is not 1842 (but it is still activated by default), and CPU limits the 1843 throughput, keeping only authentication services of IPsec as provided 1844 by ESP with NULL encryption or by AH will clearly boost performance. 1846 Now, if there is a desperate need to suppress security services 1847 between MIPv6 peers for some reason, the best thing is to use another 1848 route optimization like common RO as specified in [RFC3775], instead 1849 of trying to circumvent them. 1851 For those with some imagination, who still think the author is wrong 1852 and think about simply negotiating NULL authentication and NULL 1853 encryption, next paragraph might be worth reading. 1855 [RFC4835] defines mandatory-to-implement cryptographic algorithms for 1856 use with ESP (and AH). NULL encryption algorithm and NULL 1857 authentication algorithm must both be implemented. In section 3.2 of 1858 [RFC4303], some requirements are specified on those algorithms, 1859 preventing their simultaneous uses: 1861 Note that although both confidentiality and integrity are 1862 optional, at least one of these services MUST be selected, hence 1863 both algorithms MUST NOT be simultaneously NULL. 1865 Appendix F. MTU Gains 1867 Standard RO is based on the use of RH2 and HAO to explicitly carry 1868 the HoA of the MN, respectively as real destination or final source 1869 of the packet sent directly between the nodes: 1871 o From MN to CN: HAO 1872 o From CN to MN: RH2 1873 o From MN to MN: HAO and RH2, simultaneously. 1875 The inclusion of these explicit containers generates a loss of MTU. 1876 In common case, where no other specific extensions or options are 1877 used (to remove padding considerations), HAO and RH2 each consume 24 1878 bytes. 1880 The loss of MTU associated with those MIPv6 extension for direct 1881 MN-CN communications is 24 bytes. For direct MN-MN communications, 1882 it is 48 bytes. As an initial comparison, unprotected routing via 1883 the HA through an IPv6-in-IPv6 tunnel consumes 40 bytes. When an 1884 IPsec tunnel is used, the loss of MTU depends on the authentication 1885 and encryption algorithm, negotiation of ESN, padding requirement. 1887 As IRO has been designed to provide secure IPsec-protected direct 1888 communications between MIPv6 peers, it is difficult (and does not 1889 make that much sense) to compare the loss of MTU associated with IRO 1890 and the one of standard unprotected RO. In term of header inclusion, 1891 IRO neither use RH2 nor HAO but require AH or ESP. Depending on the 1892 size of ESP or AH header(s) and the specific type of communication 1893 (MN-MN or MN-CN), one route optimization type might consume more 1894 bandwidth than the other: 1896 o ESP in transport mode using HMAC-SHA1-96 (required in all 1897 implementation) as authentication algorithm, NULL for encryption 1898 and no ESN consumes 24 bytes (with 2 bytes of padding). Adding a 1899 meaningful encryption algorithm will make that higher. 1900 o AH in transport mode also using HMAC-SHA1-96 and no ESN will give 1901 a similar value. 1903 To make things simple, using IRO with some ESP with NULL encryption 1904 or with AH for MN-CN communications provides similar MTU loss as 1905 standard RO. Having a meaningful encryption algorithm (expected) 1906 with ESP give a little advantage to standard RO regarding MTU loss. 1908 When considering MN-MN, IRO will clearly consumes less bandwidth than 1909 standard RO in all possible combinations of algorithms for AH or ESP. 1911 Now, considering the same level of protection, i.e. by using IPsec 1912 for standard RO carried packets (we do not take into account padding 1913 variations), IRO simply gets a direct advantage: 24 bytes for MN-CN 1914 communications and 48 bytes for MN-MN communications. It is due to 1915 the complete removal of HAO and RH2 from packets exchanged directly 1916 between peers. 1918 In fact, regarding MTU considerations, IRO provides a zero cost 1919 mobility service to IPsec protected connections between end nodes. 1921 Appendix G. Compatibility with static keying 1923 IRO has been designed for enabling direct secure communications 1924 between MIPv6 entities belonging to a common trust domain. 1925 Scalability was a primary concern; This is the reason why the 1926 specification covers SA negotiation under the hypothesis that IKE is 1927 used for that purpose. But IRO is also fully compatible with static 1928 keying. 1930 In fact, the specification is not specifically bound to the use of 1931 either static or dynamic keying for SA setup; it is left as a local 1932 configuration decision to domain administrators. 1934 This appendix quickly covers the differences regarding the use of 1935 static keying with IRO. 1937 One great difference between static and dynamic keying is the removal 1938 of the IKE negotiation. For IRO, the first negotiation performed 1939 with the peer provides an additional information to the CN: a live 1940 proof of address (HoA) ownership by the MN. The removal of this step 1941 also removes the live check. This is a fact administrators should be 1942 aware of. 1944 The question of rekeying is of primary interest for the maintenance 1945 of SPI information on MN and CN that use IRO. This changes somehow 1946 with static keying as the rekeying is done ... by the user. Even if 1947 it is expected to happen less often, tracking of SA removal and 1948 addition, along with their associated SPI is still required. It is 1949 expected that the same mechanism (PF_KEY is one of them) used for 1950 tracking addition and deletion of SA by IKE be used for that purpose. 1952 There should be no specific reason preventing the simultaneous use of 1953 static and dynamic keying with IRO. 1955 Appendix H. Compatibility with the use of CoA in SP/SA 1957 SP and SA are not changed at any moment by MIPv6 stack when IRO is 1958 used. Only incoming and outgoing IPsec packets can undergo source or 1959 destination address modifications, mainly based on SPI information. 1961 When using IRO, MIPv6 stack tracks SA addition and deletion looking 1962 for local HoA or IRO peers' HoAs (MN) as source or destination 1963 addresses of those SA (endpoints for tunnel mode SA). Associated SPI 1964 are used for tracking IPsec packets. 1966 Outgoing IPsec packets are only possibly modified to change the HoA 1967 into the CoA. CoA of outgoing IPsec packets are never modified by 1968 MIPv6 stack, when IRO is used. 1970 Incoming IPsec packets will have their source modified (from CoA to 1971 peer's MN HoA) iif the SPI is the one of a tracked SA that expect the 1972 HoA of an IRO peer. This implies that no incoming packet with a CoA 1973 source will be modified if the SA associated with its SPI references 1974 that CoA (and not peer's HoA). Regarding destination address of an 1975 incoming IPsec packet, remapping of a CoA will occur if the SA 1976 associated with the SPI expects an HoA. This implies that no 1977 incoming packet with a CoA destination will be modified if the rules 1978 associated with its SPI references that CoA (and not our HoA). 1980 As a conclusion, the work of IRO is compatible with the use of CoA as 1981 destination or source address (endpoint addresses for tunnel mode) of 1982 any SP/SA. 1984 Appendix I. Rationale for not specifying a new BU 1986 IRO is not designed as a fallback mode for IPsec communications 1987 between MIPv6 entities but as an improved alternative. 1989 You cannot use IRO and common mode with the same peer. You either 1990 need the security advantages of IRO for communications with a peer or 1991 you can afford unprotected direct communications with it, for which 1992 common RO has been developed. Parallel uses of common mode and IRO 1993 mode with different MIPv6 entities (including its HA) is not 1994 forbidden but strongly discouraged as it suppresses the anonymity of 1995 the MN on its foreign link. 1997 For that reasons, IRO does not come with some detection algorithm 1998 against peers that do not have IRO activated to perform a fallback to 1999 common mode. Considering the setup associated with the protection 2000 mechanisms required by IRO and the kind of environments it is 2001 expected to be used in, requiring that entities be configured to 2002 specifically use IRO for a peer (or by default, preventing the common 2003 mode) is required. 2005 This has many positive impacts both on development costs, deployment 2006 and debugging. This notably provides the ability to reuse messages 2007 without creating parallels versions where needed. As only a few 2008 things changes when IRO is activated between two entities, most of 2009 the code remains usable. In fact, the two mains changes introduced 2010 by IRO are: 2012 o the removal of HAO/RH2 and the replacement by the remapping 2013 process on selected IPsec traffic. 2014 o a simplified registration procedure with CN (AOT* framework) 2016 Let's go a little further. One can think that it would have been 2017 possible to create specific mobility options to discriminate IRO mode 2018 from the common mode. This was impossible for multiple reason. 2019 First, from a specification perspective, section 6.1.7 of [RFC3775] 2020 requires that "The receiver MUST ignore and skip any options which it 2021 does not understand", which prevents the reuse of MIPv6 messages with 2022 a slightly modified semantic if peers are not aware of that. For 2023 options to have an interest, you have to be aware that the peer 2024 support it (not necessarily that it is activated). 2026 Anyway, there is a better reason that makes the use of common mode 2027 and IRO mode incompatible between peers: IRO remapping process must 2028 be activated on the receiver for the packets to be valid. If a MN 2029 that uses IRO sends an IPsec protected Binding Update message to a 2030 peer that is not using IRO, no remapping will occur and the checksum 2031 will end up being invalid (if it passes the IPsec stack). Section 2032 9.2 of [RFC3775] requires the following rule to be applied to such 2033 packet: "The checksum must be verified as per Section 6.1. 2034 Otherwise, the node MUST silently discard the message". 2036 Appendix J. Anonymity 2038 There are mainly 2 kinds of identifiers that can appear during an 2039 IPsec protected communication in IKE/MIPv6 environments: addresses 2040 (HoA, CoA, CN addresses) and cryptographic identifiers (IKE 2041 credentials, i.e. X.509 certificates). 2043 In MN-CN communications, the addresses of the CN and the CoA of the 2044 MN will obviously be disclosed, but they should not be meaningful. 2045 We see later that in MN-MN case, the address of the CN that appears 2046 on the wire might temporarily be the HoA, before registration has 2047 been performed by the second MN. 2049 In MIPv6, the use of explicit containers (HAO and RH2) makes the Home 2050 Address of the MN available in all cases. With IRO, the complete 2051 removal of this extensions prevents the disclosure of the HoA during 2052 direct MN-CN communications and MN-HA communications. 2054 The removal applies to: 2056 o the IPsec protected signaling traffic exchanged directly between 2057 the two peers (BU/BA for instance) 2058 o the IPsec protected data traffic exchanged in MN-MN and MN-CN 2059 cases (when tunnel mode is not already used to avoid RH2/HAO). 2061 From the perspective of an eavesdropper on the FL of the MN, when IRO 2062 is used the visible exchanges that occur are (in order, for MN-MN 2063 case, with registrations performed on that link, i.e. worst case 2064 scenario): 2066 o IKE negotiation between the CoA of the MN and its HA 2067 o IPsec protected BU/BA exchanges using CoA and HA@ as on-wire 2068 addresses (remapping rules applied on both ends) 2069 o IPsec protected (tunnel mode this time) traffic with peers 2070 o IKE exchange from the HoA, IPsec tunneled to the HA, with a CN 2071 o Direct IPsec-protected BU/BA exchanges using the CoA and the 2072 address of the the CN for on-wire addresses. 2073 o Direct IPsec-protected data traffic exchange with the CN, between 2074 the CoA and the address of the CN. 2076 In all those exchanges, the only addresses that are disclosed to an 2077 eavesdropper on the FL of the MN (if ESP with a meaningful encryption 2078 is used for all IPsec exchanges) are the CoA, the address of MN's HA 2079 and the address of the CN. The HoA of the MN never appears in those 2080 exchanges. 2082 For IKE case, even if it is used as an ID in Phase 2 for 2083 bootstrapping as described in [MIGRATE], the exchanges are encrypted 2084 and the HoA does not appear. For the negotiation with the CN, 2085 because the HoA is used for the exchanges, the IPsec tunnel to the HA 2086 protects traffic to/from the Home Network. 2088 Regarding cryptographic identifiers, the certificate of the MN is not 2089 expected to appear on the wire. In all cases, the only information 2090 one can get are associated with the MN's Home Network (HA address and 2091 possibly certificate), but nothing more specific should be disclosed. 2093 Now, considering the specific case of MN-MN communications, on the 2094 network of the initiating MN1 (the first to register with its peer), 2095 after the IKE negotiation as been performed relayed by both Home 2096 Agents, the IPsec protected Binding Update packets is emitted with 2097 the HoA of MN2 as destination (the address of the CN in previous list 2098 is the HoA of MN2). Let's consider associated SPI is 42. The packet 2099 is sent directly with the CoA of MN1 on the wire and is routed to the 2100 Home Network of the peer, before it is tunneled to it. The BA 2101 follows a reverse path but with a different SPI (say 43). After the 2102 second registration is over, the MH traffic using those SPI values 2103 (42 and 43) flows directly (remapping rules are now in place on both 2104 ends). From an eavesdropper perspective on the FL of MN1, this 2105 provides "a clue" about the association between the HoA and the CoA 2106 of the second MN2. This is introduced in [RFC4882]. 2108 Note that this is the only "leaking" that happens and only on the FL 2109 of the first MN. It is no more the case on FL that are visited 2110 later. Anyway, from the perspective of an eavesdropper monitoring 2111 that, the information will be that a Mobile Node from a known Home 2112 Network (HA@) has performed IPsec communications with a MN having a 2113 known HoA (no credentials). 2115 Author's Address 2117 Arnaud Ebalard 2118 EADS Innovation Works 2119 12, rue Pasteur - BP76 2120 Suresnes 92152 2121 France 2123 Phone: +33 1 46 97 30 28 2124 Email: arnaud.ebalard@eads.net