idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 76 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '... The nodes MAY also optionally pro...' RFC 2119 keyword, line 130: '... MUST support the formats describe...' RFC 2119 keyword, line 143: '... the home agent MUST have at least th...' RFC 2119 keyword, line 154: '...s away from home MUST have at least th...' RFC 2119 keyword, line 168: '... Updates MUST have at least the fo...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 34 has weird spacing: '...t>, and expir...' -- 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 (20 September 2002) is 7888 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) == Missing Reference: '4' is mentioned on line 1064, but not defined == Unused Reference: '3' is defined on line 1099, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-19 ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '3') (Obsoleted by RFC 4306) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Ericsson 4 Category: Standards Track Vijay Devarapalli 5 Nokia 6 Francis Dupont 7 ENST Bretagne 8 20 September 2002 10 Using IPsec to Protect Mobile IPv6 Signaling between 11 Mobile Nodes and Home Agents 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), 18 its areas, and its working groups. Note that other groups may 19 also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as work 25 in progress. 27 The list of current Internet-Drafts may be found at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories may be found at 31 http://www.ietf.org/shadow.html. 33 The distribution of this memo is unlimited. It is filed as 34 , and expires March 35 10, 2003. Please send comments to the author or to the Mobile IP 36 working group mailing list. 38 2. Abstract 40 Mobile IPv6 uses IPsec to protect signaling between the home 41 agent and the mobile node. Mobile IPv6 base document defines the 42 main requirements these nodes must follow. This draft discusses 43 these requirements in more depth, illustrates the used packet 44 formats, describes suitable configuration procedures, and shows 45 how implementations can process the packets in the right order. 47 3. Contents 49 1. Status of this Memo..................................1 50 2. Abstract.............................................1 51 3. Contents.............................................2 52 4. Introduction.........................................3 53 5. Packet Formats.......................................4 54 5.1. Binding Updates and Acknowledgements.................4 55 5.2. Return Routability Signaling.........................5 56 5.3. Prefix Discovery.....................................5 57 5.4. Payload Packets......................................5 58 6. Requirements.........................................7 59 7. Example Configurations...............................10 60 7.1. Format...............................................10 61 7.2. Manual Configuration.................................11 62 7.3. Dynamic Keying.......................................14 63 8. Processing Steps within a Node.......................17 64 8.1. Binding Update to the Home Agent.....................17 65 8.2. Binding Update from the Mobile Node..................17 66 8.3. Binding Acknowledgement to the Mobile Node...........18 67 8.4. Binding Acknowledgement from the Home Agent..........19 68 8.5. Home Test Init to the Home Agent.....................19 69 8.6. Home Test Init from the Mobile Node..................20 70 8.7. Home Test to the Mobile Node.........................20 71 8.8. Home Test from the Home Agent........................21 72 8.9. Prefix Solicitation Message to the Home Agent........21 73 8.10. Prefix Solicitation Message from the Mobile Node.....21 74 8.11. Prefix Advertisement Message to the Mobile Node......21 75 8.12. Prefix Advertisement Message from the Home Agent.....22 76 8.13. Payload Packet to the Home Agent.....................22 77 8.14. Payload Packet from the Mobile Node..................22 78 8.15. Payload Packet to the Mobile Node....................22 79 8.16. Payload Packet from the Home Agent...................22 80 9. Security Considerations..............................23 81 10. Open Issues..........................................24 82 11. References...........................................25 83 12. Acknowledgements.....................................26 84 13. Author's Address.....................................27 86 4. Introduction 88 Mobile IPv6 [1] uses IPsec [2] to protect signaling between the 89 home agent and the mobile node. This signaling consists of vari- 90 ous messages carried by the Mobility Header protocol in IPv6. 91 This signaling traffic takes the following forms: 93 (1) Binding Update and Acknowledgement messages exchanged 94 between the mobile node and the home agent, as described in 95 Sections 10.2, 10.3, 11.6.1, and 11.6.3 of [1]. 97 (2) Home Test Init and Home Test messages that pass through 98 the home agent on their way to a correspondent node, as 99 described in Section 10.7 of [1]. 101 (3) ICMPv6 messages exchanged between the mobile node and 102 the home agent for the purposes of prefix discovery, as 103 described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1]. 105 The nodes MAY also optionally protect payload traffic passing 106 through the home agent, as described in Section 5.3 of [1]. 108 Signaling between the mobile node and the home agent requires 109 message authentication, integrity, correct ordering and replay 110 protection. The mobile node and the home agent must have an 111 security association to protect this signaling. Authentication 112 Header (AH) or Encapsulating Security Payload (ESP) can be used. 114 Mobile IPv6 base document defines the main requirements the 115 mobile nodes and home agents must follow when securing the above 116 traffic. This draft discusses these requirements in more depth, 117 illustrates the used packet formats, describes suitable configu- 118 ration procedures, and shows how implementations can process the 119 packets in the right order. 121 We begin our description by showing the required wire formats for 122 the protected packets in Section 5. Section 6 describes rules 123 which associated Mobile IPv6, IPsec, and IKE implementations must 124 observe. Section 7 discusses how IPsec can be configured to use 125 either manual or automatically established security associations. 126 Section 8 shows examples of how packets are processed within the 127 nodes. 129 All implementations of Mobile IPv6 mobile node and home agent 130 MUST support the formats described in Section 5 and obey the 131 rules in Section 6. 133 5. Packet Formats 135 In this section we describe the order of headers within the pro- 136 tected and tunneled packets over the wire. Support for the 137 described ordering is mandatory for nodes that implement Mobile 138 IPv6 mobile node or home agent functionality. 140 5.1. Binding Updates and Acknowledgements 142 When the mobile node is away from its home, the BUs sent by it to 143 the home agent MUST have at least the following headers in the 144 following order: 146 IPv6 header (source = care-of address, destination = home agent) 147 Destination Options header 148 Home Address option (home address) 149 ESP header or AH header 150 Mobility header 151 Binding Update 153 The Binding Acknowledgements sent back to the mobile node when it 154 is away from home MUST have at least the following headers in the 155 following order: 157 IPv6 header (source = home agent, destination = care-of address) 158 Routing header (type 2) 159 home address 160 ESP header or AH header 161 Mobility header 162 Binding Acknowledgement 164 When the mobile node is at home, the above rules are different as 165 the mobile node can use its home address as a source address. 166 This typically happens for the de-registration Binding Update 167 when the mobile is returning home. In this situation, the Binding 168 Updates MUST have at least the following headers in the following 169 order: 171 IPv6 header (source = home address, destination = home agent) 172 ESP header or AH header 173 Mobility header 174 Binding Update 176 The Binding Acknowledgement messages sent to the home address 177 MUST have at least the following headers in the following order: 179 IPv6 header (source = home agent, destination = home address) 180 ESP header or AH header 181 Mobility header 182 Binding Acknowledgement 184 5.2. Return Routability Signaling 186 When the Home Test Init messages tunneled to the home agent are 187 protected by IPsec, they MUST have at least the following headers 188 in the following order: 190 IPv6 header (source = care-of address, destination = home agent) 191 ESP header 192 IPv6 header (source = home address, destination = correspondent node) 193 Mobility Header 194 Home Test Init 196 Similarly, when the Home Test messages tunneled from the home 197 agent are protected by IPsec, they MUST have at least the follow- 198 ing headers in the following order: 200 IPv6 header (source = home agent, destination = care-of address) 201 ESP header 202 IPv6 header (source = correspondent node, destination = home address) 203 Mobility Header 204 Home Test 206 Note that these formats rely on the SA destination address (tun- 207 nel gateway address) to change for the mobile node as it moves. 208 This is discussed further in the requirements in Section 6. 210 5.3. Prefix Discovery 212 If IPsec is used to protect prefix discovery, requests for prefix 213 from the mobile node to the home agent MUST have at least the 214 following headers in the following order. 216 IPv6 header (source = care-of address, destination = home agent) 217 Destination Options header 218 Home Address option (home address) 219 ESP header or AH header 220 ICMPv6 221 Mobile Prefix Solicitation 223 Again if IPsec is used, solicited and unsolicited prefix informa- 224 tion advertisements from the home agent to the mobile node MUST 225 have at least the following headers in the following order. 227 IPv6 header (source = home agent, destination = care-of address) 228 Routing header (type 2) 229 home address 230 ESP header or AH header 231 ICMPv6 232 Mobile Prefix Advertisement 234 5.4. Payload Packets 236 If IPsec is used to protect payload packets tunneled to the home 237 agent from the mobile node, a similar format is used as in the 238 case of tunneled Home Test Init messages. However, instead of the 239 Mobility Header these packets may contain any legal IPv6 proto- 240 col(s), and it is possible to use both AH and ESP for the protec- 241 tion: 243 IPv6 header (source = care-of address, destination = home agent) 244 ESP header or AH header 245 IPv6 header (source = home address, destination = correspondent node) 246 Any protocol 248 Similarly, when the payload packets are tunneled from the home 249 agent to the mobile node with IPsec protection, they MUST have at 250 least the following headers in the following order: 252 IPv6 header (source = home agent, destination = care-of address) 253 ESP header or AH header 254 IPv6 header (source = correspondent node, destination = home address) 255 Any protocol 257 6. Requirements 259 This section describes mandatory rules for all Mobile IPv6 mobile 260 nodes and home agents. These rules are necessary in order for it 261 to be possible to enable IPsec communications despite movements, 262 guarantee sufficient security, and to ensure correct processing 263 order of packets. 265 We will start with the main requirements: 267 - IPsec protection for Binding Updates and Acknowledgements 268 between the mobile node and home agent MUST be supported and 269 MUST be used. 271 - IPsec protection for the Home Test Init and Home Test mes- 272 sages tunneled between the mobile node and home agent MUST 273 be supported and SHOULD be used. 275 - IPsec protection for the ICMPv6 messages related to prefix 276 discovery MUST be supported and SHOULD be used. 278 - IPsec protection of the payload packets tunneled between 279 the mobile node and home agent MAY be supported and used. 281 - Manual configuration of security associations MUST be sup- 282 ported and dynamic establishment MAY be supported. 284 The following rules apply to both home agents and mobile nodes: 286 - When ESP is used for protecting ICMPv6 or Mobility Header 287 messages, a non-null authentication algorithm MUST be 288 applied. 290 - When ESP is used for protecting tunneled Home Test Init 291 and Home Test messages, a non-null encryption algorithm and 292 non-null authentication algorithm MUST be applied. 294 - If replay protection is required, dynamic keying MUST be 295 used. IPsec can easily provide replay protection only if 296 dynamic keying is used. This may not always be possible, 297 and manual keying would be preferred in some cases. IPsec 298 also does not guarantee correct ordering of packets, only 299 that they have not been replayed. Because of this, sequence 300 numbers within the Mobile IPv6 messages ensure correct 301 ordering. However, if a home agent reboots and loses its 302 state regarding the sequence numbers, replay attacks become 303 possible. The use of a key management mechanism together 304 with IPsec can be used to prevent such replay attacks. 306 - IPsec AH authenticator calculation MUST be performed as if 307 a packet with a Type 2 Routing header would have the home 308 address in the IPv6 destination address field and the care- 309 of address in the Routing header. 311 - Similarly, the authenticator calculation MUST be performed 312 as if a packet with a Home Address destination option would 313 have the home address in the IPv6 source address field and 314 the care-of address in the destination option. 316 - When a packet is matched against IPsec security policy, an 317 address appearing in a Home Address destination option MUST 318 be considered as the source address of the packet. 320 - Similarly, a home address within a Type 2 Routing header 321 MUST be considered as the destination address of the packet. 323 - When IPsec is used to protect return routability signaling 324 or payload packets, the security association from the home 325 agent to the mobile node MUST change its destination address 326 when the care-of address for the mobile node changes. At the 327 home agent, this modification takes place when a the care-of 328 address in a binding changes. At the mobile node, this modi- 329 fication takes place immediately after movement. 331 - When IPsec is used to protect return routability signaling 332 or payload packets, the security policy database entries 333 MUST be defined specifically for the tunnel interface 334 between the mobile node and the home agent. That is, the 335 policy entries are not generally applied on all traffic on 336 the physical interface(s) of the nodes, but rather only on 337 traffic that enters this tunnel. 339 The following rules apply to mobile nodes: 341 - The mobile node MUST use the Home Address destination 342 option in Binding Updates and Mobile Prefix Solicitations, 343 sent to the home agent from a care-of address. 345 - If the mobile node tunnels Home Test Init messages or pay- 346 load packets via the home agent with IPsec protection, the 347 mobile node MUST use the Home Address destination and IPsec 348 tunnel mode encapsulation. 350 Depending on whether IPsec AH or ESP is used the protection 351 offered for the Binding Updates is slightly different. AH 352 protects also the IPv6 header and any extension headers. It 353 is important for the home agent to verify that the care-of 354 address has not been tampered. If ESP is used, the IPv6 355 header where this information resides could potentially have 356 been modified by attackers on the path. As a result, the 357 attacker would have redirected the mobile node's traffic to 358 another address. In order to prevent this, Mobile IPv6 359 implementations MUST use the Alternate Care-of Address 360 mobility option when ESP is used, or when the implementation 361 does not know whether AH or ESP is used. 363 - Where dynamic keying is used, the key management protocol 364 MUST use the care-of address as the source address in the 365 protocol exchanges. 367 - Conversely, the IPsec SAs MUST be requested from the key 368 management protocol with the home address as the mobile 369 node's address. 371 The following rules apply to home agents: 373 - The home agent MUST use the Type 2 Routing header in Bind- 374 ing Acknowledgements and Mobile Prefix Advertisements sent 375 to the mobile node, again due to the need to have the home 376 address visible when the policy checks are made. 378 - If the home agent tunnels Home Test messages or payload 379 packets to the mobile node with IPsec protection, the home 380 agent MUST use the Type 2 Routing header and IPsec tunnel 381 mode encapsulation. 383 - We need to avoid the possibility that a mobile node could 384 use its security association to send a Binding Update on 385 behalf of another mobile node using the same home agent. In 386 order to do this, the security policy database entries MUST 387 unequivocally identify a single SA for any given home 388 address and home agent when manual keying is used. When 389 dynamic keying is used, the security policy database entries 390 MUST unequivocally identify the IKE phase 1 credentials 391 which can be used to create security associations for a par- 392 ticular home address. 394 7. Example Configurations 396 In the following we describe the Security Policy Database (SPD) 397 and Security Association Database (SAD) entries necessary to pro- 398 tect Binding Updates and Binding Acknowledgements exchanged 399 between the mobile node and the home agent. Our examples assume 400 the use of ESP, but a similar configuration could also be used to 401 protect the messages with AH. 403 Section 7.1 introduces the format we use in the description of 404 the SPD and the SAD. Section 7.2 describes how to configure man- 405 ually keyed security associations, and Section 7.3 describes how 406 to use dynamic keying. 408 7.1. Format 410 The format used in the examples is as follows. The SPD descrip- 411 tion has the format 413 "SPD OUT:" 414 "-" 415 "-" 416 ... 417 "-" 419 "SPD IN:" 420 "-" 421 "-" 422 ... 423 "-" 425 Where represents the name of the node, and has 426 the following format: 428 "IF" "THEN USE" | 429 "IF" "THEN CREATE" | 431 Where is an boolean expression about the fields of 432 the IPv6 packet, is the name of an SA, and is a 433 specification for an SA to be negotiated via IKE. The SAD 434 description has the format 436 "SAD:" 437 "-" 438 "-" 439 ... 440 "-" 442 Where represents the name of the node, and has 443 the following format: 445 "(" "," "," "," "," ")" ":" 446 448 Where is "IN" or "OUT", is the SPI of the SA, is the destination of the SA, is either "AH" or 450 "ESP", is either "TUNNEL" or "TRANSPORT", and 451 is a boolean expression about the fields of the IPv6 packet. 453 7.2. Manual Configuration 455 7.2.1. Binding Updates and Acknowledgements 457 Here are the contents of the SPD and SAD for protecting Binding 458 Updates and Acknowledgements in the mobile node mobile node and 459 home agent home agent: 461 mobile node SPD OUT: 462 - IF source = home address & destination = home agent & proto = MH 463 THEN USE SA1 465 mobile node SPD IN: 466 - IF source = home agent & destination = home address & proto = MH 467 THEN USE SA2 469 mobile node SAD: 470 - SA1(OUT, 5001, home agent, ESP, TRANSPORT): 471 source = home address & destination = home agent & proto = MH 472 - SA2(IN, 5002, home address, ESP, TRANSPORT): 473 source = home agent & destination = home address & proto = MH 475 home agent SPD OUT: 476 - IF source = home agent & destination = home address & proto = MH 477 THEN USE SA2 479 home agent SPD IN: 480 - IF source = home address & destination = home agent & proto = MH 481 THEN USE SA1 483 home agent SAD: 484 - SA2(OUT, 5002, home address, ESP, TRANSPORT): 485 source = home agent & destination = home address & proto = MH 486 - SA1(IN, 5001, home agent, ESP, TRANSPORT): 487 source = home address & destination = home agent & proto = MH 489 7.2.2. Return Routability Signaling 491 In the following we describe the necessary SPD and SAD entries to 492 protect return routability signaling between the mobile node and 493 the home agent. Note that the rules in the SPD are ordered, and 494 the ones in the previous section must take precedence over these 495 ones: 497 mobile node SPD OUT: 498 - IF interface = tunnel to home agent & source = home address & 499 destination = any & proto = MH 500 THEN USE SA3 502 mobile node SPD IN: 503 - IF interface = tunnel from home agent & source = any & 504 destination = home address & proto = MH 505 THEN USE SA4 507 mobile node SAD: 508 - SA3(OUT, 5003, home agent, ESP, TUNNEL): 509 source = home address & destination = any & proto = MH 510 - SA4(IN, 5004, home address, ESP, TUNNEL): 511 source = any & destination = home address & proto = MH 513 home agent SPD OUT: 514 - IF interface = tunnel to mobile node & source = any & 515 destination = home address & proto = MH 516 THEN USE SA4 518 home agent SPD IN: 519 - IF interface = tunnel from mobile node & source = home address & 520 destination = any & proto = MH 521 THEN USE SA3 523 home agent SAD: 524 - SA4(OUT, 5004, home address, ESP, TUNNEL): 525 source = any & destination = home address & proto = MH 526 - SA3(IN, 5003, home agent, ESP, TUNNEL): 527 source = home address & destination = any & proto = MH 529 7.2.3. Prefix Discovery 531 In the following we describe some additional SPD and SAD entries 532 to protect prefix discovery. (Note that when actual new prefixes 533 are discovered, there may be a need to enter new manually config- 534 ured SAs to protect Binding Updates.) 536 mobile node SPD OUT: 537 - IF source = home address & destination = home agent & proto = ICMPv6 538 THEN USE SA5 540 mobile node SPD IN: 541 - IF source = home agent & destination = home address & proto = ICMPv6 542 THEN USE SA6 544 mobile node SAD: 545 - SA5(OUT, 5005, home agent, ESP, TRANSPORT): 546 source = home address & destination = home agent & proto = ICMPv6 547 - SA6(IN, 5006, home address, ESP, TRANSPORT): 548 source = home agent & destination = home address & proto = ICMPv6 550 home agent SPD OUT: 551 - IF source = home agent & destination = home address & proto = ICMPv6 552 THEN USE SA6 554 home agent SPD IN: 555 - IF source = home address & destination = home agent & proto = ICMPv6 556 THEN USE SA5 558 home agent SAD: 559 - SA6(OUT, 5006, home address, ESP, TRANSPORT): 560 source = home agent & destination = home address & proto = ICMPv6 561 - SA5(IN, 5005, home agent, ESP, TRANSPORT): 562 source = home address & destination = home agent & proto = ICMPv6 564 7.2.4. Payload Packets 566 It is also possible to perform some additional, optional, protec- 567 tion of tunneled payload packets. This protection takes place in 568 a similar manner to the return routability protection above, but 569 requires a different value for the protocol field. The necessary 570 SPD and SAD entries are shown below. It is assumed that the 571 entries for protecting Binding Updates and Acknowledgements, and 572 the entries to protect Home Test Init and Home Test messages take 573 precedence over these entries. 575 mobile node SPD OUT: 576 - IF interface = tunnel to home agent & source = home address 577 & 578 destination = any & proto = any 579 THEN USE SA7 581 mobile node SPD IN: 582 - IF interface = tunnel from home agent & source = any & 583 destination = home address & proto = any 584 THEN USE SA8 586 mobile node SAD: 587 - SA7(OUT, 5007, home agent, ESP, TUNNEL): 588 source = home address & destination = any & proto = any 589 - SA8(IN, 5008, home address, ESP, TUNNEL): 590 source = any & destination = home address & proto = any 592 home agent SPD OUT: 593 - IF interface = tunnel to mobile node & source = any & 594 destination = home address & proto = any 595 THEN USE SA8 597 home agent SPD IN: 598 - IF interface = tunnel from mobile node & source = home 599 address & 600 destination = any & proto = any 601 THEN USE SA7 603 home agent SAD: 604 - SA8(OUT, 5008, home address, ESP, TUNNEL): 605 source = any & destination = home address & proto = any 606 - SA7(IN, 5007, home agent, ESP, TUNNEL): 607 source = home address & destination = any & proto = any 609 7.3. Dynamic Keying 611 In this section we show an example configuration that uses IKE to 612 negotiate security associations. 614 7.3.1. Binding Updates and Acknowledgements 616 Here are the contents of the SPD for protecting Binding Updates 617 and Acknowledgements: 619 mobile node SPD OUT: 620 - IF source = home address & destination = home agent & proto = MH 621 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 623 mobile node SPD IN: 624 - IF source = home agent & destination = home address & proto = MH 625 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 627 home agent SPD OUT: 628 - IF source = home agent & destination = home address & proto = MH 629 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 631 home agent SPD IN: 632 - IF source = home address & destination = home agent & proto = MH 633 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 635 (We have omitted details of the proposed transforms in the 636 above.) 638 We require IKE to be run using the care-of addresses but still 639 negotiate IPsec SAs that use home addresses. Note the extra con- 640 ditions set by the home agent SPD for the peer phase 1 identity. 641 These are needed, and must be verified by the home agent. The 642 purpose of the condition is to ensure that the IKE phase 2 nego- 643 tiation for a given user's home address can't be requested by 644 another user. 646 These checks also imply that the configuration of the home agent 647 is user-specific: every user or home address requires a specific 648 configuration entry. It would be possible to alleviate the con- 649 figuration tasks by using certificates that have home addresses 650 in the Subject AltName field. However, it isn't clear if all IKE 651 implementations allow one address to be used for carrying the IKE 652 negotiations when another address is mentioned in the used cer- 653 tificates. In any case, even this approach would have required 654 user-specific tasks in the certificate authority. 656 7.3.2. Return Routability Signaling 658 Protection for the return routability signaling can be configured 659 in a similar manner as above. 661 mobile node SPD OUT: 662 - IF interface = tunnel to home agent & 663 source = home address & destination = any & proto = MH 664 THEN CREATE ESP TUNNEL SA: gateway = home agent & 665 local phase 1 identity = user1 667 mobile node SPD IN: 668 - IF interface = tunnel from home agent & 669 source = any & destination = home address & proto = MH 670 THEN CREATE ESP TUNNEL SA: gateway = home agent & 671 local phase 1 identity = user1 673 home agent SPD OUT: 674 - IF interface = tunnel to mobile node & 675 source = any & destination = home address & proto = MH 676 THEN CREATE ESP TUNNEL SA: gateway = home address & 677 peer phase 1 identity = user1 679 home agent SPD IN: 680 - IF interface = tunnel from mobile node & 681 source = home address & destination = any & proto = MH 682 THEN CREATE ESP TUNNEL SA: gateway = home address & 683 peer phase 1 identity = user1 685 One difference to the above is that we specified the tunnel gate- 686 way address, as we need to use a different address for that than 687 those appearing in the packets. 689 Note that this specification has still the same problems as the 690 manual protection for return routability signaling had. 692 7.3.3. Prefix Discovery 694 In the following we describe some additional SPD entries to pro- 695 tect prefix discovery with IKE. (Note that when actual new pre- 696 fixes are discovered, there may be a need to enter new manually 697 configured SPD entries to specify the authorization policy for 698 the resulting new home addresses.) 700 mobile node SPD OUT: 701 - IF source = home address & destination = home agent & proto = ICMPv6 702 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 704 mobile node SPD IN: 705 - IF source = home agent & destination = home address & proto = ICMPv6 706 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 708 home agent SPD OUT: 709 - IF source = home agent & destination = home address & proto = ICMPv6 710 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 712 home agent SPD IN: 713 - IF source = home address & destination = home agent & proto = ICMPv6 714 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 716 7.3.4. Payload Packets 718 Protection for the payload packets happens similarly to the pro- 719 tection of return routability signaling. As in the manually keyed 720 case, these SPD entries have lower priority than the above ones. 722 mobile node SPD OUT: 723 - IF interface = tunnel to home agent & 724 source = home address & destination = any & proto = any 725 THEN CREATE ESP TUNNEL SA: gateway = home agent & 726 local phase 1 identity = user1 728 mobile node SPD IN: 729 - IF interface = tunnel from home agent & 730 source = any & destination = home address & proto = any 731 THEN CREATE ESP TUNNEL SA: gateway = home agent & 732 local phase 1 identity = user1 734 home agent SPD OUT: 735 - IF interface = tunnel to mobile node & 736 source = any & destination = home address & proto = any 737 THEN CREATE ESP TUNNEL SA: gateway = home address & 738 peer phase 1 identity = user1 740 home agent SPD IN: 741 - IF interface = tunnel from mobile node & 742 source = home address & destination = any & proto = any 743 THEN CREATE ESP TUNNEL SA: gateway = home address & 744 peer phase 1 identity = user1 746 8. Processing Steps within a Node 748 In this section we give examples of what processing steps node 749 can take to achieve the required packet formats and satisfy the 750 requirements. These example are for illustration purposes only, 751 and implementations are free to choose other strategies as long 752 as the results stay the same on the wire. 754 8.1. Binding Update to the Home Agent 756 Step 1. At the mobile node, Mobile IPv6 module first produces the 757 following packet 759 IPv6 header (source = home address, destination = home agent) 760 Mobility header 761 Binding Update 763 Step 2. This packet is matched against the IPsec policy data base 764 on the mobile node and we make a note that IPsec must be applied. 766 Step 3. Then, we add the necessary Mobile IPv6 options but do not 767 change the addresses yet, as described in Section 11.2.2 in [1]. 768 This results in: 770 IPv6 header (source = home address, destination = home agent) 771 Destination Options header 772 Home Address option (care-of address) 773 Mobility header 774 Binding Update 776 Step 4. Finally, IPsec headers are added and the necessary 777 authenticator values are calculated: 779 IPv6 header (source = home address, destination = home agent) 780 Destination Options header 781 Home Address option (care-of address) 782 ESP header (SPI = 5001) 783 Mobility header 784 Binding Update 786 Step 5. Before forwarding the packet, the addresses in the IPv6 787 header and the Destination Options header are changed: 789 IPv6 header (source = care-of address, destination = home agent) 790 Destination Options header 791 Home Address option (home address) 792 ESP header (SPI = 5001) 793 Mobility header 794 Binding Update 796 8.2. Binding Update from the Mobile Node 798 Step 1. The following packet is received at the home agent: 800 IPv6 header (source = care-of address, destination = home agent) 801 Destination Options header 802 Home Address option (home address) 803 ESP header (SPI = 5001) 804 Mobility header 805 Binding Update 807 Step 2. The home address option is processed first, which results 808 in 810 IPv6 header (source = home address, destination = home agent) 811 Destination Options header 812 Home Address option (care-of address) 813 ESP header (SPI = 5001) 814 Mobility header 815 Binding Update 817 Step 3. ESP header is processed next, resulting in 819 IPv6 header (source = home address, destination = home agent) 820 Destination Options header 821 Home Address option (care-of address) 822 Mobility header 823 Binding Update 825 Step 4. This packet matches the SA selectors (source = home 826 address, destination = home agent, proto = MH). 828 Step 5. Mobile IPv6 processes the Binding Update. 830 The Binding Update is delivered to the Mobile IPv6 module. 832 8.3. Binding Acknowledgement to the Mobile Node 834 Step 1. Mobile IPv6 produces the following packet: 836 IPv6 header (source = home agent, destination = home address) 837 Mobility header 838 Binding Acknowledgement 840 Step 2. This packet matches the IPsec policy entries, and we 841 remember that IPsec has to be applied. 843 Step 3. Then, we add the necessary Route Headers but do not 844 change the addresses yet, as described in Section 9.6 in [1]. 845 This results in: 846 IPv6 header (source = home agent, destination = home address) 847 Routing header (type 2) 848 care-of address 849 Mobility header 850 Binding Acknowledgement 852 Step 4. We apply IPsec: 854 IPv6 header (source = home agent, destination = home address) 855 Routing header (type 2) 856 care-of address 857 ESP header (SPI = 5002) 858 Mobility header 859 Binding Acknowledgement 861 Step 5. Finally, before sending the packet out we change the 862 addresses in the IPv6 header and the Route header: 864 IPv6 header (source = home agent, destination = care-of address) 865 Routing header (type 2) 866 home address 867 ESP header (SPI = 5002) 868 Mobility header 869 Binding Acknowledgement 871 8.4. Binding Acknowledgement from the Home Agent 873 Step 1. The following packet is received at the mobile node 875 IPv6 header (source = home agent, destination = care-of address) 876 Routing header (type 2) 877 home address 878 ESP header (SPI = 5002) 879 Mobility header 880 Binding Acknowledgement 882 Step 2. After the routing header is processed the packet becomes 884 IPv6 header (source = home agent, destination = home address) 885 Routing header (type 2) 886 care-of address 887 ESP header (SPI = 5002) 888 Mobility header 889 Binding Acknowledgement 891 Step 3. ESP header is processed next, resulting in: 893 IPv6 header (source = home agent, destination = home address) 894 Routing header (type 2) 895 care-of address 896 Mobility header 897 Binding Acknowledgement 898 Step 4. This packet matches the SA selectors (source = home 899 agent, destination = home address, proto = MH). 901 Step 5. The Binding Acknowledgement is delivered to the Mobile 902 IPv6 module. 904 8.5. Home Test Init to the Home Agent 906 Step 1. The mobile node constructs a Home Test Init message: 908 IPv6 header (source = home address, destination = correspondent node) 909 Mobility header 910 Home Test Init 912 Step 2. Mobile IPv6 determines that this packet should go to the 913 tunnel to the home agent. 915 Step 3. The packet is matched against IPsec policy entries for 916 the interface, and we find that IPsec needs to be applied. 918 Step 4. IPsec tunnel mode headers are added. Note that we use a 919 care-of address as a source address for the tunnel packet. 921 IPv6 header (source = care-of address, destination = home agent) 922 ESP header (SPI = 5003) 923 IPv6 header (source = home address, destination = correspondent node) 924 Mobility header 925 Home Test Init 927 Step 5. The packet no longer satisfies the criteria that made it 928 enter the tunnel, and it is routed directly to the home agent. 930 8.6. Home Test Init from the Mobile Node 932 Step 1. The home agent receives the following packet: 934 IPv6 header (source = care-of address, destination = home agent) 935 ESP header (SPI = 5003) 936 IPv6 header (source = home address, destination = correspondent node) 937 Mobility Header 938 Home Test Init 940 Step 2. IPsec processing is performed, resulting in: 942 IPv6 header (source = home address, destination = correspondent node) 943 Mobility Header 944 Home Test Init 946 Step 3. The resulting packet matches the selectors and the packet 947 can be processed further. 949 Step 4. The packet is then forwarded towards the correspondent 950 node. 952 8.7. Home Test to the Mobile Node 954 Step 1. The home agent receives a Home Test packet from the cor- 955 respondent node: 957 IPv6 header (source = correspondent node, destination = home address) 958 Mobility Header 959 Home Test Init 961 Step 2. The home agent determines that this packet is destined to 962 a mobile node that is away from home, and decides to tunnel it. 964 Step 3. The packet matches the IPsec policy entries for the tun- 965 nel interface, and we note that IPsec needs to be applied. 967 Step 4. IPsec is applied, resulting in a new packet. Note that 968 the home agent must keep track of the location of the mobile 969 node, and update the tunnel gateway address in the security asso- 970 ciation(s) accordingly. 972 IPv6 header (source = home agent, destination = care-of address) 973 ESP header (SPI = 5004) 974 IPv6 header (source = correspondent node, destination = home address) 975 Mobility Header 976 Home Test Init 978 Step 5. The packet no longer satisfies the criteria that made it 979 enter the tunnel, and it is routed directly to the care-of 980 address. 982 8.8. Home Test from the Home Agent 984 Step 1. The mobile node receives the following packet: 986 IPv6 header (source = home agent, destination = care-of address) 987 ESP header (SPI = 5004) 988 IPv6 header (source = correspondent node, destination = home address) 989 Mobility Header 990 Home Test Init 992 Step 2. IPsec is processed, resulting in: 994 IPv6 header (source = correspondent node, destination = home address) 995 Mobility Header 996 Home Test Init 998 Step 3. This matches the SA selectors (source = any, destination 999 = home address). 1001 Step 4. The packet is given to Mobile IPv6 processing. 1003 8.9. Prefix Solicitation Message to the Home Agent 1005 This procedure is similar to the one presented in Section 8.1. 1007 8.10. Prefix Solicitation Message from the Mobile Node 1009 This procedure is similar to the one presented in Section 8.2. 1011 8.11. Prefix Advertisement Message to the Mobile Node 1013 This procedure is similar to the one presented in Section 8.3. 1015 8.12. Prefix Advertisement Message from the Home Agent 1017 This procedure is similar to the one presented in Section 8.4. 1019 8.13. Payload Packet to the Home Agent 1021 This procedure is similar to the one presented in Section 8.5. 1023 8.14. Payload Packet from the Mobile Node 1025 This procedure is similar to the one presented in Section 8.6. 1027 8.15. Payload Packet to the Mobile Node 1029 This procedure is similar to the one presented in Section 8.7. 1031 8.16. Payload Packet from the Home Agent 1033 This procedure is similar to the one presented in Section 8.8. 1035 9. Security Considerations 1037 The Mobile IPv6 base specification [1] requires strong security 1038 between the mobile node and the home agent. This memo discusses 1039 how that security can be arranged in practise, using IPsec. 1041 10. Open Issues 1043 The following issues should be highlighted as potentially contro- 1044 versial: 1046 - We have chosen to require an encapsulation format for 1047 return routability and payload packet protection which can 1048 only be realized if the IPsec implementation can be con- 1049 trolled via an API. We expect to change the gateway address 1050 of a security association towards the mobile node as the 1051 mobile node moves. 1053 - The base Mobile IPv6 specification sets high requirements 1054 for a so-called Bumb-In-The-Wire (BITS) implementation model 1055 of IPsec. As Mobile IPv6 specific modifications of the pack- 1056 ets are required after IPsec processing, the BITS implemen- 1057 tation has to perform also some tasks related to mobility. 1058 This may increase the complexity of the implementation, even 1059 if it already performs some tasks of the IP layer (such as 1060 fragmentation). 1062 - We have chosen to require policy entries that are specific 1063 to a tunnel interface. While this seems to be required in 1064 the definition of an "interface" in [4], in practise imple- 1065 mentations don't often do this. 1067 - A further complication of the IPsec processing on a tunnel 1068 interface is that this requires access to the BITS implemen- 1069 tation before the packet actually goes out. 1071 - We have chosen to use the MAY keyword in the requirement 1072 for dynamic key management support. 1074 - We have chosen to require that a dynamic key management 1075 protocol must be able to make an authorization decision for 1076 IPsec SA creation with different addresses than where the 1077 key management protocol is run. We expect this to be done 1078 typically by configuring the allowed combinations of phase 1 1079 user identities and home addresses. 1081 - Mobile IPv6 base specification needs to be synchronized 1082 with what is stated in this document. There are also certain 1083 ambiguities in the specification, e.g., what the order of 1084 processing is for reverse tunneling, what the home agent's 1085 procedures are, and so on. 1087 - Compatibility with IPsec remote access VPNs has not been 1088 discussed. 1090 11. References 1092 [1] D. Johnson, C. Perkins, J. Arkko "Mobility Support for IPv6", 1093 Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In 1094 Progress.) September 2002. 1096 [2] S. Kent, R. Atkinson "Security Architecture for the Internet 1097 Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. 1099 [3] D. Harkins and D. Carrel "The Internet Key Exchange", RFC 1100 2409, Cisco Systems, November 1998. 1102 12. Acknowledgements 1104 The authors would like to thank Erik Nordmark, Gabriel Montene- 1105 gro, Kevin Miles, and Cheryl Madson for interesting discussions 1106 in this problem space. 1108 13. Author's Address 1110 Jari Arkko 1111 Oy LM Ericsson Ab 1112 02420 Jorvas 1113 Finland 1115 EMail: Jari.Arkko@ericsson.com 1117 Vijay Devarapalli 1118 Nokia Research Center 1119 313 Fairchild Drive 1120 Mountain View, CA 94043 1122 EMail: vijayd@iprg.nokia.com 1124 Francis Dupont 1125 ENST Bretagne 1126 Campus de Rennes 2, rue de la Chataigneraie 1127 BP 78 1128 35512 Cesson-Sevigne Cedex 1129 France 1131 EMail: Francis.Dupont@enst-bretagne.fr