idnits 2.17.1 draft-ebalard-mext-ipsec-ro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2029. 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 Copyright Line does not match the current year -- The document date (November 17, 2008) is 5639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4449' is defined on line 1956, but no explicit reference was found in the text == Unused Reference: 'RFC4487' is defined on line 1959, but no explicit reference was found in the text ** 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 (~~), 4 warnings (==), 6 comments (--). 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 November 17, 2008 5 Expires: May 21, 2009 7 Mobile IPv6 IPsec Route Optimization (IRO) 8 draft-ebalard-mext-ipsec-ro-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 21, 2009. 35 Abstract 37 This memo specifies an improved alternate route optimization 38 procedure for Mobile IPv6 designed specifically for environments 39 where IPsec is used between peers (most probably with IKE). The 40 replacement of the complex Return Routability procedure for a simple 41 mechanism and the removal of HAO and RH2 extensions from exchanged 42 packets result in performance and security improvements. 44 Table of Contents 46 1. Disclaimer and conventions . . . . . . . . . . . . . . . . . . 4 47 1.1. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.2. Conventions used in this document . . . . . . . . . . . . 4 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 2.1. Current situation . . . . . . . . . . . . . . . . . . . . 5 51 2.2. Characteristics of IRO . . . . . . . . . . . . . . . . . . 5 52 2.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 53 2.4. Notes to the reader . . . . . . . . . . . . . . . . . . . 8 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.1. The big picture . . . . . . . . . . . . . . . . . . . . . 9 56 3.2. Pre-binding steps . . . . . . . . . . . . . . . . . . . . 9 57 3.3. BU emission . . . . . . . . . . . . . . . . . . . . . . . 11 58 3.4. Proof of CoA ownership . . . . . . . . . . . . . . . . . . 11 59 3.5. BA emission . . . . . . . . . . . . . . . . . . . . . . . 12 60 3.6. Post-bindings steps . . . . . . . . . . . . . . . . . . . 12 61 4. Proof of CoA ownership . . . . . . . . . . . . . . . . . . . . 13 62 4.1. Position of the problem . . . . . . . . . . . . . . . . . 13 63 4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 4.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 14 65 4.3.1. Nonce option . . . . . . . . . . . . . . . . . . . . . 14 66 4.4. IRO Messages . . . . . . . . . . . . . . . . . . . . . . . 14 67 4.4.1. Address Ownership Test Offer (AOTO) . . . . . . . . . 14 68 4.4.2. Address Ownership Test Challenge (AOTC) . . . . . . . 15 69 4.4.3. Address Ownership Test Response (AOTR) . . . . . . . . 16 70 4.4.4. Address Ownership Test Status (AOTS) . . . . . . . . . 16 71 4.5. Concrete uses of AOT* Messages . . . . . . . . . . . . . . 17 72 4.5.1. Registration with a CN . . . . . . . . . . . . . . . . 17 73 4.5.2. Early test of CoA ownership . . . . . . . . . . . . . 18 74 4.5.3. Test of HoA ownership . . . . . . . . . . . . . . . . 19 75 5. Remapping rules . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.1.1. On-wire addresses access from userland . . . . . . . . 19 78 5.1.2. Non-MH traffic (data traffic) . . . . . . . . . . . . 20 79 5.1.2.1. Compatibility with traffic using RH2 and HAO . . . 20 80 5.1.2.2. Incoming traffic . . . . . . . . . . . . . . . . . 20 81 5.1.2.3. Outgoing traffic . . . . . . . . . . . . . . . . . 20 82 5.1.2.4. Related traffic (ICMPv6 error traffic, 83 fragments) . . . . . . . . . . . . . . . . . . . . 21 84 5.1.3. MH traffic . . . . . . . . . . . . . . . . . . . . . . 21 85 5.1.3.1. Incoming traffic . . . . . . . . . . . . . . . . . 21 86 5.2. Rules syntax . . . . . . . . . . . . . . . . . . . . . . . 22 87 5.2.1. Remapping rules content . . . . . . . . . . . . . . . 22 88 5.2.2. Remapping rules simple syntax . . . . . . . . . . . . 23 89 6. Tracking SPI changes . . . . . . . . . . . . . . . . . . . . . 23 90 6.1. Initial collect ? . . . . . . . . . . . . . . . . . . . . 24 91 6.2. SADB related PF_KEY events . . . . . . . . . . . . . . . . 25 92 6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 25 93 6.2.2. Reception of a PF_KEY SADB_GETSPI message . . . . . . 25 94 6.2.3. Reception of a PF_KEY SADB_UPDATE message . . . . . . 26 95 6.2.4. Reception of a PF_KEY SADB_ADD message . . . . . . . . 26 96 6.2.5. Reception of a PF_KEY SADB_DELETE message . . . . . . 26 97 6.2.6. Reception of a PF_KEY SADB_EXPIRE message . . . . . . 26 98 6.3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.3.1. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 26 100 7. Extending advantages of IRO to the HA . . . . . . . . . . . . 27 101 7.1. Rationale and expected advantages . . . . . . . . . . . . 27 102 7.2. Changes to HA processing . . . . . . . . . . . . . . . . . 27 103 7.3. Changes to MN processing . . . . . . . . . . . . . . . . . 28 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 8.1. Proof of address ownership . . . . . . . . . . . . . . . . 28 106 8.1.1. Position of the problem . . . . . . . . . . . . . . . 28 107 8.1.2. Home Address ownership . . . . . . . . . . . . . . . . 29 108 8.1.3. Care-of Address ownership . . . . . . . . . . . . . . 30 109 8.2. Remapping (comparison with explicit HAO/RH2 inclusion) . . 30 110 8.3. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 30 111 8.4. Limiting attack surface . . . . . . . . . . . . . . . . . 30 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 113 Appendix A. Ability to send does not prove CoA ownership . . . . 31 114 Appendix B. IKE exchanges use the HoA and the tunnel to the HA . 32 115 Appendix C. Arguments for no regular check of HoA ownership . . . 33 116 Appendix D. Lack of encryption between MN and HA . . . . . . . . 34 117 Appendix E. What if I don't need protection? . . . . . . . . . . 35 118 Appendix F. MTU Gains . . . . . . . . . . . . . . . . . . . . . . 36 119 Appendix G. Compatibility with static keying . . . . . . . . . . 37 120 Appendix H. Compatibility with the use of CoA in SP/SA . . . . . 38 121 Appendix I. Rationale for not specifying a new BU . . . . . . . . 38 122 Appendix J. Anonymity . . . . . . . . . . . . . . . . . . . . . . 39 123 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 124 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41 125 10.2. Informative References . . . . . . . . . . . . . . . . . . 42 126 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 43 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 128 Intellectual Property and Copyright Statements . . . . . . . . . . 44 130 1. Disclaimer and conventions 132 1.1. Disclaimer 134 This memo covers MIPv6 Route Optimization in IPsec/IKE environments. 135 For that reasons it is expected that the reader be familiar with the 136 main reference documents associated with those topics. 138 This includes the main MIPv6 reference documents ([RFC3775], 139 [RFC3776], [RFC4877], ...) and main IPsec/IKE reference documents 140 ([RFC4301], [RFC4303], [RFC4306] and their previous versions). 142 For the discussions regarding the security of route optimization 143 (proof of address ownership, mainly) [RFC4225] is a must read and 144 [RFC4651] provides a good summary of the issues and previous work on 145 possible solutions. 147 The Security Considerations section (section 6) of [RFC4866] also 148 provides a good security-oriented introduction to the address 149 ownership problem. 151 1.2. Conventions used in this document 153 In this document, except otherwise specified: 155 o "IKE" is used as a placeholder for both IKEv1 [RFC2409] and IKEv2 156 [RFC4306]. 157 o "Peer" is used as a placeholder for a MIPv6 end entity, i.e. a CN 158 or a MN. 159 o "HAO" is used as a placeholder for Destination Options Header 160 carrying a Home Address Option. When the address in a HAO is 161 considered, it denotes the address found in the Home Address field 162 of the Home Address option carried in the Destination Options 163 Header. 164 o When "tunnel" is used to designate the IPv6-in-IPv6 path between 165 the MN and its HA, IPsec in tunnel mode is assumed to be in place. 166 o When "MN-CN" is used it also obviously includes the MN-MN case 167 where the second MN acts as a CN for the first MN. 168 o When "IPsec flow" applies to a MN-MN or MN-CN communication, the 169 address of the MN considered for the associated SP is the HoA. 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 2. Introduction 177 2.1. Current situation 179 Mobile IPv6 specification [RFC3775] mandates the use of IPsec for 180 protection of communications (control and optionally data) between a 181 Mobile Node and its Home Agent. Support for static keying is made 182 mandatory, and dynamic keying optional. The protection is made 183 possible by the trust relationship that preexists between the HA and 184 the MN: they belong to a common trust domain (the same network, a 185 PKI). Interactions between MIPv6 and IPsec/IKE for MN and HA 186 exchanges are partly covered in [RFC3776] and [RFC4877]. 188 For implementation reasons outside the scope of previous reference 189 documents, some additional changes to IPsec/IKE are required to 190 support Mobile IPv6. [MIGRATE] specifies a way to implement those 191 changes by extending PF_KEY framework. 193 [RFC3775] also specifies a Route Optimization procedure which allows 194 direct communications to occur between a Mobile Node (MN) and a 195 Correspondent Node (CN), without suffering the delay associated with 196 the routing through the MN's Home Agent. The setup of this optimized 197 routing is based on a mechanism called Return Routability Procedure 198 (RRP). 200 One of the main hypothesis behind the design of Return Routability 201 Procedure is the lack of trust relationship between the MN and its 202 CN. This results in a complete lack of security in terms of privacy 203 and authentication of data: the procedure mainly provides a limited 204 proof of MN's HoA and CoA addresses ownership to the CN. 206 In trust domains (networks with an underlying PKI infrastructure) 207 where Mobile IPv6 gets deployed using dynamic keying (IKE or IKEv2) 208 for negotiating Security Associations, Mobile Nodes are already 209 provisioned with credentials (X.509 certificates). In those 210 environments, the initial hypothesis that led to the design of RRP 211 and its associated limited security abilities does not hold anymore. 213 At the moment, [CNIPsec] only describes how IPsec can be used to 214 protect signaling traffic between the Mobile Node and the 215 Correspondent Node but only provides a limited coverage of the 216 problem. 218 2.2. Characteristics of IRO 220 This document defines an extension of Mobile IPv6 protocol that aims 221 at replacing common RRP and RO procedures by a mechanism called IPsec 222 Route Optimization (IRO) in environments where IPsec and IKE are 223 used. 225 It allows MN to mount and maintain direct IPsec-protected 226 communications with CN and other MN with which they share some trust 227 relationship, in a completely transparent fashion for upper layer 228 protocols. 230 IRO is not a detailed set of requirements for IPsec to work between 231 MN and CN but a new mechanism resulting from the tight integration 232 and joint efforts of MIPv6, IKE and IPsec to provide a secure and 233 scalable mobility service. 235 The main functional and security advantages that best describe IRO 236 are: 238 o Protected MN-CN binding using IKE-negotiated IPsec SAs. 239 o Complete transparency for IKE (negotiation, rekeying, movement, 240 ...) and other upper layers, including layer 14 (the user). 241 o Compatibility with both tunnel and transport mode IPsec protection 242 between peers. 243 o Compatibility with static keying (See Appendix G). 244 o In MN-CN case, non-disclosure of MN's HoA on its foreign link. 245 o No additional changes to IPsec or IKE protocols and limited 246 changes to MIPv6 via four simple messages and an option resulting 247 in simple and generic integration within IPsec and Mobile IPv6 248 stacks. 249 o Improved and more generic proof of address ownership mechanism. 250 o Safe by default behavior avoiding direct unprotected traffic 251 flows. 252 o Complete removal of RH2 and HAO, resulting in simplified packet 253 handling on both sides and possibly better compatibility with 254 filtering implemented in the network. 255 o Per packet MTU gains between 24 and 48 bytes in comparison with 256 equivalent uses of IPsec in standard RO context. Details are 257 provided in Appendix F. 259 The main prerequisites of IRO are: 261 o Existence of a trust relationship between peers (i.e. shared 262 secret or ability to use IKE). 263 o Required protection of peers' exchanges (i.e. IPsec is used 264 between peers). IRO does not apply to direct unprotected 265 communications between peers. More precisely, IRO prevents them. 266 o To fully benefit from IRO improvements, data traffic between the 267 MN and its HA must be exchanged through an IKE-negotiated movement 268 resistant IPsec tunnel. If this hypothesis is not fulfilled, IRO 269 will still be usable but some security features listed previously 270 will be lost (Appendix D). 272 2.3. Motivation 274 The motivation behind this work is the direct need for both efficient 275 and secure communications in Mobile IPv6 environments already 276 benefiting from an underlying trust domain. 278 The first intended target of the mechanism described in this memo is 279 the growing number of corporate networks where PKI are now 280 widespread. This is generally due to the increasing number of 281 services (802.1X, SSL/IPsec VPN, TLS Web portal, S/MIME, ...) that 282 use them on a daily basis as the root of their security and to 283 provide logical segregation. It is also suitable for other kinds of 284 communities. 286 In environments where data confidentiality and privacy do matter 287 (IPsec is used for the protection of data between the MN and its HA), 288 current RRP and RO between peers of the trust domain are usually 289 deactivated: 291 o to prevent direct unprotected communications between peers that 292 would bypass protected tunneling through the Home Network. 293 o because their implementation and setup with IPsec/IKE does not 294 work out of the box and is not trivial even if [CNIPsec] helps for 295 signaling. 297 This results in heavy constraints on the HA (which handles all the 298 traffic to/from its MN) and the de-facto inability to get direct end- 299 to-end IPsec-protected MN-CN and MN-MN communications. 301 The ability to reduce the number of communications performed by the 302 Mobile Node that get tunneled through the HA is both an improvement 303 in term of upload bandwidth consumption on the link to the HA, 304 cryptographic processing requirements on the HA and also in term of 305 latency for applications that directly benefit from end-to-end 306 connections, like Chat, VoIP, Videoconferencing or direct file 307 exchanges. 309 In a sense, there is a kind of vicious circle regarding the use of 310 IPsec/IKE with various protocols, including MIPv6: because dynamic 311 keying and IPsec are not considered the common case, they are not 312 fully covered in specifications (static keying for simple modes). 313 The net effect is that their implementation and deployment is then 314 complicated, which results in limited use. In a sense, IRO tries to 315 break that circle. Simply put, this specification considers IKE- 316 enabled environments as the first target and then covers static 317 keying cases. 319 2.4. Notes to the reader 321 The mechanism described in this memo is very simple from a design 322 perspective. To keep this apparent simplicity and the reading of the 323 document pleasant, all design decisions and main justifications are 324 provided in the numerous appendices (around 10 pages). This allows 325 to focus on the details of the mechanism in the body of the document 326 (around 20 pages). 328 For previous reason, the reading of the document can be performed 329 linearly. The not so curious reader can skip over the appendices 330 which are only a must read for developers and security people to 331 acquire a deep understanding of the mechanism and how security has 332 been taken into account in its design. 334 Unlike many other IETF documents, this memo voluntarily provides a 335 practical implementation feedback geared towards developers. Even if 336 the associated section does not mandate an implementation design, it 337 might be of interest anyway. 339 3. Overview 341 The whole document is geared towards improved security between MIPv6 342 nodes and also improved usability of IPsec/IKE with MIPv6. This 343 section provides to the reader a quick non-normative overview of how 344 IRO works, before entering the details of the mechanism in next 345 sections. The reader is expected to be familiar with the vocabulary 346 used in [RFC3775]. We do not consider in this section the 347 relationship between the MN and its HA, only the relationship between 348 a MN and its CNs. In the whole document, IKE is considered as the 349 default mechanism used for SA setup. 351 This section provides a quick and non-normative overview of IRO and 352 introduces next sections that contain normative details. The first 353 subsection provides a rough outline of IRO. It is followed by 5 354 small subsections that cover the steps of IRO processing, in the 355 order they occur: 357 o Pre-binding steps: installation of remapping rules, which IRO uses 358 to prevent the use of RH2 and HAO in incoming and outgoing 359 signaling packets (MH traffic). 360 o BU emission: description of the steps that apply to the emission 361 of the BU by the MN in the context of IRO. 362 o Proof of CoA ownership: description of the steps that occur when a 363 proof of CoA ownership is requested by the peer. 365 o BA emission: description of the steps that apply to the emission 366 of the BA to the MN in the context of IRO. 367 o Post-binding steps: installation of additional remapping rules, 368 which IRO uses to prevent the use of RH2 and HAO in incoming and 369 outgoing data packets. 371 3.1. The big picture 373 This section simply lists the key ideas and design concepts behind 374 IRO. 376 When IPsec is used between two peers, every packet de facto contains 377 a simple piece of information (the SPI) that gives access to many 378 parameters. Among those parameters synchronized between the two 379 IPsec stacks are address information for both peers. Unlike IPsec, 380 MIPv6 uses specific extensions (RH2 and HAO) to explicitly carry 381 address information. When both protocols are used together and the 382 IPsec SA/SP make use of HoA (i.e. not CoA), the RH2 and HAO 383 extensions in packets carry the HoA. It could easily be deduced from 384 the SPI. Based on this observation, IRO removes RH2 and HAO 385 extensions from packets and replace them by simple additional steps 386 on the sender and the receiver: remapping rules for address based on 387 the SPI. 389 Previous removal of HAO and RH2 extensions from traffic between peers 390 is also perfectly applicable to the traffic between a MN and its HA. 391 This specification extend the remapping rules to the traffic between 392 a MN and its HA. When IRO is used, RH2 and HAO extensions are simply 393 not seen on the wire. 395 As stated previously, the hypothesis on which common RO and RRP are 396 based simply do not hold when peers are able to use IPsec/IKE between 397 them. For that reason, even if some proof of address ownership is 398 still required, a more suitable (read simple) mechanism is defined 399 for that purpose. 401 To sum it up (simplistic vision): 403 o IRO simplifies packets format by removing HAO and RH2 extensions. 404 o IRO fully replaces RRP by a more suitable and simple mechanism 405 taking into account the use of IPsec/IKE between peers. 406 o IRO defines how this can be extended to MN-HA exchanges. 408 3.2. Pre-binding steps 410 Before any direct communication can take place between a MN and a CN, 411 the CN must accept a binding between the CoA and the HoA of the MN. 412 For that to happen, the CN must have acquired the proof of both HoA 413 and CoA addresses ownership by the MN. 415 In RRP, the MN proves to the CN its ability to both send and receive 416 traffic from and at those addresses by a four messages exchange 417 combining both direct and HA-tunneled packets. 419 In the context of IRO, the binding registration between peers is 420 IPsec protected. It is expected that IKE be used for negotiating an 421 initial pair of ESP transport mode IPsec SAs between the HoA of the 422 MN and the address of the CN for protecting this registration (static 423 keying is covered later in the document). IKE negotiation occurs 424 using the tunnel between the MN and its HA, i.e. the MN uses the HoA 425 for that purpose. This provides the CN the initial proof of HoA 426 ownership by the MN. 428 On both entities, the specific IPsec ESP transport mode SAs 429 (protecting MH traffic) created between the peers are taken into 430 account by IRO code in Mobile IPv6 stack. This triggers the setup of 431 specific "remapping rules" on both entities, that will be applied to 432 incoming and outgoing IPsec packets whose SPI matches the one of 433 tracked SAs: 435 1. On the MN, the outgoing IPsec traffic matching the SPI of the 436 associated SA to the CN has its source address remapped to the 437 address stored (by MIPv6 process) in the ancillary data of the 438 packet (the CoA). 439 2. On the CN, the incoming IPsec traffic matching the SPI of the 440 associated SA with the MN has its source address remapped to the 441 specific source address in the SA (the HoA of the MN). The 442 remapped address is kept as an ancillary data in the local packet 443 structure for further processing. The packet is then naturally 444 handled by the IPsec stack. 445 3. On the CN, the outgoing IPsec traffic matching the SPI of the 446 associated SA to the MN has its destination address remapped to 447 the address stored in the ancillary data of the packet, if not 448 null. 449 4. On the MN, the incoming IPsec traffic matching the SPI of the 450 associated SA to the CN has its destination address compared with 451 the CoA the MN is asking a binding for to the CN. On match, the 452 destination address of the IPsec packet is remapped to the 453 destination address in the SA (the HoA of the MN). The packet is 454 then naturally handled by the IPsec stack. 456 Simply stated, rules 1 and 3 will end up performing a remapping of 457 HoA used in outgoing IPsec packets in their CoA counterparts and 458 rules 2 and 4 will do the opposite on the other side for incoming 459 IPsec packets. 461 Note that these rules apply only to IPsec packets associated with SA 462 that protect MH traffic. They are used before any data packet is 463 received or sent by the entities using a direct path. 465 3.3. BU emission 467 The MIPv6 stack on the MN emits a Binding Update packet containing a 468 Mobility Header AltCoA option which carries the CoA it is proposing a 469 binding for to the CN. This packet is sent from the HoA of the MN to 470 the address of the peer. The CoA is put as an ancillary data in the 471 local packet structure for further processing. As it matches the 472 IPsec SA put in place between the MN and the peer, it gets handled by 473 the IPsec stack to be ESP protected. Before leaving the MN, it 474 passes the set of MIPv6 rules for the MN; a match is found against 475 rule 1, so that the source address of the packet is remapped to the 476 address available as an ancillary data in the packet, the CoA of the 477 MN. 479 When the IPsec protected BU hits the MN, it passes the set of MIPv6 480 rules for the CN. It matches rule 2 so that its source address is 481 remapped to the source address of the SA (the HoA of the MN). The 482 source address found in the packet is stored as ancillary data. The 483 packet is handled by the IPsec module, matches the SA, is decrypted 484 and passed to the upper layer, the MIPv6 process. 486 During parsing, the CN compares the content of the AltCoA option with 487 the address previously stored as ancillary data. 489 3.4. Proof of CoA ownership 491 At that point, before accepting the binding and replying with a BA, 492 the CN must have the proof of CoA ownership from the MN. If one is 493 already available, it simply goes on and sends a BA, as described in 494 3.4. Otherwise, it first performs following steps. 496 It sends a newly defined MH message (AOTC, Address Ownership Test 497 Challenge) to the MN, providing the CoA as ancillary data, so that 498 the remapping rules will make the packet use the CoA for the address 499 found in the IPv6 header destination field. This packets carries a 500 freshly generated nonce. 502 On the MN, the packet follows the reverse remapping process, the CoA 503 being remapped to the HoA and passed as ancillary data. The MIPv6 504 stack replies with an IPsec protected MH message to the CN (AOTR, 505 Address Ownership Test Request), using the HoA as local source but 506 providing the CoA as ancillary data. The remapping rule makes the 507 CoA the on-wire address of the packet. This packets carries the 508 nonce sent by the CN. 510 The CN receives the packet and after having checked the source 511 address and the nonce against the one previously sent, the MIPv6 512 stack records the address ownership of the CoA for that MN, and 513 continues with the steps described in Section 3.5 515 3.5. BA emission 517 The CN constructs a Binding Acknowledgement packet to be sent to the 518 HoA of the MN. The CoA of the MN is put as an ancillary data in the 519 local packet structure for further processing. Now, as the BA 520 matches the SA, it is ESP-protected and passes the set of MIPv6 rules 521 for the CN. It matches rule 3 and the HoA is replaced with the 522 address available in the ancillary data of the packet (MN's CoA). 523 The packet is then sent. At that moment, if the status code in the 524 BA is 0 (Binding Update Accepted), the binding is effective on the 525 CN. 527 On the MN, the IPsec protected BA is received, it passes through the 528 set of MIPv6 rules for the MN and matches rule 4. The destination 529 address is changed to the destination address of the SA (HoA of the 530 MN). It is then handled by the IPsec module, and then to the MIPv6 531 process. If the status code in the BA is 0, the binding is effective 532 on the MN. 534 For the rest of this section, we consider the binding is effective on 535 both sides. Other scenarios are covered in details in Section 3. 537 3.6. Post-bindings steps 539 In [RFC3775], when the RRP has completed successfully, routing of 540 traffic between the MN and the CN is automatically modified to follow 541 a direct path. With IRO, on the contrary, a successful binding 542 between a MN and a CN does not trigger any change in routing of 543 _regular_ traffic between the MN and the CN. It still flows using 544 the IPsec tunnel through the MN's HA. Only IPsec traffic is 545 optimized. 547 This design decision provides a "safe by default" behavior and avoid 548 a successful binding to lead to unprotected direct communications. 550 Furthermore, only IPsec flows will be able to take advantage of the 551 direct path between the MN and the CN. Arguments for this design are 552 provided in Appendix E. 554 So, if existing IPsec SAs protecting non-signaling traffic (data) are 555 already available on both sides, that have the HoA and the address of 556 the MN as address selectors, remapping rules are put in place to 557 perform the same kind of address changes presented in four previous 558 rules. Those rules are static ones (they do not use any ancillary 559 data) that remap CoA to HoA and HoA to CoA (after some checks), 560 respectively before and after IPsec processing. 562 They simply replace the HAO and RH2 headers inclusion and parsing on 563 both sides by using the SPI information as an opaque multiplexing/ 564 demultiplexing value available on both ends. 566 4. Proof of CoA ownership 568 4.1. Position of the problem 570 A CN accepting a binding for the CoA of a peer is not something 571 harmless. In the context of IRO, this decision is based on: 573 o a proof of HoA ownership by the MN at the time the SA is 574 negotiated. 575 o a proof of CoA ownership by the MN. 577 The existence of a strong trust relationship between the two (pairs 578 of SA) and an easy proof of emission capability from the CoA are 579 unfortunately insufficient proofs of CoA ownership. As covered in 580 Appendix A, a proof of the ability for the MN to receive traffic at 581 its asserted CoA is required to workaround the lack of ingress- 582 filtering at the scale of Internet: it avoids the CN to involuntarily 583 take part in a DoS against the provided CoA. 585 4.2. Overview 587 As the proof of HoA ownership is only required to occur once in the 588 context of IRO, the mechanism focuses on the proof of CoA ownership. 589 Instead of reusing the complicated RRP, IRO directly benefits from 590 the available IPsec protection between the MN and its CN to simplify 591 things. 593 Furthermore, in the context of IRO, the lifetime of the provided 594 proof is no longer limited and generally de-correlated from 595 registration steps. This already reduces the amount of transferred 596 data and leaves room for further optimizations (nodes with multiple 597 simultaneous connections, nodes with limited numbers of foreign 598 networks, ...) 600 As CoTI and CoT messages have some associated requirements, options 601 and semantic, and also lacks some expressiveness, they are not reused 602 for IRO proof of address ownership. It is based on four new 603 extremely simple messages: 605 o AOTO: Sent by a MN to a CN to offer to prove address ownership. 606 o AOTC: Sent by a CN to the MN at the address to be tested, with a 607 Nonce option that will be returned in an AOTR message. 608 o AOTR: Sent by the MN as a response to an AOTC, with the received 609 Nonce option. 610 o AOTS: Sent by the CN to the MN to provide a status on ongoing 611 address ownership test. 613 4.3. Mobility Options 615 4.3.1. Nonce option 617 The Nonce option has type XX and an alignment requirement of 8n+6. 618 Its format is as follows: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type = XX | Length = 8 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 + Nonce + 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 The content of the Nonce field MUST always be filled with a freshly 631 generated 64-bit random value. 633 XXX For testing purposes, the Nonce option has type value 88. 635 4.4. IRO Messages 637 All the normative information associated with the four new messages 638 specified by IRO are provided in this subsection. This includes 639 their format, associated constants, security related information and 640 processing requirements. 642 Note that the messages defined below are used for proof of ownership 643 of the CoA. They are not used to prove ownership of the HoA: this is 644 either not done (static keying) or the result of the ability to 645 negotiate SA using IKE. 647 4.4.1. Address Ownership Test Offer (AOTO) 649 This message is sent by a MN to a CN to offer to prove its ownership 650 of the CoA the packet was sent from. An AOTO message MUST NOT be 651 sent by a MN if it is not already registered with the CN. If that 652 happens, the CN simply drops the message without further processing. 654 Reception of this message can trigger the emission of either: 656 o an AOTC containing a Nonce option, sent back to the source address 657 of the AOTO. 658 o an AOTS with status 0, indicating that the peer does not allow the 659 peer to pre-register CoA ownership information. 660 o an AOTS with status 1, indicating to the peer that the proof of 661 Address ownership is still valid. 662 o nothing if it is invalid or sent by an unregistered MN. 664 The format of the message is as follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Reserved | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Reserved field is not used yet but might be for future need. It 673 currently serves padding requirements. It should be set to null on 674 emission and ignored on reception by peers complying with this 675 specification. 677 AOTO messages do not carry options. MH Type field in Mobility Header 678 takes value XX when carrying an AOTO message. 680 XXX For test purposes, MH Type field should use value 30 682 4.4.2. Address Ownership Test Challenge (AOTC) 684 The purpose of this message is to provide a nonce to an MN at the 685 address the MN wants to provide proof of ownership for. The ability 686 for the MN to return the nonce to the CN (in an AOTR) provides a live 687 proof of its ability to receive traffic at that address. This 688 message is possibly sent by a CN to a MN in two situations: 690 o After receiving a Binding Update message that the CN is willing to 691 accept but for which it does not already has a proof of address 692 ownership for the originating CoA the packet was sent from 693 (correlated with the content of the AltCoA option). 694 o After receiving an AOTO from a MN that wants to perform a proof of 695 address ownership for the source address of the packet. 697 The format of the message is as follows: 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Reserved | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | | 705 . . 706 . Mobility Options . 707 . . 708 | | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 The Mobility Options field must always contain a Nonce option. The 712 nonce must be stored locally by the CN for that MN, along with the 713 address being tested. The nonce will be compared with the content of 714 the nonce option found in the AOTR messages. 716 MH Type field in Mobility Header takes value XX when carrying an AOTC 717 message. 719 XXX For test purposes, MH Type field should be set to 31 721 4.4.3. Address Ownership Test Response (AOTR) 723 This message is sent by the MN as a result of receiving an AOTC 724 (resulting from an initial action, BU or AOTO). It contains the same 725 nonce, in a Nonce option, the peer had included in its AOTC. The 726 AOTR message is sent from the address to be tested (the on-wire 727 destination address of the AOTC). 729 When received by the CN, on-wire source address is used to access the 730 stored nonce previously sent in an AOTC message and compare it with 731 the one in the Nonce option found in the message. On match, the 732 address ownership by the peer is considered proved. 734 The format of the message is the same as the AOTC message except for 735 MH Type field in Mobility Header which takes value XX when carrying 736 an AOTR message. 738 XXX For test purposes, MH Type field should be set to 32 740 4.4.4. Address Ownership Test Status (AOTS) 742 This message is sent by the CN with a status regarding a proof of 743 address ownership. The status can be generic (not associated to an 744 address whose ownership is being proved), for instance if this CN 745 does not allow MN initiated Address Ownership Tests to occur. It can 746 also be specific to an ongoing or already performed Test of Address 747 Ownership, for instance to explicitly acknowledge the result of the 748 test. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Code | Reserved | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 MH Type field in Mobility Header takes value XX when carrying an AOTS 757 message. Code field provides the status code the message carries. 758 The list of status codes is provided below: 760 AOTS status codes: 762 o 0 AOTO not allowed 763 o 1 Proof of Address Ownership is valid 765 XXX For test purposes, MH Type field should be set to value 33 767 4.5. Concrete uses of AOT* Messages 769 4.5.1. Registration with a CN 771 The registration process between a MN and its HA is simple and 772 efficient, being made of a simple BU [/BA] exchange. This is because 773 the proof of CoA ownership is not required by the HA from the MN. 775 Like with other route optimization procedures, with IRO, the CN is 776 required to have a proof of CoA ownership available for the MN before 777 accepting a binding and replying with a Binding Ack. More precisely, 778 the proof is needed only before sending traffic to the CoA of the MN 779 but does not impact the reception of traffic from the CoA. This is 780 of particular importance in the rest of the discussion. 782 Unlike in other more common environments where the proof has to be 783 made at every binding, or "renewed", IRO uses proofs with unlimited 784 lifetimes. This does not mean that once the ownership has been 785 proved to a CN the CoA will indefinitely belong to a MN. The 786 decision is always left to the CN, with the expectation that some 787 sufficient temporary storage will make it capable to keep the binding 788 for a while. 790 This means that if a proof of CoA ownership for a MN is available 791 locally on its CN, no live proof is required and a simple BU [/BA] 792 exchange is sufficient for the registration to occur. This also 793 means that inside small or medium communities, where MN move between 794 few locations, the number of potential CoA remains quite low and 795 stable, and can be kept locally on nodes acting as CN. 797 For instance, without limiting the possible uses, a typical scenario 798 for a daily use includes an address at home (wifi, ...), another on a 799 mobile network (3G, ...) and another at work (wifi, Ethernet, ...). 801 With IRO, when a MN sends a BU to a CN for registration or 802 reregistration purposes, it starts directing its traffic instantly 803 after the emission of the BU to the address of the CN. Then, the CN 804 will either ask for proof of CoA ownership if it has none available 805 from that MN for that CoA or send a BA to the peer. In all cases, it 806 puts in place the remapping rules for accepting traffic from the CoA 807 (and not the one for emission). That way, there is no disruption of 808 traffic from the MN to the CN. 810 If the CN replies with an AOTC message sent to the CoA of the MN, the 811 MN replies with an AOTR, proving its complete ownership. The CN then 812 replies with the expected BA and puts in place the required remapping 813 rules for the traffic to flow to the MN at its CoA. 815 Regarding re-emission, if the MN has no reply from the CN (i.e. no BA 816 or AOTC), common re-emission rules apply. Then, if the CN has sent 817 an AOTC, but receives no reply, it can keep things that way or 818 garbage collect the remapping rule (i.e. remove it after some time). 819 If the MN receives no BA from the CN, it performs re-emission of the 820 AOTR (This implies that the Nonce must be kept locally on the CN even 821 after the emission of the BA). 823 4.5.2. Early test of CoA ownership 825 There are cases where a MN will be willing to perform early proof of 826 address ownership, allowing it to avoid the delay during movement. 827 In that case, the MN sends an AOTO message to the CN, and receives 828 either and AOTC or an AOTS. If the received message is an AOTS, the 829 exchange is over. If the message is an AOTC, it replies with an AOTR 830 and waits for an AOTS. 832 A possible use of that early test of CoA ownership is by multi-homed 833 nodes that already have a list of possible CoAs they will switch to 834 if they lose their primary connectivity mean. Note that: 836 o this is only a possible optimization allowed by the AOT* framework 837 introduced in this document, not a requirement. 838 o it still requires the MN to be registered with the CN. 839 o it requires the MN to exchange AOT* messages using the address 840 whose ownership is to be proved. 842 4.5.3. Test of HoA ownership 844 IRO does not mandate regular proofs of HoA ownership, for the reasons 845 covered in Appendix C. For those who have the need, and can afford 846 to lose the associated bits on a regular basis, the AOT* messages can 847 be used for that purpose. 849 If a CN wants to get a live proof of HoA ownership from a MN, it 850 simply emits an AOTC message (with a fresh Nonce option) to the HoA 851 of the MN for which it has already accepted a registration. The MN 852 MUST reply with an AOTR message containing the received Nonce option. 853 The exchange occurs using respectively the HoA as on-wire destination 854 and source address. This implies that the packets are tunneled 855 through MN's HA. In the MN-MN case, this mainly results in packets 856 never following a direct path. 858 Note that this specification does not define the action taken by a CN 859 if it does not receive AOTR messages as response to its AOTC messages 860 sent to the HoA. 862 5. Remapping rules 864 This section covers the heart of IRO processing, the remapping rules 865 that are applied to incoming and outgoing IPsec protected traffic. 867 5.1. Requirements 869 5.1.1. On-wire addresses access from userland 871 With IRO, there is a need for the MIPv6 processing engine to both 872 pass and get on-wire source and destination addresses of received and 873 emitted IPsec protected MH packets. This need is mainly associated 874 with the proof of address ownership and binding exchanges. The need 875 is simply the same as the one associated with the ability to set and 876 get HAO/RH2 for a common MIPv6 process. Instead of having explicit 877 information in the packet, an ancillary path is required. 879 This requirement is limited only to MH traffic in general and some 880 specific MH types in particular. 882 For incoming IPsec protected MH packets, this means that during the 883 handling by remapping rules, the remapped on-wire address must be 884 kept in the local packet structure as an ancillary data that the 885 MIPv6 process will be able to access. 887 For outgoing MH packets, this means that the addresses MUST be made 888 available as ancillary data in the local packet structures by the 889 MIPv6 process and then be used, if available, by the remapping rules. 891 For all incoming IPsec packets associated with a coarse or fine 892 grained SA for MH traffic, if a remapping rule is applied to the 893 traffic, the on-wire source and destination addresses MUST be made 894 available as ancillary data to the userland process that will process 895 the packet (i.e. at socket level). In all cases (remapping rule 896 being applied or not), if an on-wire source or destination address is 897 not changed, the associated ancillary data MUST contain the 898 unspecified address (::). 900 5.1.2. Non-MH traffic (data traffic) 902 Data traffic exchanged between MN and CN using IRO has simple 903 requirements in term of remapping. We consider here only IPsec 904 packets that are not associated with a transport mode IPsec SA 905 protecting MH traffic. 907 5.1.2.1. Compatibility with traffic using RH2 and HAO 909 This specification is compatible with RH2 and HAO extensions even if 910 some care is obviously required in the order in which they are 911 handled. This is generally an implementation dependent issue outside 912 the scope of this specification. 914 In practice, it is expected (except otherwise specified) that IRO 915 module handles incoming traffic after RH* or HAO processing and 916 outgoing traffic just before emission, i.e. with expected-on wire 917 address w.r.t. to RH* and HAO. 919 5.1.2.2. Incoming traffic 921 When an incoming IPsec packet is handled by IRO, as the last step 922 before being processed by the IPsec module, the SPI is used as the 923 main key to find existing source and destination addresses remapping 924 rules for that traffic (at most one for each). 926 Each rule has an expected on-wire address. The expected address is 927 checked against the on-wire one found in the packet. If it matches, 928 the remapping occurs. Note that the remapping rules for source and 929 destination addresses are applied in an independent fashion. 931 5.1.2.3. Outgoing traffic 933 When an outgoing IPsec protected packet is handled by IRO, the SPI is 934 used as the main key to find existing source and destination 935 addresses remapping rules for that traffic (at most one for each). 936 The expected address is checked against the one found in the IPv6 937 header of the packet. If it matches, the remapping occurs. Note 938 that the remapping rules for source and destination addresses are 939 applied in an independent fashion. 941 5.1.2.4. Related traffic (ICMPv6 error traffic, fragments) 943 5.1.3. MH traffic 945 MH traffic emitted and received by a MIPv6 entity using IRO has 946 specific additional requirements compared to common data traffic 947 exchanged between those MIPv6 entities. 949 Basically, the checks and settings on source and destination 950 addresses are relaxed to allow IPsec-protected traffic sent from a 951 new non-registered CoA to pass through. In the MIPv6 stack of the 952 CN, checks are done using an ancillary path that allows the on-wire 953 address to be passed for verification. 955 Here, we only consider IPsec-protected traffic associated with 956 transport mode SAs whose selectors provide protection of MH traffic. 957 Granularity considerations are covered below. 959 The search for remapping rules is done in the same fashion as 960 previously described for data traffic. Only checks and application 961 of the rules are changed as described below. 963 5.1.3.1. Incoming traffic 965 If a remapping rule is found for source address, which contains the 966 unspecified address as check, the remapping is performed without 967 checking the source address of the packet. The unspecified address 968 is used as a wildcard. 970 In source rule case, the on-wire address found in the packet is 971 stored as an ancillary data for further processing and decision by 972 the MIPv6 stack (commonly in userland). 974 Note that this specification does not explicitly mandate when the 975 unspecified address should be used in the source remapping rule, and 976 leave that to implementors, as it is highly dependent of following 977 facts: 979 o if the system does not support fine-grained SP/SA or simply does 980 not use them for MH traffic with a peer, then the use of the 981 unspecified address will be required. 982 o if fine-grained SA are used, the MIPv6 stack will use the 983 unspecified address if the traffic received protected by that SA 984 can't be reliably mapped to a specific CoA for the peer, i.e. if 985 it is expected and authorized that the peer sends traffic from 986 another [possibly to be registered] CoA. This is the case for BU, 987 AOTO, AOTR traffic for instance. 988 o if the MIPv6 stack supports extensions to [RFC3775]-defined MH 989 messages, the use of IRO will still remain possible with those 990 extensions. 992 Note that this decision is not expected to create interoperability 993 issues, as the use of the unspecified address is based on non- 994 ambiguous criteria defined in the documents specifying the purpose of 995 MH traffic. 997 Also note that the use of the unspecified address for checks and the 998 passing of the on-wire address to the MIPv6 stack for further 999 processing is equivalent from a security standpoint to the decision 1000 that occurs in common MIPv6 processing of HAO extension. 1002 5.2. Rules syntax 1004 To avoid long descriptive sentences in following section, a simple 1005 syntax for expressing remapping rules is provided here. 1007 5.2.1. Remapping rules content 1009 A remapping rule is made of: 1011 o a direction, describing the kind of traffic it will potentially be 1012 applied to. Possible values are "incoming" or "outgoing" 1013 o an SPI value, distinguishing the IPsec packets, encountered in 1014 that direction, to which the rules might apply. 1015 o a value for expected source address or destination address, that 1016 will be respectively compared with the content of the source or 1017 destination address field in the IPv6 header. 1018 o For a source address, the unspecified address (::) is used as a 1019 wildcard, in which cases all addresses are allowed. 1020 o a value for source or destination address, that will be used for 1021 remapping the associated address in the packet. If a single 1022 address is provided, it is used for remapping after checks have 1023 been performed. 1025 If the special keyword "ancillary" is used for remapping a source 1026 address, the address to be used is found as an ancillary data in 1027 the packet. 1029 If the keyword "(ancillary)" appears next to the address to be 1030 used for remapping a destination, the remapped address should be 1031 copied as ancillary data in the packet (see example 4 in next 1032 subsection). 1034 5.2.2. Remapping rules simple syntax 1036 This subsection defines a simple syntax for providing the content 1037 described in previous subsection. Those are given as a set of 1038 examples with few comments. 1040 1. A typical set of remapping rules found on a MN (HoA, CoA) for a 1041 protected data flow with a CN available at address A: 1043 dir: out, SPI: 42, exp. src: HoA, remap. src: CoA 1044 dir: in , SPI: 43, exp. dst: CoA, remap. dst: HoA 1046 2. A typical set of remapping rules found on a MN (HoA, CoA) for 1047 protected MH flows with a CN available at address A: 1049 dir: out, SPI: 44, exp. src: HoA, remap. src: CoA 1050 dir: in , SPI: 45, exp. dst: CoA, remap. dst: HoA 1052 3. A typical set of remapping rules found on a MN (HoA1, CoA1) for a 1053 protected data flow with another MN (HoA2, CoA2): 1055 dir: out, SPI: 46, exp. src: HoA1, remap. src: CoA1 1056 dir: in , SPI: 47, exp. dst: CoA1, remap. dst: HoA1 1057 dir: out, SPI: 46, exp. dst: HoA2, remap. dst: CoA2 1058 dir: in , SPI: 47, exp. src: CoA2, remap. src: HoA2 1060 4. A typical set of remapping rules found on a MN (HoA1, CoA1) for 1061 protected MH flows with another MN (HoA2, CoA2): 1063 dir: out, SPI: 48, exp. src: HoA1, remap. src: ancillary 1064 dir: in , SPI: 49, exp. dst: CoA1, remap. dst: HoA1 1065 dir: out, SPI: 50, exp. dst: HoA2, remap. dst: CoA2 1066 dir: in , SPI: 51, exp. src: ::, remap. src: HoA2 (ancillary) 1068 Note that in example 4, last rule expresses the "blind" remapping of 1069 source address to HoA2; the remapped address is passed as ancillary 1070 data for further check by the MIPv6 process. 1072 6. Tracking SPI changes 1074 [ Following discussions are only geared towards unicast traffic and 1075 the whole section will certainly get more accurate/interesting 1076 information during implementation of the mechanism ] 1078 With IRO, the SPI values referencing SAs are of primary importance: 1079 their correct collect and tracking in the time is a requirement to 1080 allow remapping rules to be kept in sync with the changes that can 1081 occur in the IPsec stack or MIPv6 stack. One important remark is 1082 that the actions performed by the IRO part of the MIPv6 stack on 1083 incoming and outgoing IPsec protected packets is completely 1084 transparent for the IPsec stack. There is no initial requirement for 1085 the IPsec stack associated with the use of IRO (even if having IRO 1086 implemented in the IPsec stack might be beneficial). 1088 IRO acts at the lowest possible level, theoretically just outside the 1089 IPsec stack, directly on the IPsec protected packets, and only 1090 requires access to three pieces of information to track and filter 1091 that packets: SPI, source and destination addresses. 1093 This section covers that tracking and associated actions based on the 1094 availability of PF_KEYv2 API [RFC2367]. The intent is to base the 1095 discussion on a standard interface but it generally apply in a system 1096 dependent fashion to other interfaces (Netlink/XFRM, ...). It 1097 obviously rely on the synchronisation between the two IPsec stacks on 1098 peers (SADB mainly, expected to be done by IKE). 1100 6.1. Initial collect ? 1102 [The need for initial collect _clearly_ depends on the location of 1103 IRO engine is implemented and how remapping rules are pushed/changed] 1105 The way remapping rules are put in place and maintained on the system 1106 implementing IRO is a local matter. The only requirement is that the 1107 externally understood behavior be in sync with the description 1108 provided in the document. This is especially important with changes 1109 associated with registration/deregistration and movement. 1111 In that context, if IRO engine is running in userland, there might be 1112 a need for maintaining a limited local version of system's SADB to be 1113 able to efficiently manage changes (removal, addition, CoA change) 1114 against a set of SA. For instance, when an IRO registration is 1115 accepted for a peer, remapping rules are put in place to have its HoA 1116 remapped to the CoA for incoming IPsec traffic (and the reverse for 1117 outgoing IPsec traffic). Upon movement, all those remapping rules 1118 must be updated to reflect the change of CoA. 1120 In that case, the use of PF_KEY SADB_DUMP message is possible to get 1121 access to the whole SADB content, filter interesting SA, load 1122 required remapping rules for those SA (as described for PF_KEY 1123 SADB_UPDATE message in 6.2.1) and initially populate some initial IRO 1124 SA state table. 1126 Then, if used, this table could be updated when receiving PF_KEY 1127 messages described in following subsection (addition or removal of 1128 entries), during movement (access to all impacted SA whose remapping 1129 rules should be remapped), or during registration/deregistration 1130 (addition/removal of associated remapping rules). 1132 6.2. SADB related PF_KEY events 1134 This subsection covers the actions performed by IRO when receiving SA 1135 related PF_KEY events. Those actions deal with the filtering of 1136 interesting SAs and installation/removal of associated remapping 1137 rules. If another interface than PF_KEY is used to track SA related 1138 events (or IRO logic is not implemented in userland), the behavior of 1139 IRO must remain the same with regard to the addition/removal of 1140 remapping rules. 1142 6.2.1. Overview 1144 A fundamental need of IRO is associated with the ability to setup 1145 remapping rules _before_ traffic that use those rules is emitted. A 1146 direct impact of this requirement is the need to access the SPI of 1147 the SA that will protect the traffic _before_ that SA is used. In 1148 practice, when dynamic keying is used, this creates an interesting 1149 challenge: because SA negotiation is usually triggered by a packet 1150 matching a SP, and IRO does not modifies IKE processing, some care is 1151 required in the implementation to ensure that the SPI information is 1152 gathered and the associated remapping rule installed _before_ the 1153 triggering packets is IPsec- and then IRO-processed. 1155 When dynamic keying is implemented using PF_KEY framework, the 1156 sequence of events performed by the key manager allows to implement 1157 that behavior, basically by monitoring SADB_GETSPI messages from the 1158 kernel in order to access SPI value and install the remapping rule 1159 while the SA is being negotiated. 1161 It is an implementation issue to ensure that IRO will be able to 1162 access the SPI and install the remapping rules before they are used. 1163 This highly depends on the location of IRO implementation (userland, 1164 kernel space), framework (PF_KEY, ...), ... 1166 6.2.2. Reception of a PF_KEY SADB_GETSPI message 1168 When the kernel returns a PF_KEY SADB_GETSPI message to all listening 1169 processes, IRO processing engine considers this kernel message. 1170 After validation (kernel emitted, errno not set, ...), it extracts 1171 the interesting information from the message (SA, Addresses, SPI) in 1172 order to decide if remapping rules are needed for this SPI. 1174 6.2.3. Reception of a PF_KEY SADB_UPDATE message 1176 When the kernel returns a PF_KEY SADB_UPDATE message to all 1177 listeners, following reception of the message from a key manager, IRO 1178 processing engine considers this kernel message. After validation 1179 (kernel emitted, errno not set, ...), it extracts from it the Source 1180 and Destination address extensions along with the direction and the 1181 SPI value found in the association header. 1183 Direction allows to decide if the remapping rule is an incoming or 1184 outgoing one. proto values (should match) allow to decide if wildcard 1185 rules are required (MH case). As there is more granularity available 1186 with IKEv2 selectors, this implies more cases and more specific rules 1187 (based on MH Type). [This part will get the required level of 1188 precision during the implementation]. Addresses allow to decide if 1189 an address is our HoA for which a peer has registered our CoA, or the 1190 HoA of a peer for which we have registered its CoA. 1192 6.2.4. Reception of a PF_KEY SADB_ADD message 1194 From IRO standpoint, SADB_ADD message is processed in the same 1195 fashion as SADB_UPDATE message. The message returned by the kernel 1196 to all listening processes contains the required SPI (in association 1197 header) along with the source and destination address extensions. 1199 6.2.5. Reception of a PF_KEY SADB_DELETE message 1201 The reception of a PF_KEY SADB_DELETE message from the kernel must 1202 trigger the removal of associated remapping rules for the SA if any 1203 (i.e. having that SPI). 1205 6.2.6. Reception of a PF_KEY SADB_EXPIRE message 1207 When IRO engine receives a PF_KEY SADB_EXPIRE message from the kernel 1208 for a SA for which it has loaded some remapping rules, the associated 1209 action depends on the kind of expiration (hard or soft limit): 1211 o In soft case, nothing is done as the SA is still valid. 1212 o In hard case, the SA may already have been deleted from the SADB 1213 and IRO engine must remove associated remapping rules. 1215 6.3. Rekeying 1217 6.3.1. Phase 2 1219 When dynamic keying is used, negotiated IPsec SA have limited 1220 lifetime. With IKEv1, the lifetime is negotiated and the rekeying is 1221 performed by the initiator. In the context of MIPv6, this is 1222 expected to be the peer. 1224 As stated in Section 2.8 of [RFC4306], a "difference between IKEv1 1225 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, 1226 each end of the SA is responsible for enforcing its own lifetime 1227 policy on the SA and rekeying the SA when necessary. If the two ends 1228 have different lifetime policies, the end with the shorter lifetime 1229 will end up always being the one to request the rekeying". Again, in 1230 the context of MIPv6, it is expected that the MN will be the 1231 initiator that will perform the rekeying (i.e. having the shortest 1232 lifetime). 1234 In both cases, independently of the specific details of rekeying 1235 process, new SA will be put in place with new SPI values. When this 1236 event occurs on one side, IRO implementation will get _live_ 1237 information regarding the installation of new SAs by receiving PF_KEY 1238 SADB_ADD messages. It will be followed after some time by the 1239 reception of PF_KEY SADB_EXPIRE messages indicating the expiration of 1240 a "hard lifetime" for old SAs. 1242 From IRO's perspective, IPsec SA rekeying process is only seen 1243 through the reception of specific PF_KEY messages for which 1244 associated actions have previously been described. 1246 7. Extending advantages of IRO to the HA 1248 7.1. Rationale and expected advantages 1250 IRO's primary purpose is to improve security and efficiency of MIPv6 1251 communications in IPsec environments. Because most of them are 1252 expected to occur directly between peers, IRO is oriented towards 1253 MN-CN and MN-MN flows. 1255 But the flows between a MN and its HA can also benefit from the 1256 improvements: using the SPI information available on both sides to 1257 perform the remapping of incoming and outgoing IPsec traffic, the 1258 need of RH2 and HAO extensions between the MN and its HA simply 1259 disappears. This provides anonymity (See Appendix J) of the MN on a 1260 foreign link by hiding its HoA to eavesdropper on the path (if IKE 1261 does not leak that information). It also makes the MN fully capable 1262 in networks were only IPsec is allowed to flow (500/udp is required 1263 for the initial negotiation of SA and infrequently for rekeying). 1265 7.2. Changes to HA processing 1267 IRO does not mandates a detection mechanism (Appendix I) and 1268 transparently reuses most of [RFC3775]-defined messages. For that 1269 reason, MN and HA must be explicitly configured to use IRO. 1271 The changes to HA processing for the peer, required by the use of 1272 IRO, are simply the use of remapping rules instead of HAO and RH2 1273 extensions. 1275 With IRO, the relationship between a MN and one of its CN is 1276 basically the same as the relationship between the MN and its HA, 1277 with the following simple differences: 1279 o HA and MN never exchange AOT* messages as the MN is always trusted 1280 regarding the CoA information it provides in its BU. 1281 o HA and MN have a larger set of possible messages they can 1282 exchange. Remapping rules should be able to handle that. 1283 o Chances are high that an IPsec tunnel be used for protecting 1284 traffic relayed through the HA. Remapping rules do not interfere 1285 with that as the associated SA is not tracked. This is due to the 1286 fact that the SA references the CoA of the MN as the source (on- 1287 wire) address of the communication and not the HoA. 1289 7.3. Changes to MN processing 1291 The changes to MN processing for IRO to be used with its HA are quite 1292 comparable to the one previously described for the MN, i.e. they are 1293 naturally deduced from the basic requirement that RH2 and HAO must be 1294 replaced by the use of remapping rules. 1296 8. Security Considerations 1298 8.1. Proof of address ownership 1300 8.1.1. Position of the problem 1302 As a CN, registering a binding between a CoA and a HoA is not 1303 something harmless. This can be seen as a modification of local 1304 routing table, like an order from a peer to direct traffic to a 1305 specific address. For that reason, the CN needs some proof regarding 1306 this binding. In MIPv6, RRP has been designed with the hypothesis 1307 that there is no initial trust relationship between a MN and its CN. 1308 The solution to provide confidence to the CN in the HoA and CoA 1309 binding has consisted in showing the ability for the MN to send _and_ 1310 receive traffic both at the HoA and CoA. 1312 With IRO, there is an initial trust relationship between a MN and the 1313 CN it will contact. This is expected to take the form of 1314 cryptographic credentials (X.509 certificates, ...) that will allow 1315 an IKE negotiation to occur to setup SAs to protect the binding. 1317 Static keying case is covered in Appendix G. Those SA only 1318 references the HoA of the MN and not at all its CoA. 1320 The point here is that the existence of SAs does not directly provide 1321 to the CN any _live_ proof of address ownership as it occurs with 1322 RRP. 1324 Furthermore, as summarized in section 6.2 of [RFC4866] paragraph 4, 1325 the trust relationship between a HA and its MN is very different from 1326 the one between a MN and a CN, even if both use IPsec/IKE to 1327 authenticate. 1329 8.1.2. Home Address ownership 1331 The proof of HoA ownership to the CN is one of the reason behind the 1332 design decision to have MN and CN perform the IKE negotiation via the 1333 tunnel to the HA (i.e. using the HoA). That way, the existence of 1334 the SAs gets bound to a successful initial exchange between the CN 1335 and the MN. This proves to the CN the ability for the MN to send/ 1336 receive traffic from/at that address. 1338 Nonetheless, as IKE basically allows negotiation to be performed from 1339 a different address than the one the SA contain ([MIGRATE] has such 1340 an use), this behavior MUST be prevented on the CN for the purpose of 1341 negotiations of the initial SAs that will protect MH traffic for 1342 IRO's binding between the MN and the CN. 1344 While MN and CN are able to perform an IKE exchange between them 1345 using a set of credentials, there are many possible reasons for which 1346 those credentials might in fact be invalid at the time the 1347 negotiation occur. This might for instance be the case if the CN has 1348 not up to date revocation information. This can also result from the 1349 use by the MN of a different set of credentials for the purpose of 1350 protecting its HA registration and the registration with its CN. 1352 Mandating the IKE negotiation to be routed through the tunnel to the 1353 HA provides the proof that the MN is still granted ownership of the 1354 address by the network it belongs to at the time of negotiation. It 1355 should be noted that the proof of HoA ownership occurs at SA setup 1356 time and remains valid till the SA is rekeyed, i.e. each rekeying 1357 providing a new live proof. This specification does not mandates 1358 regular check of HoA ownership between rekeying. Appendix C provides 1359 arguments on that topic. 1361 The case of static keying is covered in Appendix G. 1363 8.1.3. Care-of Address ownership 1365 The proof of CoA ownership by the CN is an especially important point 1366 in the security of large scale deployments of IRO. As stated in the 1367 introduction of this section, the acceptance of a binding by a CN for 1368 a CoA is a local modification of local routing table to send current 1369 and future traffic to that address when it is destined to the HoA. 1371 The proof by the MN that it is able to both send and receive traffic 1372 at this address is a primary concern in the security of the protocol. 1373 Appendix A covers the reasons why the only ability to send is an 1374 insufficient proof of CoA ownership, even in the context of IRO. 1376 8.2. Remapping (comparison with explicit HAO/RH2 inclusion) 1378 For every remapping, the practical impact is the same as the explicit 1379 one resulting from the inclusion of a RH2 or HAO. 1381 8.3. Anonymity 1383 At the moment, this section is empty. See Appendix J. 1385 8.4. Limiting attack surface 1387 IRO can provide the ability to have port 500/udp open for remote 1388 negotiations on the HoA for the purpose of the inbound contacts and 1389 not on the CoA. CoA is only used for the discussion between the MN 1390 and its HoA, which allow to put some specific firewalling rules in 1391 place for that purpose. 1393 9. IANA Considerations 1395 The values for following mobility header messages MUST be assigned by 1396 IANA: 1398 o Address Ownership Test Offer message (AOTO, see Section 4.4.1) 1399 o Address Ownership Test Challenge message (AOTC, see Section 4.4.2) 1400 o Address Ownership Test Response message (AOTR, see Section 4.4.3) 1401 o Address Ownership Test Status message (AOTS, see Section 4.4.4) 1403 The values for following mobility option MUST be assigned by IANA: 1405 o Nonce Option (see Section 4.3.1) 1407 Appendix A. Ability to send does not prove CoA ownership 1409 With IRO, negotiation of the protection for the registration traffic 1410 between the peers is done using the tunnel to the Home Agent (i.e. 1411 the HoA). Then, the protected Binding Update message is emitted by 1412 the MN. It locally uses the HoA but a remapping process makes the 1413 CoA the address appearing on the wire for this packet. When the CN 1414 receives that packet, the address is remapped to the HoA of the MN by 1415 the MIPv6 stack. The remapped address appearing as source of the 1416 packet is passed as ancillary data to the MIPv6 process where a check 1417 will be performed during parsing against the content of the required 1418 Alternate Care-of Address option. 1420 This process proves the CN that the MN is able to _send_ traffic 1421 using the CoA. 1423 Then, IRO requires additional steps for the MN to prove its ability 1424 to receive traffic at that address. This appendix covers the threats 1425 prevented by the addition of this proof of reception capability in 1426 IRO. 1428 The trust model between the MN and its HA is based on the existence 1429 of the IPsec protection between the two. The only requirement for 1430 the update of the tunnel endpoint when a movement occur is the 1431 reception by the HA of a protected Binding Update message containing 1432 the new CoA in the Alternate CoA option. The use of the new CoA as 1433 source of the packet is not even mandatory. 1435 One would argue that the same kind of trust relationship exists 1436 between the MN and its CN as they already have an established trust 1437 relationship, materialized by the pair of SA protecting MH traffic. 1438 Nonetheless there are many difference between the two situations. 1440 The first and main one is that all the traffic emitted by the HA to 1441 the CoA provided by the MN has a traceable source: the address of the 1442 HA, which belongs to the home network. It allows to track the source 1443 of the traffic emitted to the CoA back to the Home Network. In the 1444 context of the flow from the CN to the MN, the source address might 1445 possibly be that of a foreign network (if the CN is also acting as a 1446 MN) and the destination is the one that would be provided by the MN. 1448 Now consider the following, still in the context of a proof of 1449 address ownership based solely on the ability of the MN to emit 1450 traffic from the CoA. A MN has been compromised by an attacker that 1451 has the ability to emit traffic with the address of a target (no 1452 ingress-filtering by its provider). The attacker would now be able 1453 to mount connections with the HA and then, using IRO, with all the 1454 peers that trust the MN. At the moment, it still uses some valid 1455 address where it can emit/receive traffic from/to. After having some 1456 traffic intensive connection running with a peer, it simply warns the 1457 peer of a change of CoA by advertising the address of the target. As 1458 the CN does not require a proof of reception capability, all the 1459 IPsec traffic gets redirected to the target. This might not be a 1460 problem with a single peer and some connected protocol but it is 1461 expected that the protocol be used in vast trust domains where the 1462 number of peer is not directly limited. 1464 In the end, requiring that the proof of CoA ownership includes a 1465 proof of reception capability by the MN at the CoA prevents that 1466 compromise of a MN by an attacker provides her with a potentially 1467 unlimited number of anonymous and unwilling "bots" to DoS a target 1468 other than herself. 1470 In the design of IRO, to maintain the efficiency of the protocol in 1471 term of latency associated with movement, the proof of reception 1472 capability is not required to occur before the CN can emit traffic to 1473 the CoA. 1475 Appendix B. IKE exchanges use the HoA and the tunnel to the HA 1477 Remainder: in this appendix, we still consider that the data tunnel 1478 between the HA and the MN is IPsec protected. Some security 1479 arguments in this appendix should be modulated if this hypothesis is 1480 known to be invalid. 1482 We provide here some arguments regarding the use of the HoA for 1483 performing the IKE exchanges with the peers, using the tunnel through 1484 the HA. 1486 The first simple rule which always applies with IRO is that no 1487 connection happens directly if it is not IPsec-protected. No 1488 difference is made for IKE exchanges even if those flows have 1489 intrinsic protection mechanisms. 1491 The need for performing IRO to get direct routing between the peers 1492 is motivated by the net performance impact in terms of bandwidth, 1493 delay and jitter by avoiding triangular routing and the bottleneck of 1494 HA. This is of interest for specific flows like VoIP, direct file 1495 exchanges, ... but are mainly useless for infrequent flows like IKE 1496 negotiations. When a MN performs IKE negotiation with a peer, having 1497 IKE_SA (or ISAKMP SA for IKEv1) set up is only a matter of few 1498 packets (IKEv1 Main mode exchange uses six). Then, all next CHILD_SA 1499 (or IPsec SA for IKEv1) will reuse the same IKE_SA and generally 1500 complete after a three packet exchange. As rekeying is supposed to 1501 occur extremely infrequently and does not need the advantage of 1502 direct routing, this is unneeded. The argument regarding the loss 1503 associated by the routing through the tunnel gets the same answer: 1504 the impact is very limited given the amount of traffic. Furthermore, 1505 when certificates are used, IKE packets already get fragmented even 1506 with a full 1500 bytes PMTU. 1508 In fact, the advantage of using the HoA and the IPsec tunnel to the 1509 HA for performing IKE negotiation with peers is the stability 1510 guaranteed by the migration process when movement occurs. MIPv6 1511 simply makes things transparent for all IKE daemon connections from 1512 the HoA. 1514 To conclude and after all previous functional arguments, there are 1515 also some security advantages in performing IKE negotiations with 1516 peers using the protected IPsec tunnel to the HA. 1518 The most important one is anonymity. A positive side effect of 1519 having the negotiation performed through the IPsec tunnel to the HA 1520 (ESP with meaningful encryption is assumed) is that it hides 1521 everything to people in MN's network. IKE traffic is only accessible 1522 on the path between the HA and the peer. In fact, in the MN-MN 1523 situation eavesdroppers on both foreign networks are unable to get 1524 the HoA of the peer on the other network. It requires being on the 1525 path between the two HA. The same is also true for the identity 1526 information that might appear during the IKE negotiation depending on 1527 the modes peers use. 1529 Another security advantage with that policy is that a peer is able to 1530 statefully filter 500/udp traffic received on its CoA and allow only 1531 outbound initiated connections addressed to the HoA. This policy 1532 simply allows reducing the network attack surface of the node in the 1533 foreign network. 1535 Appendix C. Arguments for no regular check of HoA ownership 1537 As presented in Section 8.1.2, when dynamic keying is used, the 1538 initial IKE negotiation protecting the registration traffic between 1539 the MN and the CN provides to the CN the proof of HoA ownership by 1540 the MN. This proof remains valid till this SA is rekeyed. This is 1541 also true for further SA negotiated between the MN and the CN. 1543 The initial proof of HoA ownership is easily obtained as it results 1544 from a positive information: packets exchanged with the MN at this 1545 address. Note that the inability for the MN or the CN to get traffic 1546 routed to the HA at that moment results in the inability to get 1547 direct connectivity as the IKE negotiation cannot be performed. In 1548 the same fashion, after the initial proof, there is no defined way to 1549 track a loss of HoA ownership through a positive event: the CN is 1550 simply not warned that the MN has been removed ownership of its HoA 1551 by its home network (resulting from a compromise, change of network 1552 prefix, ...). Discovery of a loss of HoA ownership cannot be tracked 1553 by a negative event either, such as the inability to exchange traffic 1554 with the MN at a specific moment. In fact, a crash of the HA, the 1555 loss of connectivity between the MN and its HA, or between the CN and 1556 the HA are to be expected. In that context, such a mechanism would 1557 simply amplify the existence of points of failure or allow DoS to 1558 occur. Avoiding that provides resilience and allow direct 1559 communications to survive previous failure conditions related to the 1560 HA. 1562 Another reason to prevent regular proof of HoA ownership is the use 1563 of the HoA in IRO. It acts as a local identifier on both peers. It 1564 allows the MN to acquire movement independence and can be seen as a 1565 convenience in the relationship between the peers, to find themselves 1566 initially, no matter where they are located. With IRO, the HoA never 1567 appears anymore in packet exchanged directly between the peers (due 1568 to removal of HAO and RH2). It is only understood locally in the 1569 context of ongoing IPsec communications between the peers. 1571 The last argument for not including this requirement (capability is 1572 provided, see Section 4.5.3) in the protocol is that different CN or 1573 MN might have different more efficient methods for performing that 1574 tracking. For instance, inside a home network, instead of using a 1575 constant regular polling by all MNs, an administrator revoking the 1576 credentials of a MN will easily be able to request all MNs to update 1577 their revocation information, before shutting down communications 1578 with associated MN (i.e. replacing polling by push). 1580 In the context of IRO, no mechanism to perform regular checks of HoA 1581 ownership is included. This capability is outside the scope of this 1582 specification. 1584 Appendix D. Lack of encryption between MN and HA 1586 In this specification, the use of IPsec tunnel protection of data 1587 traffic is expected. Note that section 5.5 of [RFC3775] only 1588 specifies that: 1590 For traffic tunneled via the home agent, additional IPsec ESP 1591 encapsulation MAY be supported and used. If multicast group 1592 membership control protocols or stateful address 1593 autoconfiguration protocols are supported, payload data 1594 protection MUST be supported. 1596 The logic behind previous expectation is associated with the 1597 availability of credentials between the MN and HA, and also the kind 1598 of environment in which it will get deployed. 1600 However, the lack of IPsec protection of tunneled data does not 1601 prevent IRO; it only removes some security advantages of this 1602 protection. This loss is covered in this appendix. 1604 When negotiating IRO, the MN uses the tunnel to its HA for routing 1605 IKE negotiation with the peer. As IKE is designed for robustness, 1606 the advantage of the privacy when IPsec is used for protecting the 1607 data tunnel (i.e. non NULL encryption) is the insurance that the 1608 address of the peer or its cryptographic credentials are not 1609 disclosed on MN's network. Note that MN's HoA and associated 1610 identity are expected to be disclosed to eavesdroppers during 1611 registration of the MN to its HA (if IRO is not extended to HA-MN 1612 exchanges). 1614 As a conclusion, removing the hypothesis of privacy for data tunneled 1615 to the HA removes the anonymity provided to peer's identity (HoA or 1616 CoA, and possibly cryptographic identity appearing during IKE 1617 exchange). 1619 Appendix E. What if I don't need protection? 1621 IRO mandates the use of IPsec for all direct communications between 1622 MIPv6 peers. As IPsec is only a framework, the level of protection 1623 might vary, along with the additional requirements, environments and 1624 capabilities of end devices. 1626 There will certainly be some very specific and limited cases where 1627 people will see a need in downgrading the security for performance or 1628 other reasons. To be fair, except in some very specific conditions, 1629 achieving performance while still keeping security is possible. For 1630 instance, if authentication is a real requirement but privacy is not 1631 (but it is still activated by default), and CPU limits the 1632 throughput, keeping only authentication services of IPsec as provided 1633 by ESP with NULL encryption or by AH will clearly boost performance. 1635 Now, if there is a desperate need to suppress security services 1636 between MIPv6 peers for some reason, the best thing is to use another 1637 route optimization like common RO as specified in [RFC3775], instead 1638 of trying to circumvent them. 1640 For those with some imagination, who still think the author is wrong 1641 and think about simply negotiating NULL authentication and NULL 1642 encryption, next paragraph might be worth reading. 1644 [RFC4835] defines mandatory-to-implement cryptographic algorithms for 1645 use with ESP (and AH). NULL encryption algorithm and NULL 1646 authentication algorithm must both be implemented. In section 3.2 of 1647 [RFC4303], some requirements are specified on those algorithms, 1648 preventing their simultaneous uses: 1650 Note that although both confidentiality and integrity are 1651 optional, at least one of these services MUST be selected, hence 1652 both algorithms MUST NOT be simultaneously NULL. 1654 Appendix F. MTU Gains 1656 Standard RO is based on the use of RH2 and HAO to explicitly carry 1657 the HoA of the MN, respectively as real destination or final source 1658 of the packet sent directly between the nodes: 1660 o From MN to CN: HAO 1661 o From CN to MN: RH2 1662 o From MN to MN: HAO and RH2, simultaneously. 1664 The inclusion of these explicit containers generates a loss of MTU. 1665 In common case, where no other specific extensions or options are 1666 used (to remove padding considerations), HAO and RH2 each consume 24 1667 bytes. 1669 The loss of MTU associated with those MIPv6 extension for direct 1670 MN-CN communications is 24 bytes. For direct MN-MN communications, 1671 it is 48 bytes. As an initial comparison, unprotected routing via 1672 the HA through an IPv6-in-IPv6 tunnel consumes 40 bytes. When an 1673 IPsec tunnel is used, the loss of MTU depends on the authentication 1674 and encryption algorithm, negotiation of ESN, padding requirement. 1676 As IRO has been designed to provide secure IPsec-protected direct 1677 communications between MIPv6 peers, it is difficult (and does not 1678 make that much sense) to compare the loss of MTU associated with IRO 1679 and the one of standard unprotected RO. In term of header inclusion, 1680 IRO neither use RH2 nor HAO but require AH or ESP. Depending on the 1681 size of ESP or AH header(s) and the specific type of communication 1682 (MN-MN or MN-CN), one route optimization type might consume more 1683 bandwidth than the other: 1685 o ESP in transport mode using HMAC-SHA1-96 (required in all 1686 implementation) as authentication algorithm, NULL for encryption 1687 and no ESN consumes 24 bytes (with 2 bytes of padding). Adding a 1688 meaningful encryption algorithm will make that higher. 1690 o AH in transport mode also using HMAC-SHA1-96 and no ESN will give 1691 a similar value. 1693 To make things simple, using IRO with some ESP with NULL encryption 1694 or with AH for MN-CN communications provides similar MTU loss as 1695 standard RO. Having a meaningful encryption algorithm (expected) 1696 with ESP give a little advantage to standard RO regarding MTU loss. 1698 When considering MN-MN, IRO will clearly consumes less bandwidth than 1699 standard RO in all possible combinations of algorithms for AH or ESP. 1701 Now, considering the same level of protection, i.e. by using IPsec 1702 for standard RO carried packets (we do not take into account padding 1703 variations), IRO simply gets a direct advantage: 24 bytes for MN-CN 1704 communications and 48 bytes for MN-MN communications. It is due to 1705 the complete removal of HAO and RH2 from packets exchanged directly 1706 between peers. 1708 In fact, regarding MTU considerations, IRO provides a zero cost 1709 mobility service to IPsec protected connections between end nodes. 1711 Appendix G. Compatibility with static keying 1713 IRO has been designed for enabling direct secure communications 1714 between MIPv6 entities belonging to a common trust domain. 1715 Scalability was a primary concern; This is the reason why the 1716 specification covers SA negotiation under the hypothesis that IKE is 1717 used for that purpose. But IRO is also fully compatible with static 1718 keying. 1720 In fact, the specification is not specifically bound to the use of 1721 either static or dynamic keying for SA setup; it is left as a local 1722 configuration decision to domain administrators. 1724 This appendix quickly covers the differences regarding the use of 1725 static keying with IRO. 1727 One great difference between static and dynamic keying is the removal 1728 of the IKE negotiation. For IRO, the first negotiation performed 1729 with the peer provides an additional information to the CN: a live 1730 proof of address (HoA) ownership by the MN. The removal of this step 1731 also removes the live check. This is a fact administrators should be 1732 aware of. 1734 The question of rekeying is of primary interest for the maintenance 1735 of SPI information on MN and CN that use IRO. This changes somehow 1736 with static keying as the rekeying is done ... by the user. Even if 1737 it is expected to happen less often, tracking of SA removal and 1738 addition, along with their associated SPI is still required. It is 1739 expected that the same mechanism (PF_KEY is one of them) used for 1740 tracking addition and deletion of SA by IKE be used for that purpose. 1742 There should be no specific reason preventing the simultaneous use of 1743 static and dynamic keying with IRO. 1745 Appendix H. Compatibility with the use of CoA in SP/SA 1747 SP and SA are not changed at any moment by MIPv6 stack when IRO is 1748 used. Only incoming and outgoing IPsec packets can undergo source or 1749 destination address modifications, mainly based on SPI information. 1751 When using IRO, MIPv6 stack tracks SA addition and deletion looking 1752 for local HoA or IRO peers' HoAs (MN) as source or destination 1753 addresses of those SA (endpoints for tunnel mode SA). Associated SPI 1754 are used for tracking IPsec packets. 1756 Outgoing IPsec packets are only possibly modified to change the HoA 1757 into the CoA. CoA of outgoing IPsec packets are never modified by 1758 MIPv6 stack, when IRO is used. 1760 Incoming IPsec packets will have their source modified (from CoA to 1761 peer's MN HoA) iif the SPI is the one of a tracked SA that expect the 1762 HoA of an IRO peer. This implies that no incoming packet with a CoA 1763 source will be modified if the SA associated with its SPI references 1764 that CoA (and not peer's HoA). Regarding destination address of an 1765 incoming IPsec packet, remapping of a CoA will occur if the SA 1766 associated with the SPI expects an HoA. This implies that no 1767 incoming packet with a CoA destination will be modified if the rules 1768 associated with its SPI references that CoA (and not our HoA). 1770 As a conclusion, the work of IRO is compatible with the use of CoA as 1771 destination or source address (endpoint addresses for tunnel mode) of 1772 any SP/SA. 1774 Appendix I. Rationale for not specifying a new BU 1776 IRO is not designed as a fallback mode for IPsec communications 1777 between MIPv6 entities but as an improved alternative. 1779 You cannot use IRO and common mode with the same peer. You either 1780 need the security advantages of IRO for communications with a peer or 1781 you can afford unprotected direct communications with it, for which 1782 common RO has been developed. Parallel uses of common mode and IRO 1783 mode with different MIPv6 entities (including its HA) is not 1784 forbidden but strongly discouraged as it suppresses the anonymity of 1785 the MN on its foreign link. 1787 For that reasons, IRO does not come with some detection algorithm 1788 against peers that do not have IRO activated to perform a fallback to 1789 common mode. Considering the setup associated with the protection 1790 mechanisms required by IRO and the kind of environments it is 1791 expected to be used in, requiring that entities be configured to 1792 specifically use IRO for a peer (or by default, preventing the common 1793 mode) is required. 1795 This has many positive impacts both on development costs, deployment 1796 and debugging. This notably provides the ability to reuse messages 1797 without creating parallels versions where needed. As only a few 1798 things changes when IRO is activated between two entities, most of 1799 the code remains usable. In fact, the two mains changes introduced 1800 by IRO are: 1802 o the removal of HAO/RH2 and the replacement by the remapping 1803 process on selected IPsec traffic. 1804 o a simplified registration procedure with CN (AOT* framework) 1806 Let's go a little further. One can think that it would have been 1807 possible to create specific mobility options to discriminate IRO mode 1808 from the common mode. This was impossible for multiple reason. 1809 First, from a specification perspective, section 6.1.7 of [RFC3775] 1810 requires that "The receiver MUST ignore and skip any options which it 1811 does not understand", which prevents the reuse of MIPv6 messages with 1812 a slightly modified semantic if peers are not aware of that. For 1813 options to have an interest, you have to be aware that the peer 1814 support it (not necessarily that it is activated). 1816 Anyway, there is a better reason that makes the use of common mode 1817 and IRO mode incompatible between peers: IRO remapping process must 1818 be activated on the receiver for the packets to be valid. If a MN 1819 that uses IRO sends an IPsec protected Binding Update message to a 1820 peer that is not using IRO, no remapping will occur and the checksum 1821 will end up being invalid (if it passes the IPsec stack). Section 1822 9.2 of [RFC3775] requires the following rule to be applied to such 1823 packet: "The checksum must be verified as per Section 6.1. 1824 Otherwise, the node MUST silently discard the message". 1826 Appendix J. Anonymity 1828 There are mainly 2 kinds of identifiers that can appear during an 1829 IPsec protected communication in IKE/MIPv6 environments: addresses 1830 (HoA, CoA, CN addresses) and cryptographic identifiers (IKE 1831 credentials, i.e. X.509 certificates). 1833 In MN-CN communications, the addresses of the CN and the CoA of the 1834 MN will obviously be disclosed, but they should not be meaningful. 1835 We see later that in MN-MN case, the address of the CN that appears 1836 on the wire might temporarily be the HoA, before registration has 1837 been performed by the second MN. 1839 In MIPv6, the use of explicit containers (HAO and RH2) makes the Home 1840 Address of the MN available in all cases. With IRO, the complete 1841 removal of this extensions prevents the disclosure of the HoA during 1842 direct MN-CN communications and MN-HA communications. 1844 The removal applies to: 1846 o the IPsec protected signaling traffic exchanged directly between 1847 the two peers (BU/BA for instance) 1848 o the IPsec protected data traffic exchanged in MN-MN and MN-CN 1849 cases (when tunnel mode is not already used to avoid RH2/HAO). 1851 From the perspective of an eavesdropper on the FL of the MN, when IRO 1852 is used the visible exchanges that occur are (in order, for MN-MN 1853 case, with registrations performed on that link, i.e. worst case 1854 scenario): 1856 o IKE negotiation between the CoA of the MN and its HA 1857 o IPsec protected BU/BA exchanges using CoA and HA@ as on-wire 1858 addresses (remapping rules applied on both ends) 1859 o IPsec protected (tunnel mode this time) traffic with peers 1860 o IKE exchange from the HoA, IPsec tunneled to the HA, with a CN 1861 o Direct IPsec-protected BU/BA exchanges using the CoA and the 1862 address of the the CN for on-wire addresses. 1863 o Direct IPsec-protected data traffic exchange with the CN, between 1864 the CoA and the address of the CN. 1866 In all those exchanges, the only addresses that are disclosed to an 1867 eavesdropper on the FL of the MN (if ESP with a meaningful encryption 1868 is used for all IPsec exchanges) are the CoA, the address of MN's HA 1869 and the address of the CN. The HoA of the MN never appears in those 1870 exchanges. 1872 For IKE case, even if it is used as an ID in Phase 2 for 1873 bootstrapping as described in [MIGRATE], the exchanges are encrypted 1874 and the HoA does not appear. For the negotiation with the CN, 1875 because the HoA is used for the exchanges, the IPsec tunnel to the HA 1876 protects traffic to/from the Home Network. 1878 Regarding cryptographic identifiers, the certificate of the MN is not 1879 expected to appear on the wire. In all cases, the only information 1880 one can get are associated with the MN's Home Network (HA address and 1881 possibly certificate), but nothing more specific should be disclosed. 1883 Now, considering the specific case of MN-MN communications, on the 1884 network of the initiating MN1 (the first to register with its peer), 1885 after the IKE negotiation as been performed relayed by both Home 1886 Agents, the IPsec protected Binding Update packets is emitted with 1887 the HoA of MN2 as destination (the address of the CN in previous list 1888 is the HoA of MN2). Let's consider associated SPI is 42. The packet 1889 is sent directly with the CoA of MN1 on the wire and is routed to the 1890 Home Network of the peer, before it is tunneled to it. The BA 1891 follows a reverse path but with a different SPI (say 43). After the 1892 second registration is over, the MH traffic using those SPI values 1893 (42 and 43) flows directly (remapping rules are now in place on both 1894 ends). From an eavesdropper perspective on the FL of MN1, this 1895 provides "a clue" about the association between the HoA and the CoA 1896 of the second MN2. This is introduced in [RFC4882]. 1898 Note that this is the only "leaking" that happens and only on the FL 1899 of the first MN. It is no more the case on FL that are visited 1900 later. Anyway, from the perspective of an eavesdropper monitoring 1901 that, the information will be that a Mobile Node from a known Home 1902 Network (HA@) has performed IPsec communications with a MN having a 1903 known HoA (no credentials). 1905 10. References 1907 10.1. Normative References 1909 [RFC2119] Bradner, S., ""Key Words for Use in RFCs to Indicate 1910 Requirement Levels"", RFC 2119, March 1997. 1912 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1913 Management API, Version 2", RFC 2367, July 1998. 1915 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1916 (IKE)", RFC 2409, November 1998. 1918 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1919 in IPv6", RFC 3775, June 2004. 1921 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1922 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1923 Home Agents", RFC 3776, June 2004. 1925 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1926 Internet Protocol", RFC 4301, December 2005. 1928 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1929 RFC 4303, December 2005. 1931 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1932 RFC 4306, December 2005. 1934 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 1935 Requirements for Encapsulating Security Payload (ESP) and 1936 Authentication Header (AH)", RFC 4835, April 2007. 1938 [RFC4877] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the 1939 Revised IPsec Architecture", RFC 4877, April 2007. 1941 10.2. Informative References 1943 [CNIPsec] Dupont, F. and JM. Combes, "Using IPsec between Mobile and 1944 Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-08 1945 (work in progress), August 2008. 1947 [MIGRATE] Ebalard, A. and S. Decugis, "PF_KEY Extension as an 1948 Interface between Mobile IPv6 and IPsec/IKE", 1949 draft-ebalard-mext-pfkey-enhanced-migrate-00 (work in 1950 progress), August 2008. 1952 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1953 Nordmark, "Mobile IP Version 6 Route Optimization Security 1954 Design Background", RFC 4225, December 2005. 1956 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 1957 Using a Static Shared Key", RFC 4449, June 2006. 1959 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 1960 IPv6 and Firewalls: Problem Statement", RFC 4487, 1961 May 2006. 1963 [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of 1964 Enhancements to Mobile IPv6 Route Optimization", RFC 4651, 1965 February 2007. 1967 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1968 Optimization for Mobile IPv6", RFC 4866, May 2007. 1970 [RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1971 Problem Statement", RFC 4882, May 2007. 1973 Appendix K. Acknowledgements 1975 The author acknowledge the comments and correction of Guillaume 1976 Valadon on the initial version of the document. 1978 This document was generated by xml2rfc. 1980 Author's Address 1982 Arnaud Ebalard 1983 EADS Innovation Works 1984 12, rue Pasteur - BP76 1985 Suresnes 92152 1986 France 1988 Phone: +33 1 46 97 30 28 1989 Email: arnaud.ebalard@eads.net 1991 Full Copyright Statement 1993 Copyright (C) The IETF Trust (2008). 1995 This document is subject to the rights, licenses and restrictions 1996 contained in BCP 78, and except as set forth therein, the authors 1997 retain all their rights. 1999 This document and the information contained herein are provided on an 2000 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2001 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2002 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2003 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2004 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2005 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2007 Intellectual Property 2009 The IETF takes no position regarding the validity or scope of any 2010 Intellectual Property Rights or other rights that might be claimed to 2011 pertain to the implementation or use of the technology described in 2012 this document or the extent to which any license under such rights 2013 might or might not be available; nor does it represent that it has 2014 made any independent effort to identify any such rights. Information 2015 on the procedures with respect to rights in RFC documents can be 2016 found in BCP 78 and BCP 79. 2018 Copies of IPR disclosures made to the IETF Secretariat and any 2019 assurances of licenses to be made available, or the result of an 2020 attempt made to obtain a general license or permission for the use of 2021 such proprietary rights by implementers or users of this 2022 specification can be obtained from the IETF on-line IPR repository at 2023 http://www.ietf.org/ipr. 2025 The IETF invites any interested party to bring to its attention any 2026 copyrights, patents or patent applications, or other proprietary 2027 rights that may cover technology that may be required to implement 2028 this standard. Please address the information to the IETF at 2029 ietf-ipr@ietf.org.