idnits 2.17.1 draft-sugimoto-mip6-pfkey-migrate-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 913. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 372: '... an EINVAL error MUST be returned as a...' RFC 2119 keyword, line 375: '... an ENOENT error MUST be returned. If...' RFC 2119 keyword, line 376: '...d, a success (0) MUST be returned rega...' RFC 2119 keyword, line 380: '... message MUST NOT have any effect on...' RFC 2119 keyword, line 384: '... it SHOULD first check if the messag...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (December 15, 2007) is 5971 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Sugimoto 3 Internet-Draft Ericsson 4 Intended status: Informational F. Dupont 5 Expires: June 17, 2008 CELAR 6 M. Nakamura 7 Hitachi 8 December 15, 2007 10 PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE 11 draft-sugimoto-mip6-pfkey-migrate-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 17, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes the need for an interface between Mobile IPv6 45 and IPsec/IKE and show how the two protocols can interwork. We 46 propose a set of extensions to the PF_KEY framework which allows 47 smooth and solid operation of IKE in a Mobile IPv6 environment. The 48 first extension is called PF_KEY MIGRATE and is for migrating the 49 endpoint addresses of a IPsec Security Association pair in tunnel 50 mode. The second extension is named SADB_X_EXT_PACKET and allows IKE 51 to make the right choice for address selection in bootstrapping 52 process. Both extensions are helpful for assuring smooth 53 interworking between Mobile IPv6 and IPsec/IKE and achieving 54 performance optimization. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 3 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. PF_KEY Extensions for Mobile IPv6 . . . . . . . . . . . . . . 4 62 4.1. PF_KEY MIGRATE Message . . . . . . . . . . . . . . . . . . 5 63 4.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.2. Message Sequence . . . . . . . . . . . . . . . . . . . 6 65 4.1.3. Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . 7 66 4.1.4. Processing PF_KEY MIGRATE Message . . . . . . . . . . 8 67 4.1.5. Applicability of PF_KEY MIGRATE to Other Systems . . . 9 68 4.1.6. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 69 4.1.7. Limitation of PF_KEY MIGRATE . . . . . . . . . . . . . 10 70 4.1.8. Interoperability Issue . . . . . . . . . . . . . . . . 10 71 4.2. PF_KEY Packet Extension . . . . . . . . . . . . . . . . . 11 72 4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message . . 12 73 4.2.2. Extracting Home Registration Information from 74 Acquire Message . . . . . . . . . . . . . . . . . . . 12 75 4.2.3. Relation of Packet Extension to IKEv2 . . . . . . . . 13 76 5. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Appendix A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . 16 83 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . . . 20 87 1. Introduction 89 In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent 90 (HA) use some IPsec Security Associations (SAs) in tunnel mode to 91 protect some mobility signaling messages, mobile prefix discovery and 92 optionally payload traffic. Since the MN may change its attachment 93 point to the Internet, it is necessary to update its tunnel endpoint 94 address of the IPsec SAs. This indicates that corresponding entry in 95 IPsec databases (Security Policy (SPD) and SA (SAD) databases) should 96 be updated when MN performs movements. In addition, IKE requires 97 treatment to keep its IKE session alive in a Mobile IPv6 environment. 99 This document describes the need for an interface between Mobile IPv6 100 and IPsec/IKE and shows how the two protocols can interwork. We 101 propose a set of extensions to the PF_KEY framework [RFC2367] which 102 allows smooth and solid operation of IKE in an Mobile IPv6 103 environment. The first extension is called PF_KEY MIGRATE and is for 104 migrating the endpoint addresses of the IPsec SAs in tunnel mode. 105 The second extension is named SADB_X_EXT_PACKET and allows IKE to 106 make the right choice in address selection in the bootstrapping 107 process. Both extensions are helpful for assuring smooth 108 interworking between Mobile IPv6 and IPsec/IKE and achieving 109 performance optimization. 111 In this document, the term IKE implicitly stands for both IKEv1 112 [RFC2409] and IKEv2 [RFC4306]. In description with regard to any 113 functionality that is specific to either of the protocols, specific 114 protocol name shall be provided. 116 2. Needs for Interactions between Mobile IPv6 and IPsec/IKE 118 The section 4.4 of RFC 3776 [RFC3776] specifies the rules which 119 applies to IKE for MNs and HAs. The first requirement is to run IKE 120 over the Care-of Address (CoA) because the Home Address (HoA) is 121 usable only after the home registration so not yet in the 122 bootstrapping phase. 124 A tunnel IPsec SA pair protects some signaling messages and 125 optionally all the traffic between the MN and HA. The initial SPD 126 entry uses the HoA for the MN endpoint address and updates this 127 address to the new CoA at each movement. A tunnel SA pair is created 128 on demand and is updated too. The RFC 3775 [RFC3775] assumes there 129 is an API which performs the update in the SPD and SAD on both the MN 130 and HA. This document is mainly about this API. 132 Mobile IPv6 specifies a flag named Key Management Mobility Capability 133 bit (K-bit) in Binding Update (BU) and Binding Acknowledgement (BA) 134 messages (section 10.3.1 of [RFC3775]), which indicates the ability 135 of IKE sessions to survive movement. When both the MN and HA agree 136 to use this functionality, the IKE daemons dynamically update the IKE 137 session when the MN moves. In order to realize this, IKE daemons 138 should be notified by Mobile IPv6, and necessary information to 139 migrate the IKE session should be provided. 141 Mobile IPv6 may need to make an access to the SPD not only for 142 updating an endpoint address but also for the deletion/insertion of a 143 specific SPD entry. When the MN performs Foreign-to-Home movement, 144 IPsec SAs established between the MN and HA should be deleted, which 145 means that the SPD entry should have no effect any more. On the 146 other hand, when the MN performs Home-to-Foreign movement, the IPsec 147 SAs should be restored. Hence security policy entries that are 148 associated with tunnel mode SAs may dynamically be added/removed 149 (enabled/disabled) in along with MN's movements. 151 It should be noted that NEMO Basic Support [RFC3963] has similar 152 requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO, 153 the MR works just as same as a MN registering its location 154 information to the MRHA and establishes a tunnel (IP-in-IP or IPsec 155 tunnel). When an IPsec tunnel is established between MR and MRHA, 156 the MR serves as a Security Gateway for the nodes connected to the 157 mobile network. The MR is responsible for handling its tunnel 158 endpoint properly. 160 3. Requirements 162 Given the need for an interface between Mobile IPv6 and IPsec/IKE, 163 there should be a minimum interface between the two protocols. 164 Followings are the requirements for the interface from a software 165 engineering point of view. 167 o Necessary modifications to the existing software, namely Mobile 168 IPv6 and IPsec/IKE, in order to realize proposed mechanisms, 169 should be kept minimum. 170 o Proposed mechanism should not be platform dependent. The 171 mechanism should be based on technology which is commonly 172 available on various platform. This seems to be essential for 173 achieving high portability of the implementation which supports 174 proposed mechanisms. 176 4. PF_KEY Extensions for Mobile IPv6 178 In order to fulfill the needs and requirements described in Section 2 179 and Section 3 we propose to extend the PF_KEY framework so that 180 Mobile IPv6 and IPsec/IKE could interact with each other. 182 4.1. PF_KEY MIGRATE Message 184 The first extension is primarily for migrating an endpoint address of 185 an IPsec SA pair in tunnel mode from one to another, which results in 186 updating IPsec databases. A new PF_KEY message named MIGRATE is 187 introduced for the mechanism. 189 4.1.1. Overview 191 The figure below illustrates how Mobile IPv6 and IPsec/IKE components 192 interact with each other using PF_KEY MIGRATE messages in a dynamic 193 keying scenario. On left top, there is a Mobile IPv6 entity. It may 194 be possible that Mobile IPv6 component is completely implemented 195 inside the kernel (this is the case for our implementations because 196 it makes some facilities and extensions far easier at the cost of 197 maintaining a SPD image in daemons). In any case, Mobile IPv6 should 198 be the one which issues the MIGRATE messages. On right top, there is 199 an IKE daemon which is responsible for establishing SAs required for 200 Mobile IPv6 operation. In a manual keying scenario, the difference 201 is only that there is no IKE daemon running on the system. 203 +-------------+ +------------+ 204 | | | | 205 | Mobile IPv6 | | IKE Daemon | 206 | | | | 207 +-------------+ +------------+ 208 | 1. PF_KEY A 4. Update 209 | MIGRATE | SPD & SAD 210 +-----------+ +-----------+ 211 | | 212 Userland V | 213 ==========================[PF_KEY Socket]======================== 214 Kernel | | 215 +----------+ +----------+ 216 | 2. Update | 3. Update 217 V SPD V SAD 218 +-----------+ +------------+ 219 | | | | 220 | SPD | | SAD | 221 | | | | 222 +-----------+ +------------+ 224 The primary role of PF_KEY MIGRATE messages is to migrate endpoint 225 addresses of tunnel mode SA pairs requesting IPsec to update its 226 databases (SPD and SAD). In addition, the new message can be used by 227 IKE to enhance its mobility capability. When a PF_KEY MIGRATE 228 message is properly processed by the kernel, it is sent to all open 229 sockets as normal PF_KEY messages. The processing of a sequence of 230 MIGRATE messages is done in following steps: 232 o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket. 233 o The operating system (kernel) validates the message and checks if 234 corresponding security policy entry exists in SPD. 235 o When the message is confirmed to be valid, the target SPD entry is 236 updated according to the MIGRATE message. If there is any target 237 SA found that are also target of the update, those should also be 238 updated. 239 o After the MIGRATE message is successfully processed inside the 240 kernel, it will be sent to all open PF_KEY sockets. 241 o The IKE daemon receives the MIGRATE message from its PF_KEY socket 242 and updates its SPD and SAD images. The IKE daemon may also 243 update its state to keep the IKE session alive. 245 Note that the way IKE maintains its local copy of SPD (the SPD image) 246 is an implementation specific issue since there is no standard 247 interface to access SPD. Some IKE implementation may continuously 248 monitor the SPD inside the kernel. Some IKE implementation may 249 expect notification from the kernel when the SPD is modified. In 250 either way, the proposed mechanism gives a chance for IKE to keep its 251 SPD image up-to-date which is significant in Mobile IPv6 operation. 253 4.1.2. Message Sequence 255 Next, we will see how migration takes place in along with home 256 registration. The figure below shows sequence of mobility signaling 257 and PF_KEY MIGRATE messages while the MN roams around links. It is 258 assumed that in the initial state the tunnel endpoint address for a 259 given MN is set as its home address. In the initial home 260 registration, the MN and HA migrate the tunnel endpoint address from 261 the HoA to CoA1. It should be noted that no migration takes place 262 when the MN performs re-registration since the care-of address 263 remains the same. Accordingly, the MN performs movement and changes 264 its primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE 265 message is issued on both MN and HA for each direction. When the MN 266 returns to home, migration takes place updating the endpoint address 267 with the MN's home address. 269 With regard to the timing of issuing a MIGRATE message on the MN 270 side, the message can be issued immediately after the home 271 registration. That is, there is no need to wait until the 272 acknowledgment from the HA to issue migrate the endpoint addresses 273 stored in the IPsec databases. The Mobile IPv6 specification 274 ([RFC3775] Section 11.6.3) actually allows the MN to start using the 275 new care-of address immediately after sending a BU message to the HA. 277 This may help the MN to minimize the packet loss of its outbound 278 traffic during the handover. 280 MN HA 281 | | 282 ~ ~ 283 Movement->| BU (Initial home registration) | 284 |----------------------------------------->| 285 MIGRATE ->| BA |<- MIGRATE 286 (HoA->CoA1) |<-----------------------------------------| (HoA->CoA1) 287 | | 288 ~ BU (Home re-registration) ~ 289 |----------------------------------------->| 290 | BA | 291 |<-----------------------------------------| 292 | | 293 ~ ~ 294 | | 295 Movement->| BU (Home registration) | 296 |----------------------------------------->| 297 MIGRATE ->| BA |<- MIGRATE 298 (CoA1->CoA2)|<-----------------------------------------| (CoA1->CoA2) 299 | | 300 ~ ~ 301 Movement->| BU (Home de-registration) | 302 |----------------------------------------->| 303 MIGRATE ->| BA |<- MIGRATE 304 (CoA2->HoA) |<-----------------------------------------| (CoA2->HoA) 305 | | 307 4.1.3. Issuing PF_KEY MIGRATE Message 309 The Mobile IPv6 entity (MN or HA code) triggers the migration by 310 sending a PF_KEY MIGRATE message to its PF_KEY socket. Conceptually, 311 the PF_KEY MIGRATE message should contain following information: 313 o Selector information: 314 * source address/port 315 * destination address/port 316 * upper layer protocol (i.e., Mobility Header) 317 * direction (inbound/outbound) 318 o Old SA information: 319 * old source endpoint address 320 * old destination endpoint address 321 * IPsec protocol (ESP/AH) 322 * mode (Tunnel) 324 o New SA information: 325 * new source endpoint address 326 * new destination endpoint address 327 * IPsec protocol (ESP/AH) 328 * mode (Tunnel) 330 Selector information is required for specifying the target SPD entry 331 to be updated. Basically the information should contain necessary 332 elements which characterize traffic selector as specified in the 333 IPsec architecture ([RFC2401], [RFC4301]). With regard to the upper 334 layer protocol, when the Mobile IPv6 stack is not fully aware of 335 IPsec configuration, an wild-card value could be given. In such 336 case, an upper layer protocol information should not be taken into 337 account for searching SPD entry. Plus, the direction of the security 338 policy (inbound/outbound) should be provided. The old SA information 339 is used to specify target security association to be updated. The 340 source and destination addresses of the target entry should be 341 overwritten with the ones included in the new SA information. Note 342 that the IPsec protocol and mode fields should not be updated by a 343 PF_KEY MIGRATE message. 345 A PF_KEY MIGRATE message should be formed based on security policy 346 configuration and binding record. The selector information and some 347 parts of the SA information (IPsec protocol and mode) should be taken 348 from the policy configuration. The rest of the information should be 349 taken from the sequential binding information. For example, in the 350 case where the MN updates its inbound security policy and 351 corresponding tunnel mode SA pair, the old source address should be 352 set as its previous CoA, and the new source address should be set as 353 its current CoA. Hence, the MN should sequentially keep track of its 354 CoA record. Such information shall be stored in binding update list 355 entry. For the same reason, the HA should keep track of previous 356 CoAs of MNs. Such information shall be stored in binding cache 357 entry. 359 Additionally, a piece of information which indicates a mobility 360 capability of IKE (K-bit) should be provided by any means. This 361 makes it possible for IKE to see if there is a need to update its 362 state (IKE endpoint addresses) in accordance with PF_KEY MIGRATE 363 messages. 365 A detailed message format of PF_KEY MIGRATE is provided in 366 Appendix A. 368 4.1.4. Processing PF_KEY MIGRATE Message 370 Since a PF_KEY MIGRATE message is applied to a single SPD entry, the 371 kernel should first check validity of the message. If the message is 372 invalid, an EINVAL error MUST be returned as a return value for the 373 write() operation made to the PF_KEY socket. After the validation, 374 the kernel checks if the target SPD entry really exists. If no entry 375 is found, an ENOENT error MUST be returned. If a SPD entry is found 376 and successfully updated, a success (0) MUST be returned regardless 377 of subsequent result of SAD lookup/update. Note that there may be a 378 case where a corresponding SAD entry does not exist even if a SPD 379 entry is successfully updated. In any error case, a PF_KEY MIGRATE 380 message MUST NOT have any effect on the SPD and SAD. 382 With respect to the behavior of a normal process (including the IKE 383 daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket, 384 it SHOULD first check if the message does not include erroneous 385 information. When there is any error indicated, the process MUST 386 silently discard the PF_KEY MIGRATE message. Otherwise, the 387 processing of the message may continue. 389 4.1.5. Applicability of PF_KEY MIGRATE to Other Systems 391 The PF_KEY MIGRATE extension can also be applied to other systems 392 than Mobile IPv6. In some systems, there is a need to update 393 endpoint address of IPsec security association for various reasons 394 such as mobility management and multihoming. 396 In a Mobile VPN scenario (aka "road warrior"), client node roams 397 around different IP subnets while maintaining security association 398 with the security gateway. Just like the case in Mobile IPv6, both 399 of the IKE peers need to update the endpoint of the IPsec tunnel and 400 PF_KEY MIGRATE message can be used for the update. 402 In HIP mobility management scenario[I-D.ietf-hip-mm], a mobile host 403 can maintain a HIP association with its peer while moving around IP 404 subnets. When the mobile host changes its attachment point to the 405 Internet, it sends an UPDATE message to the peer reporting its new 406 locator. Since HIP association is represented by an IPsec security 407 association of ESP BEET mode, the same mechanism can be applied for 408 the purpose of updating endpoint. The procedure of MIGRATE can take 409 place when the mobile host detects movement and when the peer 410 receives the UPDATE message. 412 From the ID/Locator separation point of view, PF_KEY MIGRATE is 413 designed to update locators stored in an IPsec security association. 414 Hence, the message can be applied to IPsec security association in 415 tunnel mode. However, there are exceptional cases where IPsec 416 security associations are bundled. In some case, a transport mode 417 security association may be bundled with a tunnel mode security 418 association. For instance, a combination of AH (transport mode) and 419 ESP (tunnel mode) may assure confidentiality of the payload as well 420 as data integrity of the whole IP packet including outer header. In 421 such case, PF_KEY MIGRATE message may be used for updating endpoint 422 addresses of IPsec transport mode. 424 4.1.6. NAT Traversal 426 Dual Stack Mobile IPv6 [I-D.ietf-mip6-nemo-v4traversal] supports a 427 scenario where a MN is connected to a network behind a Network 428 Address Translator (NAT). In such case, the MN assigns an IPv4 429 private address to its network interface but it is still capable of 430 registering its care-of address to the HA, using the NAT Traversal 431 technique [RFC3948]. The MN and HA leverage an IPsec tunnel to 432 protect the return routability messages. 434 It is possible for the PF_KEY MIGRATE message to handle IPv4 private 435 address when the MN is behind a NAT device. In a NAT Traversal case, 436 the endpoint address of the MN is characterized by the IP address and 437 the pair of source and destination port numbers used for the UDP 438 encapsulation. Therefore, in a NAT Traversal scenario, a Mobile IPv6 439 module MUST issue a PF_KEY MIGRATE message along with the pair of 440 source and destination port numbers of a UDP encapsulation, to handle 441 IPv4 private address. 443 4.1.7. Limitation of PF_KEY MIGRATE 445 Currently, a Security Parameter Index (SPI) is not included in the 446 old SA information to specify target SAD entry. This helps to lessen 447 operational burden of Mobile IPv6. However, this simplification can 448 produce ambiguity in searching for the target security association 449 entry. When the unique SPD level is available, it should be used 450 because it avoids this problem both by marking the SAs to update and 451 by limiting SA sharing. 453 It should be noted that delivery of PF_KEY MIGRATE messages cannot be 454 guaranteed, which is common to other PF_KEY messages. It may be 455 possible that a MIGRATE message is lost. In such case, there will be 456 inconsistency between the binding record managed by Mobile IPv6 and 457 IPsec database inside the kernel or the IKE daemon. Once a PF_KEY 458 MIGRATE message is lost, it would not be possible for the receiver to 459 process some subsequent MIGRATE messages properly. Reinitialization 460 of the Mobile IPv6 stack and IPsec databases may be needed for 461 recovery. 463 4.1.8. Interoperability Issue 465 It is a choice of implementers whether to support the PF_KEY MIGRATE 466 message in their MIPv6 and IPsec/IKE implementations. However, 467 asymmetry in the support of the PF_KEY MIGRATE message may cause an 468 interoperability issue in some case. 470 It should be noted that an interoperability issue may be raised when 471 the HA does not support PF_KEY MIGRATE message whereas the MN does 472 support the mechanism. This is based on the working assumption that 473 HA serves as a responder in the IKE negotiations conducted to 474 maintain the IPsec SAs required for MIPv6 operation. It is unlikely 475 that the HA serves as an initiator in the IKE negotiation in the 476 MIPv6 network scenario for practical reasons. Thus, the HA without 477 the support of PF_KEY MIGRATE suffers from having the old information 478 in the IPsec database. More specifically, the HA may forward the IP 479 packets destined for the MN to a wrong destination. 481 Therefore, it is RECOMMENDED that HA implements PF_KEY MIGRATE 482 message or equivalent function to avoid an interoperability issue 483 with regard to the dynamic update of IPsec database. 485 4.2. PF_KEY Packet Extension 487 In the bootstrapping stage of Mobile IPv6, the MN and HA need to 488 establish IPsec SA to protect signaling messages of Mobile IPv6 such 489 as BU and BA. When IKE is used to establish and maintain the SA 490 pairs, the IKE negotiation is the very first transaction made between 491 the MN and HA. 493 As mentioned in [RFC3776], a care is needed for the address 494 management of the IKE negotiation in Mobile IPv6 environments. In 495 particular, IKE negotiation to be made to establish a transport mode 496 IPsec SA pair is tricky in a sense that the IKE endpoint and the SA 497 address on the MN side are different; IKE endpoint must be an IP 498 address other than the home address of the MN, whereas the SA address 499 must be the MN's home address. This is because the home address 500 cannot be used prior to the initial home registration. The best 501 candidate for the IKE endpoint on MN side is the primary care-of 502 address of the MN since it is verified by the Mobile IPv6 module to 503 work. 505 For the above reasons, there is a need to guide IKE module to make 506 the right choice of IKE endpoint and SA address. More specifically, 507 IKE module should be notified on which IP address the IKE negotiation 508 should run. 510 A simple solution which enables the notification is to add the 511 information of the triggering packet to the SADB_ACQUIRE message. 512 The extension is called Packet Extension, which allows a receiver of 513 a SADB_ACQUIRE message (e.g. IKE module) to inspect the triggering 514 packet and take necessary action, such as choosing specific IP 515 address as an IKE endpoint for the subsequent IKE negotiation. 517 The following is a structure of an extended SADB_ACQUIRE message. As 518 the figure shows, information of the triggering packet is appended to 519 the SADB_ACQUIRE message. 521 524 4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message 526 The IPsec subsystem MAY include a Packet Extension to a SADB_ACQUIRE 527 message when absence of IPsec SA is detected during outbound packet 528 processing. The IP packet to be included in the Packet Extension 529 MUST be the very IP packet which triggered the ACQUIRE message IPsec 530 sublayer. 532 The information of the triggering packet MUST contain IP header, IP 533 header options (in the case of IPv4), IP extension headers (in the 534 case of IPv6), and the transport layer protocol header if there is 535 any. 537 More than one packet extensions MUST NOT be appended to a 538 SADB_ACQUIRE message. 540 The figure below shows the format of the Packet Extension which 541 conforms the extension header specified in [RFC2367]. 543 struct sadb_x_packet { 544 uint16_t sadb_packet_len; 545 uint16_t sadb_packet_exttype; 546 uint32_t sadb_packet_copylen; 547 }; 548 /* sizeof(struct sadb_x_packet) == 8 */ 549 /* followed by an IP packet header which triggered 550 the SADB_ACQUIRE message */ 552 sadb_packet_copylen Indicates the exact length of the packet header 553 that follows the extension header. Note that the 64 bit alignment 554 rule applies to the Packet Extension thus there could be padding 555 appended to meet the alignment requirement. This padding SHOULD 556 be set to zero by the sender (kernel) and MUST be ignored by the 557 receiver. 559 4.2.2. Extracting Home Registration Information from Acquire Message 561 A receiver of a SADB_ACQUIRE message with a Packet Extension MAY 562 extract and process the extension header. 564 A Mobile IPv6 aware IKE daemon should be able to process a Packet 565 Extension which includes the IPv6 packet containing the initial home 566 registration BU message. An IPv6 packet which contains following 567 information is suspected to be a home registration Binding Update 568 message: 570 o A mobility header message with message type 5 (BU). 571 o In the BU message, Home Registration (H) bit is set. 573 The source address field of the IPv6 header is supposed to be the 574 home address of the MN. In some systems, a home address destination 575 option may be present in the IP packet. In such case, a care is 576 needed to extract the care-of address of the MN. In any case, the 577 care-of address MUST be extracted from the alternate care-of address, 578 if the option is present in the packet. 580 Recommendation: Mobile IPv6 module is recommended to include an 581 alternate care-of address option in every BU message, regardless of 582 the type of IPsec protocol (AH or ESP) which is used to protect the 583 message. 585 4.2.3. Relation of Packet Extension to IKEv2 587 The Packet Extension is useful not only for Mobile IPv6 usage but 588 also for other network scenarios where IKEv2 is used as a key 589 management protocol. 591 In IKEv2 [RFC4306], it is specified that the first traffic selector 592 of TSi and TSr should contain the information of triggering packet 593 when an initiator requests establishment of IPsec SA triggered by a 594 data packet. The Packet Extension can provide the information of the 595 triggering packet to the IKE module. 597 5. Necessary Modifications to Mobile IPv6 and IPsec/IKE 599 In order to realize the proposed mechanism, there are some necessary 600 modifications to Mobile IPv6 and IPsec/IKE. Following are the 601 summary of necessary modifications, which could be of interest to 602 implementors of Mobile IPv6 and/or IPsec/IKE. 604 o Modifications to Mobile IPv6: 605 * The Mobile IPv6 code can make an access to PF_KEY socket. In 606 particular, the Mobile IPv6 code should have privilege to write 607 messages into a PF_KEY socket. 608 * Issuing PF_KEY MIGRATE messages: in order to send MIGRATE 609 messages, it is required that the Mobile IPv6 code has some 610 knowledge of its IPsec configuration and precise binding 611 record. The Mobile IPv6 code may be aware of exact IPsec 612 configuration in form or security policy. It would also be 613 possible that the Mobile IPv6 code is only aware of minimum 614 IPsec configuration whether if IPsec is utilized or not. 615 o Modifications to IPsec: 616 * Processing PF_KEY MIGRATE messages: the kernel should be able 617 to process PF_KEY MIGRATE messages sent by the Mobile IPv6 618 code. Unless the message is invalid, it should be sent to all 619 open PF_KEY sockets. 620 * Enabling Packet Extensions (SADB_X_EXT_PACKET): the kernel 621 should be able to append a SADB_X_EXT_PACKET extension to 622 SADB_ACQUIRE messages when they are triggered by an output of a 623 data packet. 624 o Modifications to IKE: 625 * Processing PF_KEY MIGRATE messages: the IKE code may update its 626 local copy of IPsec databases (SPD and SAD) in accordance with 627 received PF_KEY MIGRATE messages. In addition, it may update 628 its state / IKE session with new endpoint addresses indicated 629 by PF_KEY MIGRATE messages. 630 * Processing of Packet Extensions (SADB_X_EXT_PACKET): the IKE 631 code may process SADB_X_EXT_PACKET extensions and extract 632 necessary information from triggering packets. In order for 633 the IKE code to be MIPv6-aware, it should properly extract the 634 home address, care-of address, and HA address from IP packets 635 which carry home registration BU messages. 637 6. Security Considerations 639 The proposed schemes in this document do not raise any security issue 640 with regard to the authenticity of the IP packets to be handled under 641 the protection of an IPsec SA pair in tunnel mode. This is because 642 authenticity of the IP packet has nothing to do with IP addresses in 643 the IP header. 645 7. Conclusion 647 o There is a need for Mobile IPv6 and IPsec/IKE to interact with 648 each other to provide full support of IPsec security functions. 649 o An extension to the PF_KEY framework (PF_KEY MIGRATE message) is 650 proposed, which makes it possible for the IPsec/IKE to migrate an 651 endpoint address of tunnel IPsec SAs from one to another. 652 o PF_KEY MIGRATE messages also make it possible for IKE to survive 653 movements by updating its IKE session. 654 o In order for the IKE to perform key negotiations and rekeying, 655 effort should be made to keep its SPD image up-to-date. 657 o The proposed mechanism was implemented on both Linux and BSD 658 platforms and confirmed to be working well. 659 o Currently, large portion of the proposed mechanism is 660 implementation dependent due to lack of standard interface to 661 access the SPD (PF_POLICY?). 663 8. References 665 8.1. Normative References 667 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 668 Management API, Version 2", RFC 2367, July 1998. 670 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 671 Internet Protocol", RFC 2401, November 1998. 673 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 674 (IKE)", RFC 2409, November 1998. 676 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 677 in IPv6", RFC 3775, June 2004. 679 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 680 Protect Mobile IPv6 Signaling Between Mobile Nodes and 681 Home Agents", RFC 3776, June 2004. 683 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 684 Internet Protocol", RFC 4301, December 2005. 686 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 687 RFC 4306, December 2005. 689 8.2. Informative References 691 [I-D.ietf-hip-mm] 692 Henderson, T., "End-Host Mobility and Multihoming with the 693 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 694 progress), March 2007. 696 [I-D.ietf-mip6-nemo-v4traversal] 697 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 698 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 699 (work in progress), November 2007. 701 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 702 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 703 RFC 3948, January 2005. 705 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 706 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 707 RFC 3963, January 2005. 709 Appendix A. PF_KEY MIGRATE Message Format 711 The figure below shows the message format of PF_KEY MIGRATE. The 712 message consists of 6 parts (boundary of each part is marked with 713 ">"). The message starts with PF_KEY base message header followed by 714 two address extensions. A pair of address extensions hold source and 715 destination address of the selector. Rest of the message are 716 specific to IPsec implementation on BSD. sadb_x_policy{} structure 717 holds additional information of security policy. The last part of 718 the message is a pair of sadb_x_ipsecrequest{} structures that hold 719 old and new SA information. 721 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 722 +---------------+---------------+---------------+---------------+ 723 | ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype | 724 +---------------+---------------+---------------+---------------+ 725 | sadb_msg_len | sadb_msg_reserved | 726 +---------------+---------------+---------------+---------------+ 727 | sadb_msg_seq | 728 +---------------+---------------+---------------+---------------+ 729 | sadb_msg_pid | 730 >+---------------+---------------+---------------+---------------+ 731 | sadb_address_len | sadb_address_exttype | 732 +---------------+---------------+---------------+---------------+ 733 | _address_proto| ..._prefixlen | sadb_address_reserved | 734 +---------------+---------------+---------------+---------------+ 735 ~ selector source address (64-bit aligned sockaddr) ~ 736 >+---------------+---------------+---------------+---------------+ 737 | sadb_address_len | sadb_address_exttype | 738 +---------------+---------------+---------------+---------------+ 739 | _address_proto| ..._prefixlen | sadb_address_reserved | 740 +---------------+---------------+---------------+---------------+ 741 ~ selector destination address (64-bit aligned sockaddr) ~ 742 >+---------------+---------------+---------------+---------------+ 743 | sadb_x_policy_len | sadb_x_policy_exttype | 744 +---------------+---------------+---------------+---------------+ 745 | sadb_x_policy_type | ..._dir | ..._reserved | 746 +---------------+---------------+---------------+---------------+ 747 | sadb_x_policy_id | 748 +---------------+---------------+---------------+---------------+ 749 | sadb_x_policy_priority | 750 >+---------------+---------------+---------------+---------------+ 751 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 752 +---------------+---------------+---------------+---------------+ 753 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 754 +---------------+---------------+---------------+---------------+ 755 | sadb_x_ipsecrequest_reqid | 756 +---------------+---------------+---------------+---------------+ 757 | sadb_x_ipsecrequest_reserved2 | 758 +---------------+---------------+---------------+---------------+ 759 ~ old tunnel source address (64-bit aligned ... ~ 760 +---------------+---------------+---------------+---------------+ 761 ~ old tunnel destination address ... pair of sockaddr) ~ 762 >+---------------+---------------+---------------+---------------+ 763 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 764 +---------------+---------------+---------------+---------------+ 765 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 766 +---------------+---------------+---------------+---------------+ 767 | sadb_x_ipsecrequest_reqid | 768 +---------------+---------------+---------------+---------------+ 769 | sadb_x_ipsecrequest_reserved2 | 770 +---------------+---------------+---------------+---------------+ 771 ~ new tunnel source address (64-bit aligned ... ~ 772 +---------------+---------------+---------------+---------------+ 773 ~ new tunnel destination address ... pair of sockaddr) ~ 774 +---------------+---------------+---------------+---------------+ 776 Following is a structure of PF_KEY base message header specified in 777 [RFC2367]. A new message type for PF_KEY MIGRATE (i.e., 778 SADB_X_MIGRATE) should be specified in member sadb_msg_type. 780 struct sadb_msg { 781 uint8_t sadb_msg_version; 782 uint8_t sadb_msg_type; 783 uint8_t sadb_msg_errno; 784 uint8_t sadb_msg_satype; 785 uint16_t sadb_msg_len; 786 uint16_t sadb_msg_reserved; 787 uint32_t sadb_msg_seq; 788 uint32_t sadb_msg_pid; 789 }; 791 Following is a structure of address extension header specified in 792 [RFC2367]. Upper layer protocol should be specified in member 793 sadb_address_proto. 795 struct sadb_address { 796 uint16_t sadb_address_len; 797 uint16_t sadb_address_exttype; 798 uint8_t sadb_address_proto; 799 uint8_t sadb_address_prefixlen; 800 uint16_t sadb_address_reserved; 801 }; 803 Following is a structure for holding attributes that are relevant to 804 security policy, which is available on BSD IPsec implementation. 805 Direction of the target security policy should be specified in member 806 sadb_x_policy_dir. 808 struct sadb_x_policy { 809 uint16_t sadb_x_policy_len; 810 uint16_t sadb_x_policy_exttype; 811 uint16_t sadb_x_policy_type; 812 uint8_t sadb_x_policy_dir; 813 uint8_t sadb_x_policy_reserved; 814 uint32_t sadb_x_policy_id; 815 uint32_t sadb_x_policy_priority; 816 }; 818 Following is a structure for holding attributes that are relevant to 819 security association, which is available on BSD IPsec implementation. 820 IPsec protocol (ESP or AH) and mode (Tunnel) of the target security 821 association should be provided in member sadb_x_ipsecrequest_proto 822 and sadb_x_ipsecrequest_mode, respectively. 824 struct sadb_x_ipsecrequest { 825 uint16_t sadb_x_ipsecrequest_len; 826 uint16_t sadb_x_ipsecrequest_proto; 827 uint8_t sadb_x_ipsecrequest_mode; 828 uint8_t sadb_x_ipsecrequest_level; 829 uint16_t sadb_x_ipsecrequest_reserved1; 830 uint32_t sadb_x_ipsecrequest_reqid; 831 uint32_t sadb_x_ipsecrequest_reserved2; 832 }; 834 Appendix B. Acknowledgements 836 The authors gratefully acknowledge the contribution of (in 837 alphabetical order): Arnaud Ebalard, Sebastien Decugis, Mitsuru 838 Kanda, Kazunori Miyazawa, Tsuyoshi Momose Shoichi Sakane, Keiichi 839 Shima, Noriaki Takamiya, and Hideaki Yoshifuji. 841 Support of NAT Traversal was suggested by Kazunori Miyazawa. 843 Kazunori Miyazawa provided valuable comments on Packet Extension. 844 Arnaud Ebalard provided valuable comments on Packet Extension based 845 on his implementation experience. 847 This document was generated by xml2rfc. 849 Authors' Addresses 851 Shinta Sugimoto 852 Nippon Ericsson K.K. 853 Koraku Mori Building 854 1-4-14, Koraku, Bunkyo-ku 855 Tokyo 112-0004 856 Japan 858 Phone: +81 3 3830 2241 859 Email: shinta.sugimoto@ericsson.com 861 Francis Dupont 862 CELAR 864 Email: Francis.Dupont@fdupont.fr 866 Masahide Nakamura 867 Hitachi Communication Technologies, Ltd. 868 216 Totsuka-cho, Totsuka-ku 869 Yokohama 244-8567 870 Japan 872 Phone: +81 45 865 7003 873 Email: masahide.nakamura.cz@hitachi.com 875 Full Copyright Statement 877 Copyright (C) The IETF Trust (2007). 879 This document is subject to the rights, licenses and restrictions 880 contained in BCP 78, and except as set forth therein, the authors 881 retain all their rights. 883 This document and the information contained herein are provided on an 884 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 885 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 886 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 887 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 888 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 889 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 891 Intellectual Property 893 The IETF takes no position regarding the validity or scope of any 894 Intellectual Property Rights or other rights that might be claimed to 895 pertain to the implementation or use of the technology described in 896 this document or the extent to which any license under such rights 897 might or might not be available; nor does it represent that it has 898 made any independent effort to identify any such rights. Information 899 on the procedures with respect to rights in RFC documents can be 900 found in BCP 78 and BCP 79. 902 Copies of IPR disclosures made to the IETF Secretariat and any 903 assurances of licenses to be made available, or the result of an 904 attempt made to obtain a general license or permission for the use of 905 such proprietary rights by implementers or users of this 906 specification can be obtained from the IETF on-line IPR repository at 907 http://www.ietf.org/ipr. 909 The IETF invites any interested party to bring to its attention any 910 copyrights, patents or patent applications, or other proprietary 911 rights that may cover technology that may be required to implement 912 this standard. Please address the information to the IETF at 913 ietf-ipr@ietf.org. 915 Acknowledgment 917 Funding for the RFC Editor function is provided by the IETF 918 Administrative Support Activity (IASA).