idnits 2.17.1 draft-ietf-mobileip-mipv6-ha-ipsec-01.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 28 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 28 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 67 instances of too long lines in the document, the longest one being 11 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 106: '... 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...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The SAs created for BU/BA protection SHOULD not be deleted as they do not depend on care-of addresses and can be used again. -- 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 (15 October 2002) is 7862 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: '3' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1136, 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) ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) Summary: 15 errors (**), 0 flaws (~~), 7 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 15 October 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 7.4. Mobile Node Returning Home...........................17 64 8. Processing Steps within a Node.......................18 65 8.1. Binding Update to the Home Agent.....................18 66 8.2. Binding Update from the Mobile Node..................18 67 8.3. Binding Acknowledgement to the Mobile Node...........19 68 8.4. Binding Acknowledgement from the Home Agent..........20 69 8.5. Home Test Init to the Home Agent.....................20 70 8.6. Home Test Init from the Mobile Node..................21 71 8.7. Home Test to the Mobile Node.........................21 72 8.8. Home Test from the Home Agent........................22 73 8.9. Prefix Solicitation Message to the Home Agent........22 74 8.10. Prefix Solicitation Message from the Mobile Node.....22 75 8.11. Prefix Advertisement Message to the Mobile Node......22 76 8.12. Prefix Advertisement Message from the Home Agent.....23 77 8.13. Payload Packet to the Home Agent.....................23 78 8.14. Payload Packet from the Mobile Node..................23 79 8.15. Payload Packet to the Mobile Node....................23 80 8.16. Payload Packet from the Home Agent...................23 81 9. Implementation Considerations........................24 82 10. Security Considerations..............................25 83 11. References...........................................26 84 12. Acknowledgements.....................................27 85 13. Author's Address.....................................28 87 4. Introduction 89 Mobile IPv6 [1] uses IPsec [2] to protect signaling between the 90 home agent and the mobile node. This signaling consists of 91 various messages carried by the Mobility Header protocol in 92 IPv6. This signaling traffic takes the following forms: 94 (1) Binding Update and Acknowledgement messages exchanged 95 between the mobile node and the home agent, as described in 96 Sections 10.2, 10.3, 11.6.1, and 11.6.3 of [1]. 98 (2) Home Test Init and Home Test messages that pass through 99 the home agent on their way to a correspondent node, as 100 described in Section 10.7 of [1]. 102 (3) ICMPv6 messages exchanged between the mobile node and 103 the home agent for the purposes of prefix discovery, as 104 described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1]. 106 The nodes MAY also optionally protect payload traffic passing 107 through the home agent, as described in Section 5.3 of [1]. 109 Signaling between the mobile node and the home agent requires 110 message authentication, integrity, correct ordering and replay 111 protection. The mobile node and the home agent must have an 112 security association to protect this signaling. 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 118 configuration procedures, and shows how implementations can 119 process the 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 136 protected 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 198 following 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 207 (tunnel gateway address) to change for the mobile node as it 208 moves. 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 224 information advertisements from the home agent to the mobile node 225 MUST 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 240 protocol(s), and it is possible to use both AH and ESP for the 241 protection: 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 272 messages tunneled between the mobile node and home agent 273 MUST 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 282 supported 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. Type 2 Routing header 310 should be treated by IPsec in the same manner as Type 0 311 Routing header. 313 - Similarly, the authenticator calculation MUST be performed 314 as if a packet with a Home Address destination option would 315 have the home address in the IPv6 source address field and 316 the care-of address in the destination option. 318 - When a packet is matched against IPsec security policy or 319 selectors of a security association, an address appearing in 320 a Home Address destination option MUST be considered as the 321 source address of the packet. 323 - Similarly, a home address within a Type 2 Routing header 324 MUST be considered as the destination address of the packet, 325 when a packet is matched against IPsec security policy or 326 selectors of a security association. 328 - When IPsec is used to protect return routability signaling 329 or payload packets, the security association between the 330 home agent and the mobile node MUST change its destination 331 address (tunneled gateway address) when the care-of address 332 for the mobile node changes. At the home agent, this 333 modification takes place when a the care-of address in a 334 binding changes. At the mobile node, this modification takes 335 place immediately after movement. 337 - When IPsec is used to protect return routability signaling 338 or payload packets, the security policy database entries 339 SHOULD be defined specifically for the tunnel interface 340 between the mobile node and the home agent. That is, the 341 policy entries are not generally applied on all traffic on 342 the physical interface(s) of the nodes, but rather only on 343 traffic that enters this tunnel. 345 The following rules apply to mobile nodes: 347 - The mobile node MUST use the Home Address destination 348 option in Binding Updates and Mobile Prefix Solicitations, 349 sent to the home agent from a care-of address. 351 - If IPsec is used to protect return routability signaling 352 or payload packets tunneled via the home agent, IPsec tunnel 353 mode encapsulation MUST be used. 355 - Depending on whether IPsec AH or ESP is used the protec- 356 tion offered for the Binding Updates is slightly different. 357 AH protects also the IPv6 header and any extension headers. 358 It is important for the home agent to verify that the care- 359 of address has not been tampered. If ESP is used, the IPv6 360 header where this information resides could potentially have 361 been modified by attackers on the path. As a result, the 362 attacker would have redirected the mobile node's traffic to 363 another address. In order to prevent this, Mobile IPv6 364 implementations MUST use the Alternate Care-of Address 365 mobility option when ESP is used, or when the implementation 366 does not know whether AH or ESP is used. 368 - Where dynamic keying is used, the key management protocol 369 MUST use the care-of address as the source address in the 370 protocol exchanges. 372 - Conversely, the IPsec SAs MUST be requested from the key 373 management protocol with the home address as the mobile 374 node's address. 376 The following rules apply to home agents: 378 - The home agent MUST use the Type 2 Routing header in 379 Binding Acknowledgements and Mobile Prefix Advertisements 380 sent to the mobile node, again due to the need to have the 381 home address visible when the policy checks are made. 383 - If IPsec is used to protect return routability signaling 384 or payload packets tunneled to and from the mobile node, 385 IPsec tunnel mode encapsulation MUST be used. 387 - We need to avoid the possibility that a mobile node could 388 use its security association to send a Binding Update on 389 behalf of another mobile node using the same home agent. In 390 order to do this, the security policy database entries MUST 391 unequivocally identify a single SA for any given home 392 address and home agent when manual keying is used. When 393 dynamic keying is used, the security policy database entries 394 MUST unequivocally identify the IKE phase 1 credentials 395 which can be used to create security associations for a 396 particular home address. 398 7. Example Configurations 400 In the following we describe the Security Policy Database (SPD) 401 and Security Association Database (SAD) entries necessary to 402 protect Binding Updates and Binding Acknowledgements exchanged 403 between the mobile node and the home agent. Our examples assume 404 the use of ESP, but a similar configuration could also be used to 405 protect the messages with AH. 407 Section 7.1 introduces the format we use in the description of 408 the SPD and the SAD. Section 7.2 describes how to configure 409 manually keyed security associations, and Section 7.3 describes 410 how to use dynamic keying. 412 7.1. Format 414 The format used in the examples is as follows. The SPD 415 description has the format 417 "SPD OUT:" 418 "-" 419 "-" 420 ... 421 "-" 423 "SPD IN:" 424 "-" 425 "-" 426 ... 427 "-" 429 Where represents the name of the node, and has 430 the following format: 432 "IF" "THEN USE" | 433 "IF" "THEN CREATE" | 435 Where is an boolean expression about the fields of 436 the IPv6 packet, is the name of an SA, and is a 437 specification for an SA to be negotiated via IKE. The SAD 438 description has the format 440 "SAD:" 441 "-" 442 "-" 443 ... 444 "-" 446 Where represents the name of the node, and has 447 the following format: 449 "(" "," "," "," "," ")" ":" 450 452 Where is "IN" or "OUT", is the SPI of the SA, is the destination of the SA, is either "AH" or 454 "ESP", is either "TUNNEL" or "TRANSPORT", and 455 is a boolean expression about the fields of the IPv6 packet. 457 We will be using an example mobile node in this section with the 458 home address "home_address_1". The user's identity in this mobile 459 node is "user_1". The home agent's address is "home_agent_1". 461 7.2. Manual Configuration 463 7.2.1. Binding Updates and Acknowledgements 465 Here are the contents of the SPD and SAD for protecting Binding 466 Updates and Acknowledgements in the mobile node mobile node and 467 home agent home agent: 469 mobile node SPD OUT: 470 - IF source = home_address_1 & destination = home_agent_1 & 471 proto = MH 472 THEN USE SA1 474 mobile node SPD IN: 475 - IF source = home_agent_1 & destination = home_address_1 & 476 proto = MH 477 THEN USE SA2 479 mobile node SAD: 480 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 481 source = home_address_1 & destination = home_agent_1 & 482 proto = MH 483 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 484 source = home_agent_1 & destination = home_address_1 & 485 proto = MH 487 home agent SPD OUT: 488 - IF source = home_agent_1 & destination = home_address_1 & 489 proto = MH 490 THEN USE SA2 492 home agent SPD IN: 493 - IF source = home_address_1 & destination = home_agent_1 & 494 proto = MH 495 THEN USE SA1 497 home agent SAD: 498 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 499 source = home_agent_1 & destination = home_address_1 & 500 proto = MH 501 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 502 source = home_address_1 & destination = home_agent_1 & 503 proto = MH 505 7.2.2. Return Routability Signaling 507 In the following we describe the necessary SPD and SAD entries to 508 protect return routability signaling between the mobile node and 509 the home agent. Note that the rules in the SPD are ordered, and 510 the ones in the previous section must take precedence over these 511 ones: 513 mobile node SPD OUT: 514 - IF interface = tunnel to home_agent_1 & source = home_address_1 & 515 destination = any & proto = MH 516 THEN USE SA3 518 mobile node SPD IN: 519 - IF interface = tunnel from home_agent_1 & source = any & 520 destination = home_address_1 & proto = MH 521 THEN USE SA4 523 mobile node SAD: 524 - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): 525 source = home_address_1 & destination = any & proto = MH 526 - SA4(IN, spi_d, home_address_1, ESP, TUNNEL): 527 source = any & destination = home_address_1 & proto = MH 529 home agent SPD OUT: 530 - IF interface = tunnel to home_address_1 & source = any & 531 destination = home_address_1 & proto = MH 532 THEN USE SA4 534 home agent SPD IN: 535 - IF interface = tunnel from home_address_1 & source = home_address_1 & 536 destination = any & proto = MH 537 THEN USE SA3 539 home agent SAD: 540 - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): 541 source = any & destination = home_address_1 & proto = MH 542 - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): 543 source = home_address_1 & destination = any & proto = MH 545 7.2.3. Prefix Discovery 547 In the following we describe some additional SPD and SAD entries 548 to protect prefix discovery. 550 mobile node SPD OUT: 551 - IF source = home_address_1 & destination = home_agent_1 & 552 proto = ICMPv6 553 THEN USE SA5. 555 mobile node SPD IN: 556 - IF source = home_agent_1 & destination = home_address_1 & 557 proto = ICMPv6 558 THEN USE SA6 560 mobile node SAD: 561 - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): 562 source = home_address_1 & destination = home_agent_1 & 563 proto = ICMPv6 564 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): 565 source = home_agent_1 & destination = home_address_1 & 566 proto = ICMPv6 568 home agent SPD OUT: 569 - IF source = home_agent_1 & destination = home_address_1 & 570 proto = ICMPv6 571 THEN USE SA6 573 home agent SPD IN: 574 - IF source = home_address_1 & destination = home_agent_1 & 575 proto = ICMPv6 576 THEN USE SA5 578 home agent SAD: 579 - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): 580 source = home_agent_1 & destination = home_address_1 & 581 proto = ICMPv6 582 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): 583 source = home_address_1 & destination = home_agent_1 & 584 proto = ICMPv6 586 Note that the SPDs described above protect all ICMPv6 traffic 587 between the mobile node and the home agent. 589 When new prefixes are advertised by the home agent, the MN MAY 590 configure additional new home addresses. There may be a need to 591 create new security associations, if the mobile node intends to 592 use any of these home addresses to send a Binding Update to the 593 home agent. 595 7.2.4. Payload Packets 597 It is also possible to perform some additional, optional, 598 protection of tunneled payload packets. This protection takes 599 place in a similar manner to the return routability protection 600 above, but requires a different value for the protocol field. The 601 necessary SPD and SAD entries are shown below. It is assumed that 602 the entries for protecting Binding Updates and Acknowledgements, 603 and the entries to protect Home Test Init and Home Test messages 604 take precedence over these entries. 606 mobile node SPD OUT: 607 - IF interface = tunnel to home_agent_1 & source = 608 home_address_1 & 609 destination = any & proto = X 610 THEN USE SA7 612 mobile node SPD IN: 613 - IF interface = tunnel from home_agent_1 & source = any & 614 destination = home_address_1 & proto = X 615 THEN USE SA8 617 mobile node SAD: 618 - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): 619 source = home_address_1 & destination = any & proto = X 620 - SA8(IN, spi_h, home_address_1, ESP, TUNNEL): 621 source = any & destination = home_address_1 & proto = X 623 home agent SPD OUT: 624 - IF interface = tunnel to home_address_1 & source = any & 625 destination = home_address_1 & proto = X 626 THEN USE SA8 628 home agent SPD IN: 629 - IF interface = tunnel from home_address_1 & source = 630 home_address_1 & 631 destination = any & proto = X 632 THEN USE SA7 634 home agent SAD: 635 - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): 636 source = any & destination = home_address_1 & proto = X 637 - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL): 638 source = home_address_1 & destination = any & proto = X 640 7.3. Dynamic Keying 642 In this section we show an example configuration that uses IKE to 643 negotiate security associations. 645 7.3.1. Binding Updates and Acknowledgements 647 Here are the contents of the SPD for protecting Binding Updates 648 and Acknowledgements: 650 mobile node SPD OUT: 651 - IF source = home_address_1 & destination = home_agent_1 & proto = MH 652 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 654 mobile node SPD IN: 655 - IF source = home_agent_1 & destination = home_address_1 & proto = MH 656 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 658 home agent SPD OUT: 659 - IF source = home_agent_1 & destination = home_address_1 & proto = MH 660 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 662 home agent SPD IN: 663 - IF source = home_address_1 & destination = home_agent_1 & proto = MH 664 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 666 We have omitted details of the proposed transforms in the above, 667 and all details related to the particular authentication method 668 such as certificates beyond listing a specific identity that must 669 be used. 671 We require IKE to be run using the care-of addresses but still 672 negotiate IPsec SAs that use home addresses. The extra conditions 673 set by the home agent SPD for the peer phase 1 identity to be 674 "user_1" must be verified by the home agent. The purpose of the 675 condition is to ensure that the IKE phase 2 negotiation for a 676 given user's home address can't be requested by another user. In 677 the mobile node, we simply set our local identity to be "user_1". 679 These checks also imply that the configuration of the home agent 680 is user-specific: every user or home address requires a specific 681 configuration entry. It would be possible to alleviate the 682 configuration tasks by using certificates that have home addresses 683 in the Subject AltName field. However, it isn't clear if all IKE 684 implementations allow one address to be used for carrying the IKE 685 negotiations when another address is mentioned in the used cer- 686 tificates. In any case, even this approach would have required 687 user-specific tasks in the certificate authority. 689 7.3.2. Return Routability Signaling 691 Protection for the return routability signaling can be configured 692 in a similar manner as above. 694 mobile node SPD OUT: 695 - IF interface = tunnel to home_agent_1 & 696 source = home_address_1 & destination = any & proto = MH 697 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 698 local phase 1 identity = user_1 700 mobile node SPD IN: 701 - IF interface = tunnel from home_agent_1 & 702 source = any & destination = home_address_1 & proto = MH 703 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 704 local phase 1 identity = user_1 706 home agent SPD OUT: 707 - IF interface = tunnel to home_address_1 & 708 source = any & destination = home_address_1 & proto = MH 709 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 710 peer phase 1 identity = user_1 712 home agent SPD IN: 713 - IF interface = tunnel from home_address_1 & 714 source = home_address_1 & destination = any & proto = MH 715 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 716 peer phase 1 identity = user_1 718 One difference to the above is that we specified the tunnel 719 gateway address, as we need to use a different address for that 720 than those appearing in the packets. 722 7.3.3. Prefix Discovery 724 In the following we describe some additional SPD entries to 725 protect prefix discovery with IKE. (Note that when actual new 726 prefixes are discovered, there may be a need to enter new 727 manually configured SPD entries to specify the authorization 728 policy for the resulting new home addresses.) 730 mobile node SPD OUT: 731 - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 732 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 734 mobile node SPD IN: 735 - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 736 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 738 home agent SPD OUT: 739 - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 740 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 742 home agent SPD IN: 743 - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6 744 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 746 7.3.4. Payload Packets 748 Protection for the payload packets happens similarly to the 749 protection of return routability signaling. As in the manually 750 keyed case, these SPD entries have lower priority than the above 751 ones. 753 mobile node SPD OUT: 754 - IF interface = tunnel to home_agent_1 & 755 source = home_address_1 & destination = any & proto = X 756 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 757 local phase 1 identity = user_1 759 mobile node SPD IN: 760 - IF interface = tunnel from home_agent_1 & 761 source = any & destination = home_address_1 & proto = X 762 THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & 763 local phase 1 identity = user_1 765 home agent SPD OUT: 766 - IF interface = tunnel to home_address_1 & 767 source = any & destination = home_address_1 & proto = X 768 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 769 peer phase 1 identity = user_1 771 home agent SPD IN: 772 - IF interface = tunnel from home_address_1 & 773 source = home_address_1 & destination = any & proto = X 774 THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & 775 peer phase 1 identity = user_1 777 7.4. Mobile Node Returning Home 779 When the MN returns home and deregisters with the Home Agent, the 780 tunnel between the home agent and the MN's CoA is torn down. The 781 SPD entries, which were used for protecting tunneled traffic 782 between the MN and the HA become inactive. The corresponding SAs 783 could be stored or deleted depending on how they were created. If 784 the SAs were created dynamically using IKE, they are 785 automatically deleted when they expire. If the SAs were created 786 through manual configuration, they can be retained and used later 787 if the MN moves aways from home. 789 The SAs created for BU/BA protection SHOULD not be deleted as 790 they do not depend on care-of addresses and can be used again. 792 8. Processing Steps within a Node 794 In this section we give examples of what processing steps node 795 can take to achieve the required packet formats and satisfy the 796 requirements. These example are for illustration purposes only, 797 and implementations are free to choose other strategies as long 798 as the results stay the same on the wire. 800 8.1. Binding Update to the Home Agent 802 Step 1. At the mobile node, Mobile IPv6 module first produces the 803 following packet 805 IPv6 header (source = home address, destination = home agent) 806 Mobility header 807 Binding Update 809 Step 2. This packet is matched against the IPsec policy data base 810 on the mobile node and we make a note that IPsec must be applied. 812 Step 3. Then, we add the necessary Mobile IPv6 options but do not 813 change the addresses yet, as described in Section 11.2.2 in [1]. 814 This results in: 816 IPv6 header (source = home address, destination = home agent) 817 Destination Options header 818 Home Address option (care-of address) 819 Mobility header 820 Binding Update 822 Step 4. Finally, IPsec headers are added and the necessary 823 authenticator values are calculated: 825 IPv6 header (source = home address, destination = home agent) 826 Destination Options header 827 Home Address option (care-of address) 828 ESP header (SPI = spi_a) 829 Mobility header 830 Binding Update 832 Step 5. Before sending the packet, the addresses in the IPv6 833 header and the Destination Options header are changed: 835 IPv6 header (source = care-of address, destination = home agent) 836 Destination Options header 837 Home Address option (home address) 838 ESP header (SPI = spi_a) 839 Mobility header 840 Binding Update 842 8.2. Binding Update from the Mobile Node 844 Step 1. The following packet is received at the home agent: 846 IPv6 header (source = care-of address, destination = home agent) 847 Destination Options header 848 Home Address option (home address) 849 ESP header (SPI = spi_a) 850 Mobility header 851 Binding Update 853 Step 2. The home address option is processed first, which results 854 in 856 IPv6 header (source = home address, destination = home agent) 857 Destination Options header 858 Home Address option (care-of address) 859 ESP header (SPI = spi_a) 860 Mobility header 861 Binding Update 863 Step 3. ESP header is processed next, resulting in 865 IPv6 header (source = home address, destination = home agent) 866 Destination Options header 867 Home Address option (care-of address) 868 Mobility header 869 Binding Update 871 Step 4. This packet matches the SA selectors (source = home 872 address, destination = home agent, proto = MH). 874 Step 5. Mobile IPv6 processes the Binding Update. 876 The Binding Update is delivered to the Mobile IPv6 module. 878 8.3. Binding Acknowledgement to the Mobile Node 880 Step 1. Mobile IPv6 produces the following packet: 882 IPv6 header (source = home agent, destination = home address) 883 Mobility header 884 Binding Acknowledgement 886 Step 2. This packet matches the IPsec policy entries, and we 887 remember that IPsec has to be applied. 889 Step 3. Then, we add the necessary Route Headers but do not 890 change the addresses yet, as described in Section 9.6 in [1]. 891 This results in: 892 IPv6 header (source = home agent, destination = home address) 893 Routing header (type 2) 894 care-of address 895 Mobility header 896 Binding Acknowledgement 898 Step 4. We apply IPsec: 900 IPv6 header (source = home agent, destination = home address) 901 Routing header (type 2) 902 care-of address 903 ESP header (SPI = spi_b) 904 Mobility header 905 Binding Acknowledgement 907 Step 5. Finally, before sending the packet out we change the 908 addresses in the IPv6 header and the Route header: 910 IPv6 header (source = home agent, destination = care-of address) 911 Routing header (type 2) 912 home address 913 ESP header (SPI = spi_b) 914 Mobility header 915 Binding Acknowledgement 917 8.4. Binding Acknowledgement from the Home Agent 919 Step 1. The following packet is received at the mobile node 921 IPv6 header (source = home agent, destination = care-of address) 922 Routing header (type 2) 923 home address 924 ESP header (SPI = spi_b) 925 Mobility header 926 Binding Acknowledgement 928 Step 2. After the routing header is processed the packet becomes 930 IPv6 header (source = home agent, destination = home address) 931 Routing header (type 2) 932 care-of address 933 ESP header (SPI = spi_b) 934 Mobility header 935 Binding Acknowledgement 937 Step 3. ESP header is processed next, resulting in: 939 IPv6 header (source = home agent, destination = home address) 940 Routing header (type 2) 941 care-of address 942 Mobility header 943 Binding Acknowledgement 944 Step 4. This packet matches the SA selectors (source = home 945 agent, destination = home address, proto = MH). 947 Step 5. The Binding Acknowledgement is delivered to the Mobile 948 IPv6 module. 950 8.5. Home Test Init to the Home Agent 952 Step 1. The mobile node constructs a Home Test Init message: 954 IPv6 header (source = home address, destination = correspondent node) 955 Mobility header 956 Home Test Init 958 Step 2. Mobile IPv6 determines that this packet should go to the 959 tunnel to the home agent. 961 Step 3. The packet is matched against IPsec policy entries for 962 the interface, and we find that IPsec needs to be applied. 964 Step 4. IPsec tunnel mode headers are added. Note that we use a 965 care-of address as a source address for the tunnel packet. 967 IPv6 header (source = care-of address, destination = home agent) 968 ESP header (SPI = spi_c) 969 IPv6 header (source = home address, destination = correspondent node) 970 Mobility header 971 Home Test Init 973 Step 5. The packet no longer satisfies the criteria that made it 974 enter the tunnel, and it is sent directly to the home agent. 976 8.6. Home Test Init from the Mobile Node 978 Step 1. The home agent receives the following packet: 980 IPv6 header (source = care-of address, destination = home agent) 981 ESP header (SPI = spi_c) 982 IPv6 header (source = home address, destination = correspondent node) 983 Mobility Header 984 Home Test Init 986 Step 2. IPsec processing is performed, resulting in: 988 IPv6 header (source = home address, destination = correspondent node) 989 Mobility Header 990 Home Test Init 992 Step 3. The resulting packet matches the selectors and the packet 993 can be processed further. 995 Step 4. The packet is then forwarded towards the correspondent 996 node. 998 8.7. Home Test to the Mobile Node 1000 Step 1. The home agent receives a Home Test packet from the 1001 correspondent node: 1003 IPv6 header (source = correspondent node, destination = home address) 1004 Mobility Header 1005 Home Test Init 1007 Step 2. The home agent determines that this packet is destined to 1008 a mobile node that is away from home, and decides to tunnel it. 1010 Step 3. The packet matches the IPsec policy entries for the 1011 tunnel interface, and we note that IPsec needs to be applied. 1013 Step 4. IPsec is applied, resulting in a new packet. Note that 1014 the home agent must keep track of the location of the mobile 1015 node, and update the tunnel gateway address in the security 1016 association(s) accordingly. 1018 IPv6 header (source = home agent, destination = care-of address) 1019 ESP header (SPI = spi_d) 1020 IPv6 header (source = correspondent node, destination = home address) 1021 Mobility Header 1022 Home Test Init 1024 Step 5. The packet no longer satisfies the criteria that made it 1025 enter the tunnel, and it is sent directly to the care-of address. 1027 8.8. Home Test from the Home Agent 1029 Step 1. The mobile node receives the following packet: 1031 IPv6 header (source = home agent, destination = care-of address) 1032 ESP header (SPI = spi_d) 1033 IPv6 header (source = correspondent node, destination = home address) 1034 Mobility Header 1035 Home Test Init 1037 Step 2. IPsec is processed, resulting in: 1039 IPv6 header (source = correspondent node, destination = home address) 1040 Mobility Header 1041 Home Test Init 1043 Step 3. This matches the SA selectors (source = any, destination 1044 = home address). 1046 Step 4. The packet is given to Mobile IPv6 processing. 1048 8.9. Prefix Solicitation Message to the Home Agent 1050 This procedure is similar to the one presented in Section 8.1. 1052 8.10. Prefix Solicitation Message from the Mobile Node 1054 This procedure is similar to the one presented in Section 8.2. 1056 8.11. Prefix Advertisement Message to the Mobile Node 1058 This procedure is similar to the one presented in Section 8.3. 1060 8.12. Prefix Advertisement Message from the Home Agent 1062 This procedure is similar to the one presented in Section 8.4. 1064 8.13. Payload Packet to the Home Agent 1066 This procedure is similar to the one presented in Section 8.5. 1068 8.14. Payload Packet from the Mobile Node 1070 This procedure is similar to the one presented in Section 8.6. 1072 8.15. Payload Packet to the Mobile Node 1074 This procedure is similar to the one presented in Section 8.7. 1076 8.16. Payload Packet from the Home Agent 1078 This procedure is similar to the one presented in Section 8.8. 1080 9. Implementation Considerations 1082 We have chosen to require an encapsulation format for return 1083 routability and payload packet protection which can only be 1084 realized if the IPsec implementation can be controlled via an 1085 API. One of the main reasons for choosing such a format is that 1086 it removes the overhead of twenty four bytes when a home address 1087 option or routing header is added to the tunneled packet. The API 1088 should minimally support changing the gateway address of a 1089 security association towards the mobile node as the mobile node 1090 moves. Implementations are free to choose other methods to update 1091 a security association. This includes deleting the current SA 1092 and adding a new SA. 1094 We have also chosen to require that a dynamic key management 1095 protocol must be able to make an authorization decision for IPsec 1096 SA creation with different addresses than with what the key 1097 management protocol is run. We expect this to be done typically by 1098 configuring the allowed combinations of phase 1 user identities 1099 and home addresses. 1101 The base Mobile IPv6 specification sets high requirements for a 1102 so-called Bump-In-The-Stack (BITS) implementation model of IPsec. 1103 As Mobile IPv6 specific modifications of the packets are required 1104 after IPsec processing, the BITS implementation has to perform 1105 also some tasks related to mobility. This may increase the 1106 complexity of the implementation, even if it already performs 1107 some tasks of the IP layer (such as fragmentation). 1109 We have chosen to require policy entries that are specific to a 1110 tunnel interface. This means that implementations have to regard 1111 the Home Agent - Mobile Node tunnel as a separate interface on 1112 which IPsec SPDs can be based. 1114 A further complication of the IPsec processing on a tunnel 1115 interface is that this requires access to the BITS implementation 1116 before the packet actually goes out. 1118 10. Security Considerations 1120 The Mobile IPv6 base specification [1] requires strong security 1121 between the mobile node and the home agent. This memo discusses 1122 how that security can be arranged in practise, using IPsec. 1124 11. References 1126 [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support for 1127 IPv6", Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In 1128 Progress.) September 2002. 1130 [2] S. Kent, R. Atkinson, "Security Architecture for the 1131 Internet Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. 1133 [3] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 1134 2409, Cisco Systems, November 1998. 1136 [4] S. Deering and R. Hinden, "Internet Protocol, Version 6 1137 (IPv6) Specification", RFC 2460, December 1998. 1139 12. Acknowledgements 1141 The authors would like to thank Erik Nordmark, Gabriel 1142 Montenegro, Kevin Miles, Cheryl Madson and Jari T. Malinen for 1143 interesting discussions in this problem space. 1145 13. Author's Address 1147 Jari Arkko 1148 Oy LM Ericsson Ab 1149 02420 Jorvas 1150 Finland 1152 EMail: Jari.Arkko@ericsson.com 1154 Vijay Devarapalli 1155 Nokia Research Center 1156 313 Fairchild Drive 1157 Mountain View, CA 94043 1159 EMail: vijayd@iprg.nokia.com 1161 Francis Dupont 1162 ENST Bretagne 1163 Campus de Rennes 2, rue de la Chataigneraie 1164 BP 78 1165 35512 Cesson-Sevigne Cedex 1166 France 1168 EMail: Francis.Dupont@enst-bretagne.fr