idnits 2.17.1 draft-dupont-ikev2-addrmgmt-08.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 701. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 714. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack 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 236: '...e peer addresses MUST be stable during...' RFC 2119 keyword, line 237: '...E_AUTH exchanges MUST be transported u...' RFC 2119 keyword, line 241: '... request MUST be sent to the source ...' RFC 2119 keyword, line 253: '...sses. So a peer MAY retransmit an IKE...' RFC 2119 keyword, line 267: '...est. Of course the reply MUST contain...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2005) is 6734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Ni' on line 326 == Outdated reference: A later version (-04) exists of draft-dupont-mobike-transport-03 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-07 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-04 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '11') (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dupont 3 Internet-Draft Point6 4 Expires: May 22, 2006 November 18, 2005 6 Address Management for IKE version 2 7 draft-dupont-ikev2-addrmgmt-08.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 22, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The current IKEv2 proposal lacks an address management feature. As 41 it is compatible with the NAT traversal capability, this document 42 specifies a complete address management with support for multi-homing 43 and mobility, and fulfill mobike IETF working group goals 1, 2, 3, 4, 44 and 6. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Simplicity, Performance and Security . . . . . . . . . . . 3 51 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3. Multi-homing requirements . . . . . . . . . . . . . . . . 4 53 2.4. Mobility requirements . . . . . . . . . . . . . . . . . . 4 54 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Kept points from/clarification to the IKEv2 draft 17 . . . 6 56 3.2. Minor points . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.3. Peer address notifications . . . . . . . . . . . . . . . . 7 58 3.4. Explicit peer address update payload . . . . . . . . . . . 7 59 3.5. Open issues . . . . . . . . . . . . . . . . . . . . . . . 8 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Appendix A. Peer Address Notification Format . . . . . . . . . . 11 66 Appendix B. Peer Address Update Payload Format . . . . . . . . . 12 67 Appendix C. NAT Prevention Notification Format . . . . . . . . . 14 68 Appendix D. Return Routability Cookie Notification Format . . . . 15 69 Appendix E. PF_KEY version 2 SADB_X_ADDUPD . . . . . . . . . . . 15 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 Intellectual Property and Copyright Statements . . . . . . . . . . 18 73 1. Introduction 75 This document proposes an address management for IKEv2 [1] for all 76 the IETF mobike working group goals [4] at the exception of the goal 77 5 (handled by [5]). 79 In this document, the addresses used to transport IKE messages are 80 named the "peer addresses" (term introduced by [6]). These peer 81 addresses should no more be directly or indirectly included in 82 identities ([7] and [8]) as it is commonly done for IKEv1. 84 The current IKEv2 draft [1] often makes the implicit assumption that 85 an address identifies a node when nodes behind a NAT can share the 86 same address and a node can use many different addresses. This must 87 be taken into account in implementations, for instance by reading 88 this document before writing code... 90 This document describes the goals of an address management for IKEv2, 91 including the requirements for multi-homing and mobility support 92 (this part will be removed as soon as the mobike requirements 93 document [9] is finalized), and finishes by a concrete proposal. 95 In this document, open questions are introduced by the word NOTE and 96 will be refined in a dedicated section. 98 2. Goals 100 The goals of the address management proposed in the document can be 101 divided in some general goals and in requirements for the three 102 mechanisms which can change the peer addresses. 104 2.1. Simplicity, Performance and Security 106 The address management should be as simple as possible, i.e., it 107 should introduce minimal additions to the current IKEv2 draft [1] and 108 each addition should be justified. 110 The performance is an important criterion. For instance, rekeying 111 can update the peer addresses of an IKE SA or an IPsec SA pair, but 112 rekeying is too expensive and a specific solution is needed. 114 As a security protocol, IKEv2 should get a high security level. 115 Unfortunately we already showed that the NAT traversal feature comes 116 with a security issue (the transient pseudo-NAT attack [10]). 118 Such problems introduced by the peer address flexibility must be 119 described in this document and at least be mitigated by options in 120 configurations. For instance, the NAT traversal feature should never 121 be enabled when one knows that there can not be a NAT as today in 122 IPv6. 124 An other example of an insecure mechanism is to use the addresses in 125 IP headers of CREATE_CHILD_SA messages as the endpoint addresses of 126 the new IPsec SAs without further control on them: peer addresses 127 must be managed. 129 2.2. Terminology 131 The addresses of the two peers are named "peer addresses". With 132 other words the peer addresses are the addresses IKE runs over but 133 this document extends this basic definition. The primary peer 134 address of a peer is initialized to the address used to transport 135 messages of the initial exchanges, other addresses are "alternate 136 peer addresses". 138 The proxy case is the setup of transport mode IPsec SAs on the behalf 139 of another party, i.e., transport mode IPsec SAs where the traffic 140 selectors do not match the primary peer addresses. 142 2.3. Multi-homing requirements 144 In this document, the support of multi-homing is the support of nodes 145 with several global addresses. Some of the addresses can be "better" 146 than others, or "better" for some destinations. Some can, from time 147 to time, be unavailable. 149 The main requirement for the support of multi-homing is the 150 management of a set of peer addresses for each peer. The set can be 151 partially ordered or some subsets can be loosely associated with some 152 destinations (i.e., some subsets of the other peer address set, this 153 is needed when a destination address can be reached only using 154 particular source addresses). 156 For the communication between multi-addressed hosts, the support of 157 the proxy case can be useful because it provides an easy way to setup 158 transport mode IPsec SAs with different addresses from one IKE SA. 159 In such cases the other party is in fact the same host, this 160 dramatically simplifies the authorization issue. 162 2.4. Mobility requirements 164 In the context of Mobile IPv6 ([11] and for the special case of Home 165 Agents [12]), the interaction of Mobility and IPsec was analyzed in 166 another document [13]. This document assumes an IPv6 context as 167 Mobile IPv6 is the most powerful mobility proposal available today. 169 An IPv6 mobile node is another type of multi-addressed node with: 170 - a care-of address in a prefix of the visited link. 171 The care-of address is used to route packets. 172 - the home address in a prefix of the home link. 173 The home address is used to identify the mobile node. 175 The care-of address is transient and usually the mobile node can not 176 provide a proof that it is the node using it. So it has to be 177 trusted and a return routability check (i.e., an enforced answer from 178 this address) should be used if it is not. 180 With a common correspondent, the mobility is transparent and there is 181 no reason to use another address than the home address. For 182 optimized schemes, without an implementation of header compression in 183 ESP tunnel mode (the goal 5 of mobike [4]) the choice between a 184 transport mode using triangular routing (IPsec can be used to verify 185 home address options) and a tunnel mode with routing optimization is 186 not clear. But this case does not add new requirement, i.e., the 187 home agent case includes them. 189 With the home agent, there are three main cases (c.f. [12]): 191 - The mobility signaling which is mandatory protected and raises a 192 specific issue in its initial phase: the IKE SA must be setup 193 using the care-of address as the peer address but this IKE SA is 194 used to build an IPsec SA pair with the home address as traffic 195 selector. This IPsec SA will protect the home registration which 196 will make the home address available. This can be considered as a 197 specialized proxy case. 199 - Other genuine communications between the home agent and the mobile 200 node can be covered by the proxy case support too. Note this is 201 the only case at the exception of signaling where mobility behaves 202 in a different way than a mobile IPsec VPN (so we proposed to 203 relax the corresponding rule in a future version of [11] and 204 [12]). 206 - The traffic relayed by the home agent through a tunnel with the 207 mobile node can be partially or fully protected by IPsec SA 208 pair(s). Encapsulation should be performed only once, including 209 for degenerated (but not for free) encapsulation like the home 210 address option or the mobility routing header. 212 In all cases of interaction with the home agent, the mobile node peer 213 address should be a care-of address. When the mobile node moves, 214 another care-of address is used and some SAs, including the IKE SA, 215 must be updated to use the new address. 217 Usually the previous peer address is no more usable. In order to 218 avoid a trivial denial of services, a strong sequencing of updates is 219 required with a way to cancel possible pending updates when fast 220 multiple handoff happen. 222 The IPsec pair which protects the mobility signaling uses the home 223 address as its traffic selector for the mobile node. It must not be 224 updated at each handoff. The update mechanism must provide a fine 225 grain (i.e., per SA) update. 227 3. Proposal 229 The proposal for an address management in IKEv2 is spawn from the NAT 230 traversal mechanisms, mainly with a new peer address update payload. 231 But there are some points that have to be kept or clarify as they 232 already are in the current IKEv2 draft [1]. 234 3.1. Kept points from/clarification to the IKEv2 draft 17 236 The peer addresses MUST be stable during the initial exchanges, i.e., 237 the IKE_SA_INIT and IKE_AUTH exchanges MUST be transported using the 238 same peer address pair. 240 The peer addresses are used to transport messages. The reply to a 241 request MUST be sent to the source of the request from the 242 destination request, i.e., addresses and ports are reversed between 243 the request and its reply. There is no exception to this rule. 245 For tunnel mode IPsec SAs, the endpoint addresses are the primary 246 peer addresses. We don't propose an alternate way to specify them. 247 The same requirement applies to transport mode IPsec SAs at the 248 exception of the proxy case. 250 3.2. Minor points 252 In retransmission of requests or responses, copies of messages do not 253 include peer addresses. So a peer MAY retransmit an IKE message from 254 or to a different address. 256 The primary peer addresses are IKE SA parameters and are specified by 257 the IKE_SA_INIT exchange. Note that when NAT traversal is not 258 active, they are implicitly protected by the NAT_DETECTION or 259 NAT_PREVENTION notifications. 261 All the text below applies only to the case where NAT traversal is 262 not active. Everything relative to transport mode, including the 263 proxy case, is dealt with in [2]. 265 Return routability checks are done using an informational exchange 266 carrying a RR_COOKIE notification in order to get a proof the probed 267 peer really receives the request. Of course the reply MUST contain 268 the same RR_COOKIE notification than the request. 270 3.3. Peer address notifications 272 The peer address notifications are copied from the current 273 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 274 notifications. They includes the peer source or destination address 275 with its family and an operation code. They MUST be in an encrypted 276 payload. Operations are MARK, ADD and DELETE (last two for alternate 277 addresses, see open issue section for the empty set one and the 278 delete operation on the primary peer address). 280 All messages after the first exchange involving an alternate peer 281 address MUST include at least one peer address notification for each 282 peer, i.e., at least one for the source and at least one for the 283 destination. 285 Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, or 286 carry the peer address update payload defined below, or are pure peer 287 address set management (add/delete). 289 They provide a cryptographically proof of no en-route alteration of 290 the peer addresses and enable operations on the sets of peer 291 addresses, i.e., change of the primary peer address of a peer, 292 addition to and deletion from the peer address set of a peer. 294 When the peer address notifications are not supported, the capability 295 to use an alternate peer address, and only this, is lost. 297 As these notifications do not transport zone indications, they MUST 298 NOT be used for ambiguous not-global addresses. But it is still 299 possible to use a not-global address in the IKE_SA_INIT exchange. 301 NOTE: this seems the only reasonnable common possibility and of 302 course in this case the not-global address is not ambiguous. 304 3.4. Explicit peer address update payload 306 A new payload has to be defined for an explicit peer address update 307 mechanism. We propose to copy it from the delete payload, see 308 Appendix B. 310 The new peer address update payload has strong sequencing 311 requirements. IKEv2 messages have a protected sequence number so the 312 only sequencing issues are the window of processing and pending 313 exchanges. Any messages with a peer address update payload MUST be 314 processed in order. 316 When the receiver of an additin or update request has to check the 317 validity of a new peer address, it MAY use a return routability check 318 sending an informational request carrying a RR_COOKIE notification at 319 the new address and waiting for an answer. As informational 320 exchanges are protected no more is needed. 322 Example of a return routability check: 324 I ----- address update request -----> R 325 I <-- informational RR [Ni] request - R 326 I --- informational RR [Ni] reply --> R 327 now the responder knows the initiator should be where it claimed 328 to be. 329 I <------ address update reply ------ R 331 When a peer address update deletes the current primary address, 332 pending (i.e., to be retransmitted) requests MUST be sent to the new 333 address(es) even it is (they are) not yet checked. 335 NOTE: look at the open issue about the detection of the movement 336 behind a NAT. 338 As for the delete payload, the peer address update payload specifies 339 the SPIs of the IPsec and IKE SAs it applies to. But a simple way to 340 specify all SAs (i.e., the IKE SA and all the tunnel mode IPsec SAs 341 it negotiated) is needed so is provided. 343 An updated peer address may be in some corresponding SPD entries: 344 when an IPsec SA is modified, by default the SPD entry which matches 345 the traffic selector SHOULD be accordingly modified (cf. the next 346 version of the IPsec architecture [3]). This behavior MAY be 347 disabled. 349 3.5. Open issues 351 Notification/payload/exchange: the current choice is a notification 352 for peer addresses (copied on NAT detection notifications) and a 353 payload for peer address update (copied on SA delete payload). 355 Interaction with NAT-T: the current choice is to avoid the case where 356 one peer is behind a NAT then uses NAT-T and the other peer uses 357 MOBIKE: in this situation NAT-T usage by both peers MUST be enforced. 359 Path failure detection: the proposal does not provide any dedicated 360 mechanism, the generic mobility or multi-homing control SHOULD be 361 used instead, including for simultaneous changes. 363 When to perform a return routability check?: this is a policy issue, 364 some answers follow. 366 Can a peer address set be empty?: still open. Mechanisms permit 367 this... 369 New error notification for address problems: likely to be necessary. 371 Dead lock with too small message window?: message windows greater 372 than one are RECOMMENDED and the last message of windows SHOULD be 373 reserved to MOBIKE. 375 Peer address addition request from an unknown address: (here unknown 376 means not in the peer address set even after the processing of the 377 message) this is the only circumstance where a return routability 378 check is clearly REQUIRED: 379 - if it succeeds for the peer address the message MUST be accepted 380 - if it fails for the peer address but succeeds for the unknown 381 source address the peer has moved behind a NAT. 383 Last point: how to update the SPD entries? One possibility is to 384 change the PAD ([3] section 4.4.3 defining the Peer Authorization 385 Database) too. 387 4. Security Considerations 389 Great care was used to avoid to introduce new security threats. 391 The NAT traversal feature comes with a security flaw (the transient 392 pseudo-NAT attack [10]) which can not be easily avoid. IMHO the NAT 393 traversal feature should be enabled only when the presence of NATs is 394 likely/possible. 396 When the NAT traversal feature is disabled, the address of the other 397 peer can not be changed en-route by an attacker but the proofs the 398 peer is really at its address are: 399 - the trust in the peer 400 - the source address is topologically plausible 401 - the proof that the peer can receive messages sent to its address. 403 The second (a.k.a. the return routability check) works only with at 404 least two ot three not-trivial messages, i.e., for the initial 405 exchange (with the address stability requirement) and for explicit 406 checks. IMHO these checks SHOULD be required for a new alternate 407 peer address as soon as there is no proof of the address validity, 408 for instance when: 409 - the message does not come from this address (ingress filtering 410 [14] can drop a message with a fake source address), 411 - and there is no authorization for this address. 413 5. Acknowledgments 415 The rare people in the Mobility world with IPsec interests, or in the 416 IPsec world with Mobility interest, should receive all thanks because 417 without them we (me and all the future co-authors) have given up for 418 a long time. 420 Tero Kivinen helped to improve the NAT traversal part of this 421 proposal. Tero and Jari Arkko proposed another form of peer address 422 update based on the IKE SA addresses. Pasi Eronen suggested the 423 NAT_PREVENTION notification. 425 6. References 427 6.1. Normative References 429 [1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", 430 draft-ietf-ipsec-ikev2-17.txt (work in progress), 431 September 2004. 433 [2] Dupont, F., "IPsec transport mode in Mobike environments", 434 draft-dupont-mobike-transport-03.txt (work in progress), 435 October 2005. 437 [3] Kent, S. and K. Seo, "Security Architecture for the Internet 438 Protocol", draft-ietf-ipsec-rfc2401bis-06.txt (work in 439 progress), March 2005. 441 6.2. Informative References 443 [4] IKEv2 Mobility and Multihoming (mobike), "Charter", 2004, 444 . 446 [5] Vilhuber, J., "IP header compression in IPsec ESP", 447 draft-vilhuber-hcoesp-01.txt (work in progress), July 2004. 449 [6] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 450 ISAKMP, IKEv2, and PKIX", 451 draft-ietf-pki4ipsec-ikecert-profile-07.txt (work in progress), 452 November 2005. 454 [7] Hoffman, P., "Adding revised identities to IKEv2", 455 November 2002, >. 458 [8] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", 459 RFC 2956, October 2000. 461 [9] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", 462 draft-ietf-mobike-design-04.txt (work in progress), 463 October 2005. 465 [10] Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks or 466 how NATs are even more evil than you believed", 467 draft-dupont-transient-pseudonat-04.txt (work in progress), 468 June 2004. 470 [11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 471 IPv6", RFC 3775, June 2004. 473 [12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 474 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 475 Agents", RFC 3776, June 2004. 477 [13] Dupont, F. and W. Haddad, "How to make IPsec more mobile IPv6 478 friendly", draft-dupont-ipsec-mipv6-05.txt (work in progress), 479 February 2004. 481 [14] Ferguson, P. and D. Senie, "Network Ingress Filtering: 482 Defeating Denial of Service Attacks which employ IP Source 483 Address Spoofing", RFC 2827, BCP 38, May 2000. 485 [15] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management 486 API, Version 2", RFC 2367, July 1998. 488 Appendix A. Peer Address Notification Format 490 The following diagram illustrates the content of the Peer Address 491 Notification: 493 1 2 3 495 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 ! Next Payload !C! RESERVED ! Payload Length ! 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 ! Protocol-ID ! SPI Size ! Notify Message Type ! 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 ! Address Family ! Operation ! 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 ~ Address ~ 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 1 508 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 509 no SPI). The Address Family is from IANA Address Family Numbers 510 (IPv4 is 1 and IPv6 2). The proposed names are PEER_ADDRESS_SOURCE 511 and PEER_ADDRESS_DESTINATION, with 248XX. Operation codes are: 512 - MARK (1): the peer address is marked for further operation, for 513 instance an peer address update: the marked address will become 514 the new primary peer address. 515 - ADD (2): add a new alternate peer address to the set. 516 - DELETE (3): delete an alternate peer address from the set. 518 Appendix B. Peer Address Update Payload Format 520 The next figure shows the format of the Peer Address Update Payload. 521 It is possible to send multiple SPIs in a Peer Address Update 522 payload, however, each SPI MUST be for the same protocol. Mixing of 523 Protocol Identifiers MUST NOT be performed in a the Peer Address 524 Update payload. It is permitted, however, to include multiple Peer 525 Address Update payloads in a single INFORMATIONAL Exchange where each 526 Peer Address Update payload lists SPIs for a different protocol. 528 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but no 529 SPI. Update of a CHILD_SA, such as ESP or AH, will contain the 530 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 531 SPI the sending endpoint would expect in inbound ESP or AH packets. 533 The following diagram illustrates the content of the Peer Address 534 Update Notification: 536 1 2 3 538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 ! Next Payload !C! RESERVED ! Payload Length ! 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 !A|O|Protocol-ID! SPI Size ! # of SPIs ! 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 ! ! 545 ~ Security Parameter Index(es) (SPI) ~ 546 ! ! 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 2 551 - A[ll] (1 bit) - MUST be set to one when all SAs (the IKE SA and 552 all tunnel mode outgoing IPsec SAs negotiated by it) are updated. 553 In this case the update is for the IKE-SA (Protocol-ID 0, SPI size 554 0, no SPI and number of SPIs 0). MUST be set to zero when an 555 individual SA is updated. 557 - O[nly] (1 bit) - MUST be set to one when the corresponding SPD 558 entry when it exists MUST NOT be modified. MUST be set to zero 559 for the default behavior: for all SPD entries matching traffic 560 selectors of updated IPsec SAs the peer address(es) MUST be 561 updated. 563 - Protocol_Id (6 bits) - MUST be zero for an IKE_SA, 1 for ESP, or 2 564 for AH. 566 - SPI Size (1 octet) - Length in octets of the SPI as defined by the 567 Protocol-Id. Zero for IKE (the SPI is got from the message 568 header) or four for AH or ESP. 570 - # of SPIs (2 octets) - The number of SPIs contained in the Peer 571 Address Update Notification. The size of each SPI is defined by 572 the SPI Size field. 574 - Security Parameter Index(es) (variable length) - Identifies the 575 specific security association(s) to delete. The lengths of these 576 fields are determined by the SPI Size and the number of SPIs 577 fields. 579 The C[ritical] bit MUST be set to one even a peer which does not 580 support Peer Address Update Payloads does not support Peer Address 581 Notifications too. 583 ESP and AH SAs always exist in pairs, with one SA in each direction. 584 When an SA is updated for a peer address, both members of the pair 585 MUST be updated. When SAs are nested, as when data (and IP headers 586 if in tunnel mode) are encapsulated first with IPcomp, then with ESP, 587 and finally with AH between the same pair of endpoints, all of the 588 SAs MUST be updated together. Each endpoint MUST update the SAs it 589 receives on and allow the other endpoint to update the other SA in 590 each pair. 592 To update a peer address of an SA, an Informational Exchange with one 593 or more peer address update payloads is sent listing the SPIs (as 594 they would be placed in the headers of inbound packets) of the SAs to 595 be updated, and with a peer address notification setting the primary 596 peer address. The recipient MUST update the designated SAs. 597 Normally, the reply in the Informational Exchange will contain peer 598 address update payloads for the paired SAs going in the other 599 direction. Note there is no special case for update collision. 601 The proposed name is the Update (U) payload. 603 Appendix C. NAT Prevention Notification Format 605 The NAT_PREVENTION notification purpose is to protect the peer 606 addresses in the IKE_SA_INIT exchange without misleading the 607 responder, i.e., NAT_DETECTION_SOURCE_IP and 608 NAT_DETECTION_DESTINATION_IP do the same thing but suggest the 609 responder is ready to accept NAT traversal. 611 The NAT_PREVENTION notification SHOULD be used when NAT traversal is 612 not wanted and the authentication does not validate the peer address: 613 the default policy (cf. [6] section 3.1.1 about address ID payloads) 614 is to validate peer addresses but only when the ID payload is an 615 address and this validation may be disabled. 617 1 2 3 619 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 ! Next Payload !C! RESERVED ! Payload Length ! 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 ! Protocol-ID ! SPI Size ! Notify Message Type ! 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 ~ SHA-1 Hash of the Pseudo-Header ~ 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Figure 3 629 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 630 no SPI). The content is the SHA-1 hash of the transport pseudo- 631 header. 633 NOTE: there is an IPR issue over the NAT detection notifications. 635 Appendix D. Return Routability Cookie Notification Format 637 The RR_COOKIE notification layout is: 639 1 2 3 641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 ! Next Payload !C! RESERVED ! Payload Length ! 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 ! Protocol-ID ! SPI Size ! Notify Message Type ! 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 ~ Cookie ~ 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 4 652 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 653 no SPI). The data associated with the notification (i.e., the cookie 654 itself) MUST be between 16 and 64 octets in length (inclusive). 656 This cookie SHOULD be included in return routability probes in order 657 to make them unpredictable. A reply to a request carrying a 658 RR_COOKIE notification MUST contain a copy of it. 660 Appendix E. PF_KEY version 2 SADB_X_ADDUPD 662 This annex describes an extension to PF_KEYv2 [15] which provides a 663 way to ask a peer address update of an IPsec SA and all its siblings 664 (i.e., an update with the All flag set to one). 666 The format of the message is: 667 668 and is sent the registered socket listeners by or via the kernel. No 669 answer is needed because if it fails it will be done again. 671 New values are needed for SADB_X_ADDUPD and for 672 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST which 673 should have the same layout than SADB_EXT_ADDRESS_*, i.e., 674 sadb_address structure. 676 NOTE: IKE itself needs a PF_KEYv2 extension for individual updating 677 of an IPsec SA. 679 Author's Address 681 Francis Dupont 682 Point6 683 c/o GET/ENST Bretagne 684 2 rue de la Chataigneraie 685 CS 17607 686 35576 Cesson-Sevigne Cedex 687 France 689 Fax: +33 2 99 12 70 30 690 Email: Francis.Dupont@enst-bretagne.fr 692 Intellectual Property Statement 694 The IETF takes no position regarding the validity or scope of any 695 Intellectual Property Rights or other rights that might be claimed to 696 pertain to the implementation or use of the technology described in 697 this document or the extent to which any license under such rights 698 might or might not be available; nor does it represent that it has 699 made any independent effort to identify any such rights. Information 700 on the procedures with respect to rights in RFC documents can be 701 found in BCP 78 and BCP 79. 703 Copies of IPR disclosures made to the IETF Secretariat and any 704 assurances of licenses to be made available, or the result of an 705 attempt made to obtain a general license or permission for the use of 706 such proprietary rights by implementers or users of this 707 specification can be obtained from the IETF on-line IPR repository at 708 http://www.ietf.org/ipr. 710 The IETF invites any interested party to bring to its attention any 711 copyrights, patents or patent applications, or other proprietary 712 rights that may cover technology that may be required to implement 713 this standard. Please address the information to the IETF at 714 ietf-ipr@ietf.org. 716 Disclaimer of Validity 718 This document and the information contained herein are provided on an 719 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 720 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 721 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 722 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 723 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 724 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 726 Copyright Statement 728 Copyright (C) The Internet Society (2005). This document is subject 729 to the rights, licenses and restrictions contained in BCP 78, and 730 except as set forth therein, the authors retain all their rights. 732 Acknowledgment 734 Funding for the RFC Editor function is currently provided by the 735 Internet Society.