idnits 2.17.1 draft-dupont-ikev2-addrmgmt-07.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. ** 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 235: '...e peer addresses MUST be stable during...' RFC 2119 keyword, line 236: '...E_AUTH exchanges MUST be transported u...' RFC 2119 keyword, line 240: '... request MUST be sent to the source ...' RFC 2119 keyword, line 252: '...sses. So a peer MAY retransmit an IKE...' RFC 2119 keyword, line 266: '...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 (May 17, 2005) is 6917 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 325 == Outdated reference: A later version (-04) exists of draft-dupont-mobike-transport-02 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-04 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-02 -- 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. -------------------------------------------------------------------------------- 1 Network Working Group F. Dupont 2 Internet-Draft Point6 3 Expires: November 18, 2005 May 17, 2005 5 Address Management for IKE version 2 6 draft-dupont-ikev2-addrmgmt-07.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 18, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 The current IKEv2 proposal lacks an address management feature. As 40 it is compatible with the NAT traversal capability, this document 41 specifies a complete address management with support for multi-homing 42 and mobility, and fulfill mobike IETF working group goals 1, 2, 3, 4, 43 and 6. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1 Simplicity, Performance and Security . . . . . . . . . . . 3 50 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.3 Multi-homing requirements . . . . . . . . . . . . . . . . 4 52 2.4 Mobility requirements . . . . . . . . . . . . . . . . . . 4 53 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1 Kept points from/clarification to the IKEv2 draft 17 . . . 6 55 3.2 Minor points . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.3 Peer address notifications . . . . . . . . . . . . . . . . 7 57 3.4 Explicit peer address update payload . . . . . . . . . . . 7 58 3.5 Open issues . . . . . . . . . . . . . . . . . . . . . . . 8 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 63 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 65 A. Peer Address Notification Format . . . . . . . . . . . . . . . 11 66 B. Peer Address Update Payload Format . . . . . . . . . . . . . . 12 67 C. NAT Prevention Notification Format . . . . . . . . . . . . . . 14 68 D. Return Routability Cookie Notification Format . . . . . . . . 15 69 E. PF_KEY version 2 SADB_X_ADDUPD . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . . 16 72 1. Introduction 74 This document proposes an address management for IKEv2 [1] for all 75 the IETF mobike working group goals [4] at the exception of the goal 76 5 (handled by [5]). 78 In this document, the addresses used to transport IKE messages are 79 named the "peer addresses" (term introduced by [6]). These peer 80 addresses should no more be directly or indirectly included in 81 identities ([7] and [8]) as it is commonly done for IKEv1. 83 The current IKEv2 draft [1] often makes the implicit assumption that 84 an address identifies a node when nodes behind a NAT can share the 85 same address and a node can use many different addresses. This must 86 be taken into account in implementations, for instance by reading 87 this document before writing code... 89 This document describes the goals of an address management for IKEv2, 90 including the requirements for multi-homing and mobility support 91 (this part will be removed as soon as the mobike requirements 92 document [9] is finalized), and finishes by a concrete proposal. 94 In this document, open questions are introduced by the word NOTE and 95 will be refined in a dedicated section. 97 2. Goals 99 The goals of the address management proposed in the document can be 100 divided in some general goals and in requirements for the three 101 mechanisms which can change the peer addresses. 103 2.1 Simplicity, Performance and Security 105 The address management should be as simple as possible, i.e., it 106 should introduce minimal additions to the current IKEv2 draft [1] and 107 each addition should be justified. 109 The performance is an important criterion. For instance, rekeying 110 can update the peer addresses of an IKE SA or an IPsec SA pair, but 111 rekeying is too expensive and a specific solution is needed. 113 As a security protocol, IKEv2 should get a high security level. 114 Unfortunately we already showed that the NAT traversal feature comes 115 with a security issue (the transient pseudo-NAT attack [10]). 117 Such problems introduced by the peer address flexibility must be 118 described in this document and at least be mitigated by options in 119 configurations. For instance, the NAT traversal feature should never 120 be enabled when one knows that there can not be a NAT as today in 121 IPv6. 123 An other example of an insecure mechanism is to use the addresses in 124 IP headers of CREATE_CHILD_SA messages as the endpoint addresses of 125 the new IPsec SAs without further control on them: peer addresses 126 must be managed. 128 2.2 Terminology 130 The addresses of the two peers are named "peer addresses". With 131 other words the peer addresses are the addresses IKE runs over but 132 this document extends this basic definition. The primary peer 133 address of a peer is initialized to the address used to transport 134 messages of the initial exchanges, other addresses are "alternate 135 peer addresses". 137 The proxy case is the setup of transport mode IPsec SAs on the behalf 138 of another party, i.e., transport mode IPsec SAs where the traffic 139 selectors do not match the primary peer addresses. 141 2.3 Multi-homing requirements 143 In this document, the support of multi-homing is the support of nodes 144 with several global addresses. Some of the addresses can be "better" 145 than others, or "better" for some destinations. Some can, from time 146 to time, be unavailable. 148 The main requirement for the support of multi-homing is the 149 management of a set of peer addresses for each peer. The set can be 150 partially ordered or some subsets can be loosely associated with some 151 destinations (i.e., some subsets of the other peer address set, this 152 is needed when a destination address can be reached only using 153 particular source addresses). 155 For the communication between multi-addressed hosts, the support of 156 the proxy case can be useful because it provides an easy way to setup 157 transport mode IPsec SAs with different addresses from one IKE SA. 158 In such cases the other party is in fact the same host, this 159 dramatically simplifies the authorization issue. 161 2.4 Mobility requirements 163 In the context of Mobile IPv6 ([11] and for the special case of Home 164 Agents [12]), the interaction of Mobility and IPsec was analyzed in 165 another document [13]. This document assumes an IPv6 context as 166 Mobile IPv6 is the most powerful mobility proposal available today. 168 An IPv6 mobile node is another type of multi-addressed node with: 169 - a care-of address in a prefix of the visited link. 170 The care-of address is used to route packets. 171 - the home address in a prefix of the home link. 172 The home address is used to identify the mobile node. 174 The care-of address is transient and usually the mobile node can not 175 provide a proof that it is the node using it. So it has to be 176 trusted and a return routability check (i.e., an enforced answer from 177 this address) should be used if it is not. 179 With a common correspondent, the mobility is transparent and there is 180 no reason to use another address than the home address. For 181 optimized schemes, without an implementation of header compression in 182 ESP tunnel mode (the goal 5 of mobike [4]) the choice between a 183 transport mode using triangular routing (IPsec can be used to verify 184 home address options) and a tunnel mode with routing optimization is 185 not clear. But this case does not add new requirement, i.e., the 186 home agent case includes them. 188 With the home agent, there are three main cases (c.f. [12]): 190 - The mobility signaling which is mandatory protected and raises a 191 specific issue in its initial phase: the IKE SA must be setup 192 using the care-of address as the peer address but this IKE SA is 193 used to build an IPsec SA pair with the home address as traffic 194 selector. This IPsec SA will protect the home registration which 195 will make the home address available. This can be considered as a 196 specialized proxy case. 198 - Other genuine communications between the home agent and the mobile 199 node can be covered by the proxy case support too. Note this is 200 the only case at the exception of signaling where mobility behaves 201 in a different way than a mobile IPsec VPN (so we proposed to 202 relax the corresponding rule in a future version of [11] and 203 [12]). 205 - The traffic relayed by the home agent through a tunnel with the 206 mobile node can be partially or fully protected by IPsec SA 207 pair(s). Encapsulation should be performed only once, including 208 for degenerated (but not for free) encapsulation like the home 209 address option or the mobility routing header. 211 In all cases of interaction with the home agent, the mobile node peer 212 address should be a care-of address. When the mobile node moves, 213 another care-of address is used and some SAs, including the IKE SA, 214 must be updated to use the new address. 216 Usually the previous peer address is no more usable. In order to 217 avoid a trivial denial of services, a strong sequencing of updates is 218 required with a way to cancel possible pending updates when fast 219 multiple handoff happen. 221 The IPsec pair which protects the mobility signaling uses the home 222 address as its traffic selector for the mobile node. It must not be 223 updated at each handoff. The update mechanism must provide a fine 224 grain (i.e., per SA) update. 226 3. Proposal 228 The proposal for an address management in IKEv2 is spawn from the NAT 229 traversal mechanisms, mainly with a new peer address update payload. 230 But there are some points that have to be kept or clarify as they 231 already are in the current IKEv2 draft [1]. 233 3.1 Kept points from/clarification to the IKEv2 draft 17 235 The peer addresses MUST be stable during the initial exchanges, i.e., 236 the IKE_SA_INIT and IKE_AUTH exchanges MUST be transported using the 237 same peer address pair. 239 The peer addresses are used to transport messages. The reply to a 240 request MUST be sent to the source of the request from the 241 destination request, i.e., addresses and ports are reversed between 242 the request and its reply. There is no exception to this rule. 244 For tunnel mode IPsec SAs, the endpoint addresses are the primary 245 peer addresses. We don't propose an alternate way to specify them. 246 The same requirement applies to transport mode IPsec SAs at the 247 exception of the proxy case. 249 3.2 Minor points 251 In retransmission of requests or responses, copies of messages do not 252 include peer addresses. So a peer MAY retransmit an IKE message from 253 or to a different address. 255 The primary peer addresses are IKE SA parameters and are specified by 256 the IKE_SA_INIT exchange. Note that when NAT traversal is not 257 active, they are implicitly protected by the NAT_DETECTION or 258 NAT_PREVENTION notifications. 260 All the text below applies only to the case where NAT traversal is 261 not active. Everything relative to transport mode, including the 262 proxy case, is dealt with in [2]. 264 Return routability checks are done using an informational exchange 265 carrying a RR_COOKIE notification in order to get a proof the probed 266 peer really receives the request. Of course the reply MUST contain 267 the same RR_COOKIE notification than the request. 269 3.3 Peer address notifications 271 The peer address notifications are copied from the current 272 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 273 notifications. They includes the peer source or destination address 274 with its family and an operation code. They MUST be in an encrypted 275 payload. Operations are MARK, ADD and DELETE (last two for alternate 276 addresses, see open issue section for the empty set one and the 277 delete operation on the primary peer address). 279 All messages after the first exchange involving an alternate peer 280 address MUST include at least one peer address notification for each 281 peer, i.e., at least one for the source and at least one for the 282 destination. 284 Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, or 285 carry the peer address update payload defined below, or are pure peer 286 address set management (add/delete). 288 They provide a cryptographically proof of no en-route alteration of 289 the peer addresses and enable operations on the sets of peer 290 addresses, i.e., change of the primary peer address of a peer, 291 addition to and deletion from the peer address set of a peer. 293 When the peer address notifications are not supported, the capability 294 to use an alternate peer address, and only this, is lost. 296 As these notifications do not transport zone indications, they MUST 297 NOT be used for ambiguous not-global addresses. But it is still 298 possible to use a not-global address in the IKE_SA_INIT exchange. 300 NOTE: this seems the only reasonnable common possibility and of 301 course in this case the not-global address is not ambiguous. 303 3.4 Explicit peer address update payload 305 A new payload has to be defined for an explicit peer address update 306 mechanism. We propose to copy it from the delete payload, see 307 Appendix B. 309 The new peer address update payload has strong sequencing 310 requirements. IKEv2 messages have a protected sequence number so the 311 only sequencing issues are the window of processing and pending 312 exchanges. Any messages with a peer address update payload MUST be 313 processed in order. 315 When the receiver of an additin or update request has to check the 316 validity of a new peer address, it MAY use a return routability check 317 sending an informational request carrying a RR_COOKIE notification at 318 the new address and waiting for an answer. As informational 319 exchanges are protected no more is needed. 321 Example of a return routability check: 323 I ----- address update request -----> R 324 I <-- informational RR [Ni] request - R 325 I --- informational RR [Ni] reply --> R 326 now the responder knows the initiator should be where it claimed 327 to be. 328 I <------ address update reply ------ R 330 When a peer address update deletes the current primary address, 331 pending (i.e., to be retransmitted) requests MUST be sent to the new 332 address(es) even it is (they are) not yet checked. 334 NOTE: look at the open issue about the detection of the movement 335 behind a NAT. 337 As for the delete payload, the peer address update payload specifies 338 the SPIs of the IPsec and IKE SAs it applies to. But a simple way to 339 specify all SAs (i.e., the IKE SA and all the tunnel mode IPsec SAs 340 it negotiated) is needed so is provided. 342 An updated peer address may be in some corresponding SPD entries: 343 when an IPsec SA is modified, by default the SPD entry which matches 344 the traffic selector SHOULD be accordingly modified (cf. the next 345 version of the IPsec architecture [3]). This behavior MAY be 346 disabled. 348 3.5 Open issues 350 Notification/payload/exchange: the current choice is a notification 351 for peer addresses (copied on NAT detection notifications) and a 352 payload for peer address update (copied on SA delete payload). 354 Interaction with NAT-T: the current choice is to avoid the case where 355 one peer is behind a NAT then uses NAT-T and the other peer uses 356 MOBIKE: in this situation NAT-T usage by both peers MUST be enforced. 358 Path failure detection: the proposal does not provide any dedicated 359 mechanism, the generic mobility or multi-homing control SHOULD be 360 used instead, including for simultaneous changes. 362 When to perform a return routability check?: this is a policy issue, 363 some answers follow. 365 Can a peer address set be empty?: still open. Mechanisms permit 366 this... 368 New error notification for address problems: likely to be necessary. 370 Dead lock with too small message window?: message windows greater 371 than one are RECOMMENDED and the last message of windows SHOULD be 372 reserved to MOBIKE. 374 Peer address addition request from an unknown address: (here unknown 375 means not in the peer address set even after the processing of the 376 message) this is the only circumstance where a return routability 377 check is clearly REQUIRED: 378 - if it succeeds for the peer address the message MUST be accepted 379 - if it fails for the peer address but succeeds for the unknown 380 source address the peer has moved behind a NAT. 382 Last point: how to update the SPD entries? One possibility is to 383 change the PAD ([3] section 4.4.3 defining the Peer Authorization 384 Database) too. 386 4. Security Considerations 388 Great care was used to avoid to introduce new security threats. 390 The NAT traversal feature comes with a security flaw (the transient 391 pseudo-NAT attack [10]) which can not be easily avoid. IMHO the NAT 392 traversal feature should be enabled only when the presence of NATs is 393 likely/possible. 395 When the NAT traversal feature is disabled, the address of the other 396 peer can not be changed en-route by an attacker but the proofs the 397 peer is really at its address are: 398 - the trust in the peer 399 - the source address is topologically plausible 400 - the proof that the peer can receive messages sent to its address. 402 The second (a.k.a. the return routability check) works only with at 403 least two ot three not-trivial messages, i.e., for the initial 404 exchange (with the address stability requirement) and for explicit 405 checks. IMHO these checks SHOULD be required for a new alternate 406 peer address as soon as there is no proof of the address validity, 407 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-02.txt (work in progress), 435 April 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-04.txt (work in progress), 452 December 2004. 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-02.txt (work in progress), 463 February 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 Author's Address 490 Francis Dupont 491 Point6 492 c/o GET/ENST Bretagne 493 2 rue de la Chataigneraie 494 CS 17607 495 35576 Cesson-Sevigne Cedex 496 France 498 Fax: +33 2 99 12 70 30 499 Email: Francis.Dupont@enst-bretagne.fr 501 Appendix A. Peer Address Notification Format 503 The following diagram illustrates the content of the Peer Address 504 Notification: 506 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 ! Next Payload !C! RESERVED ! Payload Length ! 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 ! Protocol-ID ! SPI Size ! Notify Message Type ! 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 ! Address Family ! Operation ! 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 ~ Address ~ 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 1 521 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 522 no SPI). The Address Family is from IANA Address Family Numbers 523 (IPv4 is 1 and IPv6 2). The proposed names are PEER_ADDRESS_SOURCE 524 and PEER_ADDRESS_DESTINATION, with 248XX. Operation codes are: 525 - MARK (1): the peer address is marked for further operation, for 526 instance an peer address update: the marked address will become 527 the new primary peer address. 528 - ADD (2): add a new alternate peer address to the set. 529 - DELETE (3): delete an alternate peer address from the set. 531 Appendix B. Peer Address Update Payload Format 533 The next figure shows the format of the Peer Address Update Payload. 534 It is possible to send multiple SPIs in a Peer Address Update 535 payload, however, each SPI MUST be for the same protocol. Mixing of 536 Protocol Identifiers MUST NOT be performed in a the Peer Address 537 Update payload. It is permitted, however, to include multiple Peer 538 Address Update payloads in a single INFORMATIONAL Exchange where each 539 Peer Address Update payload lists SPIs for a different protocol. 541 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but no 542 SPI. Update of a CHILD_SA, such as ESP or AH, will contain the 543 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 544 SPI the sending endpoint would expect in inbound ESP or AH packets. 546 The following diagram illustrates the content of the Peer Address 547 Update Notification: 549 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 ! Next Payload !C! RESERVED ! Payload Length ! 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 !A|O|Protocol-ID! SPI Size ! # of SPIs ! 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 ! ! 558 ~ Security Parameter Index(es) (SPI) ~ 559 ! ! 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 2 564 - A[ll] (1 bit) - MUST be set to one when all SAs (the IKE SA and 565 all tunnel mode outgoing IPsec SAs negotiated by it) are updated. 566 In this case the update is for the IKE-SA (Protocol-ID 0, SPI size 567 0, no SPI and number of SPIs 0). MUST be set to zero when an 568 individual SA is updated. 570 - O[nly] (1 bit) - MUST be set to one when the corresponding SPD 571 entry when it exists MUST NOT be modified. MUST be set to zero 572 for the default behavior: for all SPD entries matching traffic 573 selectors of updated IPsec SAs the peer address(es) MUST be 574 updated. 576 - Protocol_Id (6 bits) - MUST be zero for an IKE_SA, 1 for ESP, or 2 577 for AH. 579 - SPI Size (1 octet) - Length in octets of the SPI as defined by the 580 Protocol-Id. Zero for IKE (the SPI is got from the message 581 header) or four for AH or ESP. 583 - # of SPIs (2 octets) - The number of SPIs contained in the Peer 584 Address Update Notification. The size of each SPI is defined by 585 the SPI Size field. 587 - Security Parameter Index(es) (variable length) - Identifies the 588 specific security association(s) to delete. The lengths of these 589 fields are determined by the SPI Size and the number of SPIs 590 fields. 592 The C[ritical] bit MUST be set to one even a peer which does not 593 support Peer Address Update Payloads does not support Peer Address 594 Notifications too. 596 ESP and AH SAs always exist in pairs, with one SA in each direction. 597 When an SA is updated for a peer address, both members of the pair 598 MUST be updated. When SAs are nested, as when data (and IP headers 599 if in tunnel mode) are encapsulated first with IPcomp, then with ESP, 600 and finally with AH between the same pair of endpoints, all of the 601 SAs MUST be updated together. Each endpoint MUST update the SAs it 602 receives on and allow the other endpoint to update the other SA in 603 each pair. 605 To update a peer address of an SA, an Informational Exchange with one 606 or more peer address update payloads is sent listing the SPIs (as 607 they would be placed in the headers of inbound packets) of the SAs to 608 be updated, and with a peer address notification setting the primary 609 peer address. The recipient MUST update the designated SAs. 610 Normally, the reply in the Informational Exchange will contain peer 611 address update payloads for the paired SAs going in the other 612 direction. Note there is no special case for update collision. 614 The proposed name is the Update (U) payload. 616 Appendix C. NAT Prevention Notification Format 618 The NAT_PREVENTION notification purpose is to protect the peer 619 addresses in the IKE_SA_INIT exchange without misleading the 620 responder, i.e., NAT_DETECTION_SOURCE_IP and 621 NAT_DETECTION_DESTINATION_IP do the same thing but suggest the 622 responder is ready to accept NAT traversal. 624 The NAT_PREVENTION notification SHOULD be used when NAT traversal is 625 not wanted and the authentication does not validate the peer address: 626 the default policy (cf. [6] section 3.1.1 about address ID payloads) 627 is to validate peer addresses but only when the ID payload is an 628 address and this validation may be disabled. 630 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 ! Next Payload !C! RESERVED ! Payload Length ! 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 ! Protocol-ID ! SPI Size ! Notify Message Type ! 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 ~ SHA-1 Hash of the Pseudo-Header ~ 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 3 643 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 644 no SPI). The content is the SHA-1 hash of the transport pseudo- 645 header. 647 NOTE: there is an IPR issue over the NAT detection notifications. 649 Appendix D. Return Routability Cookie Notification Format 651 The RR_COOKIE notification layout is: 653 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 ! Next Payload !C! RESERVED ! Payload Length ! 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 ! Protocol-ID ! SPI Size ! Notify Message Type ! 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 ~ Cookie ~ 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 4 666 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 and 667 no SPI). The data associated with the notification (i.e., the cookie 668 itself) MUST be between 16 and 64 octets in length (inclusive). 670 This cookie SHOULD be included in return routability probes in order 671 to make them unpredictable. A reply to a request carrying a 672 RR_COOKIE notification MUST contain a copy of it. 674 Appendix E. PF_KEY version 2 SADB_X_ADDUPD 676 This annex describes an extension to PF_KEYv2 [15] which provides a 677 way to ask a peer address update of an IPsec SA and all its siblings 678 (i.e., an update with the All flag set to one). 680 The format of the message is: 681 682 and is sent the registered socket listeners by or via the kernel. No 683 answer is needed because if it fails it will be done again. 685 New values are needed for SADB_X_ADDUPD and for 686 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST which 687 should have the same layout than SADB_EXT_ADDRESS_*, i.e., 688 sadb_address structure. 690 NOTE: IKE itself needs a PF_KEYv2 extension for individual updating 691 of an IPsec SA. 693 Intellectual Property Statement 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 717 Disclaimer of Validity 719 This document and the information contained herein are provided on an 720 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 721 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 722 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 723 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 724 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Copyright Statement 729 Copyright (C) The Internet Society (2005). This document is subject 730 to the rights, licenses and restrictions contained in BCP 78, and 731 except as set forth therein, the authors retain all their rights. 733 Acknowledgment 735 Funding for the RFC Editor function is currently provided by the 736 Internet Society.