idnits 2.17.00 (12 Aug 2021) /tmp/idnits44369/draft-sugimoto-mip6-pfkey-migrate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** 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 350: '... an EINVAL error MUST be returned as a...' RFC 2119 keyword, line 353: '... an ENOENT error MUST be returned. If...' RFC 2119 keyword, line 354: '...d, a success (0) MUST be returned rega...' RFC 2119 keyword, line 358: '... message MUST NOT have any effect on...' RFC 2119 keyword, line 362: '... it SHOULD first check if the messag...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 2005) is 6122 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipsec-rfc2401bis' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 578, but no explicit reference was found in the text == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-ipsec-rfc2401bis has been published as RFC 4301 ** Downref: Normative reference to an Informational RFC: RFC 2367 ** 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) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 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 Expires: February 2, 2006 F. Dupont 5 Point6 6 M. Nakamura 7 Hitachi 8 August 2005 10 PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE 11 draft-sugimoto-mip6-pfkey-migrate-01 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 February 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . 4 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. Limitation of PF_KEY MIGRATE . . . . . . . . . . . . . 9 69 4.2. PF_KEY Packet Extension . . . . . . . . . . . . . . . . . 10 70 4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message . . 10 71 4.2.2. Processing SADB_ACQUIRE Message with Packet 72 Extension . . . . . . . . . . . . . . . . . . . . . . 11 73 4.2.3. Relation of Packet Extension to IKEv2 . . . . . . . . 11 74 5. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Appendix A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . 14 79 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Introduction 85 In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent 86 (HA) use some IPsec Security Associations (SAs) in tunnel mode to 87 protect some mobility signaling messages, mobile prefix discovery and 88 optionally payload traffic. Since the MN may change its attachment 89 point to the Internet, it is necessary to update its endpoint address 90 of the IPsec SAs. This indicates that corresponding entry in IPsec 91 databases (Security Policy (SPD) and SA (SADB) databases) should be 92 updated when MN performs movements. In addition, IKE requires 93 treatment to keep its IKE session alive in a Mobile IPv6 environment. 95 This document describes the need for an interface between Mobile IPv6 96 and IPsec/IKE and shows how the two protocols can interwork. We 97 propose a set of extensions to the PF_KEY framework [RFC2367] which 98 allows smooth and solid operation of IKE in an Mobile IPv6 99 environment. The first extension is called PF_KEY MIGRATE and is for 100 migrating the endpoint addresses of the IPsec SAs in tunnel mode. 101 The second extension is named SADB_X_EXT_PACKET and allows IKE to 102 make the right choice in address selection in the bootstrapping 103 process. Both extensions are helpful for assuring smooth 104 interworking between Mobile IPv6 and IPsec/IKE and achieving 105 performance optimization. 107 2. Needs for Interactions between Mobile IPv6 and IPsec/IKE 109 The section 4.4 of RFC 3776 [RFC3776] specifies the rules which 110 applies to IKEv1 for MNs and HAs. The first requirement is to run 111 IKE over the Care-of Address (CoA) because the Home Address (HoA) is 112 usable only after the home registration so not yet in the 113 bootstrapping phase. 115 A tunnel IPsec SA pair protects some signaling messages and 116 optionally all the traffic between the MN and HA. The initial SPD 117 entry uses the HoA for the MN endpoint address and updates this 118 address to the new CoA at each movement. A tunnel SA pair is created 119 on demand and is updated too. The RFC 3775 [RFC3775] assumes there 120 is an API which performs the update in the SPD and SADB on both the 121 MN and HA. This document is mainly about this API. 123 Mobile IPv6 specifies a flag named Key Management Mobility Capability 124 bit (K-bit) in Binding Update (BU) and Binding Acknowledgement (BA) 125 messages (section 10.3.1 of [RFC3775]), which indicates the ability 126 of IKE sessions to survive movement. When both the MN and HA agree 127 to use this functionality, the IKE daemons dynamically update the IKE 128 session when the MN moves. In order to realize this, IKE daemons 129 should be notified by Mobile IPv6, and necessary information to 130 migrate the IKE session should be provided. 132 Mobile IPv6 may need to make an access to the SPD not only for 133 updating an endpoint address but also for the deletion/insertion of a 134 specific SPD entry. When the MN performs Foreign-to-Home movement, 135 IPsec SAs established between the MN and HA should be deleted, which 136 means that the SPD entry should have no effect any more. On the 137 other hand, when the MN performs Home-to-Foreign movement, the IPsec 138 SAs should be restored. Hence security policy entries that are 139 associated with tunnel mode SAs may dynamically be added/removed 140 (enabled/disabled) in along with MN's movements. 142 It should be noted that NEMO Basic Support [RFC3963] has similar 143 requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO, 144 the MR works just as same as a MN registering its location 145 information to the MRHA and establishes a tunnel (IP-in-IP or IPsec 146 tunnel). When an IPsec tunnel is established between MR and MRHA, 147 the MR serves as a Security Gateway for the nodes connected to the 148 mobile network. The MR is responsible for handling its tunnel 149 endpoint properly. 151 3. Requirements 153 Given the need for an interface between Mobile IPv6 and IPsec/IKE, 154 there should be a minimum interface between the two protocols. 155 Followings are the requirements for the interface from a software 156 engineering point of view. 158 o Necessary modifications to the existing software, namely Mobile 159 IPv6 and IPsec/IKE, in order to realize proposed mechanisms, 160 should be kept minimum. 161 o Proposed mechanism should not be platform dependent. The 162 mechanism should be based on technology which is commonly 163 available on various platform. This seems to be essential for 164 achieving high portability of the implementation which supports 165 proposed mechanisms. 167 4. PF_KEY Extensions for Mobile IPv6 169 In order to fulfil the needs and requirements described in Section 2 170 and Section 3 we propose to extend the PF_KEY framework so that 171 Mobile IPv6 and IPsec/IKE could interact with each other. 173 4.1. PF_KEY MIGRATE Message 175 The first extension is primarily for migrating an endpoint address of 176 an IPsec SA pair in tunnel mode from one to another, which results in 177 updating IPsec databases. A new PF_KEY message named MIGRATE is 178 introduced for the mechanism. 180 4.1.1. Overview 182 The figure below illustrates how Mobile IPv6 and IPsec/IKE components 183 interact with each other using PF_KEY MIGRATE messages in a dynamic 184 keying scenario. On left top, there is a Mobile IPv6 entity. It may 185 be possible that Mobile IPv6 component is completely implemented 186 inside the kernel (this is the case for our implementations because 187 it makes some facilities and extensions far easier at the cost of 188 maintaining a SPD image in daemons). In any case, Mobile IPv6 should 189 be the one which issues the MIGRATE messages. On right top, there is 190 an IKE daemon which is responsible for establishing SAs required for 191 Mobile IPv6 operation. In a manual keying scenario, the difference 192 is only that there is no IKE daemon running on the system. 194 +-------------+ +------------+ 195 | | | | 196 | Mobile IPv6 | | IKE Daemon | 197 | | | | 198 +-------------+ +------------+ 199 | 1. PF_KEY A 4. Update 200 | MIGRATE | SPD & SADB 201 +-----------+ +-----------+ 202 | | 203 Userland V | 204 ==========================[PF_KEY Socket]======================== 205 Kernel | | 206 +----------+ +----------+ 207 | 2. Update | 3. Update 208 V SPD V SADB 209 +-----------+ +------------+ 210 | | | | 211 | SPD | | SADB | 212 | | | | 213 +-----------+ +------------+ 215 The primary role of PF_KEY MIGRATE messages is to migrate endpoint 216 addresses of tunnel mode SA pairs requesting IPsec to update its 217 databases (SPD and SADB). In addition, the new message can be used 218 by IKE to enhance its mobility capability. When a PF_KEY MIGRATE 219 message is properly processed by the kernel, it is sent to all open 220 sockets as normal PF_KEY messages. The processing of a sequence of 221 MIGRATE messages is done in following steps: 223 o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket. 224 o The operating system (kernel) validates the message and checks if 225 corresponding security policy entry exists in SPD. 226 o When the message is confirmed to be valid, the target SPD entry is 227 updated according to the MIGRATE message. If there is any target 228 SA found that are also target of the update, those should also be 229 updated. 230 o After the MIGRATE message is successfully processed inside the 231 kernel, it will be sent to all open PF_KEY sockets. 232 o The IKE daemon receives the MIGRATE message from its PF_KEY socket 233 and updates its SPD and SADB images. The IKE daemon may also 234 update its state to keep the IKE session alive. 236 Note that the way IKE maintains its local copy of SPD (the SPD image) 237 is implementation specific issue since there is no standard interface 238 to access SPD. Some IKE implementation may continuously monitor the 239 SPD inside the kernel. Some IKE implementation may expect 240 notification from the kernel when the SPD is modified. In either 241 way, the proposed mechanism gives a chance for IKE to keep its SPD 242 image up-to-date which is significant in Mobile IPv6 operation. 244 4.1.2. Message Sequence 246 Next, we will see how migration takes place in along with home 247 registration. The figure below shows sequence of mobility signaling 248 and PF_KEY MIGRATE messages while the MN roams around links. It is 249 assumed that in the initial state the tunnel endpoint address for a 250 given MN is set as its home address. In the initial home 251 registration, the MN and HA migrate the tunnel endpoint address from 252 the HoA to CoA1. It should be noted that no migration takes place 253 when the MN performs re-registration since the care-of address 254 remains the same. Accordingly, the MN performs movement and changes 255 its primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE 256 message is issued on both MN and HA for each direction. When the MN 257 returns to home, migration takes place updating the endpoint address 258 with the MN's home address. 260 MN HA 261 | | 262 ~ ~ 263 Movement->| BU (Initial home registration) | 264 |----------------------------------------->| 265 MIGRATE ->| BA |<- MIGRATE 266 (HoA->CoA1) |<-----------------------------------------| (HoA->CoA1) 267 | | 268 ~ BU (Home re-registration) ~ 269 |----------------------------------------->| 270 | BA | 271 |<-----------------------------------------| 272 | | 273 ~ ~ 274 | | 275 Movement->| BU (Home registration) | 276 |----------------------------------------->| 277 MIGRATE ->| BA |<- MIGRATE 278 (CoA1->CoA2)|<-----------------------------------------| (CoA1->CoA2) 279 | | 280 ~ ~ 281 Movement->| BU (Home de-registration) | 282 |----------------------------------------->| 283 MIGRATE ->| BA |<- MIGRATE 284 (CoA2->HoA) |<-----------------------------------------| (CoA2->HoA) 285 | | 287 4.1.3. Issuing PF_KEY MIGRATE Message 289 The Mobile IPv6 entity (MN or HA code) triggers the migration by 290 sending a PF_KEY MIGRATE message to its PF_KEY socket. Conceptually, 291 the PF_KEY MIGRATE message should contain following information: 293 o Selector information: 294 * source address/port 295 * destination address/port 296 * upper layer protocol (i.e., Mobility Header) 297 * direction (inbound/outbound) 298 o Old SA information: 299 * old source endpoint address 300 * old destination endpoint address 301 * IPsec protocol (ESP/AH) 302 * mode (Tunnel) 303 o New SA information: 304 * new source endpoint address 305 * new destination endpoint address 306 * IPsec protocol (ESP/AH) 307 * mode (Tunnel) 309 Selector information is required for specifying the target SPD entry 310 to be updated. Basically the information should contain necessary 311 elements which characterize traffic selector as specified in 312 [RFC2401]. With regard to the upper layer protocol, when the Mobile 313 IPv6 stack is not fully aware of IPsec configuration, an wild-card 314 value could be given. In such case, an upper layer protocol 315 information should not be taken into account for searching SPD entry. 316 Plus, the direction of the security policy (inbound/outbound) should 317 be provided. The old SA information is used to specify target 318 security association to be updated. The source and destination 319 addresses of the target entry should be overwritten with the ones 320 included in the new SA information. Note that the IPsec protocol and 321 mode fields should not be updated by a PF_KEY MIGRATE message. 323 A PF_KEY MIGRATE message should be formed based on security policy 324 configuration and binding record. The selector information and some 325 parts of the SA information (IPsec protocol and mode) should be taken 326 from the policy configuration. The rest of the information should be 327 taken from the sequential binding information. For example, in the 328 case where the MN updates its inbound security policy and 329 corresponding tunnel mode SA pair, the old source address should be 330 set as its previous CoA, and the new source address should be set as 331 its current CoA. Hence, the MN should sequentially keep track of its 332 CoA record. Such information shall be stored in binding update list 333 entry. For the same reason, the HA should keep track of previous 334 CoAs of MNs. Such information shall be stored in binding cache 335 entry. 337 Additionally, a piece of information which indicates a mobility 338 capability of IKE (K-bit) should be provided by any means. This 339 makes it possible for IKE to see if there is a need to update its 340 state (IKE endpoint addresses) in accordance with PF_KEY MIGRATE 341 messages. 343 A detailed message format of PF_KEY MIGRATE is provided in 344 Appendix A. 346 4.1.4. Processing PF_KEY MIGRATE Message 348 Since a PF_KEY MIGRATE message is applied to a single SPD entry, the 349 kernel should first check validity of the message. If the message is 350 invalid, an EINVAL error MUST be returned as a return value for the 351 write() operation made to the PF_KEY socket. After the validation, 352 the kernel checks if the target SPD entry really exists. If no entry 353 is found, an ENOENT error MUST be returned. If a SPD entry is found 354 and successfully updated, a success (0) MUST be returned regardless 355 of subsequent result of SADB lookup/update. Note that there may be a 356 case where a corresponding SADB entry does not exist even if a SPD 357 entry is successfully updated. In any error case, a PF_KEY MIGRATE 358 message MUST NOT have any effect on the SPD and SADB. 360 With respect to the behavior of a normal process (including the IKE 361 daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket, 362 it SHOULD first check if the message does not include erroneous 363 information. When there is any error indicated, the process MUST 364 silently discard the PF_KEY MIGRATE message. Otherwise, the 365 processing of the message may continue. 367 4.1.5. Applicability of PF_KEY MIGRATE to Other Systems 369 It should be noted that the PF_KEY MIGRATE extension is also 370 applicable to other systems than Mobile IPv6 and/or IKEv1. For 371 example, it can be used in a scenario where an IPsec/IKE enabled node 372 establishes tunnel mode SAs association with its Security Gateway 373 while it roams around the network (aka "road warrior"). The security 374 policy is set as such that all traffic should bi-directionally go 375 through the tunnel IPsec SAs. In such case, the migration of a 376 tunnel endpoint address can be handled by PF_KEY MIGRATE messages. 377 Each time the node changes its attachment point to the Internet, 378 PF_KEY MIGRATE messages should be issued to the system. 379 Consequently, the IPsec databases (SPD and SADB) shall be properly 380 updated. 382 It is also essential to keep design of the mechanism protocol 383 independent. More specifically, the PF_KEY MIGRATE extension should 384 be able to work on both IPv4 and IPv6. In order to achieve this, the 385 IP addresses to be stored in selector and SA information should be 386 handled in a protocol-independent manner. 388 4.1.6. Limitation of PF_KEY MIGRATE 390 Currently, a Security Parameter Index (SPI) is not included in the 391 old SA information to specify target SADB entry. This helps to 392 lessen operational burden of Mobile IPv6. However, this 393 simplification can produce ambiguity in searching for the target 394 security association entry. When the unique SPD level is available, 395 it should be use because it avoids this problem both by marking the 396 SAs to update and by limiting SA sharing. 398 It should be noted that delivery of PF_KEY MIGRATE messages cannot be 399 guaranteed, which is common to other PF_KEY messages. It may be 400 possible that a MIGRATE message is lost. In such case, there will be 401 inconsistency between the binding record managed by Mobile IPv6 and 402 IPsec database inside the kernel. Once a PF_KEY MIGRATE message is 403 lost, it would not be possible for the receiver to process some 404 subsequent MIGRATE messages properly. Reinitialization of the Mobile 405 IPv6 stack and IPsec databases may be needed for recovery. 407 4.2. PF_KEY Packet Extension 409 In the initial stage of MIPv6 operation known as the bootstrapping 410 process, the MN and HA probably need to establish SAs from scratch in 411 order to start the MIPv6 operation. If IKE is used to maintain the 412 SAs, the MN and HA are required to establish a transport mode SA pair 413 so that the MN could make the initial protected home registration to 414 the HA. As mentioned in RFC 3776 [RFC3776], the IKE negotiation 415 should be done carefully in terms of handling the identity of the MN. 416 More specifically, IKE must be run over the MN's primary CoA while 417 the SA pair should be based on the MN's HoA. Note that the HoA 418 cannot be used prior to the initial home registration. This is an 419 exceptional case of IKE negotiation in a sense that the peer address 420 (the address on which IKE runs) and the IP address to be used as 421 selector for the SAs are different. Since IKE should not be required 422 to maintain mobility state, there is a need to guide IKE to make the 423 right choice for address/identity. 425 A simple solution for this explicit notification can be provided by 426 extending PF_KEY framework by including information of the triggering 427 packet into SADB_ACQUIRE messages. This extension allows receiver of 428 a SADB_ACQUIRE message to determine which address to use for what 429 purpose, i.e., to recognize the exceptional case as all the needed 430 informations are already in the home registration binding update. As 431 shown below, a SADB_ACQUIRE message MAY contain an extension which 432 contains the triggering packet (the whole packet, information 433 extracted from it by the kernel or as we recommend enough of the 434 beginning of it). 436 439 4.2.1. Inserting Packet Extension to SADB_ACQUIRE Message 441 The IPsec subsystem MAY include a Packet Extension to a SADB_ACQUIRE 442 message when it is triggered by an output of data packet. The Packet 443 Extension simply contains the information of the triggering packet. 444 Like any other extension headers specified in RFC 2367 [RFC2367], a 445 Packet Extension (SADB_X_EXT_PACKET) MUST follow the basic rules and 446 be formulated in the type-length-value format. A redundant part of 447 the original IP packet (i.e., payload/tralier) MAY be eliminated. 448 More than one Packet Extension header MUST NOT be appended to the 449 message. A sadb_x_packet extension header is followed by an IP 450 packet which has triggered the SADB_ACQUIRE message. Note that the 451 Packet Extension is protocol independent, which means that the 452 triggering packet included in the extension header could be either 453 IPv4 or IPv6. The address family of the triggering packet can be 454 recognized by the first 4 bits of the IP packet. 456 struct sadb_x_packet { 457 uint16_t sadb_packet_len; 458 uint16_t sadb_packet_exttype; 459 }; 460 /* sizeof(struct sadb_x_packet) == 4 */ 461 /* followed by an IP packet header which triggered 462 the SADB_ACQUIRE message */ 464 4.2.2. Processing SADB_ACQUIRE Message with Packet Extension 466 A receiver of a SADB_ACQUIRE message with a Packet Extension MAY 467 extract and process the extension header. A MIPv6-aware IKE daemon 468 should be able to process a Packet Extension which includes the IPv6 469 packet which carries an initial home registration BU message. Such 470 packet includes a home address destination option which contains the 471 primary CoA of the MN and the source address field of the IPv6 header 472 contains the HoA of the MN (note the exact layout depends on the 473 place of the IPsec acquiring code, we assume here its place follows 474 the section 11.3.2 of [RFC3775]). The destination address field of 475 the IPv6 header contains the address of the HA, the mobility header a 476 BU (type 5) for home registration (H flag set to one). 478 Receipt of SADB_ACQUIRE Message with Packet Extension containing BU 479 message implies that IKE is required to establish SAs for the MIPv6 480 home registration. Accordingly, the IKE should be able to make a 481 right choice of address selection. The CoA must be used as a peer 482 address in the IKE negotiation and the HoA should be used as selector 483 of transport mode SAs and as endpoint address of tunnel mode SAs. 485 4.2.3. Relation of Packet Extension to IKEv2 487 In IKEv2 [I-D.ietf-ipsec-ikev2], when the initiator has requested to 488 establish SAs triggered by a data packet, the first traffic selector 489 of TSi and TSr should reflect the triggering packet. Therefore, 490 IKEv2 could take advantage of Packet Extensions when some information 491 from triggering packets are needed for a traffic selector 492 negotiation. 494 5. Necessary Modifications to Mobile IPv6 and IPsec/IKE 496 In order to realize the proposed mechanism, there are some necessary 497 modifications to Mobile IPv6 and IPsec/IKE. Following are the 498 summary of necessary modifications, which could be of interest to 499 implementors of Mobile IPv6 and/or IPsec/IKE. 501 o Modifications to Mobile IPv6: 502 * The Mobile IPv6 code can make an access to PF_KEY socket. In 503 particular, the Mobile IPv6 code should have privilege to write 504 messages into a PF_KEY socket. 505 * Issuing PF_KEY MIGRATE messages: in order to form MIGRATE 506 messages, it is required that the Mobile IPv6 code has some 507 knowledge of its IPsec configuration and precise binding 508 record. The Mobile IPv6 code may be aware of exact IPsec 509 configuration in form or security policy. It would also be 510 possible that the Mobile IPv6 code is only aware of minimum 511 IPsec configuration whether if IPsec is utilized or not. 512 o Modifications to IPsec: 513 * Processing PF_KEY MIGRATE messages: the kernel should be able 514 to process PF_KEY MIGRATE messages sent by the Mobile IPv6 515 code. Unless the message is invalid, it should be sent to all 516 open PF_KEY sockets. 517 * Enabling Packet Extensions (SADB_X_EXT_PACKET): the kernel 518 should be able to append a SADB_X_EXT_PACKET extension to 519 SADB_MIGRATE messages when they are triggered by an output of a 520 data packet. 521 o Modifications to IKE: 522 * Processing PF_KEY MIGRATE messages: the IKE code may update its 523 local copy of IPsec databases (SPD and SADB) in accordance with 524 received PF_KEY MIGRATE messages. In addition, it may update 525 its state / IKE session with new endpoint addresses indicated 526 by PF_KEY MIGRATE messages. 527 * Processing of Packet Extensions (SADB_X_EXT_PACKET): the IKE 528 code may process SADB_X_EXT_PACKET extensions and extract 529 necessary information from triggering packets. In order for 530 the IKE code to be MIPv6-aware, it should properly extract the 531 home address, care-of address, and HA address from IP packets 532 which carry home registration BU messages. 534 6. Security Considerations 536 There is no specific security considerations for the mechanisms 537 introduced by the document but as it should make deployment of 538 dynamic keying in Mobile IPv6 environments easier it should improve 539 the security of such environments. Note that dynamic keying is known 540 to be more secure (it provides anti-replay for instance) and far more 541 scalable. 543 7. Conclusion 545 o There is a need for Mobile IPv6 and IPsec/IKE to interact with 546 each other to provide full support of IPsec security functions. 547 o An extension to the PF_KEY framework (PF_KEY MIGRATE message) is 548 proposed, which makes it possible for the IPsec/IKE to migrate an 549 endpoint address of tunnel IPsec SAs from one to another. 550 o PF_KEY MIGRATE messages also make it possible for IKE to survive 551 movements by updating its IKE session. 552 o In order for the IKE to perform key negotiations and rekeying, 553 effort should be made to keep its SPD image up-to-date. 554 o The proposed mechanism was implemented on both Linux and BSD 555 platforms and confirmed to be working well. 556 o Currently, large portion of the proposed mechanism is 557 implementation dependent due to lack of standard interface to 558 access the SPD (PF_POLICY?). 560 8. References 562 [I-D.ietf-ipsec-ikev2] 563 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 564 draft-ietf-ipsec-ikev2-17 (work in progress), 565 October 2004. 567 [I-D.ietf-ipsec-rfc2401bis] 568 Kent, S. and K. Seo, "Security Architecture for the 569 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 570 in progress), April 2005. 572 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 573 Management API, Version 2", RFC 2367, July 1998. 575 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 576 Internet Protocol", RFC 2401, November 1998. 578 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 579 (IKE)", RFC 2409, November 1998. 581 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 582 in IPv6", RFC 3775, June 2004. 584 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 585 Protect Mobile IPv6 Signaling Between Mobile Nodes and 586 Home Agents", RFC 3776, June 2004. 588 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 589 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 590 RFC 3963, January 2005. 592 Appendix A. PF_KEY MIGRATE Message Format 594 The figure below shows the message format of PF_KEY MIGRATE. The 595 message consists of 6 parts (boundary of each part is marked with 596 ">"). The message starts with PF_KEY base message header followed by 597 two address extensions. A pair of address extensions hold source and 598 destination address of the selector. Rest of the message are 599 specific to IPsec implementation on BSD. sadb_x_policy{} structure 600 holds additional information of security policy. The last part of 601 the message is a pair of sadb_x_ipsecrequest{} structures that hold 602 old and new SA information. 604 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 605 +---------------+---------------+---------------+---------------+ 606 | ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype | 607 +---------------+---------------+---------------+---------------+ 608 | sadb_msg_len | sadb_msg_reserved | 609 +---------------+---------------+---------------+---------------+ 610 | sadb_msg_seq | 611 +---------------+---------------+---------------+---------------+ 612 | sadb_msg_pid | 613 >+---------------+---------------+---------------+---------------+ 614 | sadb_address_len | sadb_address_exttype | 615 +---------------+---------------+---------------+---------------+ 616 | _address_proto| ..._prefixlen | sadb_address_reserved | 617 +---------------+---------------+---------------+---------------+ 618 ~ selector source address (64-bit aligned sockaddr) ~ 619 >+---------------+---------------+---------------+---------------+ 620 | sadb_address_len | sadb_address_exttype | 621 +---------------+---------------+---------------+---------------+ 622 | _address_proto| ..._prefixlen | sadb_address_reserved | 623 +---------------+---------------+---------------+---------------+ 624 ~ selector destination address (64-bit aligned sockaddr) ~ 625 >+---------------+---------------+---------------+---------------+ 626 | sadb_x_policy_len | sadb_x_policy_exttype | 627 +---------------+---------------+---------------+---------------+ 628 | sadb_x_policy_type | ..._dir | ..._reserved | 629 +---------------+---------------+---------------+---------------+ 630 | sadb_x_policy_id | 631 +---------------+---------------+---------------+---------------+ 632 | sadb_x_policy_priority | 633 >+---------------+---------------+---------------+---------------+ 634 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 635 +---------------+---------------+---------------+---------------+ 636 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 637 +---------------+---------------+---------------+---------------+ 638 | sadb_x_ipsecrequest_reqid | 639 +---------------+---------------+---------------+---------------+ 640 | sadb_x_ipsecrequest_reserved2 | 641 +---------------+---------------+---------------+---------------+ 642 ~ old tunnel source address (64-bit aligned sockaddr) ~ 643 +---------------+---------------+---------------+---------------+ 644 ~ old tunnel destination address (64-bit aligned sockaddr) ~ 645 >+---------------+---------------+---------------+---------------+ 646 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 647 +---------------+---------------+---------------+---------------+ 648 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 649 +---------------+---------------+---------------+---------------+ 650 | sadb_x_ipsecrequest_reqid | 651 +---------------+---------------+---------------+---------------+ 652 | sadb_x_ipsecrequest_reserved2 | 653 +---------------+---------------+---------------+---------------+ 654 ~ new tunnel source address (64-bit aligned sockaddr) ~ 655 +---------------+---------------+---------------+---------------+ 656 ~ new tunnel destination address (64-bit aligned sockaddr) ~ 657 +---------------+---------------+---------------+---------------+ 659 Following is a structure of PF_KEY base message header specified in 660 [RFC2367]. A new message type for PF_KEY MIGRATE (i.e., 661 SADB_X_MIGRATE) should be specified in member sadb_msg_type. 663 struct sadb_msg { 664 uint8_t sadb_msg_version; 665 uint8_t sadb_msg_type; 666 uint8_t sadb_msg_errno; 667 uint8_t sadb_msg_satype; 668 uint16_t sadb_msg_len; 669 uint16_t sadb_msg_reserved; 670 uint32_t sadb_msg_seq; 671 uint32_t sadb_msg_pid; 672 }; 674 Following is a structure of address extension header specified in 675 [RFC2367]. Upper layer protocol should be specified in member 676 sadb_address_proto. 678 struct sadb_address { 679 uint16_t sadb_address_len; 680 uint16_t sadb_address_exttype; 681 uint8_t sadb_address_proto; 682 uint8_t sadb_address_prefixlen; 683 uint16_t sadb_address_reserved; 684 }; 686 Following is a structure for holding attributes that are relevant to 687 security policy, which is available on BSD IPsec implementation. 689 Direction of the target security policy should be specified in member 690 sadb_x_policy_dir. 692 struct sadb_x_policy { 693 uint16_t sadb_x_policy_len; 694 uint16_t sadb_x_policy_exttype; 695 uint16_t sadb_x_policy_type; 696 uint8_t sadb_x_policy_dir; 697 uint8_t sadb_x_policy_reserved; 698 uint32_t sadb_x_policy_id; 699 uint32_t sadb_x_policy_priority; 700 }; 702 Following is a structure for holding attributes that are relevant to 703 security association, which is available on BSD IPsec implementation. 704 IPsec protocol (ESP or AH) and mode (Tunnel) of the target security 705 association should be provided in member sadb_x_ipsecrequest_proto 706 and sadb_x_ipsecrequest_mode, respectively. 708 struct sadb_x_ipsecrequest { 709 uint16_t sadb_x_ipsecrequest_len; 710 uint16_t sadb_x_ipsecrequest_proto; 711 uint8_t sadb_x_ipsecrequest_mode; 712 uint8_t sadb_x_ipsecrequest_level; 713 uint16_t sadb_x_ipsecrequest_reserved1; 714 uint32_t sadb_x_ipsecrequest_reqid; 715 uint32_t sadb_x_ipsecrequest_reserved2; 716 }; 718 Appendix B. Acknowledgements 720 The authors gratefully acknowledge the contribution of: Kazunori 721 Miyazawa, Noriaki Takamiya, Shoichi Sakane, Mitsuru Kanda, Keiichi 722 Shima, Tsuyoshi Momose and other members from USAGI Project and KAME 723 Project. 725 Authors' Addresses 727 Shinta Sugimoto 728 Nippon Ericsson K.K. 729 Koraku Mori Building 730 1-4-14, Koraku, Bunkyo-ku 731 Tokyo 112-0004 732 Japan 734 Phone: +81 3 3830 2241 735 Email: shinta.sugimoto@ericsson.com 737 Francis Dupont 738 Point6 739 c/o GET/ENST Bretagne 740 2 rue de la Chataigneraie 741 CS 17607 742 35576 Cesson-Sevigne Cedex 743 France 745 Fax: +33 2 99 12 70 30 746 Email: Francis.Dupont@enst-bretagne.fr 748 Masahide Nakamura 749 Hitachi Communication Technologies, Ltd. 750 216 Totsuka-cho, Totsuka-ku 751 Yokohama 244-8567 752 Japan 754 Phone: +81 45 865 7003 755 Email: masahide_nakamura@hitachi-com.co.jp 757 Intellectual Property Statement 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 Disclaimer of Validity 783 This document and the information contained herein are provided on an 784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 786 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 787 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 788 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 791 Copyright Statement 793 Copyright (C) The Internet Society (2005). This document is subject 794 to the rights, licenses and restrictions contained in BCP 78, and 795 except as set forth therein, the authors retain all their rights. 797 Acknowledgment 799 Funding for the RFC Editor function is currently provided by the 800 Internet Society.