idnits 2.17.1 draft-tschofenig-omipv6-multihoming-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2005) is 6857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-mobike-protocol' is defined on line 455, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.haddad-mip6-cga-omipv6' == Outdated reference: A later version (-02) exists of draft-haddad-privacy-omipv6-anonymity-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.haddad-privacy-omipv6-anonymity' == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-01 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-02 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-protocol-01 == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-04 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 19, 2006 W. Haddad 5 Ericsson Research 6 July 18, 2005 8 OMIPv6 Multi-Homing and Privacy 9 draft-tschofenig-omipv6-multihoming-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Optimized Mobile IPv6 with CGA (OMIPv6-CGA) protocol specifies a 43 new route optimization (RO) to solve the mobility problem. Privacy 44 extensions for OMIPv6 adds anonymity and unlinkability support to the 45 OMIPv6-CGA protocol. 47 This document combines OMIPv6-CGA including its privacy extension 48 with support for multi-homing. As such, it offers an efficient and 49 secure multi-homing and mobility support for MIPv6 using CGAs 50 including privacy support. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Strawman Protocol Proposal . . . . . . . . . . . . . . . . . 4 58 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1 Alternate Care-of Address extension . . . . . . . . . . . 5 60 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 63 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 64 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 11.1 Normative References . . . . . . . . . . . . . . . . . . 10 67 11.2 Informative References . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 69 Intellectual Property and Copyright Statements . . . . . . . 13 71 1. Introduction 73 Optimized Mobile IPv6 with CGA [I-D.haddad-mip6-cga-omipv6] protocol 74 specifies a new route optimization (RO) to solve the mobility 75 problem. Privacy extensions for OMIPv6 added anonymity and 76 unlinkability support to the OMIPv6-CGA protocol. 78 This document combines these previously mentioned documents and adds 79 multi-homing support. As such, it offers an efficient and secure 80 multi-homing and mobility support for MIPv6 using CGAs with privacy 81 support. 83 To provide multi-homing support based on [I-D.haddad-privacy-omipv6- 84 anonymity] requires to deal with the following aspects: 85 o Ability to inform the other peer about the peer address set 86 o Ability to inform the other peer about the preferred address 87 o Ability to test connectivity along a path and thereby to detect an 88 outage situation 89 o Ability to change the preferred address 90 o Ability to change the peer address set 92 Additionally, it is worth pointing out that a new care-of address 93 must be authorized prior to its usage. The procedure detailed in 94 OMIPv6 [I-D.haddad-mip6-cga-omipv6] and not repeated in this 95 document. Finally, the aspect of state indexing needs to be 96 considered. OMIPv6 selects the Binding Cache Entry (BCE) based on 97 the Home Address. The privacy extensions defined for OMIPv6 modify 98 this state selection approach and use a specially generated "Sequence 99 Value" (SQV). Since this document builds on top of the privacy 100 extensions for OMIPv6 SQV state indexing approach is reused. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 Terms, such as peer, peer address set, path or preferred address, are 109 reused from MOBIKE [I-D.ietf-mobike-design]. Terminology related to 110 OMIPv6 [I-D.haddad-mip6-cga-omipv6] and its privacy extension 111 [I-D.haddad-privacy-omipv6-anonymity] can be found in the respective 112 documents. 114 3. Assumptions 116 This document makes the following assumptions: 118 o The home agent (HA) is supporting multiple care of addresses since 119 otherwise "Dynamic Home Agent Address Discovery" extensions, as 120 proposed in[I-D.wakikawa-mobileip-multiplecoa] are needed, to 121 query HAs for their capabilities regarding this option. 122 o Implicitly selecting the preferred address by using the 123 information from IP headers is sufficient. In contrast, 124 [I-D.wakikawa-mobileip-multiplecoa] uses an explicit signaling 125 mechanism based on flag in the binding update. 126 o Extension to the "Alternate Care-of address" field in the Binding 127 Update message to the CN and the HA. [I-D.wakikawa-mobileip- 128 multiplecoa] states that registering multiple CoAs to single HA is 129 prohibited: 130 * "However, according to Section 11.5.3 of the Mobile IPv6 131 specification, a mobile node is not allowed to register 132 multiple care-of addresses bound to a single home address." 133 * Section 11.5.3 of the Mobile IPv6 RFC does not state this 134 restriction explicitly. 135 o The entire document that OMIPv6 [I-D.haddad-mip6-cga-omipv6] and 136 its privacy extension [I-D.haddad-privacy-omipv6-anonymity] is 137 used. 139 4. Strawman Protocol Proposal 141 This document requires the following protocol processing: 142 Ability to inform the other peer about the peer address set: 144 The MN indicates support for multihoming in the Binding Update 145 with the Alternate Care-of Address extension. This payload also 146 indicates the available addresses. 148 Ability to inform the other peer about the preferred address: 150 The source and the destination address of a packet directly sent 151 to the CN is the preferred address pair. 153 Ability to test connectivity: 155 Procedures for path testing need further study. This procedure 156 ensures that a currently used path stopped working. [Editor's 157 Note: Some words about congestion control for concurrent path 158 tests are needed.] 160 Ability to change the preferred address: 162 The source and the destination address of a packet directly sent 163 to the CN is the preferred address pair. As a policy the MN 164 thereby decides about the preferred address pair being used. This 165 allows the protocol to work if stateful packet filtering firewalls 166 are deployed in IPv6 networks. 168 Ability to change the peer address set: 170 The mobile node can change its peer address set at any time by 171 sending a new Binding Update with a modified list of addresses in 172 the Care-of Address payload. 174 [Editor's Note: Detailed protocol processing rules for the MN and the 175 CN will be described in a future version of the document.] 177 5. Packet Format 179 This document defines an extension for the alternate care-of address 180 extension to carry multiple care-of address values. 182 5.1 Alternate Care-of Address extension 184 This extensions is used to carry multiple care-of addresses of the 185 mobile node. Normally, the "Alternate Care-of Address" field can 186 only carry a single IPv6 address. The number of CoAs can be 187 calculated by dividing the number of bytes indicated by "Option 188 Length" with 16. The field should be inserted in any Binding Update 189 message sent by the mobile node in case a mobile node wants to convey 190 more than one care-of address. The data structure transmits all 191 care-of addresses at once and the preferred address is implicitly 192 selected by the source/destination pair of the data packet it is 193 encapsulated. For any changes, adding or deleting addresses a new 194 set of addresses will be transmitted. 196 The format of the option is defined as shown in Figure 1: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Option Type | Option Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | | 204 + + 205 . Option Data . 206 . (Set of care-off addresses) . 207 . . 208 + + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Option Type 214 . (ADDRESS_LIST) 216 Option Length 218 Length of the option. 219 (Length/16 indicates the number of stored IPv6 addresses) 221 Option Data 223 This field contains the mobile node's care-of addresses 224 it wishes to convey to Cn/HA. 226 Figure 1: Alternate Care-of Address Payload Format 228 As an alternative the extensions proposed in [I-D.wakikawa-mobileip- 229 multiplecoa] could be used. This proposal is based on serial 230 transmission of multiple CoAs and explicit signaling of preferred CoA 231 by means of a primary flag in the Binding-Update. 233 For identification and selection of registered bindings, a Binding 234 Unique Identification number (BID) is used. 236 A BID is selected by the MN for each CoA. Together with the HoA it 237 is used as a selector for Binding Cache Entries. 239 6. Example 241 This section shows a few example message flows. The first exchange 242 shows the usage of multiple CoAs as part of the OMIPv6 draft: 244 1. MN to CN (via HA): Pre Binding Update 245 2a. CN to MN (via HA): Pre Binding Acknowledgement 246 2b. CN to MN (directly): Pre Binding Test 247 3. MN to CN (directly): Binding Update + CoA set + ESN + CGA Key 248 + SIG + BAD 249 4. CN to MN (directly): Binding Acknowledgment + ESN + SKey + BAD 250 5a. CN to MN (via HA): Home Test remaining CoA (HoT) 251 5b. CN to MN (directly): Care-of Test remaining CoA (CoT) 253 The message exchanges shown in (1), (2a) and (2b) establishes the 254 binding cache for the preferred address. The preferred address is 255 chosen implicitly by learning the source address of the MN from the 256 IPv6 header. 258 Then, in step (3) the Binding Update is performed, which transmits 259 all remaining Care-of Addresses _at once_ ('CoA set' in the list) by 260 using the extended version of the "Alternate Care-of Address" object 261 defined in Section 5. 263 Later, steps (5a) and (5b) are repeated for all CoAs except the 264 preferred one. The decision when performing the address test is a 265 matter of local policy. 267 Subsequent movement will then require the following message exchange 268 to take place. 270 6. MN to CN (directly): Care-of Test Init [+ ESN + KeepFlow + BAD] 271 7. CN to MN (directly): Care-of Test 272 8. MN to CN (directly): Binding Update + new CoA set + 273 + NI + ESN + BAD 274 9. CN to MN (directly): Binding Acknowledgment + ESN + BAD 275 10a.CN to MN (via HA): Home Test remaining CoA (HoT) 276 10b.CN to MN (directly): Care-of Test remaining CoA (CoT) 278 Like in the initial case, the new preferred address will first be 279 checked for return routability with steps (6) and (7). The Binding 280 Update (8), may then contain an updated set of Care-of Addresses, 281 which will again be acknowledged by a Binding Acknowledgment message 282 (9). 284 Finally, the remaining CoAs of the CoA set are checked for return 285 routablity, which is done by messages (10a) and (10b). 287 Graphically, the exchange between the involved parties can be shown 288 as follows: 290 Mobile node Home agent Correspondent Node 291 | Pre Binding Update | | 292 |------------------------->|------------------------->| 293 | | Pre Binding Ack. | 294 |<-------------------------|<-------------------------| 295 | Pre Binding Test | 296 |<----------------------------------------------------| 297 | Binding Update + Care-of address set | 298 |---------------------------------------------------->| 299 | Binding Acknowledgement (optional) | 300 |<----------------------------------------------------| 301 . . 302 . . 303 . . 304 | Return routability tests remaining CoAs | 305 |<----------------------------------------------------| 306 | | | 307 |<-------------------------|--------------------------| 308 . . 309 . . 310 . . 311 | Care-of Test Init (CoTI) | 312 |---------------------------------------------------->| 313 | Care-of Test (CoT) | 314 |<----------------------------------------------------| 315 | Binding Update + new care-of address set | 316 |---------------------------------------------------->| 317 | Binding Acknowledgement (optional) | 318 |<----------------------------------------------------| 319 . . 320 . . 321 . . 322 | Return routability tests remaining CoAs | 323 |<----------------------------------------------------| 324 | | | 325 |<-------------------------|--------------------------| 326 . . 327 . . 328 . . 330 As a comparison the mechanisms proposed in [I-D.wakikawa-mobileip- 331 multiplecoa] would require the following protocol exchange to the 332 place. 334 1a. MN to CN (via HA): Home Test Init (HoTI) 335 1b. MN to CN (directly): Care-of Test Init (CoTI) 336 2a. CN to MN (via HA): Home Test (HoT) 337 2b. CN to MN (directly): Care-of Test (CoT) 338 3. MN to CN (directly): Binding Update 339 4. CN to MN (directly): Binding Acknowledgment 340 5. MN to CN (directly): Registration of remaining CoA 342 Step (5) is repeated for all CoA except the preferred one. 344 The flow shown by the list above and the figure below is an extension 345 of the one given in the Mobile IPv6 [RFC3775]. Unlike the OMIPv6 346 draft example, this message flow is based on two initial MN to CN 347 messages (1a), (1b) for performing a return routability check. After 348 receiving, the CN sends two answers back to the MN, one directly and 349 one through the HA. (2a), (2b) 351 If the return routability check has succeeded, the MN sends a Binding 352 Update message (3), which is acknowledged by an Binding 353 Acknowledgement message from the CN (4), in case the MN signaled the 354 request by setting the 'A' flag in the Binding Update. 356 The first Binding Update message also conveys the "Primary Care-of 357 Address". Furthermore, the "Primary CoA" is marked with the 'B' flag 358 to indicate that multiple CoA will be used by the MN. Afterwards, 359 the MN sends all remaining CoA serially (5) to the CN, with a 360 separate message. 362 Mobile node Home agent Correspondent Node 363 | Home Test Init (HoTI) | | 364 |------------------------->|------------------------->| 365 | Care-of Test Init (CoTI) | 366 |---------------------------------------------------->| 367 | | Home Test (HoT) | 368 |<-------------------------|<-------------------------| 369 | Care-of Test (CoT) | 370 |<----------------------------------------------------| 371 | Binding Update | 372 |---------------------------------------------------->| 373 | Binding Acknowledgement (optional) | 374 |<----------------------------------------------------| 375 . . 376 . . 377 . . 378 | Registration of remaining CoA | 379 |---------------------------------------------------->| 380 . . 381 . . 383 . . 385 7. Security Considerations 387 The security properties of the extension defined in this document are 388 based on the OMIPv6-CGA [I-D.haddad-mip6-cga-omipv6] and subsequently 389 on the security of CGAs (see [I-D.ietf-send-cga]). Privacy related 390 aspects are discussed in [I-D.haddad-momipriv-problem-statement] and 391 in [I-D.haddad-privacy-omipv6-anonymity] and applicable to this 392 document. Mobility specific threats, such as traffic redirecting and 393 hijacking, third-party flooding and blackholing, are addressed by the 394 base OMIPv6-CGA proposal. 396 8. IANA Considerations 398 This document does not require actions by IANA. 400 9. Contributors 402 We would like to thank Franz Muenz for his contributions to this 403 draft. 405 10. Open Issues 407 The aspect of multiple HoA/HAs is not addressed in this document. 408 Registration of multiple CoA will provide benefits for the MN in a 409 sending case. However, the CN will still have only one HoA it may 410 choose from. For achieving goals like load balancing in both 411 directions, i.e., spreading work load over several interfaces, a 412 correspondent node would benefit from more than one HoA. 414 Another scenario which requires a change in the HoA is the battery 415 consumption. In fact, a user may be interested for example, to 416 switch off its 802.xx backup interface, i.e., HoA1, and switch on its 417 CDMA2000 backup interface, i.e., HoA2, while keeping the RO mode 418 running on WLAN interface. Of course it will always be possible to 419 update the HA1 with the HoA2 (as a CoA). However, applying OMIPv6 420 Anonymity design in such scenario can provide flexibility to do 421 changes on both sides: the RO interface and eventually backup 422 interfaces. 424 11. References 426 11.1 Normative References 428 [I-D.haddad-mip6-cga-omipv6] 429 Haddad, W., "Applying Cryptographically Generated 430 Addresses to Optimize MIPv6 (CGA-OMIPv6)", 431 draft-haddad-mip6-cga-omipv6-04 (work in progress), 432 May 2005. 434 [I-D.haddad-privacy-omipv6-anonymity] 435 Haddad, W., "Anonymity and Unlinkability Extension for 436 CGA-OMIPv6", draft-haddad-privacy-omipv6-anonymity-00 437 (work in progress), June 2005. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", March 1997. 442 11.2 Informative References 444 [I-D.haddad-momipriv-problem-statement] 445 Haddad, W., "Privacy for Mobile and Multi-homed Nodes: 446 MoMiPriv Problem Statement", 447 draft-haddad-momipriv-problem-statement-01 (work in 448 progress), February 2005. 450 [I-D.ietf-mobike-design] 451 Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 452 protocol", draft-ietf-mobike-design-02 (work in progress), 453 February 2005. 455 [I-D.ietf-mobike-protocol] 456 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 457 (MOBIKE)", draft-ietf-mobike-protocol-01 (work in 458 progress), July 2005. 460 [I-D.ietf-send-cga] 461 Aura, T., "Cryptographically Generated Addresses (CGA)", 462 draft-ietf-send-cga-06 (work in progress), April 2004. 464 [I-D.wakikawa-mobileip-multiplecoa] 465 Wakikawa, R., "Multiple Care-of Addresses Registration", 466 draft-wakikawa-mobileip-multiplecoa-04 (work in progress), 467 June 2005. 469 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 470 in IPv6", RFC 3775, June 2004. 472 Authors' Addresses 474 Hannes Tschofenig 475 Siemens 476 Otto-Hahn-Ring 6 477 Munich, Bavaria 81739 478 Germany 480 Email: Hannes.Tschofenig@siemens.com 482 Wassim Haddad 483 Ericsson Research 484 8400, Decarie Blvd 485 Town of Mount Royal, Quebec H4P 2N2 486 Canada 488 Phone: +1 514 345 7900 (#2334) 489 Email: Wassim.Haddad@ericsson.com 491 Intellectual Property Statement 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Disclaimer of Validity 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Copyright Statement 527 Copyright (C) The Internet Society (2005). This document is subject 528 to the rights, licenses and restrictions contained in BCP 78, and 529 except as set forth therein, the authors retain all their rights. 531 Acknowledgment 533 Funding for the RFC Editor function is currently provided by the 534 Internet Society.