idnits 2.17.1 draft-dupont-ikev2-addrmgmt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 60 lines 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 ([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 97: '... IKE SA MUST be done using only ...' RFC 2119 keyword, line 205: '... a request MUST be sent to the sour...' RFC 2119 keyword, line 218: '...esses. So a peer MAY retransmit a mess...' RFC 2119 keyword, line 235: '... REQUIRED, the defaults SHOULD be:...' RFC 2119 keyword, line 244: '...source or destination port and MUST be...' (18 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 2003) is 7593 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) == Unused Reference: '6' is defined on line 408, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-08 == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-pki-profile-02 == Outdated reference: A later version (-04) exists of draft-dupont-transient-pseudonat-01 == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-23 == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-05 == Outdated reference: A later version (-05) exists of draft-dupont-ipsec-mipv6-03 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 2 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 ENST Bretagne 3 Expires in December 2003 June 2003 5 Address Management for IKE version 2 7 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "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 Distribution of this memo is unlimited. 33 Abstract 35 The current IKEv2 proposal [1] lacks an address management 36 feature. As it is compatible with the NAT traversal capability, 37 this document specifies a complete address management with support 38 for multi-homing and mobility. 40 1. Introduction 42 In this document, the addresses used to transport IKE messages are 43 named the "peer addresses" (term introduced by [2]). These peer 44 addresses should no more be directly or indirectly included in 45 identities ([3] and [4]) as it is commonly done for IKEv1. 47 The current IKEv2 draft [1] often makes the assumption that an 48 address identifies a node when nodes behind a NAT can share the 49 same address and a node can use many different addresses. This 50 must be fixed. 52 This document describes the goals of an address management for 53 IKEv2, including the requirements for multi-homing and mobility 54 support, and finishes by a concrete proposal. 56 In this document, open questions are introduced by the word NOTE. 58 2. Goals 60 The goals of the address management proposed in the document can be 61 divided in some general goals and in requirements for the three 62 mechanisms which can change the peer addresses. 64 2.1 General goals 66 2.1.1 Simplicity, Performance and Security 68 The address management should be as simple as possible, i.e., it 69 should introduce minimal changes to the current IKEv2 draft [1] 70 and each changes should be justified. 72 The performance is an important criterion. For instance, rekeying 73 can update the peer addresses of an IKE SA or of an IPsec SA pair, 74 but rekeying is too expensive and a specific solution is needed. 76 As a security protocol, IKEv2 should get a high security 77 level. Unfortunately we already showed that the NAT traversal 78 feature comes with a security issue (the transient pseudo-NAT 79 attack [5]). Such problems introduced by the peer address 80 flexibility must be described in this document and at least be 81 mitigated by options in configurations. For instance, the NAT 82 traversal feature should never be enabled when one knows that 83 there can not be a NAT as in today IPv6. 85 2.1.4 Extensions of the IKEv2 draft 87 The first things to fix in the current IKEv2 draft [1] are for 88 the NAT traversal mechanisms but we exclude them from the scope 89 of this document. We assume that the NAT detection is performed 90 in the first exchange, i.e., NAT_DETECTION notifications are 91 mandatory when IKE doesn't run over UDP port 500. 93 The second missing thing in the current IKEv2 draft [1] is about 94 some misusage of the peer addresses: 96 - At the reception of a message, the lookup of the corresponding 97 IKE SA MUST be done using only the SPIs, never using the peer 98 addresses. 100 - An INITIAL-CONTACT notification deletes old IKE SAs associated 101 to the peer Identity, not to the peer address. Current wording 102 is a bit misleading. 104 - The revised identity proposal [3] should be integrated in the 105 IKEv2 specifications. According to IAB recommendations [4], 106 addresses should not be used as or associated to identities. 108 Note that the last point stresses the issue of the lack of 109 protection of peer addresses. 111 The last thing to fix in the current IKEv2 draft [1] is the 112 support of the proxy case: the setup of transport mode IPsec SAs 113 on the behalf of another party. 115 2.2 Multi-homing requirements 117 In this document, the support of multi-homing is the support of 118 nodes with several global addresses. Some of the addresses can be 119 "better" than others, or "better" for some destinations. Some can, 120 from time to time, be unavailable. 122 The main requirement for the support of multi-homing is the 123 management of a set of peer addresses for each peer. The set can 124 be partially ordered or some subset can be loosely associated with 125 some destinations (i.e., some subset of the other peer address 126 set). 128 For the communication between multi-addressed hosts, the support 129 of the proxy case can be useful because it provides an easy way to 130 setup transport mode IPsec SAs with different addresses from one 131 IKE SA. In such cases the other party is in fact the same host, 132 this dramatically simplifies the authorization issue. 134 2.3 Mobility requirements 136 In the context of Mobile IPv6 ([7] and for the special case of 137 Home Agents [8]), the interaction of Mobility and IPsec was 138 analyzed in another document [9]. This document assumes an IPv6 139 context as Mobile IPv6 is the most powerful mobility proposal 140 available today. 142 An IPv6 mobile node is another type of multi-addressed node with: 143 - a care-of address in a prefix of the visited link. 144 The care-of address is used to route packets. 145 - the home address in a prefix of the home link. 146 The home address is used to identify the mobile node. 148 The care-of address is transient and usually the mobile node can 149 not provide a proof that it is the node using it. So it must be 150 trusted and a return routability check (i.e., an enforced answer 151 from this address) should be used if it is not. 153 With a common correspondent, the mobility is transparent and 154 there is no reason to use another address than the home address. 156 With the home agent, there are three main cases (c.f. [8]): 158 - The mobility signaling which is mandatory protected and 159 raises a specific issue in its initial phase: the IKE SA 160 must be setup using the care-of address as the peer address 161 but this IKE SA is used to build an IPsec SA pair with 162 the home address as traffic selector. This IPsec SA will 163 protect the home registration which will make the home 164 address available. This can be considered as a special 165 proxy case. 167 - Other genuine communications between the home agent and 168 the mobile node can be covered by the proxy case support 169 too. Note this is the only case at the exception of signaling 170 where mobility behaves in a different way than a mobile IPsec 171 VPN (so we proposed to relax the corresponding rule in a 172 future version of [7] and [8]). 174 - The traffic relayed by the home agent through a tunnel with the 175 mobile node can be partially or fully protected by IPsec SA 176 pair(s). Encapsulation should be performed only once, including 177 for degenerated (but not for free) encapsulation like the home 178 address option or the mobility routing header. 180 In all cases of interaction with the home agent, the mobile node 181 peer address should be a care-of address. When the mobile node 182 moves, another care-of address is used and some SAs, including the 183 IKE SA, must be updated to use the new address. 185 Usually the previous peer address is no more usable. In order to 186 avoid a trivial denial of services, a strong sequencing of updates 187 is required with a way to cancel possible pending updates when 188 fast multiple handoff happen. 190 The IPsec pair which protects the mobility signaling uses the home 191 address as its traffic selector for the mobile node. It must not 192 be updated at each handoff. The update mechanism must provide a 193 fine grain (i.e., per SA) update. 195 3. Proposal 197 The proposal for an address management in IKEv2 is spawn from the 198 NAT traversal mechanisms, mainly with a new peer address update 199 payload. But there are some points that have to be kept as they 200 are in the current IKEv2 draft [1]. 202 3.1 Kept points from draft 06 204 The peer addresses are used to transport messages. The reply to 205 a request MUST be sent to the source of the request from the 206 destination request, i.e., addresses and ports are reversed 207 between the request and its reply. There is no exception to this 208 rule. 210 For tunnel mode IPsec SAs, the endpoint addresses are the peer 211 addresses. We don't propose an alternate way to specify them. 212 The same requirement applies to transport mode IPsec SAs at the 213 exception of the proxy case. 215 3.2 Small points 217 In retransmission of requests or responses, copies of messages do 218 not include peer addresses. So a peer MAY retransmit a message 219 from or to a different address. Proposition: clarify that 220 messages are "IKE messages". 222 The peer addresses are IKE SA parameters and are specified by 223 the IKE_SA_INIT exchange. Note that when NAT traversal is not 224 active, they are implicitly protected by the mandatory 225 NAT_DETECTION notifications. 227 All the text below implies only to the case where NAT traversal 228 is not active. 230 In the proxy case, the initiator is acting as a client negotiator 231 on the behalf of another party. The address of this other party is 232 sent in the initiator traffic selector and will become the address 233 of this end of the transport mode IPsec SA pair. A proper 234 authorization in the local policy of the responder is 235 REQUIRED, the defaults SHOULD be: 236 - using another address of the peer address set is permitted 237 - other cases are denied. 239 3.3 Peer address notifications 241 The peer address notifications are copied from the current 242 NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP 243 notifications. They includes the peer source or destination 244 address and the source or destination port and MUST be 245 in an encrypted payload. 247 All messages after the first exchange involving peer addresses 248 which are not the current IKE SA addresses MUST include at least 249 one peer address notification for each peer, i.e., at least one 250 for the source and at least one for the destination. 251 Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, 252 or carry the peer address update payload defined below. 254 They provide a cryptographically proof of no alteration en-route 255 of the peer addresses and, when multiple peer address 256 notifications for the same peer are included, they encode its 257 whole peer address set. To allow the reduction of the peer 258 address set to one address, an address MAY be repeated. 260 If multiple peer address notifications for the same peer are 261 included in a message, the first one MUST be the used peer 262 address. 264 In order to associate some possible peer source addresses to 265 possible peer destination addresses, the source and destination 266 peer addresses notifications MAY be mixed (i.e., not in the common 267 order source(s) first, destination(s) after). For instance S1, S2, 268 D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction 269 with D1, S3 with D2 or D3. 271 In case of a mismatch of a peer address with the corresponding 272 peer address notifications, there is a dangling update or an 273 attack. If the possibly compromised message is a new request, its 274 content MUST be ignored and a warning notification sent, but the 275 message counter MUST be incremented in order to accept next 276 requests. If it is a retransmitted request, the cached reply MUST 277 be sent. If it is a reply, the corresponding request MUST be 278 retransmitted. 280 If the peer has moved between two retransmissions of a request, it 281 can interleave an explicit address update of at least the IKE SA. 283 When the peer address notifications are not supported, the 284 capability to use different peer addresses, and only this, 285 is lost. 287 3.4 Explicit peer address update payload 289 A new payload has to be defined for an explicit peer address 290 update mechanism. We propose to copy it from the delete payload, 291 see Annex C. 293 The new peer address update payload has strong sequencing 294 requirements. IKEv2 messages have a protected sequence number so 295 the only sequencing issues are the window of processing and 296 pending exchanges. Any messages with a peer address update payload 297 MUST be processed in order. 299 When the receiver of an update request has to check the validity 300 of the new peer address, it MAY use a return routability check 301 sending an informational request at the new address and waiting 302 for an answer. As informational exchanges are protected no more is 303 needed. 305 Example of a return routability check: 307 I --- address update request --> R 308 I <-- informational RR request - R 309 I --- informational RR reply --> R 310 now the responder knows the initiator should be where it 311 claimed to be. 312 I <--- address update reply ---- R 314 As for the delete payload, the peer address update payload 315 specifies the SPIs of the IPsec and IKE SAs it applies to. But a 316 simple way to specify all SAs (i.e., the IKE SA and all the 317 tunnel mode IPsec SAs it negotiated) is needed. 319 4. Security Considerations 321 Great care was used to avoid to introduce security threats. 323 The NAT traversal feature comes with a security flaw (the transient 324 pseudo-NAT attack [5]) which can not be easily avoid. IMHO the NAT 325 traversal feature should be enabled only when the presence of NATs 326 is likely/possible. 328 When the NAT traversal feature is disabled, the other peer address 329 can not be changed en-route by an attacker but the proofs the peer 330 is really at its address are: 331 - the trust in the peer 332 - the proof that the peer can receive messages sent to its address 333 The second (a.k.a. the return routability check) works only with at 334 least three messages, i.e., for the initial exchange (with the 335 address stability requirement) and for the explicit optional 336 checks. IMHO these checks SHOULD be required by default. 338 5. Acknowledgments 340 The need for an address management for IKEv2 was explained at the 341 ipsec session of the Yokohama IETF meeting. It seems most people 342 agree but do not propose concrete solutions. 344 The rare people in the Mobility world with IPsec interests, or in 345 the IPsec world with Mobility interest, should receive all thanks 346 because without them we (me and all the future co-authors) have 347 given up for a long time. 349 Tero Kivinen helped to improve the NAT traversal part of this 350 proposal. Tero and Jari Arkko proposed another form of peer 351 address update based on the IKE SA addresses. 353 6. Changes from previous versions 355 6.1 Changes from the previous version 357 Remove the address stability stuff. 359 Permit by default only the proxy case on the behalf of the same 360 node. 362 Remove the clarification request for INITIAL_CONTACT. 364 Make the peer addresses IKE SA parameters specified by the 365 IKE_SA_INIT exchange. 367 Exceptions for the "All flag" are all transport mode IPsec SAs, 368 not proxy case SAs only. 370 6.2 Previous changes 372 The explicit peer address update mechanism is a new payload 373 (and it followed the update of the deletion payload). 375 The NAT traversal part was dropped and the "merge" style given up. 377 Secret peer addresses are supported. 379 The implicit mechanism comes back but is restricted to NAT traversal. 381 Annexes are added for a more accurate proposal. 383 7. Normative References 385 None? 387 8. Informative References 389 [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 390 draft-ietf-ipsec-ikev2-08.txt, May 2003. 392 [2] B. Korver, E. Rescorla, "The Internet IP Security PKI 393 Profile of ISAKMP and PKIX", 394 draft-ietf-ipsec-pki-profile-02.txt, February 2003. 396 [3] P. Hoffman, "Adding revised identities to IKEv2", 397 http://www.vpnc.org/ietf-ipsec/, 398 Message-Id: , 399 November 2002. 401 [4] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 402 RFC 2956, October 2000. 404 [5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 405 or how NATs are even more evil than you believed", 406 draft-dupont-transient-pseudonat-01.txt, December 2002. 408 [6] Jayant Shukla, "RE: peer address protection and NAT Traversal", 409 http://www.vpnc.org/ietf-ipsec/, 410 Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>, 411 January 2003. 413 [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 414 draft-ietf-mobileip-ipv6-23.txt, May 2003. 416 [8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect 417 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 418 draft-ietf-mobileip-mipv6-ha-ipsec-05.txt, May 2003. 420 [9] F. Dupont, W. Haddad, "How to make IPsec more mobile IPv6 421 friendly", draft-dupont-ipsec-mipv6-03.txt, March 2003. 423 [10] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 424 Version 2", RFC 2367, July 1998. 426 9. Author's Address 428 Francis Dupont 429 ENST Bretagne 430 Campus de Rennes 431 2, rue de la Chataigneraie 432 CS 17607 433 35576 Cesson-Sevigne Cedex 434 FRANCE 435 Fax: +33 2 99 12 70 30 436 EMail: Francis.Dupont@enst-bretagne.fr 438 Annex A. Proxy Case Usage Scenario. 440 +-+-+-+-+-+-+ 441 ! ! 442 !Negotiator ! 443 !Endpoint !<.....\ IKE 444 ! ! \............................\ 445 +-+-+-+-+-+-+ ! 446 V 447 +-+-+-+-+-+ +-+-+-+-+-+ 448 ! ! ! ! 449 !Protected! IPsec Transport !Protected! 450 !Endpoint !<-------------------------------->!Endpoint ! 451 ! ! ! ! 452 +-+-+-+-+-+ +-+-+-+-+-+ 454 In this scenario, both protected endpoints of the IP connection 455 implement IPsec both the first one does not support IKE. The 456 negotiator endpoint needs only to implement IKE. Address 457 management is not supported for the IPsec SAs between the two 458 protected endpoints because the negotiator endpoint has no 459 control over the address of the protected endpoint it establishes 460 on the behalf of. For instance, NAT traversal is not supported. 462 In the environments addressed by this document, the protected 463 endpoint is the same than the negotiator but another address 464 is used. As this other address is in the peer address set, there 465 is no authorization issue. 467 Annex B. Peer Address Notification Format. 469 The following diagram illustrates the content of the Peer Address 470 Notification: 472 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 ! Next Payload !C! RESERVED ! Payload Length ! 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 ! Protocol-ID ! SPI Size ! Notify Message Type ! 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 ! Address Family ! Port ! 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 ~ Address ~ 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 485 and no SPI. The Address Family is from IANA Address Family Numbers 486 (IPv4 is 1 and IPv6 2). The proposed names are PEER-ADDRESS-SOURCE 487 and PEER-ADDRESS-DESTINATION, with 248XX. 489 Annex C. Peer Address Update Payload Format. 491 The next figure 17 shows the format of the Peer Address Update 492 Payload. It is possible to send multiple SPIs in a Peer Address 493 Update payload, however, each SPI MUST be for the same 494 protocol. Mixing of Protocol Identifiers MUST NOT be performed in a 495 the Peer Address Update payload. It is permitted, however, to 496 include multiple Peer Address Update payloads in a single 497 INFORMATIONAL Exchange where each Peer Address Update payload lists 498 SPIs for a different protocol. 500 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but 501 no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the 502 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 503 SPI the sending endpoint would expect in inbound ESP or AH packets. 505 The following diagram illustrates the content of the Peer Address 506 Update Notification: 508 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 ! Next Payload !C! RESERVED ! Payload Length ! 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 !A| Protocol-ID ! SPI Size ! # of SPIs ! 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 ! ! 516 ~ Security Parameter Index(es) (SPI) ~ 517 ! ! 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 o All (1 bit) - MUST be set to one when all SAs (the IKE SA and 521 all tunnel mode outgoing IPsec SAs negotiated by it) are 522 updated. In this case the update is for the IKE-SA (Protocol-ID 523 0, SPI size 0, no SPI and number of SPIs 0). MUST be set to zero 524 when an individual SA is updated. 526 o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for 527 ESP, or 2 for AH. 529 o SPI Size (1 octet) - Length in octets of the SPI as defined by 530 the Protocol-Id. Zero for IKE (SPI is in message header) 531 or four for AH and ESP. 533 o # of SPIs (2 octets) - The number of SPIs contained in the Peer 534 Address Update Notification. The size of each SPI is defined by 535 the SPI Size field. 537 o Security Parameter Index(es) (variable length) - Identifies the 538 specific security association(s) to delete. The lengths of these 539 fields are determined by the SPI Size and # of SPIs fields. 541 ESP and AH SAs always exist in pairs, with one SA in each direction. 542 When an SA is updated for a peer address, both members of the pair 543 MUST be updated. When SAs are nested, as when data (and IP headers 544 if in tunnel mode) are encapsulated first with IPcomp, then with 545 ESP, and finally with AH between the same pair of endpoints, all of 546 the SAs MUST be updated together. Each endpoint MUST update the SAs 547 it receives on and allow the other endpoint to update the other SA 548 in each pair. 550 To update a peer address of an SA, an Informational Exchange with 551 one or more peer address update payloads is sent listing the SPIs 552 (as they would be placed in the headers of inbound packets) of the 553 SAs to be updated. The recipient MUST update the designated SAs. 554 Normally, the reply in the Informational Exchange will contain peer 555 address update payloads for the paired SAs going in the other 556 direction. Note there is no special case for update collision. 558 The proposed name is the Update (U) payload. 560 Annex D. PF_KEY version 2 SADB_X_ADDUPD 562 This annex describes an extension to PF_KEYv2 [10] which provides 563 a way to ask a peer address update of an IPsec SA and all its 564 siblings (i.e., an update with the All flag set to one). 565 The format of the message is: 566 567 and is sent the registered socket listeners by or via the kernel. 568 No answer is needed because if it fails it will be done again. 570 New values are needed for SADB_X_ADDUPD and for 571 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST 572 which should have the same layout than SADB_EXT_ADDRESS_*, 573 i.e., sadb_address structure. 575 NOTE: IKE itself needs a PF_KEYv2 extension for individual 576 updating of an IPsec SA.