idnits 2.17.1 draft-dupont-ikev2-addrmgmt-05.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 3667, Section 5.1 on line 12. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == 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 abstract seems to contain references ([2], [3], [1]), 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 208: '...e peer addresses MUST be stable during...' RFC 2119 keyword, line 209: '...IKE_AUTH exchanges MUST be transported...' RFC 2119 keyword, line 213: '... a request MUST be sent to the sourc...' RFC 2119 keyword, line 226: '...esses. So a peer MAY retransmit an IKE...' RFC 2119 keyword, line 241: '...l policy of the responder is REQUIRED,...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2004) is 7255 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 301 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-14 == Outdated reference: A later version (-01) exists of draft-vilhuber-hcoesp-00 == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-00 == Outdated reference: A later version (-04) exists of draft-dupont-transient-pseudonat-03 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '8') (Obsoleted by RFC 6275) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Francis Dupont 2 INTERNET DRAFT GET/ENST Bretagne 3 Expires in December 2004 June 2004 5 Address Management for IKE version 2 7 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 or will be disclosed, and any of which I become aware will be 12 disclosed, in accordance with RFC 3668. 14 Status of this Memo 16 This document is an Internet Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Distribution of this memo is unlimited. 38 Abstract 40 The current IKEv2 proposal [1] lacks an address management 41 feature. As it is compatible with the NAT traversal capability, 42 this document specifies a complete address management with support 43 for multi-homing and mobility, and fulfill mobike working group 44 [2] goals 1, 2, 3, 4, and 6 (for goal 5 look at [3]). 46 1. Introduction 48 In this document, the addresses used to transport IKE messages are 49 named the "peer addresses" (term introduced by [4]). These peer 50 addresses should no more be directly or indirectly included in 51 identities ([5] and [6]) as it is commonly done for IKEv1. 53 The current IKEv2 draft [1] often makes the assumption that an 54 address identifies a node when nodes behind a NAT can share the 55 same address and a node can use many different addresses. This 56 must be taken into account in implementations, for instance by 57 reading this document before writing code... 59 This document describes the goals of an address management for 60 IKEv2, including the requirements for multi-homing and mobility 61 support (this part will be removed as soon as the mobike 62 requirements document [12] is finalized), and finishes by a 63 concrete proposal. 65 In this document, open questions are introduced by the word NOTE 66 and will be refined in a dedicated section. 68 2. Goals 70 The goals of the address management proposed in the document can be 71 divided in some general goals and in requirements for the three 72 mechanisms which can change the peer addresses. 74 2.1 Simplicity, Performance and Security 76 The address management should be as simple as possible, i.e., it 77 should introduce minimal additions to the current IKEv2 draft [1] 78 and each addition should be justified. 80 The performance is an important criterion. For instance, rekeying 81 can update the peer addresses of an IKE SA or an IPsec SA pair, 82 but rekeying is too expensive and a specific solution is needed. 84 As a security protocol, IKEv2 should get a high security 85 level. Unfortunately we already showed that the NAT traversal 86 feature comes with a security issue (the transient pseudo-NAT 87 attack [7]). 89 Such problems introduced by the peer address flexibility must be 90 described in this document and at least be mitigated by options in 91 configurations. For instance, the NAT traversal feature should 92 never be enabled when one knows that there can not be a NAT as 93 today in IPv6. 95 An other example of an insecure mechanism is to use the addresses 96 in IP headers of CREATE_CHILD_SA messages as the endpoint 97 addresses of the new IPsec SAs without further control on them: 98 peer addresses must be managed. 100 2.2 Terminology 102 The addresses of the two peers are named "peer addresses". With 103 other words the peer addresses are the addresses IKE runs over 104 but this document extends this basic definition. The primary peer 105 address of a peer is initialized to the address used to transport 106 messages of the initial exchanges, other addresses are "alternate 107 peer addresses". 109 The proxy case is the setup of transport mode IPsec SAs on the 110 behalf of another party, i.e., transport mode IPsec SAs where the 111 traffic selectors do not match the primary peer addresses. 113 2.3 Multi-homing requirements 115 In this document, the support of multi-homing is the support of 116 nodes with several global addresses. Some of the addresses can be 117 "better" than others, or "better" for some destinations. Some can, 118 from time to time, be unavailable. 120 The main requirement for the support of multi-homing is the 121 management of a set of peer addresses for each peer. The set can 122 be partially ordered or some subset can be loosely associated with 123 some destinations (i.e., some subset of the other peer address 124 set). 126 For the communication between multi-addressed hosts, the support 127 of the proxy case can be useful because it provides an easy way to 128 setup transport mode IPsec SAs with different addresses from one 129 IKE SA. In such cases the other party is in fact the same host, 130 this dramatically simplifies the authorization issue. 132 2.4 Mobility requirements 134 In the context of Mobile IPv6 ([8] and for the special case of 135 Home Agents [9]), the interaction of Mobility and IPsec was 136 analyzed in another document [10]. This document assumes an IPv6 137 context as Mobile IPv6 is the most powerful mobility proposal 138 available today. 140 An IPv6 mobile node is another type of multi-addressed node with: 141 - a care-of address in a prefix of the visited link. 142 The care-of address is used to route packets. 143 - the home address in a prefix of the home link. 144 The home address is used to identify the mobile node. 146 The care-of address is transient and usually the mobile node can 147 not provide a proof that it is the node using it. So it has to be 148 trusted and a return routability check (i.e., an enforced answer 149 from this address) should be used if it is not. 151 With a common correspondent, the mobility is transparent and there 152 is no reason to use another address than the home address. For 153 optimized schemes, without an implementation of header compression 154 in ESP tunnel mode (the goal 5 of mobike [2]) the choice between a 155 transport mode using triangular routing (IPsec can be used to 156 verify home address options) and a tunnel mode with routing 157 optimization is not clear. But this case does not add new 158 requirement, i.e., the home agent case includes them. 160 With the home agent, there are three main cases (c.f. [9]): 162 - The mobility signaling which is mandatory protected and 163 raises a specific issue in its initial phase: the IKE SA 164 must be setup using the care-of address as the peer address 165 but this IKE SA is used to build an IPsec SA pair with 166 the home address as traffic selector. This IPsec SA will 167 protect the home registration which will make the home 168 address available. This can be considered as a specialized 169 proxy case. 171 - Other genuine communications between the home agent and 172 the mobile node can be covered by the proxy case support 173 too. Note this is the only case at the exception of signaling 174 where mobility behaves in a different way than a mobile IPsec 175 VPN (so we proposed to relax the corresponding rule in a 176 future version of [8] and [9]). 178 - The traffic relayed by the home agent through a tunnel with the 179 mobile node can be partially or fully protected by IPsec SA 180 pair(s). Encapsulation should be performed only once, including 181 for degenerated (but not for free) encapsulation like the home 182 address option or the mobility routing header. 184 In all cases of interaction with the home agent, the mobile node 185 peer address should be a care-of address. When the mobile node 186 moves, another care-of address is used and some SAs, including the 187 IKE SA, must be updated to use the new address. 189 Usually the previous peer address is no more usable. In order to 190 avoid a trivial denial of services, a strong sequencing of updates 191 is required with a way to cancel possible pending updates when 192 fast multiple handoff happen. 194 The IPsec pair which protects the mobility signaling uses the home 195 address as its traffic selector for the mobile node. It must not 196 be updated at each handoff. The update mechanism must provide a 197 fine grain (i.e., per SA) update. 199 3. Proposal 201 The proposal for an address management in IKEv2 is spawn from the 202 NAT traversal mechanisms, mainly with a new peer address update 203 payload. But there are some points that have to be kept or 204 clarify as they already are in the current IKEv2 draft [1]. 206 3.1 Kept points from/clarification to the IKEv2 draft 14 208 The peer addresses MUST be stable during the initial exchanges, 209 i.e., the IKE_SA_INIT and IKE_AUTH exchanges MUST be transported 210 using the same peer address pair. 212 The peer addresses are used to transport messages. The reply to 213 a request MUST be sent to the source of the request from the 214 destination request, i.e., addresses and ports are reversed 215 between the request and its reply. There is no exception to this 216 rule. 218 For tunnel mode IPsec SAs, the endpoint addresses are the primary 219 peer addresses. We don't propose an alternate way to specify them. 220 The same requirement applies to transport mode IPsec SAs at the 221 exception of the proxy case. 223 3.2 Minor points 225 In retransmission of requests or responses, copies of messages do 226 not include peer addresses. So a peer MAY retransmit an IKE message 227 from or to a different address. 229 The primary peer addresses are IKE SA parameters and are specified 230 by the IKE_SA_INIT exchange. Note that when NAT traversal is not 231 active, they are implicitly protected by the NAT_DETECTION 232 notifications. 234 All the text below applies only to the case where NAT traversal 235 is not active. 237 In the proxy case, the initiator is acting as a client negotiator 238 on the behalf of another party. The address of this other party is 239 sent in the initiator traffic selector and will become the address 240 of this end of the transport mode IPsec SA pair. A proper 241 authorization in the local policy of the responder is REQUIRED, 242 the default rule SHOULD be: 243 - using an alternate peer address is permitted 244 - other cases are denied. 246 Return routability checks are done using an informational exchange 247 carrying a nonce in order to get a proof the probed peer really 248 receives the request. Of course the replay MUST contain the same 249 nonce payload than the request. 251 3.3 Peer address notifications 253 The peer address notifications are copied from the current 254 NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP 255 notifications. They includes the peer source or destination 256 address with its family and an operation code. They MUST be 257 in an encrypted payload. Operations are PRIMARY, ADD and 258 DELETE (last two for alternate addresses, see open issue 259 section for the empty set one and the delete operation on 260 the primary peer address). 262 All messages after the first exchange involving an alternate peer 263 address MUST include at least one peer address notification for 264 each peer, i.e., at least one for the source and at least one for 265 the destination. 267 Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, 268 or carry the peer address update payload defined below, or 269 are pure peer address set management (add/delete). 271 They provide a cryptographically proof of no en-route alteration 272 of the peer addresses and enable operations on the sets of peer 273 addresses, i.e., change of the primary peer address of a peer, 274 addition to and deletion from the peer address set of a peer. 276 When the peer address notifications are not supported, the 277 capability to use an alternate peer address, and only this, 278 is lost. 280 3.4 Explicit peer address update payload 282 A new payload has to be defined for an explicit peer address 283 update mechanism. We propose to copy it from the delete payload, 284 see Annex B. 286 The new peer address update payload has strong sequencing 287 requirements. IKEv2 messages have a protected sequence number so 288 the only sequencing issues are the window of processing and 289 pending exchanges. Any messages with a peer address update payload 290 MUST be processed in order. 292 When the receiver of an update request has to check the validity 293 of the new primary peer address, it MAY use a return routability 294 check sending an informational request carrying a nonce payload 295 at the new address and waiting for an answer. As informational 296 exchanges are protected no more is needed. 298 Example of a return routability check: 300 I ----- address update request -----> R 301 I <-- informational RR [Ni] request - R 302 I --- informational RR {Ni] reply --> R 303 now the responder knows the initiator should be where it 304 claimed to be. 305 I <------ address update reply ------ R 307 As for the delete payload, the peer address update payload 308 specifies the SPIs of the IPsec and IKE SAs it applies to. But 309 a simple way to specify all SAs (i.e., the IKE SA and all the 310 tunnel mode IPsec SAs it negotiated) is needed so is provided. 312 3.5 Open issues 314 Notification/payload/exchange: the current choice is a notification 315 for peer addresses (copied on NAT detection notifications) and a 316 payload for peer address update (copied on SA delete payload). 318 Interaction with NAT-T: the current choice is to avoid the case 319 where one peer is behind a NAT then uses NAT-T and the other 320 peer uses MOBIKE: in this situation NAT-T usage by both peers 321 MUST be enforced. 323 Path failure detection: the proposal does not provide any dedicated 324 mechanism, the generic mobility or multi-homing control SHOULD be 325 used instead, including for simultaneous changes. 327 When to perform a return routability check?: this is a policy 328 issue, some answers are in the next section. 330 Can a peer address set be empty?: still open. Mechanisms permit 331 this... 333 New error notification for address problems: likely to be 334 necessary. 336 Peer address addition request from an unknown address: (here 337 unknown means not in the peer address set even after processing of 338 the message) this is the only circumstance where return routability 339 checks are clearly REQUIRED: 340 - if it succeeds for the peer address the message MUST be accepted 341 - if it fails for the peer address but succeeds for the unknown 342 source address the peer has moved behind a NAT 344 4. Security Considerations 346 Great care was used to avoid to introduce security threats. 348 The NAT traversal feature comes with a security flaw (the transient 349 pseudo-NAT attack [7]) which can not be easily avoid. IMHO the NAT 350 traversal feature should be enabled only when the presence of NATs 351 is likely/possible. 353 When the NAT traversal feature is disabled, the address of the 354 other peer can not be changed en-route by an attacker but the 355 proofs the peer is really at its address are: 356 - the trust in the peer 357 - the source address is topologically plausible 358 - the proof that the peer can receive messages sent to its address. 360 The second (a.k.a. the return routability check) works only with at 361 least two ot three not-trivial messages, i.e., for the initial 362 exchange (with the address stability requirement) and for explicit 363 checks. IMHO these checks SHOULD be required for a new alternate 364 peer address as soon as there is no proof of the address validity, 365 for instance when: 366 - the message does not come from this address (ingress filtering 367 [13] can drop a message with a fake source address), 368 - and there is no authorization for this address. 370 5. Acknowledgments 372 The rare people in the Mobility world with IPsec interests, or in 373 the IPsec world with Mobility interest, should receive all thanks 374 because without them we (me and all the future co-authors) have 375 given up for a long time. 377 Tero Kivinen helped to improve the NAT traversal part of this 378 proposal. Tero and Jari Arkko proposed another form of peer 379 address update based on the IKE SA addresses. 381 7. Normative References 383 [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 384 draft-ietf-ipsec-ikev2-14.txt, May 2004. 386 8. Informative References 388 [2] IKEv2 Mobility and Multihoming (mobike), "charter", 389 http://www.ietf.org/html.charters/mobike-charter.html. 391 [3] J. Vilhuber, "IP header compression in IPsec ESP", 392 draft-vilhuber-hcoesp-00.txt, January 2003. 394 [4] B. Korver, "The Internet IP Security PKI Profile of 395 IKEv1/ISAKMP, IKEv2, and PKIX", 396 draft-ietf-pki4ipsec-ikecert-profile-00.txt, May 2004. 398 [5] P. Hoffman, "Adding revised identities to IKEv2", 399 http://www.vpnc.org/ietf-ipsec/, 400 Message-Id: , 401 November 2002. 403 [6] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 404 RFC 2956, October 2000. 406 [7] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 407 or how NATs are even more evil than you believed", 408 draft-dupont-transient-pseudonat-03.txt, February 2004. 410 [8] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 411 RFC 3775, June 2004. 413 [9] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect 414 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 415 RFC 3776, June 2004. 417 [10] F. Dupont, W. Haddad, "How to make IPsec more mobile IPv6 418 friendly", draft-dupont-ipsec-mipv6-05.txt, February 2004. 420 [11] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 421 Version 2", RFC 2367, July 1998. 423 [12] T. Kivinen, "Design of the MOBIKE protocol", 424 draft-kivinen-mobike-design-00.txt, February 2004. 426 [13] P. Ferguson, D. Senie, "Network Ingress Filtering: 427 Defeating Denial of Service Attacks which employ IP Source 428 Address Spoofing", RFC 2827 / BCP 38, May 2000. 430 9. Author's Address 432 Francis Dupont 433 ENST Bretagne 434 Campus de Rennes 435 2, rue de la Chataigneraie 436 CS 17607 437 35576 Cesson-Sevigne Cedex 438 FRANCE 439 Fax: +33 2 99 12 70 30 440 EMail: Francis.Dupont@enst-bretagne.fr 442 Annex A. Peer Address Notification Format. 444 The following diagram illustrates the content of the Peer Address 445 Notification: 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ! Next Payload !C! RESERVED ! Payload Length ! 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ! Protocol-ID ! SPI Size ! Notify Message Type ! 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ! Address Family ! Operation ! 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 ~ Address ~ 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 459 and no SPI. The Address Family is from IANA Address Family Numbers 460 (IPv4 is 1 and IPv6 2). The proposed names are PEER-ADDRESS-SOURCE 461 and PEER-ADDRESS-DESTINATION, with 248XX. Operation codes are: 462 - PRIMARY (1): the primary peer address is set to the address. 463 The peer address update payload MUST be used to change the 464 primary peer address. 465 - ADD (2): add a new alternate peer address to the set. 466 - DELETE (3): delete an alternate peer address from the set. 468 Annex B. Peer Address Update Payload Format. 470 The next figure 17 shows the format of the Peer Address Update 471 Payload. It is possible to send multiple SPIs in a Peer Address 472 Update payload, however, each SPI MUST be for the same 473 protocol. Mixing of Protocol Identifiers MUST NOT be performed in a 474 the Peer Address Update payload. It is permitted, however, to 475 include multiple Peer Address Update payloads in a single 476 INFORMATIONAL Exchange where each Peer Address Update payload lists 477 SPIs for a different protocol. 479 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but 480 no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the 481 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 482 SPI the sending endpoint would expect in inbound ESP or AH packets. 484 The following diagram illustrates the content of the Peer Address 485 Update Notification: 486 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 ! Next Payload !C! RESERVED ! Payload Length ! 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 !A| Protocol-ID ! SPI Size ! # of SPIs ! 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 ! ! 495 ~ Security Parameter Index(es) (SPI) ~ 496 ! ! 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 o A[ll] (1 bit) - MUST be set to one when all SAs (the IKE SA 500 and all tunnel mode outgoing IPsec SAs negotiated by it) are 501 updated. In this case the update is for the IKE-SA (Protocol-ID 502 0, SPI size 0, no SPI and number of SPIs 0). 503 MUST be set to zero when an individual SA is updated. 505 o Protocol_Id (7 bits) - MUST be zero for an IKE_SA, 1 for 506 ESP, or 2 for AH. 508 o SPI Size (1 octet) - Length in octets of the SPI as defined by 509 the Protocol-Id. Zero for IKE (the SPI is got from the message 510 header) or four for AH or ESP. 512 o # of SPIs (2 octets) - The number of SPIs contained in the Peer 513 Address Update Notification. The size of each SPI is defined 514 by the SPI Size field. 516 o Security Parameter Index(es) (variable length) - Identifies the 517 specific security association(s) to delete. The lengths of these 518 fields are determined by the SPI Size and the number of SPIs 519 fields. 521 The C[ritical] bit MUST be set to one even a peer which does not 522 support Peer Address Update Payloads does not support Peer 523 Address Notifications too. 525 ESP and AH SAs always exist in pairs, with one SA in each direction. 526 When an SA is updated for a peer address, both members of the pair 527 MUST be updated. When SAs are nested, as when data (and IP headers 528 if in tunnel mode) are encapsulated first with IPcomp, then with 529 ESP, and finally with AH between the same pair of endpoints, all of 530 the SAs MUST be updated together. Each endpoint MUST update the SAs 531 it receives on and allow the other endpoint to update the other SA 532 in each pair. 534 To update a peer address of an SA, an Informational Exchange with 535 one or more peer address update payloads is sent listing the SPIs 536 (as they would be placed in the headers of inbound packets) of the 537 SAs to be updated, and with a peer address notification setting 538 the primary peer address. The recipient MUST update the designated 539 SAs. Normally, the reply in the Informational Exchange will 540 contain peer address update payloads for the paired SAs going in 541 the other direction. Note there is no special case for update 542 collision. 544 The proposed name is the Update (U) payload. 546 Annex C. PF_KEY version 2 SADB_X_ADDUPD 548 This annex describes an extension to PF_KEYv2 [11] which provides 549 a way to ask a peer address update of an IPsec SA and all its 550 siblings (i.e., an update with the All flag set to one). 552 The format of the message is: 553 554 and is sent the registered socket listeners by or via the kernel. 555 No answer is needed because if it fails it will be done again. 557 New values are needed for SADB_X_ADDUPD and for 558 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST 559 which should have the same layout than SADB_EXT_ADDRESS_*, 560 i.e., sadb_address structure. 562 NOTE: IKE itself needs a PF_KEYv2 extension for individual 563 updating of an IPsec SA.