idnits 2.17.00 (12 Aug 2021) /tmp/idnits25283/draft-ebalard-mext-pfkey-enhanced-migrate-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([MIGRATE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 30, 2010) is 4251 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 5996 (Obsoleted by RFC 7296) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ebalard 3 Internet-Draft EADS 4 Intended status: Informational S. Decugis 5 Expires: April 3, 2011 NICT 6 September 30, 2010 8 PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE 9 draft-ebalard-mext-pfkey-enhanced-migrate-01 11 Abstract 13 This document describes the need for an interface between Mobile IPv6 14 and IPsec/IKE and shows how the two protocols can interwork. An 15 extension of the PF_KEY framework is proposed which allows smooth and 16 solid operation of IPsec/IKE in a Mobile IPv6 environment. 18 This document is heavily based on a previous draft [MIGRATE] written 19 by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply 20 reuses the MIGRATE mechanism defined in the expired document, removes 21 a companion extension (SADB_X_EXT_PACKET) based on implementation 22 feedback (complexity, limitations, ...) and fills the gap by very 23 simple changes to MIGRATE mechanism. This results in a more simple 24 and consistent mechanism, which also proved to be easier to 25 implement. This document is expected to serve as a continuation of 26 [MIGRATE] work. For that reason, the name of the extension has been 27 kept. 29 PF_KEY MIGRATE message serves as a carrier for updated information 30 for both the in-kernel IPsec structures (Security Policy Database / 31 Security Association Database) and those maintained by the key 32 managers. This includes in-kernel Security Policy / Security 33 Association endpoints, key manager maintained equivalents, and 34 addresses used by IKE_SA (current and to be negotiated). The 35 extension is helpful for assuring smooth interworking between Mobile 36 IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their 37 movements. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 3, 2011. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 5 76 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message . . 6 78 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1.1. System Overview . . . . . . . . . . . . . . . . . . . 7 80 5.1.2. Bootstrapping . . . . . . . . . . . . . . . . . . . . 8 81 5.1.3. Movement . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.1.4. IKE_SA Update . . . . . . . . . . . . . . . . . . . . 10 83 5.2. Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . . . 11 84 5.3. Processing PF_KEY MIGRATE Message . . . . . . . . . . . . 12 85 5.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 86 5.5. Limitations of PF_KEY MIGRATE . . . . . . . . . . . . . . 13 87 6. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 14 88 7. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 15 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Appendix A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . 17 96 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent 102 (HA) use some IPsec Security Associations (SA): 104 o in transport mode to protect signaling traffic (Binding Update and 105 Binding Ack). Those SA reference the Home Address (HoA) of the 106 MN. 107 o in tunnel mode to protect some mobility signaling messages, mobile 108 prefix discovery and optionally payload traffic. Those SA 109 reference both the Care-of Address (CoA) and the HoA of the MN. 111 To negotiate initial transport mode SA, the IKE daemon needs to be 112 directed to use current CoA as source of the IKE exchanges. By 113 default, the (currently unusable) HoA would be used. 115 Later, since the MN may change its attachment point to the Internet, 116 it is necessary for it to update the tunnel endpoint address of its 117 IPsec SA. This indicates that corresponding entries in IPsec 118 databases (Security Policy (SPD) and Security Association (SAD) 119 databases) should be updated when MN performs movements. 121 In a Mobile IPv6 environment, the key manager (KM) also needs to be 122 notified when the SPD and SAD are updated. More generally, it needs 123 to be provided with updated addresses for already negotiated and 124 future IKE_SA. Because of its role and unlike common applications, a 125 key manager has to take part to the mobility process it secures: it 126 needs to be aware of address changes. 128 This document describes the need for an interface between Mobile IPv6 129 and IPsec/IKE and shows how the two protocols can interwork. An 130 extension to the PF_KEY framework [RFC2367] which allows smooth and 131 solid operation of IKE in a Mobile IPv6 environment is defined. The 132 extension is called PF_KEY MIGRATE and serves as a carrier for the 133 necessary information for both the in-kernel IPsec stack and the key 134 managers. 136 For the IPsec stack, this allows migrating the endpoint addresses of 137 the IPsec SA (and associated SP). For the key managers, this allows 138 the mirrored structures to be updated (SAD and SPD). This also 139 allows the addresses of already negotiated and associated IKE_SA to 140 be migrated, and to make specific addresses available for 141 negotiations of future IKE_SA. This set of operations performed by 142 the key manager on its internal structures is initiated by the MIPv6 143 process. 145 With the extension, the bootstrapping of the MN appears as a common 146 operation for IKE, by having the right addresses needed for the 147 negotiation available prior to its beginning (i.e. at the reception 148 of the PF_KEY ACQUIRE message by the IKE daemon). 150 The extension is helpful for assuring smooth interworking between 151 Mobile IPv6 and IPsec/IKE and achieving performance optimization: 152 upon movement, both sides (MN and HA) locally notify the IPsec stack 153 and the key manager of the new CoA, thus preventing the need to flush 154 and renegotiate existing SA. 156 As stated in the abstract, this document is heavily based on the 157 content of a previous draft MIGRATE [MIGRATE]. This expired memo 158 served as the basis for this work both from technical and editorial 159 standpoints. Numerous technical discussions with some of its authors 160 took place while working on this memo and associated implementations. 162 2. Terminology 164 In this document, the term IKE implicitly stands for both IKEv1 165 [RFC2409] and IKEv2 [RFC5996]. IKEv2 terminology is used 166 preferentially when describing actions performed by the key manager 167 but they also apply to the IKEv1 counterparts. For instance, when 168 actions occur on IKE_SA, they also apply to ISAKMP SA for IKEv1, 169 except otherwise specified. The terms "IKE daemon" and "Key Manager 170 (KM)" are used interchangeably in the document. 172 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 3. Needs for Interactions between Mobile IPv6 and IPsec/IKE 178 Sections 4.4 of [RFC3776] and [RFC4877] specify the rules which apply 179 to IKE for MN and HA. The first requirement is to run IKE over the 180 Care-of Address because the Home Address is usable only after the 181 home registration but not yet in the bootstrapping phase, when 182 Transport mode IPsec SA are commonly negotiated to protect BU/BA. 184 A tunnel IPsec SA pair protects some signaling messages and 185 optionally all the traffic between the MN and HA. The initial SPD 186 entry uses the HoA for the MN endpoint address and updates this 187 address to the new CoA at each movement. A tunnel SA pair is created 188 on demand and is updated too. RFC 3775 [RFC3775] assumes there is an 189 API which performs the update in the SPD and SAD on both the MN and 190 HA, and notify the IKE daemon. This memo proposes such an API based 191 on PF_KEY framework both to document the needs and ease 192 interoperability between components which may be provided by 193 different vendors. 195 Mobile IPv6 may need to make an access to the SPD not only for 196 updating an endpoint address but also for deleting/inserting a 197 specific SPD entry. When the MN performs Foreign-to-Home movement, 198 IPsec SA established between the MN and HA to protect data traffic 199 should be deleted, and associated SPD entries should have no effect 200 anymore. On the other hand, when the MN performs Home-to-Foreign 201 movement, those IPsec SP should be restored. Hence security policy 202 entries that are associated with tunnel mode SA may dynamically be 203 added/removed (enabled/disabled) in along with MN's movements. As a 204 side note for such a scenario, Home Link detection mechanism becomes 205 critical security-wise [hld-sec]. 207 It should be noted that NEMO Basic Support [RFC3963] has similar 208 requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO, 209 the MR works just like a MN registering its location information to 210 the MRHA and establishes a tunnel (IP-in-IP or IPsec tunnel). When 211 an IPsec tunnel is established between MR and MRHA, the MR serves as 212 a Security Gateway for the nodes connected to the mobile network. 213 The MR is responsible for handling its tunnel endpoint properly. 215 4. Requirements 217 Despite the need for an interface between Mobile IPv6 and IPsec/IKE, 218 it should be kept simple. Following are the requirements for the 219 interface from a software engineering point of view. 221 o Necessary modifications to the existing software, namely Mobile 222 IPv6 and IPsec/IKE, in order to realize proposed mechanisms, 223 should be kept minimum. 224 o Proposed mechanism should not be platform dependent. The 225 mechanism should be based on technology which is commonly 226 available on various platforms. This seems to be essential for 227 achieving high portability of the implementation which supports 228 proposed mechanisms. 230 5. PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message 232 In order to fulfill the needs and requirements described in Section 3 233 and Section 4 an extension of PF_KEY framework is proposed so that 234 Mobile IPv6 and IPsec/IKE can interact with each other. The new 235 message dedicated to that function is called MIGRATE. A new simple 236 PF_KEY structure (struct sadb_x_kmaddress, see Appendix A) is also 237 defined to be used by MIGRATE to serve the purpose of IKE_SA update. 239 5.1. Overview 241 5.1.1. System Overview 243 The MIGRATE message is used for providing updated information to its 244 two targets, the kernel IPsec stack and the key manager (when used). 245 The figure below illustrates how Mobile IPv6 and IPsec/IKE components 246 interact with each other using PF_KEY MIGRATE message in a dynamic 247 keying scenario. On left top is a Mobile IPv6 entity (it may be 248 possible that Mobile IPv6 component is completely implemented inside 249 the kernel). In any case, Mobile IPv6 should be the one issuing the 250 MIGRATE message. On right top is an IKE daemon which is responsible 251 for establishing SA required for Mobile IPv6 operation. In a manual 252 keying scenario, the difference is mainly that there is no IKE daemon 253 running on the system. 255 +-------------+ +------------+ 256 | | | | 257 | Mobile IPv6 | | IKE Daemon | 258 | | | | 259 +-------------+ +------------+ 260 | 1. PF_KEY A 4. Update SPD & SAD 261 | MIGRATE | 5. Update IKE_SA 262 +-----------+ +-----------+ 263 | | 264 Userland V | 265 ==========================[PF_KEY Socket]======================== 266 Kernel | | 267 +----------+ +----------+ 268 | 2. Update | 3. Update 269 V SPD V SAD 270 +-----------+ +------------+ 271 | | | | 272 | SPD | | SAD | 273 | | | | 274 +-----------+ +------------+ 276 In the kernel, the primary role of PF_KEY MIGRATE message is to 277 change the endpoint addresses of SA, i.e. requesting IPsec to update 278 its databases (SPD and SAD). Even if tunnel mode is the primary 279 target for MIPv6, MIGRATE is not limited to that mode. Then, after 280 proper processing by the kernel, the MIGRATE message is sent to all 281 open PF_KEY socket. A listening key manager processes it , which 282 results in a possible update of its internal structures. The 283 specific actions are introduced on the following figure. 285 MIPv6 ---------------- kernel -------------------> IKE 286 process 287 1) update of SP 1) Update of SA and SP 288 endpoints and endpoints (in image) 289 associated SA. 2) Update of source and 290 destination addresses 291 in SPD image for 292 future SA negotiation 293 3) Update of IKE_SA 294 source and destination 295 addresses associated 296 with provided SA 298 In more details, the processing of a MIGRATE message can be divided 299 in following steps: 301 o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket. 302 o The operating system (kernel IPsec stack) validates the message 303 and checks if corresponding security policy entry exists in SPD. 304 o When the message is confirmed to be valid, the SPD entry is 305 updated according to the MIGRATE message. If there is any target 306 SA found that is also target of the update, it is also updated. 307 This is detailed in Section 5.3. 308 o After the MIGRATE has been successfully processed inside the 309 kernel, it is sent to all open PF_KEY sockets. 310 o The IKE daemon receives the MIGRATE message from its PF_KEY socket 311 and validates it. 312 o The key manager starts by updating the SP entries described in the 313 message with the updated endpoint information. It also updates in 314 its SPD image the local and remote addresses to be used for future 315 negotiation of SA associated with those SP (addresses used by 316 future IKE_SA). Then, it updates the SA related information: the 317 endpoints of already negotiated SA and the local and remote values 318 of associated IKE_SA. 320 Note that the way IKE maintains its local copy of SPD (the SPD image) 321 is an implementation specific issue since there is no standard 322 interface to access SPD. Some IKE implementations may continuously 323 monitor the SPD inside the kernel. Some IKE implementation may 324 expect notifications from the kernel when the SPD is modified. In 325 either way, the proposed mechanism gives a chance for IKE to keep its 326 SPD image up-to-date which is significant in Mobile IPv6 operation. 328 5.1.2. Bootstrapping 330 In the bootstrapping stage of Mobile IPv6, the MN and the HA need to 331 establish IPsec SA to protect signaling messages of Mobile IPv6 such 332 as BU and BA. When IKE is used to establish and maintain the SA 333 pairs, the IKE negotiation is the very first transaction made between 334 the MN and the HA. 336 As mentioned in [RFC3776], some care is needed for the address 337 management during IKE negotiations in Mobile IPv6 environments. In 338 particular, IKE negotiation to be made to establish a transport mode 339 IPsec SA pair is tricky because the local IKE_SA address and the SA 340 endpoint on the MN side (the Home Address) are different. This is 341 because the Home Address cannot be used prior to the initial home 342 registration. SADB_X_EXT_KMADDRESS extension defined in this memo 343 enables the MIPv6 module to notify the IKE module about the IKE 344 endpoints. 346 A simple solution to make the key manager aware that a different 347 address must be used for the negotiation of SA is to have it record 348 this address within its mirrored SPD entries as soon as it becomes 349 available. With that information, the key manager is able to inflect 350 its usual processing where it selects by default the source address 351 of the SA for the negotiation (i.e. as local address of the IKE_SA). 352 By having the MIGRATE message emitted by the Mobile IPv6 process 353 before the emission of the BU, the address is already available to 354 the key manager when the ACQUIRE message is received. 356 Even if the bootstrapping process initially appears differently than 357 the usual process, having the internal structure of the key manager 358 explicitly record the address (to be used for the negotiation of the 359 SA for a specific SP) allows to keep things simple. The only 360 requirement is that the MIGRATE message be emitted by the Mobile IPv6 361 process before it sends its Binding Update. 363 5.1.3. Movement 365 Next, we will see how migration takes place along with home 366 registration. The figure below shows a sequence of mobility 367 signaling and PF_KEY MIGRATE messages while the MN roams around 368 links. It is assumed that in the initial state the tunnel endpoint 369 address for a given MN is set as its home address. In the initial 370 home registration, the MN and HA migrate the tunnel endpoint address 371 from the HoA to CoA1. It should be noted that no migration takes 372 place when the MN performs re-registration since the care-of address 373 remains the same. Accordingly, the MN performs movement and changes 374 its primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE 375 message is issued both on MN and HA for each direction. When the MN 376 returns home, migration takes place updating the endpoint address 377 with the MN's home address. 379 With regard to the timing of issuing the MIGRATE message on the MN 380 during a handover, it must occur immediately before the emission of 381 the binding update performing the home registration (as for 382 bootstrapping). It is possible that ESP-protected (IPsec tunneled) 383 user traffic be sent from the new CoA which is not known to the HA 384 yet. As the HA processes the packets protected under IPsec, and as 385 far as it finds a valid SA, then those packets will be authenticated 386 regardless of their source IP address. In the end, there is no 387 security issue in updating the IPsec SA endpoint while sending the BU 388 and no reason not to do it. Furthermore, this may help the MN to 389 minimize the packet loss of its outbound traffic during the handover. 391 MN HA 392 | | 393 ~ ~ 394 Movement->| 395 MIGRATE ->| BU (Initial home registration) | 396 (HoA->CoA1)|----------------------------------------->| 397 | BA |<- MIGRATE 398 |<-----------------------------------------| (HoA->CoA1) 399 | | 400 ~ BU (Home re-registration) ~ 401 |----------------------------------------->| 402 | BA | 403 |<-----------------------------------------| 404 | | 405 ~ ~ 406 | | 407 Movement->| BU (Home registration) | 408 MIGRATE ->| BA | 409 (CoA1->CoA2)|----------------------------------------->| 410 | |<- MIGRATE 411 |<-----------------------------------------| (CoA1->CoA2) 412 | | 413 ~ ~ 414 Movement->| BU (Home de-registration) | 415 MIGRATE ->| BA | 416 (CoA2->HoA)|----------------------------------------->| 417 | |<- MIGRATE 418 |<-----------------------------------------| (CoA2->HoA) 419 | | 421 5.1.4. IKE_SA Update 423 The bootstrapping process described in Section 5.1.2 allows the 424 creation of the SA by having the right source address available to 425 the key manager before the beginning of the negotiation. When the SA 426 has been negotiated, some further exchanges are expected to happen 427 during the lifetime of the SA, including rekeying related exchanges. 428 After the first movement (and obviously further ones), the address 429 used during the bootstrapping process becomes invalid. Even if the 430 SPD and SAD entries are updated (as described in Section 5.1.1), 431 there is also a need for the key manager to update the addresses used 432 by the IKE_SA. 434 When the key manager processes the MIGRATE message, it uses the local 435 and remote address information provided by the sadb_x_kmaddress 436 structure to update: 437 o local copy of the SP entry maintained by the IKE daemon which is 438 specified in the MIGRATE message (as described in Section 5.1.2). 439 o the existing IKE_SA associated with the SP entry which is 440 specified by the MIGRATE message. 442 5.2. Issuing PF_KEY MIGRATE Message 444 The Mobile IPv6 entity (MN or HA) code triggers the migration by 445 sending a PF_KEY MIGRATE message to its PF_KEY socket. Conceptually, 446 the PF_KEY MIGRATE message should contain following information: 448 o Key manager address information \ 449 * source address | For IKE only 450 * destination address / 451 o Selector information: \ 452 * source address/port | 453 * destination address/port | 454 * upper layer protocol (i.e., Mobility Header) | 455 * direction (inbound/outbound) | 456 o Old SA information: | 457 * old source endpoint address | For IKE and 458 * old destination endpoint address | IPsec stack 459 * IPsec protocol (ESP/AH) | 460 * mode (Tunnel/Transport) | 461 o New SA information: | 462 * new source endpoint address | 463 * new destination endpoint address | 464 * IPsec protocol (ESP/AH) | 465 * mode (Tunnel/Transport) / 467 Key manager address information content (source and destination 468 address) is recorded in the associated entry of the SPD image. Those 469 SHOULD be used from now on by the key manager for SA negotiation 470 associated with that SP. The information SHOUD also be used by the 471 key manager to update the local and remote addresses of the IKE_SA 472 (used by already negotiated SA associated with the SP). 474 Selector information is required to specify the target SPD entry to 475 be updated. Basically the information should contain necessary 476 elements which characterize traffic selector as specified in the 477 IPsec architecture ([RFC2401], [RFC4301]). With regard to the upper 478 layer protocol, when the Mobile IPv6 stack is not fully aware of 479 IPsec configuration, a wildcard value can be given. In such case, an 480 upper layer protocol information SHOULD NOT be taken into account for 481 searching SPD entry. Plus, the direction of the security policy 482 (inbound/outbound) SHOULD be provided. 484 The old SA information, along with old locator information is used to 485 specify target SA to be updated. For tunnel mode, the endpoint 486 addresses refer to the source and destination IP addresses that 487 appear in the IP header, and those should be provided by the MIGRATE 488 message. For transport mode, we require it to be present to keep a 489 fixed message format. For all modes, the address information 490 represents the locators of the SA. For transport mode, it must match 491 the addresses provided in the selector. For tunnel mode, it is 492 obviously not required. 494 The source and destination addresses (locators) of the target entry 495 should be overwritten. New locator values should also be used to 496 update SP. Note that the IPsec protocol and mode fields SHOULD NOT 497 be updated by a PF_KEY MIGRATE message. 499 A PF_KEY MIGRATE message should be formed, based on security policy 500 configuration and binding record. The selector information and some 501 parts of the SA information (IPsec protocol and mode) should be taken 502 from the policy configuration. The rest of the information should be 503 taken from the sequential binding information. For example, in the 504 case where the MN updates its inbound security policy and 505 corresponding tunnel mode SA pair, the old source address should be 506 set as its previous CoA, and the new source address should be set as 507 its current CoA. Hence, the MN should sequentially keep track of its 508 CoA record. Such information shall be stored in binding update list 509 entry. For the same reason, the HA should keep track of previous 510 CoAs of MNs. Such information shall be stored in binding cache 511 entry. In previous scenario, the source and destination entries of 512 the address information for the key manager should respectively be 513 set to the CoA and the address of the HA. 515 A detailed format of MIGRATE message is provided in Appendix A. 517 5.3. Processing PF_KEY MIGRATE Message 519 Since a PF_KEY MIGRATE message is applied to a single SPD entry, the 520 kernel should first check validity of the message. During this 521 process, the content of sadb_x_kmaddress structure is skipped, 522 because its content is intended for the key manager and is simply 523 relayed by the kernel. 525 If the message is invalid, an EINVAL error MUST be returned as a 526 return value for the write() operation made to the PF_KEY socket. 527 After the validation, the kernel checks if the target SPD entry 528 really exists. If no entry is found, an ENOENT error MUST be 529 returned. If a SPD entry is found and successfully updated, a 530 success (0) MUST be returned regardless of subsequent result of SAD 531 lookup/update. Note that there may be cases where a corresponding 532 SAD entry does not exist even if a SPD entry is successfully updated. 533 In any error case, a PF_KEY MIGRATE message MUST NOT have any effect 534 on the SPD and SAD. 536 With respect to the behavior of a normal process (including the IKE 537 daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket, 538 it SHOULD first check if the message does not include erroneous 539 information. When there is any error indicated, the process MUST 540 silently discard the PF_KEY MIGRATE message. Otherwise, the 541 processing of the message may continue. This implies that the kernel 542 is the only entity responsible for returning a status regarding 543 message validation. 545 5.4. NAT Traversal 547 Dual Stack Mobile IPv6 [DSMIPv6] supports a scenario where a MN is 548 connected to an IPv4 network behind a Network Address Translator 549 (NAT). In such case, the MN assigns an IPv4 private address to its 550 network interface but it is still capable of registering its care-of 551 address to the HA, using the NAT Traversal technique [RFC3948]. The 552 MN and HA may set up an IPsec tunnel to protect data and return 553 routability traffic. 555 The PF_KEY MIGRATE mechanism described in this document does not 556 support [DSMIPv6] operations. Even if it may be possible to extend 557 it to support DSMIPv6, it is left for future work. The main reasons 558 for that decision are: 560 o the current complexity of IPsec and IKE NAT-T implementations, 561 including system specific differences. 562 o the current lack of feedback and available complete implementation 563 of DSMIPv6 on which to implement and test extensions of MIGRATE to 564 support DSMIPv6. 566 5.5. Limitations of PF_KEY MIGRATE 568 A Security Parameter Index (SPI) is not included in the old SA 569 information to specify target SAD entry. This helps to lessen 570 operational burden of Mobile IPv6. However, this simplification can 571 produce ambiguity in searching for the target security association 572 entry. When the unique SPD level is available, it should be used 573 because it avoids this problem both by marking the SA to update and 574 by limiting SA sharing. 576 It should be noted that delivery of PF_KEY MIGRATE messages cannot be 577 guaranteed, which is common to other PF_KEY messages. It may be 578 possible (even if highly unlikely) that a MIGRATE message be lost. 579 In such case, there will be inconsistency between the binding record 580 managed by Mobile IPv6 and IPsec database inside the kernel or the 581 IKE daemon. Once a PF_KEY MIGRATE message is lost, it would not be 582 possible for the receiver to process some subsequent MIGRATE messages 583 properly. Reinitialization of the Mobile IPv6 stack and IPsec 584 databases may be needed for recovery. 586 6. Necessary Modifications to Mobile IPv6 and IPsec/IKE 588 In order to realize the proposed mechanism, there are some necessary 589 modifications to Mobile IPv6 and IPsec/IKE. They are listed below 590 for implementors of Mobile IPv6 and/or IPsec/IKE. 592 o Modifications to Mobile IPv6: 593 * The Mobile IPv6 code needs to make an access to PF_KEY socket. 594 In particular, the Mobile IPv6 code should have privilege to 595 write messages into a PF_KEY socket. 596 * Issuing PF_KEY MIGRATE messages: in order to send MIGRATE 597 messages, it is required that the Mobile IPv6 code has some 598 knowledge of its IPsec configuration and precise binding 599 record. The Mobile IPv6 code may be aware of exact IPsec 600 configuration in form of security policy. It would also be 601 possible that the Mobile IPv6 code is only aware of minimum 602 IPsec configuration whether IPsec is used or not. 603 * With regard to the emission of the MIGRATE message during the 604 home registration, the Mobile IPv6 code need to emit it before 605 issuing the Binding Update. 606 o Modifications to IPsec stack: 607 * Processing PF_KEY MIGRATE messages: the kernel should be able 608 to process PF_KEY MIGRATE messages sent by the Mobile IPv6 609 code. Unless the message is invalid, it should be sent to all 610 open PF_KEY sockets. 611 o Modifications to IKE (associated with processing of MIGRATE): 612 * the IKE code needs to update its local copy of IPsec databases 613 (SPD and SAD) in accordance with received PF_KEY MIGRATE 614 message. 615 * the IKE code needs to update its associated IKE_SA with new 616 local and remote addresses specifically provided in PF_KEY 617 MIGRATE messages (in sadb_x_kmaddress structure). It also 618 needs to maintain in its SPD the addresses to be used for 619 future negotiation of IKE_SA. 621 7. Implementation 623 The mechanism described in this memo has been implemented for Linux: 625 o Linux kernel IPsec stack: the mechanism is fully implemented since 626 version 2.6.28 (released in December 2008) both for PF_KEY (as 627 described in this memo) and Linux native interface (Netlink, see 628 [RFC3549]) with in-kernel XFRM transformation framework (basis of 629 the IPsec stack). 630 o UMIP (Linux Mobile IPv6 Daemon): the mechanism is fully supported 631 for years. Details and documentation are available at 632 http://umip.org. Linux native interface (Netlink) is used by UMIP 633 to pass MIGRATE message to the kernel which passes it after 634 processing to registered (PF_KEY and Netlink/XFRM) key managers. 635 o Racoon IKEv1 daemon: the mechanism is fully supported and 636 available upstream since 2008. Racoon relies on PF_KEY for 637 communications with the kernel IPsec stack. 638 o StrongSwan IKEv2 daemon for Linux: the mechanism is fully 639 supported upstream since version 4.2.9, released in November 2008. 640 Support has been developed by StrongSwan's main developers (Martin 641 Willi and Andreas Steffen) based on this specification. 642 StrongSwan IKEv2 daemon uses Netlink for communications with the 643 kernel. 645 8. Security Considerations 647 There is no specific security considerations for the mechanisms 648 introduced by the document but as it makes deployment of dynamic 649 keying in Mobile IPv6 environments easier it should improve the 650 security of such environments. Note that dynamic keying is known to 651 be more secure (it provides anti-replay for instance) and far more 652 scalable. 654 9. IANA Considerations 656 This document has no actions for IANA. 658 10. Conclusion 660 o There is a need for Mobile IPv6 and IPsec/IKE to interact with 661 each other to provide full support of IPsec security functions. 662 o An extension to the PF_KEY framework (PF_KEY MIGRATE message) is 663 proposed, which makes it possible: 665 * for the IPsec/IKE to migrate endpoint addresses IPsec SA from 666 one to another. 667 * to make the source address to be used by the key manager for SA 668 negotiation available before it is needed. 669 * to update addresses of IKE_SA after movement. 670 o An additional requirement associated with the solution for IKE is 671 the addition in SPD image of additional per-SP hints to be used as 672 addresses for negotiation of SA. 673 o Currently, large portion of the proposed mechanism is 674 implementation dependent due to lack of standard interface to 675 access the SPD (PF_POLICY?). 677 11. References 679 11.1. Normative References 681 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 682 Requirement Levels", RFC 2119, March 1997. 684 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 685 Management API, Version 2", RFC 2367, July 1998. 687 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 688 Internet Protocol", RFC 2401, November 1998. 690 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 691 (IKE)", RFC 2409, November 1998. 693 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 694 in IPv6", RFC 3775, June 2004. 696 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 697 Protect Mobile IPv6 Signaling Between Mobile Nodes and 698 Home Agents", RFC 3776, June 2004. 700 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 701 Internet Protocol", RFC 4301, December 2005. 703 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 704 IKEv2 and the Revised IPsec Architecture", RFC 4877, 705 April 2007. 707 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 708 "Internet Key Exchange Protocol version 2 (IKEv2)", 709 RFC 5996, September 2010. 711 11.2. Informative References 713 [DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 714 Routers", RFC 5555, June 2009. 716 [MIGRATE] Sugimoto, S., Nakamura, M., and F. Dupont, "PF_KEY 717 Extension as an Interface between Mobile IPv6 and IPsec/ 718 IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in 719 progress), December 2007. 721 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 722 "Linux Netlink as an IP Services Protocol", RFC 3549, 723 July 2003. 725 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 726 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 727 RFC 3948, January 2005. 729 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 730 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 731 RFC 3963, January 2005. 733 [hld-sec] Ebalard, A., "Mobile IPv6 Home Link Detection Mechanism 734 Security considerations", 735 draft-ebalard-mext-hld-security-00 (work in progress), 736 April 2009. 738 Appendix A. PF_KEY MIGRATE Message Format 740 The figure below shows the message format of PF_KEY MIGRATE. The 741 message consists of 7 parts (boundary of each part is marked with 742 ">"). The message starts with PF_KEY base message header directly 743 followed by a sadb_x_kmaddress{} structure. The extension holds the 744 two IKE_SA local and remote addresses as opaque data for the key 745 manager (two 64-bit aligned sockaddr). It is then followed by two 746 address extensions: those respectively hold source and destination 747 addresses of the selector. The rest of the message is specific to 748 IPsec implementations on BSD and Linux. sadb_x_policy{} structure 749 holds additional information of security policy. The last part of 750 the message is a pair of sadb_x_ipsecrequest{} structures that hold 751 old and new SA information. 753 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 754 +---------------+---------------+---------------+---------------+ 755 | ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype | 756 +---------------+---------------+---------------+---------------+ 757 | sadb_msg_len | sadb_msg_reserved | 758 +---------------+---------------+---------------+---------------+ 759 | sadb_msg_seq | 760 +---------------+---------------+---------------+---------------+ 761 | sadb_msg_pid | 762 >+---------------+---------------+---------------+---------------+ 763 | sadb_x_kmaddress_len | sadb_x_kmaddress_exttype | 764 +---------------+---------------+---------------+---------------+ 765 | sadb_x_kmaddress_reserved | 766 +---------------+---------------+---------------+---------------+ 767 ~ IKE_SA local address (64-bit aligned ... ~ 768 +---------------+---------------+---------------+---------------+ 769 ~ IKE_SA remote address ... pair of sockaddr) ~ 770 >+---------------+---------------+---------------+---------------+ 771 | sadb_address_len | sadb_address_exttype | 772 +---------------+---------------+---------------+---------------+ 773 | _address_proto| ..._prefixlen | sadb_address_reserved | 774 +---------------+---------------+---------------+---------------+ 775 ~ selector source address (64-bit aligned sockaddr) ~ 776 >+---------------+---------------+---------------+---------------+ 777 | sadb_address_len | sadb_address_exttype | 778 +---------------+---------------+---------------+---------------+ 779 | _address_proto| ..._prefixlen | sadb_address_reserved | 780 +---------------+---------------+---------------+---------------+ 781 ~ selector destination address (64-bit aligned sockaddr) ~ 782 >+---------------+---------------+---------------+---------------+ 783 | sadb_x_policy_len | sadb_x_policy_exttype | 784 +---------------+---------------+---------------+---------------+ 785 | sadb_x_policy_type | ..._dir | ..._reserved | 786 +---------------+---------------+---------------+---------------+ 787 | sadb_x_policy_id | 788 +---------------+---------------+---------------+---------------+ 789 | sadb_x_policy_priority | 790 >+---------------+---------------+---------------+---------------+ 791 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 792 +---------------+---------------+---------------+---------------+ 793 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 794 +---------------+---------------+---------------+---------------+ 795 | sadb_x_ipsecrequest_reqid | 796 +---------------+---------------+---------------+---------------+ 797 | sadb_x_ipsecrequest_reserved2 | 798 +---------------+---------------+---------------+---------------+ 799 ~ old source endpoint address (64-bit aligned ... ~ 800 +---------------+---------------+---------------+---------------+ 801 ~ old destination endpoint address ... pair of sockaddr) ~ 802 >+---------------+---------------+---------------+---------------+ 803 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 804 +---------------+---------------+---------------+---------------+ 805 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 806 +---------------+---------------+---------------+---------------+ 807 | sadb_x_ipsecrequest_reqid | 808 +---------------+---------------+---------------+---------------+ 809 | sadb_x_ipsecrequest_reserved2 | 810 +---------------+---------------+---------------+---------------+ 811 ~ new source endpoint address (64-bit aligned ... ~ 812 +---------------+---------------+---------------+---------------+ 813 ~ new destination endpoint address ... pair of sockaddr) ~ 814 +---------------+---------------+---------------+---------------+ 816 Following is a structure of PF_KEY base message header specified in 817 [RFC2367]. A new message type for PF_KEY MIGRATE (i.e., 818 SADB_X_MIGRATE) should be specified in member sadb_msg_type. 820 struct sadb_msg { 821 uint8_t sadb_msg_version; 822 uint8_t sadb_msg_type; 823 uint8_t sadb_msg_errno; 824 uint8_t sadb_msg_satype; 825 uint16_t sadb_msg_len; 826 uint16_t sadb_msg_reserved; 827 uint32_t sadb_msg_seq; 828 uint32_t sadb_msg_pid; 829 }; 831 Following is the structure of key manager address extension header. 832 SADB_X_EXT_KMADDRESS should be specified in sadb_x_kmaddress_exttype 833 field. It is followed by a pair of sockaddr structures holding 834 respectively up-to-date local and remote address to be used by 835 IKE_SA. The pair is globally 64-bit aligned. 837 struct sadb_x_kmaddress { 838 uint16_t sadb_x_kmaddress_len; 839 uint16_t sadb_x_kmaddress_exttype; 840 uint32_t sadb_x_kmaddress_reserved; 841 }; 842 /* sizeof(struct sadb_x_kmaddress) == 8 */ 843 /* Followed by two sockaddr (local and remote) */ 845 Following is a structure of address extension header specified in 846 [RFC2367]. Upper layer protocol should be specified in member 847 sadb_address_proto. 849 struct sadb_address { 850 uint16_t sadb_address_len; 851 uint16_t sadb_address_exttype; 852 uint8_t sadb_address_proto; 853 uint8_t sadb_address_prefixlen; 854 uint16_t sadb_address_reserved; 855 }; 857 Following is a structure for holding attributes that are relevant to 858 security policy, which is available on BSD and Linux IPsec 859 implementations. Direction of the target security policy should be 860 specified in member sadb_x_policy_dir. 862 struct sadb_x_policy { 863 uint16_t sadb_x_policy_len; 864 uint16_t sadb_x_policy_exttype; 865 uint16_t sadb_x_policy_type; 866 uint8_t sadb_x_policy_dir; 867 uint8_t sadb_x_policy_reserved; 868 uint32_t sadb_x_policy_id; 869 uint32_t sadb_x_policy_priority; 870 }; 872 Following is a structure for holding attributes that are relevant to 873 security association, which is available on BSD and Linux IPsec 874 implementation. IPsec protocol (ESP or AH) and mode of the target 875 security association should be provided in member 876 sadb_x_ipsecrequest_proto and sadb_x_ipsecrequest_mode, respectively. 878 struct sadb_x_ipsecrequest { 879 uint16_t sadb_x_ipsecrequest_len; 880 uint16_t sadb_x_ipsecrequest_proto; 881 uint8_t sadb_x_ipsecrequest_mode; 882 uint8_t sadb_x_ipsecrequest_level; 883 uint16_t sadb_x_ipsecrequest_reserved1; 884 uint32_t sadb_x_ipsecrequest_reqid; 885 uint32_t sadb_x_ipsecrequest_reserved2; 886 }; 888 Appendix B. Acknowledgements 890 Various people had contributed and were acknowledged in previous 891 version of [MIGRATE] draft. Because most of the text from previous 892 draft has been kept in this document, those acknowledgements are 893 still valid: Mitsuru Kanda, Kazunori Miyazawa, Tsuyoshi Momose 894 Shoichi Sakane, Keiichi Shima, Noriaki Takamiya, and Hideaki 895 Yoshifuji. 897 We would also like to acknowledge here the positive technical 898 feedback from Shinta Sugimoto while extending his MIGRATE mechanism 899 and also the work provided by people of USAGI (Masahide Nakamura, 900 Shinta Sugimoto, Hideaki Yoshifuji, ...) on Linux kernel's Mobile 901 IPv6 and IPsec stack. Additionally, Romain Kuntz and Jean-Michel 902 Combes provided thorough reviews of the document during the 903 publication process. 905 This document was generated by xml2rfc. 907 Authors' Addresses 909 Arnaud Ebalard 910 EADS Innovation Works 911 12, rue Pasteur - BP76 912 Suresnes 92152 913 France 915 Email: arno@natisbad.org 917 Sebastien Decugis 918 National Institute of Information and Communications Technology 919 4-2-1, Nukui-Kitamachi, 920 Koganei, Tokyo 184-8795 921 Japan 923 Email: sdecugis@nict.go.jp