idnits 2.17.1 draft-ebalard-mext-pfkey-enhanced-migrate-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 932. 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 abstract seems to contain references ([MIGRATE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 493: '... an EINVAL error MUST be returned as a...' RFC 2119 keyword, line 496: '... an ENOENT error MUST be returned. If...' RFC 2119 keyword, line 497: '...ssfully updated, a success (0) MUST be...' RFC 2119 keyword, line 501: '... MIGRATE message MUST NOT have any eff...' RFC 2119 keyword, line 506: '... it SHOULD first check if the messag...' (2 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 (August 18, 2008) is 5731 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) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-05 -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: February 19, 2009 NICT 6 August 18, 2008 8 PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE 9 draft-ebalard-mext-pfkey-enhanced-migrate-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 19, 2009. 36 Abstract 38 This document describes the need for an interface between Mobile IPv6 39 and IPsec/IKE and show how the two protocols can interwork. An 40 extension of the PF_KEY framework is proposed which allows smooth and 41 solid operation of IKE in a Mobile IPv6 environment. 43 This document is heavily based on a previous draft [MIGRATE] written 44 by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply 45 reuses the MIGRATE mechanism defined in the expired document, removes 46 a companion extension (SADB_X_EXT_PACKET) based on implementation 47 feedback (complexity, limitations, ...) and fills the gap by very 48 simple changes to MIGRATE mechanism. This results in a more simple 49 and consistent mechanism, which also proved to be easier to 50 implement. This document is expected to serve as a continuation of 51 [MIGRATE] work. For that reason, the name of the extension has been 52 kept. 54 PF_KEY MIGRATE message serves as a carrier for updated address 55 information for both the in-kernel IPsec structures (SP/SA) and those 56 maintained by the key managers. This includes in-kernel SP/SA 57 endpoints, key manager maintained equivalents and addresses used by 58 IKE_SA (current and to be negotiated). The extension is helpful for 59 assuring smooth internetworking between Mobile IPv6 and IPsec/IKE for 60 the bootstrapping of mobile nodes and their movements. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Needs for Interactions between Mobile IPv6 and IPsec/IKE . . . 4 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message . . 5 69 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1.1. System Overview . . . . . . . . . . . . . . . . . . . 5 71 5.1.2. Bootstrapping . . . . . . . . . . . . . . . . . . . . 7 72 5.1.3. Movement . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.1.4. IKE_SA Update . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Issuing PF_KEY MIGRATE Message . . . . . . . . . . . . . . 10 75 5.3. Processing PF_KEY MIGRATE Message . . . . . . . . . . . . 11 76 5.4. Applicability of PF_KEY MIGRATE to Other Systems . . . . . 12 77 5.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 78 5.6. Limitations of PF_KEY MIGRATE . . . . . . . . . . . . . . 13 79 6. Necessary Modifications to Mobile IPv6 and IPsec/IKE . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Appendix A. PF_KEY MIGRATE Message Format . . . . . . . . . . . . 16 86 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 Intellectual Property and Copyright Statements . . . . . . . . . . 21 90 1. Introduction 92 In Mobile IPv6 [RFC3775], the Mobile Node (MN) and the Home Agent 93 (HA) use some IPsec Security Associations (SAs) in tunnel mode to 94 protect some mobility signaling messages, mobile prefix discovery and 95 optionally payload traffic. Since the MN may change its attachment 96 point to the Internet, it is necessary for it to update the tunnel 97 endpoint address of its IPsec SAs. This indicates that corresponding 98 entries in IPsec databases (Security Policy (SPD) and SA (SAD) 99 databases) should be updated when MN performs movements. 101 In a Mobile IPv6 environment, a key manager also needs to be notified 102 when the SPD and SAD are updated. More generally, it needs to be 103 provided with updated addresses for already negotiated and future 104 IKE_SA. Because of its role and unlike common applications, key 105 managers have to take part to the mobility process they secure: they 106 need to be aware of address changes. 108 This document describes the need for an interface between Mobile IPv6 109 and IPsec/IKE and shows how the two protocols can interwork. An 110 extension to the PF_KEY framework [RFC2367] which allows smooth and 111 solid operation of IKE in a Mobile IPv6 environment is defined in the 112 document. The extension is called PF_KEY MIGRATE and serves as a 113 carrier for the necessary information for both the in-kernel IPsec 114 stack and the key managers. 116 For the IPsec stack, this allows migrating the endpoint addresses of 117 the IPsec SAs (and associated SP). For the key managers, this allows 118 the mirrored structures to be updated (SAD and SPD). This also 119 allows the addresses of already negotiated and associated IKE_SA to 120 be migrated, and to make specific addresses available for 121 negotiations of future IKE_SA. This set of operations performed by 122 the KM on its internal structures is initiated by the MIPv6 process. 124 With the extension, the bootstrapping of the MN appears as a common 125 operation for IKE, by having the right addresses needed for the 126 negotiation available prior to the reception of the ACQUIRE message. 128 The extension is helpful for assuring smooth interworking between 129 Mobile IPv6 and IPsec/IKE and achieving performance optimization. 131 As stated in the abstract, this document is heavily based on the 132 content of a previous draft MIGRATE [MIGRATE]. This expired memo 133 served as the basis for this work both from technical and editorial 134 standpoints. Numerous technical discussions with some of its authors 135 took place while working on this memo. 137 2. Terminology 139 In this document, the term IKE implicitly stands for both IKEv1 140 [RFC2409] and IKEv2 [RFC4306]. IKEv2 terminology is used 141 preferentially when describing actions performed by the key manager 142 but they also apply to the IKEv1 counterparts. For instance, when 143 actions occur on IKE_SA, they also apply to Phase 1 for IKEv1, except 144 otherwise specified. Key manager is used as a more generic term in 145 the memo to refer to the IKE daemon. 147 3. Needs for Interactions between Mobile IPv6 and IPsec/IKE 149 The section 4.4 of RFC 3776 [RFC3776] specifies the rules which apply 150 to IKE for MNs and HAs. The first requirement is to run IKE over the 151 Care-of Address (CoA) because the Home Address (HoA) is usable only 152 after the home registration but not yet in the bootstrapping phase, 153 when Transport mode IPsec SA are commonly negotiated to protect 154 BU/BA. 156 A tunnel IPsec SA pair protects some signaling messages and 157 optionally all the traffic between the MN and HA. The initial SPD 158 entry uses the HoA for the MN endpoint address and updates this 159 address to the new CoA at each movement. A tunnel SA pair is created 160 on demand and is updated too. The RFC 3775 [RFC3775] assumes there 161 is an API which performs the update in the SPD and SAD on both the MN 162 and HA, and notify the IKE daemon. This document is mainly about 163 this API. 165 Mobile IPv6 may need to make an access to the SPD not only for 166 updating an endpoint address but also for deleting/inserting a 167 specific SPD entry. When the MN performs Foreign-to-Home movement, 168 IPsec SAs established between the MN and HA should be deleted, which 169 means that the SPD entry should have no effect anymore. On the other 170 hand, when the MN performs Home-to-Foreign movement, the IPsec SAs 171 should be restored. Hence security policy entries that are 172 associated with tunnel mode SAs may dynamically be added/removed 173 (enabled/disabled) in along with MN's movements. 175 It should be noted that NEMO Basic Support [RFC3963] has similar 176 requirements for the Mobile Router (MR) and MR's HA (MRHA). In NEMO, 177 the MR works just like a MN registering its location information to 178 the MRHA and establishes a tunnel (IP-in-IP or IPsec tunnel). When 179 an IPsec tunnel is established between MR and MRHA, the MR serves as 180 a Security Gateway for the nodes connected to the mobile network. 181 The MR is responsible for handling its tunnel endpoint properly. 183 4. Requirements 185 Despite the need for an interface between Mobile IPv6 and IPsec/IKE, 186 it should be kept simple. Following are the requirements for the 187 interface from a software engineering point of view. 189 o Necessary modifications to the existing software, namely Mobile 190 IPv6 and IPsec/IKE, in order to realize proposed mechanisms, 191 should be kept minimum. 192 o Proposed mechanism should not be platform dependent. The 193 mechanism should be based on technology which is commonly 194 available on various platform. This seems to be essential for 195 achieving high portability of the implementation which supports 196 proposed mechanisms. 198 5. PF_KEY Extensions for Mobile IPv6: PF_KEY MIGRATE Message 200 In order to fulfill the needs and requirements described in Section 3 201 and Section 4 we propose to extend the PF_KEY framework so that 202 Mobile IPv6 and IPsec/IKE can interact with each other. The new 203 message dedicated to that function is called MIGRATE. A new simple 204 PF_KEY structure (sadb_x_kmaddress) is also defined to be used by 205 MIGRATE to serve the purpose of IKE_SA update. 207 5.1. Overview 209 5.1.1. System Overview 211 The MIGRATE message is used for providing updated information to its 212 two targets, the kernel IPsec stack and the key manager (when used). 213 The figure below illustrates how Mobile IPv6 and IPsec/IKE components 214 interact with each other using PF_KEY MIGRATE message in a dynamic 215 keying scenario. On left top is a Mobile IPv6 entity (it may be 216 possible that Mobile IPv6 component is completely implemented inside 217 the kernel). In any case, Mobile IPv6 should be the one which issues 218 the MIGRATE message. On right top is an IKE daemon which is 219 responsible for establishing SAs required for Mobile IPv6 operation. 220 In a manual keying scenario, the difference is mainly that there is 221 no IKE daemon running on the system. 223 +-------------+ +------------+ 224 | | | | 225 | Mobile IPv6 | | IKE Daemon | 226 | | | | 227 +-------------+ +------------+ 228 | 1. PF_KEY A 4. Update SPD & SAD 229 | MIGRATE | 5. Update IKE_SA 230 +-----------+ +-----------+ 231 | | 232 Userland V | 233 ==========================[PF_KEY Socket]======================== 234 Kernel | | 235 +----------+ +----------+ 236 | 2. Update | 3. Update 237 V SPD V SAD 238 +-----------+ +------------+ 239 | | | | 240 | SPD | | SAD | 241 | | | | 242 +-----------+ +------------+ 244 In the kernel, the primary role of PF_KEY MIGRATE message is to 245 migrate endpoint addresses of SA pairs, which results in requesting 246 IPsec to update its databases (SPD and SAD). Even if tunnel mode is 247 the primary target for MIPv6, MIGRATE is not limited to that mode 248 (See Section 5.4). Then, after proper processing by the kernel, the 249 MIGRATE message is sent to all open sockets. A listening key manager 250 processes it, which results in a possible update of its internal 251 structures. The specific actions are introduced on the following 252 figure. 254 MIPv6 ---------------- kernel -------------------> IKE 255 process 256 1) update of SP 1) Update of SA and SP 257 endpoints and endpoints (in image) 258 associated SA. 2) Update of src and dst 259 @ in SPD image for 260 future SA negotiation 261 3) Update of IKE_SA src 262 and dst @ associated 263 with provided SA 265 In more details, the processing of a MIGRATE message is done in 266 following steps: 268 o Mobile IPv6 issues a PF_KEY MIGRATE message to the PF_KEY socket. 270 o The operating system (kernel) validates the message and checks if 271 corresponding security policy entry exists in SPD. 272 o When the message is confirmed to be valid, the SPD entry is 273 updated according to the MIGRATE message. If there is any target 274 SA found that is also target of the update, it should also be 275 updated. 276 o After the MIGRATE has beensuccessfully processed inside the 277 kernel, it is sent to all open PF_KEY sockets. 278 o The IKE daemon receives the MIGRATE message from its PF_KEY socket 279 and validates it. 280 o The key manager starts by updating the SP entries described in the 281 message with the updated endpoint information. It also updates in 282 its SPD image the local and remote addresses to be used for future 283 negotiation of SA associated with those SP (addresses used by 284 future IKE_SA). Then, it updates the SA related information: the 285 endpoints of already negotiated SA and the local and remote values 286 of associated IKE_SA. 288 Note that the way IKE maintains its local copy of SPD (the SPD image) 289 is an implementation specific issue since there is no standard 290 interface to access SPD. Some IKE implementations may continuously 291 monitor the SPD inside the kernel. Some IKE implementation may 292 expect notifications from the kernel when the SPD is modified. In 293 either way, the proposed mechanism gives a chance for IKE to keep its 294 SPD image up-to-date which is significant in Mobile IPv6 operation. 296 5.1.2. Bootstrapping 298 In the bootstrapping stage of Mobile IPv6, the MN and the HA need to 299 establish IPsec SA to protect signaling messages of Mobile IPv6 such 300 as BU and BA. When IKE is used to establish and maintain the SA 301 pairs, the IKE negotiation is the very first transaction made between 302 the MN and the HA. 304 As mentioned in [RFC3776], some care is needed for the address 305 management of the IKE negotiation in Mobile IPv6 environments. In 306 particular, IKE negotiation to be made to establish a transport mode 307 IPsec SA pair is tricky because the local IKE_SA address and the SA 308 endpoint on the MN side (the Home Address) are different. This is 309 because the home address cannot be used prior to the initial home 310 registration. Even if the SADB_X_EXT_KMADDRESS extension defined in 311 this memo enables the MIPv6 module to notify the IKE module about the 312 IKE endpoint, address selection is left outside the scope of the 313 document. In practice, a suitable candidate for the IKE endpoint is 314 the primary CoA. 316 A simple solution to have the key manager be aware that a different 317 address must be used for the negotiation of SA is to have it record 318 this address within its mirrored SPD entries as soon as it becomes 319 available. With that information, it is able to inflect its usual 320 processing where it selects by default the source address of the SA 321 for the negotiation (i.e. as local address of the IKE_SA). By having 322 the MIGRATE message emitted by the Mobile IPv6 process before the 323 emission of the BU, the address is already available to the key 324 manager when the ACQUIRE message is received. 326 Even if the bootstrapping process initially appears differently than 327 the usual process, having the internal structure of the key manager 328 explicitly record the address (to be used for the negotiation of the 329 SA for a specific SP) allows to keep things simple. The only 330 requirement is that the MIGRATE message be emitted by the Mobile IPv6 331 process before it sends its Binding Update. 333 5.1.3. Movement 335 Next, we will see how migration takes place in along with home 336 registration. The figure below shows sequence of mobility signaling 337 and PF_KEY MIGRATE messages while the MN roams around links. It is 338 assumed that in the initial state the tunnel endpoint address for a 339 given MN is set as its home address. In the initial home 340 registration, the MN and HA migrate the tunnel endpoint address from 341 the HoA to CoA1. It should be noted that no migration takes place 342 when the MN performs re-registration since the care-of address 343 remains the same. Accordingly, the MN performs movement and changes 344 its primary care-of address from CoA1 to CoA2. A PF_KEY MIGRATE 345 message is issued on both MN and HA for each direction. When the MN 346 returns to home, migration takes place updating the endpoint address 347 with the MN's home address. 349 With regard to the timing of issuing the MIGRATE message on the MN 350 side during a handover, it must occur immediately before the emission 351 of the binding update performing the home registration (as for 352 bootstrapping). It is possible that ESP-protected (IPsec tunneled) 353 user traffic be sent from the new CoA which is not known to the HA 354 yet. As the HA processes the packets under IPsec, and as far as it 355 finds a valid SA, then those packets will be authenticated regardless 356 of their source IP address. In the end, there is no security issue 357 in updating the IPsec SA endpoint while sending the BU and no reason 358 not to do it. Furthermore, this may help the MN to minimize the 359 packet loss of its outbound traffic during the handover. 361 MN HA 362 | | 363 ~ ~ 364 Movement->| 365 MIGRATE ->| BU (Initial home registration) | 366 (HoA->CoA1)|----------------------------------------->| 367 | BA |<- MIGRATE 368 |<-----------------------------------------| (HoA->CoA1) 369 | | 370 ~ BU (Home re-registration) ~ 371 |----------------------------------------->| 372 | BA | 373 |<-----------------------------------------| 374 | | 375 ~ ~ 376 | | 377 Movement->| BU (Home registration) | 378 MIGRATE ->| BA | 379 (CoA1->CoA2)|----------------------------------------->| 380 | |<- MIGRATE 381 |<-----------------------------------------| (CoA1->CoA2) 382 | | 383 ~ ~ 384 Movement->| BU (Home de-registration) | 385 MIGRATE ->| BA | 386 (CoA2->HoA)|----------------------------------------->| 387 | |<- MIGRATE 388 |<-----------------------------------------| (CoA2->HoA) 389 | | 391 5.1.4. IKE_SA Update 393 The bootstrapping process described in Section 5.1.2 allows the 394 creation of the SA by having the right source address available to 395 the key manager before the beginning of the negotiation. When the SA 396 has been negotiated, some further exchanges are expected to happen 397 during the lifetime of the SA, including rekeying related exchanges. 398 After the first movement (and obviously further ones), the address 399 used during the bootstrapping process becomes invalid. Even if the 400 SPD and SAD entries are updated (as described in Section 5.1.1), 401 there is also a need for the key manager to update the addresses used 402 by the IKE_SA. 404 When the key manager processes the MIGRATE message, it uses the local 405 and remote address information provided by the sadb_x_kmaddress 406 structure to update: 408 o local copy of the SP entry maintained by the IKE daemon which is 409 specified in the MIGRATE message (as described in Section 5.1.2). 410 o the existing IKE_SA associated with the SP entry which is 411 specified by the MIGRATE message. 413 5.2. Issuing PF_KEY MIGRATE Message 415 The Mobile IPv6 entity (MN or HA) code triggers the migration by 416 sending a PF_KEY MIGRATE message to its PF_KEY socket. Conceptually, 417 the PF_KEY MIGRATE message should contain following information: 419 o Key manager address information \ 420 * source address | For IKE only 421 * destination address / 422 o Selector information: \ 423 * source address/port | 424 * destination address/port | 425 * upper layer protocol (i.e., Mobility Header) | 426 * direction (inbound/outbound) | 427 o Old SA information: | 428 * old source endpoint address | For IKE and 429 * old destination endpoint address | IPsec stack 430 * IPsec protocol (ESP/AH) | 431 * mode (Tunnel/Transport/BEET) | 432 o New SA information: | 433 * new source endpoint address | 434 * new destination endpoint address | 435 * IPsec protocol (ESP/AH) | 436 * mode (Tunnel/Transport/BEET) / 438 Key manager address information content (source and destination 439 address) is recorded in the associated entry of the SPD image. Those 440 are used from now on by the key manager for SA negotiation associated 441 with that SP. The information is also used by the key manager to 442 update the local and remote addresses of the IKE_SA (used by already 443 negotiated SA associated with the SP). 445 Selector information is required for specifying the target SPD entry 446 to be updated. Basically the information should contain necessary 447 elements which characterize traffic selector as specified in the 448 IPsec architecture ([RFC2401], [RFC4301]). With regard to the upper 449 layer protocol, when the Mobile IPv6 stack is not fully aware of 450 IPsec configuration, a wildcard value could be given. In such case, 451 an upper layer protocol information should not be taken into account 452 for searching SPD entry. Plus, the direction of the security policy 453 (inbound/outbound) should be provided. 455 The old SA information, along with old locator information is used to 456 specify target SA to be updated. For tunnel and BEET 457 [I-D.nikander-esp-beet-mode] modes, the endpoint addresses refer to 458 the source and destination IP addresses that appear in the IP header, 459 and those should be provided by the MIGRATE message. For transport 460 mode, we require it to be present to keep a fixed message format. 461 For all modes, the address information represents the locators of the 462 SA. For transport mode, it must match with the addresses provided in 463 the selector. For tunnel mode, it is obviously not required. 465 The source and destination addresses (locators) of the target entry 466 should be overwritten. New locator values should also be used to 467 update SP. Note that the IPsec protocol and mode fields should not 468 be updated by a PF_KEY MIGRATE message. 470 A PF_KEY MIGRATE message should be formed, based on security policy 471 configuration and binding record. The selector information and some 472 parts of the SA information (IPsec protocol and mode) should be taken 473 from the policy configuration. The rest of the information should be 474 taken from the sequential binding information. For example, in the 475 case where the MN updates its inbound security policy and 476 corresponding tunnel mode SA pair, the old source address should be 477 set as its previous CoA, and the new source address should be set as 478 its current CoA. Hence, the MN should sequentially keep track of its 479 CoA record. Such information shall be stored in binding update list 480 entry. For the same reason, the HA should keep track of previous 481 CoAs of MNs. Such information shall be stored in binding cache 482 entry. In previous scenario, the source and destination entries of 483 the address information for the key manager should respectively be 484 set to the CoA and the address of the HA. 486 A detailed format of MIGRATE message is provided in Appendix A. 488 5.3. Processing PF_KEY MIGRATE Message 490 Since a PF_KEY MIGRATE message is applied to a single SPD entry, the 491 kernel should first check validity of the message. During that 492 process, it simply skips sadb_x_kmaddress structure content. If the 493 message is invalid, an EINVAL error MUST be returned as a return 494 value for the write() operation made to the PF_KEY socket. After the 495 validation, the kernel checks if the target SPD entry really exists. 496 If no entry is found, an ENOENT error MUST be returned. If a SPD 497 entry is found and successfully updated, a success (0) MUST be 498 returned regardless of subsequent result of SAD lookup/update. Note 499 that there may be cases where a corresponding SAD entry does not 500 exist even if a SPD entry is successfully updated. In any error 501 case, a PF_KEY MIGRATE message MUST NOT have any effect on the SPD 502 and SAD. 504 With respect to the behavior of a normal process (including the IKE 505 daemon) which receives a PF_KEY MIGRATE message from a PF_KEY socket, 506 it SHOULD first check if the message does not include erroneous 507 information. When there is any error indicated, the process MUST 508 silently discard the PF_KEY MIGRATE message. Otherwise, the 509 processing of the message may continue. This implies that the kernel 510 is the only entity responsible for returning a status regarding 511 message validation. 513 5.4. Applicability of PF_KEY MIGRATE to Other Systems 515 The PF_KEY MIGRATE extension can also be applied to other systems 516 than Mobile IPv6. In some systems, there is a need to update 517 endpoint address of IPsec security association for various reasons 518 such as mobility management and multihoming. 520 In a Mobile VPN scenario (aka "road warrior"), client node roams 521 around different IP subnets while maintaining security associations 522 with the security gateway. Just like in Mobile IPv6 case, both of 523 the IKE peers need to update the endpoint of the IPsec tunnel and 524 PF_KEY MIGRATE message can be used for that purpose. 526 In HIP mobility management scenario [RFC5206], a mobile host can 527 maintain a HIP association with its peer while moving around IP 528 subnets. When the mobile host changes its attachment point to the 529 Internet, it sends an UPDATE message to the peer reporting its new 530 locator. Since HIP association is represented by an IPsec security 531 association of ESP BEET mode, the same mechanism can be applied for 532 the purpose of updating endpoint. The procedure of MIGRATE can take 533 place when the mobile host detects movement and when the peer 534 receives the UPDATE message. 536 From the ID/Locator separation point of view, PF_KEY MIGRATE is 537 designed to update locators stored in an IPsec security association. 538 Even if this usually applies to IPsec security associations in tunnel 539 mode, the MIGRATE framework also covers the transport mode. For 540 instance, there are exceptional cases where IPsec security 541 associations are bundled. In some case, a transport mode security 542 association may be bundled with a tunnel mode security association. 543 For instance, a combination of AH (transport mode) and ESP (tunnel 544 mode) may assure confidentiality of the payload as well as data 545 integritiy of the whole IP packet including outer header. In such 546 case, PF_KEY MIGRATE message may be used for updating endpoint 547 addresses of IPsec transport mode. 549 5.5. NAT Traversal 551 Dual Stack Mobile IPv6 [I-D.ietf-mext-nemo-v4traversal] supports a 552 scenario where a MN is connected to a network behind a Network 553 Address Translator (NAT). In such case, the MN assigns a IPv4 554 private address to its network interface but it is still capable of 555 registering its care-of address to the HA, using the NAT Traversal 556 technique [RFC3948]. The MN and HA leverage an IPsec tunnel to 557 protect the return routability messages. 559 It is possible for the PF_KEY MIGRATE message to handle IPv4 private 560 address when the MN is behind a NAT device. In a NAT Traversal case, 561 the endpoint address of the MN is characterized by the IP address and 562 the pair of source and destination port numbers used for the UDP 563 encapsulation. Therefore, in a NAT Traversal scenario, a Mobile IPv6 564 module MUST issue a PF_KEY MIGRATE message along with the pair of 565 source and destination port numbers of a UDP encpasulation, to handle 566 IPv4 private address. 568 5.6. Limitations of PF_KEY MIGRATE 570 Currently, a Security Parameter Index (SPI) is not included in the 571 old SA information to specify target SAD entry. This helps to lessen 572 operational burden of Mobile IPv6. However, this simplification can 573 produce ambiguity in searching for the target security association 574 entry. When the unique SPD level is available, it should be used 575 because it avoids this problem both by marking the SAs to update and 576 by limiting SA sharing. 578 It should be noted that delivery of PF_KEY MIGRATE messages cannot be 579 guaranteed, which is common to other PF_KEY messages. It may be 580 possible (even if highly unlikely) that a MIGRATE message be lost. 581 In such case, there will be inconsistency between the binding record 582 managed by Mobile IPv6 and IPsec database inside the kernel or the 583 IKE daemon. Once a PF_KEY MIGRATE message is lost, it would not be 584 possible for the receiver to process some subsequent MIGRATE messages 585 properly. Reinitialization of the Mobile IPv6 stack and IPsec 586 databases may be needed for recovery. 588 6. Necessary Modifications to Mobile IPv6 and IPsec/IKE 590 In order to realize the proposed mechanism, there are some necessary 591 modifications to Mobile IPv6 and IPsec/IKE. They are listed below 592 for implementors of Mobile IPv6 and/or IPsec/IKE. 594 o Modifications to Mobile IPv6: 595 * The Mobile IPv6 code needs to make an access to PF_KEY socket. 596 In particular, the Mobile IPv6 code should have privilege to 597 write messages into a PF_KEY socket. 598 * Issuing PF_KEY MIGRATE messages: in order to send MIGRATE 599 messages, it is required that the Mobile IPv6 code has some 600 knowledge of its IPsec configuration and precise binding 601 record. The Mobile IPv6 code may be aware of exact IPsec 602 configuration in form of security policy. It would also be 603 possible that the Mobile IPv6 code is only aware of minimum 604 IPsec configuration whether IPsec is utilized or not. 605 * With regard to the emission of the MIGRATE message during the 606 home registration, the Mobile IPv6 code need to emit it before 607 issuing the Binding Update. 608 o Modifications to IPsec: 609 * Processing PF_KEY MIGRATE messages: the kernel should be able 610 to process PF_KEY MIGRATE messages sent by the Mobile IPv6 611 code. Unless the message is invalid, it should be sent to all 612 open PF_KEY sockets. 613 o Modifications to IKE (associated with processing of MIGRATE): 614 * the IKE code need to update its local copy of IPsec databases 615 (SPD and SAD) in accordance with received PF_KEY MIGRATE 616 message. 617 * the IKE code need to update its associated IKE_SA with new 618 local and remote addresses specifically provided in PF_KEY 619 MIGRATE messages (in sadb_x_kmaddress structure). It also 620 needs to maintain in its SPD the addresses to be used for 621 future negotiation of IKE_SA. 623 7. Security Considerations 625 There is no specific security considerations for the mechanisms 626 introduced by the document but as it makes deployment of dynamic 627 keying in Mobile IPv6 environments easier it should improve the 628 security of such environments. Note that dynamic keying is known to 629 be more secure (it provides anti-replay for instance) and far more 630 scalable. 632 8. Conclusion 634 o There is a need for Mobile IPv6 and IPsec/IKE to interact with 635 each other to provide full support of IPsec security functions. 636 o An extension to the PF_KEY framework (PF_KEY MIGRATE message) is 637 proposed, which makes it possible: 639 * for the IPsec/IKE to migrate endpoint addresses IPsec SAs from 640 one to another. 641 * to make the source address to be used by the key manager for SA 642 negotiation available before it is needed. 643 * to update addresses of IKE_SA after movement. 644 o An additional requirement associated with the solution for IKE is 645 the addition in SPD image of additional per-SP hints to be used as 646 addresses for negotiation of SAs. 647 o Currently, large portion of the proposed mechanism is 648 implementation dependent due to lack of standard interface to 649 access the SPD (PF_POLICY?). 651 9. References 653 9.1. Normative References 655 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 656 Management API, Version 2", RFC 2367, July 1998. 658 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 659 Internet Protocol", RFC 2401, November 1998. 661 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 662 (IKE)", RFC 2409, November 1998. 664 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 665 in IPv6", RFC 3775, June 2004. 667 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 668 Protect Mobile IPv6 Signaling Between Mobile Nodes and 669 Home Agents", RFC 3776, June 2004. 671 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 672 Internet Protocol", RFC 4301, December 2005. 674 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 675 RFC 4306, December 2005. 677 9.2. Informative References 679 [I-D.ietf-mext-nemo-v4traversal] 680 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 681 Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-05 682 (work in progress), July 2008. 684 [I-D.nikander-esp-beet-mode] 685 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 686 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 687 (work in progress), August 2008. 689 [MIGRATE] Sugimoto, S., Nakamura, M., and F. Dupont, "PF_KEY 690 Extension as an Interface between Mobile IPv6 and IPsec/ 691 IKE", draft-sugimoto-mip6-pfkey-migrate-04 (work in 692 progress), December 2007. 694 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 695 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 696 RFC 3948, January 2005. 698 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 699 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 700 RFC 3963, January 2005. 702 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 703 Host Mobility and Multihoming with the Host Identity 704 Protocol", RFC 5206, April 2008. 706 Appendix A. PF_KEY MIGRATE Message Format 708 The figure below shows the message format of PF_KEY MIGRATE. The 709 message consists of 7 parts (boundary of each part is marked with 710 ">"). The message starts with PF_KEY base message header directly 711 followed by a sadb_x_kmaddress{} structure. The extension holds the 712 two IKE_SA local and remote addresses as opaque data for the key 713 manager (two 64-bit aligned sockaddr). It is then followed by two 714 address extensions: those respectively hold source and destination 715 addresses of the selector. The rest of the message is specific to 716 IPsec implementations on BSD and Linux. 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_x_kmaddress_len | sadb_x_kmaddress_exttype | 732 +---------------+---------------+---------------+---------------+ 733 | sadb_x_kmaddress_reserved | 734 +---------------+---------------+---------------+---------------+ 735 ~ IKE_SA local address (64-bit aligned ... ~ 736 +---------------+---------------+---------------+---------------+ 737 ~ IKE_SA remote address ... pair of sockaddr) ~ 738 >+---------------+---------------+---------------+---------------+ 739 | sadb_address_len | sadb_address_exttype | 740 +---------------+---------------+---------------+---------------+ 741 | _address_proto| ..._prefixlen | sadb_address_reserved | 742 +---------------+---------------+---------------+---------------+ 743 ~ selector source address (64-bit aligned sockaddr) ~ 744 >+---------------+---------------+---------------+---------------+ 745 | sadb_address_len | sadb_address_exttype | 746 +---------------+---------------+---------------+---------------+ 747 | _address_proto| ..._prefixlen | sadb_address_reserved | 748 +---------------+---------------+---------------+---------------+ 749 ~ selector destination address (64-bit aligned sockaddr) ~ 750 >+---------------+---------------+---------------+---------------+ 751 | sadb_x_policy_len | sadb_x_policy_exttype | 752 +---------------+---------------+---------------+---------------+ 753 | sadb_x_policy_type | ..._dir | ..._reserved | 754 +---------------+---------------+---------------+---------------+ 755 | sadb_x_policy_id | 756 +---------------+---------------+---------------+---------------+ 757 | sadb_x_policy_priority | 758 >+---------------+---------------+---------------+---------------+ 759 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 760 +---------------+---------------+---------------+---------------+ 761 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 762 +---------------+---------------+---------------+---------------+ 763 | sadb_x_ipsecrequest_reqid | 764 +---------------+---------------+---------------+---------------+ 765 | sadb_x_ipsecrequest_reserved2 | 766 +---------------+---------------+---------------+---------------+ 767 ~ old source endpoint address (64-bit aligned ... ~ 768 +---------------+---------------+---------------+---------------+ 769 ~ old destination endpoint address ... pair of sockaddr) ~ 770 >+---------------+---------------+---------------+---------------+ 771 | sadb_x_ipsecrequest_len | sadb_x_ipsecrequest_proto | 772 +---------------+---------------+---------------+---------------+ 773 | ..._mode | ..._level | sadb_x_ipsecrequest_reserved1 | 774 +---------------+---------------+---------------+---------------+ 775 | sadb_x_ipsecrequest_reqid | 776 +---------------+---------------+---------------+---------------+ 777 | sadb_x_ipsecrequest_reserved2 | 778 +---------------+---------------+---------------+---------------+ 779 ~ new source endpoint address (64-bit aligned ... ~ 780 +---------------+---------------+---------------+---------------+ 781 ~ new destination endpoint address ... pair of sockaddr) ~ 782 +---------------+---------------+---------------+---------------+ 784 Following is a structure of PF_KEY base message header specified in 785 [RFC2367]. A new message type for PF_KEY MIGRATE (i.e., 786 SADB_X_MIGRATE) should be specified in member sadb_msg_type. 788 struct sadb_msg { 789 uint8_t sadb_msg_version; 790 uint8_t sadb_msg_type; 791 uint8_t sadb_msg_errno; 792 uint8_t sadb_msg_satype; 793 uint16_t sadb_msg_len; 794 uint16_t sadb_msg_reserved; 795 uint32_t sadb_msg_seq; 796 uint32_t sadb_msg_pid; 797 }; 799 Following is the structure of key manager address extension header. 800 SADB_X_EXT_KMADDRESS should be specified in sadb_x_kmaddress_exttype 801 field. It is followed by a pair of sockaddr structures holding 802 respectively up-to-date local and remote address to be used by 803 IKE_SA. The pair is globally 64-bit aligned. 805 struct sadb_x_kmaddress { 806 uint16_t sadb_x_kmaddress_len; 807 uint16_t sadb_x_kmaddress_exttype; 808 uint32_t sadb_x_kmaddress_reserved; 809 }; 810 /* sizeof(struct sadb_x_kmaddress) == 8 */ 811 /* Followed by two sockaddr (local and remote) */ 813 Following is a structure of address extension header specified in 814 [RFC2367]. Upper layer protocol should be specified in member 815 sadb_address_proto. 817 struct sadb_address { 818 uint16_t sadb_address_len; 819 uint16_t sadb_address_exttype; 820 uint8_t sadb_address_proto; 821 uint8_t sadb_address_prefixlen; 822 uint16_t sadb_address_reserved; 823 }; 825 Following is a structure for holding attributes that are relevant to 826 security policy, which is available on BSD and Linux IPsec 827 implementations. Direction of the target security policy should be 828 specified in member sadb_x_policy_dir. 830 struct sadb_x_policy { 831 uint16_t sadb_x_policy_len; 832 uint16_t sadb_x_policy_exttype; 833 uint16_t sadb_x_policy_type; 834 uint8_t sadb_x_policy_dir; 835 uint8_t sadb_x_policy_reserved; 836 uint32_t sadb_x_policy_id; 837 uint32_t sadb_x_policy_priority; 838 }; 840 Following is a structure for holding attributes that are relevant to 841 security association, which is available on BSD and Linux IPsec 842 implementation. IPsec protocol (ESP or AH) and mode of the target 843 security association should be provided in member 844 sadb_x_ipsecrequest_proto and sadb_x_ipsecrequest_mode, respectively. 846 struct sadb_x_ipsecrequest { 847 uint16_t sadb_x_ipsecrequest_len; 848 uint16_t sadb_x_ipsecrequest_proto; 849 uint8_t sadb_x_ipsecrequest_mode; 850 uint8_t sadb_x_ipsecrequest_level; 851 uint16_t sadb_x_ipsecrequest_reserved1; 852 uint32_t sadb_x_ipsecrequest_reqid; 853 uint32_t sadb_x_ipsecrequest_reserved2; 854 }; 856 Appendix B. Acknowledgements 858 Various people had contributed and were acknowledged in previous 859 version of MIGRATE draft. Because most of the text from previous 860 draft has been kept in this document, those acknowledgements are 861 still valid: Sebastien Decugis, Mitsuru Kanda, Kazunori Miyazawa, 862 Tsuyoshi Momose Shoichi Sakane, Keiichi Shima, Noriaki Takamiya, and 863 Hideaki Yoshifuji. 865 Support of NAT Traversal was suggested by Kazunori Miyazawa. 867 We would also like to acknowledge here the positive technical 868 feedback from Shinta Sugimoto while extending his MIGRATE mechanism 869 and also the work provided by people of USAGI (Masahide Nakamura, 870 Shinta Sugimoto, Hideaki Yoshifuji, ...) on Linux kernel's Mobile 871 IPv6 and IPsec stack. 873 This document was generated by xml2rfc. 875 Authors' Addresses 877 Arnaud Ebalard 878 EADS Innovation Works 879 12, rue Pasteur - BP76 880 Suresnes 92152 881 France 883 Phone: +33 1 46 97 30 28 884 Email: arnaud.ebalard@eads.net 886 Sebastien Decugis 887 National Institute of Information and Communications Technology 888 4-2-1, Nukui-Kitamachi, 889 Koganei, Tokyo 184-8795 890 Japan 892 Email: sdecugis@hongo.wide.ad.jp 894 Full Copyright Statement 896 Copyright (C) The IETF Trust (2008). 898 This document is subject to the rights, licenses and restrictions 899 contained in BCP 78, and except as set forth therein, the authors 900 retain all their rights. 902 This document and the information contained herein are provided on an 903 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 904 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 905 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 906 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 907 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 908 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 910 Intellectual Property 912 The IETF takes no position regarding the validity or scope of any 913 Intellectual Property Rights or other rights that might be claimed to 914 pertain to the implementation or use of the technology described in 915 this document or the extent to which any license under such rights 916 might or might not be available; nor does it represent that it has 917 made any independent effort to identify any such rights. Information 918 on the procedures with respect to rights in RFC documents can be 919 found in BCP 78 and BCP 79. 921 Copies of IPR disclosures made to the IETF Secretariat and any 922 assurances of licenses to be made available, or the result of an 923 attempt made to obtain a general license or permission for the use of 924 such proprietary rights by implementers or users of this 925 specification can be obtained from the IETF on-line IPR repository at 926 http://www.ietf.org/ipr. 928 The IETF invites any interested party to bring to its attention any 929 copyrights, patents or patent applications, or other proprietary 930 rights that may cover technology that may be required to implement 931 this standard. Please address the information to the IETF at 932 ietf-ipr@ietf.org.