idnits 2.17.1 draft-dupont-ikev2-addrmgmt-02.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-04-24) 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 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 96: '... IKE SA MUST be done using only ...' RFC 2119 keyword, line 204: '...e peer addresses MUST NOT change durin...' RFC 2119 keyword, line 212: '... a request MUST be sent to the sour...' RFC 2119 keyword, line 229: '... REQUIRED. Note that the IPsec SAs ...' RFC 2119 keyword, line 238: '...esses. So a peer MAY retransmit a mess...' (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 (April 2003) is 7680 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 385, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-06 == 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-21 == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-04 == Outdated reference: A later version (-05) exists of draft-dupont-ipsec-mipv6-03 Summary: 6 errors (**), 0 flaws (~~), 8 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 October 2003 April 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 includes a NAT traversal capability, this document 37 extends it to a complete address management with support for 38 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 must 50 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. 92 The second missing thing in the current IKEv2 draft [1] is about 93 some misusage of the peer addresses: 95 - At the reception of a message, the lookup of the corresponding 96 IKE SA MUST be done using only the SPIs, never using the peer 97 addresses. 99 - An INITIAL-CONTACT notification deletes old IKE SAs associated 100 to the peer Identity, not to the peer address. Current wording 101 is a bit misleading. 103 - The revised identity proposal [3] should be integrated in the 104 IKEv2 specifications. According to IAB recommendations [4], 105 addresses should not be used as or associated to identities. 107 Note that the last point stresses the issue of the lack of 108 protection of peer addresses. 110 The last thing to fix in the current IKEv2 draft [1] is the 111 support of the proxy case: the setup of transport mode IPsec SAs 112 on the behalf of another party. 114 2.2 Multi-homing requirements 116 In this document, the support of multi-homing is the support of 117 nodes with several global addresses. Some of the addresses can be 118 "better" than others, or "better" for some destinations. Some can, 119 from time to time, be unavailable. 121 The main requirement for the support of multi-homing is the 122 management of a set of peer addresses for each peer. The set can 123 be partially ordered or some subset can be loosely associated with 124 some destinations (i.e., some subset of the other peer address 125 set). 127 For the communication between multi-addressed hosts, the support 128 of the proxy case can be useful because it provides an easy way to 129 setup transport mode IPsec SAs with different addresses from one 130 IKE SA. In such cases the other party is in fact the same host, 131 this dramatically simplifies the authorization issue. 133 2.3 Mobility requirements 135 In the context of Mobile IPv6 ([7] and for the special case of 136 Home Agents [8]), the interaction of Mobility and IPsec was 137 analyzed in another document [9]. This document assumes an IPv6 138 context as Mobile IPv6 is the most powerful mobility proposal 139 available today. 141 An IPv6 mobile node is another type of multi-addressed node with: 142 - a care-of address in a prefix of the visited link. 143 The care-of address is used to route packets. 144 - the home address in a prefix of the home link. 145 The home address is used to identify the mobile node. 147 The care-of address is transient and usually the mobile node can 148 not provide a proof that it is the node using it. So it must be 149 trusted and a return routability check (i.e., an enforced answer 150 from this address) should be used if it is not. 152 With a common correspondent, the mobility is transparent and 153 there is no reason to use another address than the home address. 155 With the home agent, there are three main cases (c.f. [8]): 157 - The mobility signaling which is mandatory protected and 158 raises a specific issue in its initial phase: the IKE SA 159 must be setup using the care-of address as the peer address 160 but this IKE SA is used to build an IPsec SA pair with 161 the home address as traffic selector. This IPsec SA will 162 protect the home registration which will make the home 163 address available. This can be considered as a special 164 proxy case. 166 - Other genuine communications between the home agent and 167 the mobile node can be covered by the proxy case support 168 too. Note this is the only case at the exception of signaling 169 where mobility behaves in a different way than a mobile IPsec 170 VPN (so we proposed to relax the corresponding rule in a 171 future version of [7] and [8]). 173 - The traffic relayed by the home agent through a tunnel with the 174 mobile node can be partially or fully protected by IPsec SA 175 pair(s). Encapsulation should be performed only once, including 176 for degenerated (but not for free) encapsulation like the home 177 address option or the mobility routing header. 179 In all cases of interaction with the home agent, the mobile node 180 peer address should be a care-of address. When the mobile node 181 moves, another care-of address is used and some SAs, including the 182 IKE SA, must be updated to use the new address. 184 Usually the previous peer address is no more usable. In order to 185 avoid a trivial denial of services, a strong sequencing of updates 186 is required with a way to cancel possible pending updates when 187 fast multiple handoff happen. 189 The IPsec pair which protects the mobility signaling uses the home 190 address as its traffic selector for the mobile node. It must not 191 be updated at each handoff. The update mechanism must provide a 192 fine grain (i.e., per SA) update. 194 3. Proposal 196 The proposal for an address management in IKEv2 is spawn from the 197 NAT traversal mechanisms, mainly with a new peer address update 198 notification. But there are some points that have to be kept as 199 they are in the current IKEv2 draft [1]. 201 3.1 Kept points from draft 06 203 A peer address change has to be supported but not at any time: 204 the peer addresses MUST NOT change during an exchange, i.e., 205 they are allowed to change only between two exchanges. 207 This address stability requirement applies in fact only to the 208 Initial exchange as it is the only exchange with more than two 209 messages specified today. 211 The peer addresses are used to transport messages. The reply to 212 a request MUST be sent to the source of the request from the 213 destination request, i.e., addresses and ports are reversed 214 between the request and its reply. There is no exception to this 215 rule. 217 For tunnel mode IPsec SAs, the endpoint addresses are the peer 218 addresses. We don't propose an alternate way to specify them. 219 The same requirement applies to transport mode IPsec SAs at the 220 exception of the proxy case. 222 3.2 Small points 224 In the proxy case, the initiator is acting as a client negotiator 225 on the behalf of another party. The address of this other party is 226 sent in the initiator traffic selector and will become the address 227 of this end of the transport mode IPsec SA pair. A proper 228 authorization in the local policy of the responder is 229 REQUIRED. Note that the IPsec SAs built in such cases are not 230 managed in the proposal of these document, and that the proxy case 231 is limited to the transport mode. 233 The INITIAL-CONTACT notification uses only identities. All the 234 references to peer addresses must be removed from or fixed in the 235 current wording. 237 In retransmission of requests or responses, copies of messages do 238 not include peer addresses. So a peer MAY retransmit a message 239 from or to a different address. 241 3.3 Peer address notifications 243 The peer address notifications are copied from the current 244 NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP 245 notifications. They includes the peer source or destination 246 address and the source or destination port and MUST be 247 in an encrypted payload. 249 All messages after the first exchange MUST include at least one 250 peer address notification for each peer, i.e., at least one for 251 the source and at least one for the destination. 253 They provide a cryptographically proof of no alteration en-route 254 of the peer addresses and, when multiple peer address 255 notifications for the same peer are included, they encode its 256 whole peer address set. To allow the reduction of the peer 257 address set to one address, an address MAY be repeated. 259 If multiple peer address notifications for the same peer are 260 included in a message, the first one MUST be the used peer 261 address. 263 In order to associate some possible peer source addresses to 264 possible peer destination addresses, the source and destination 265 peer addresses notifications MAY be mixed (i.e., not in the common 266 order source(s) first, destination(s) after). For instance S1, S2, 267 D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction 268 with D1, S3 with D2 or D3. 270 In case of a mismatch of a peer address with the corresponding 271 peer address notifications, there is a dangling update or an 272 attack. If the possibly compromised message is a new request, its 273 content MUST be ignored and a warning notification sent, but the 274 message counter MUST be incremented in order to accept next 275 requests. If it is a retransmitted request, the cached reply MUST 276 be sent. If it is a reply, the corresponding request MUST be 277 retransmitted. 279 If the peer has moved between two retransmissions of a request, it 280 can interleave an explicit address update of at least the IKE SA. 282 3.4 Explicit address update payload 284 The explicit mechanism MUST be used when NAT traversal is disabled 285 and only it this case. A new payload has to be defined. 286 We propose to copy it from the delete payload, see Annex C. 288 The new peer address update payload has strong sequencing 289 requirements. IKEv2 messages have a protected sequence number so 290 the only sequencing issues are the window of processing and 291 pending exchanges. Any messages with a peer address update payload 292 MUST be processed in order. 294 When the receiver of an update request has to check the validity 295 of the new peer address, it MAY use a return routability check 296 sending an informational request at the new address and waiting 297 for an answer. As informational exchanges are protected no more is 298 needed. 300 Example of a return routability check: 302 I --- address update request --> R 303 I <-- informational RR request - R 304 I --- informational RR reply --> R 305 now the responder knows the initiator should be where it 306 claimed to be. 307 I <--- address update reply ---- R 309 As for the delete [ayload, the peer address update payload 310 specifies the SPIs of the IPsec and IKE SAs it applies to. But a 311 simple way to specify all SAs (i.e., the IKE SA and all the 312 non-proxy IPsec SAs it negotiated) is needed. 314 4. Security Considerations 316 Great care was used to avoid to introduce security threats. 318 The NAT traversal feature comes with a security flaw (the transient 319 pseudo-NAT attack [5]) which can not be easily avoid. IMHO the NAT 320 traversal feature should be enabled only when the presence of NATs 321 is likely/possible. 323 When the NAT traversal feature is disabled, the other peer address 324 can not be changed en-route by an attacker but the proofs the peer 325 is really at its address are: 326 - the trust in the peer 327 - the proof that the peer can receive messages sent to its address 328 The second (a.k.a. the return routability check) works only with at 329 least three messages, i.e., for the initial exchange (with the 330 address stability requirement) and for the explicit optional 331 checks. IMHO these checks SHOULD be required by default. 333 5. Acknowledgments 335 The need for an address management for IKEv2 was explained at the 336 ipsec session of the Yokohama IETF meeting. It seems most people 337 agree but do not propose concrete solutions. 339 The rare people in the Mobility world with IPsec interests, or in 340 the IPsec world with Mobility interest, should receive all thanks 341 because without them we (me and all the future co-authors) have 342 given up for a long time. 344 Tero Kivinen helped to improve the NAT traversal part of this 345 proposal. 347 6. Changes from previous versions 349 The explicit peer address update mechanism is a new payload 350 (and it followed the update of the deletion payload). 352 The NAT traversal part was dropped and the "merge" style given up. 354 Secret peer addresses are supported. 356 The implicit mechanism comes back but is restricted to NAT traversal. 358 Annexes are added for a more accurate proposal. 360 7. Normative References 362 None? 364 8. Informative References 366 [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 367 draft-ietf-ipsec-ikev2-06.txt, March 2003. 369 [2] B. Korver, E. Rescorla, "The Internet IP Security PKI 370 Profile of ISAKMP and PKIX", 371 draft-ietf-ipsec-pki-profile-02.txt, February 2003. 373 [3] P. Hoffman, "Adding revised identities to IKEv2", 374 http://www.vpnc.org/ietf-ipsec/, 375 Message-Id: , 376 November 2002. 378 [4] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 379 RFC 2956, October 2000. 381 [5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 382 or how NATs are even more evil than you believed", 383 draft-dupont-transient-pseudonat-01.txt, December 2002. 385 [6] Jayant Shukla, "RE: peer address protection and NAT Traversal", 386 http://www.vpnc.org/ietf-ipsec/, 387 Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>, 388 January 2003. 390 [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 391 draft-ietf-mobileip-ipv6-21.txt, February 2003. 393 [8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect 394 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 395 draft-ietf-mobileip-mipv6-ha-ipsec-04.txt, March 2003. 397 [9] F. Dupont, W. Haddad, "How to make IPsec more mobile IPv6 398 friendly", draft-dupont-ipsec-mipv6-03.txt, March 2003. 400 [10] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 401 Version 2", RFC 2367, July 1998. 403 9. Author's Address 405 Francis Dupont 406 ENST Bretagne 407 Campus de Rennes 408 2, rue de la Chataigneraie 409 BP 78 410 35512 Cesson-Sevigne Cedex 411 FRANCE 412 Fax: +33 2 99 12 70 30 413 EMail: Francis.Dupont@enst-bretagne.fr 415 Annex A. Proxy Case Usage Scenario. 417 +-+-+-+-+-+-+ 418 ! ! 419 !Negotiator ! 420 !Endpoint !<.....\ IKE 421 ! ! \............................\ 422 +-+-+-+-+-+-+ ! 423 V 424 +-+-+-+-+-+ +-+-+-+-+-+ 425 ! ! ! ! 426 !Protected! IPsec Transport !Protected! 427 !Endpoint !<-------------------------------->!Endpoint ! 428 ! ! ! ! 429 +-+-+-+-+-+ +-+-+-+-+-+ 431 In this scenario, both protected endpoints of the IP connection 432 implement IPsec both the first one does not support IKE. The 433 negotiator endpoint needs only to implement IKE. Address 434 management is not supported for the IPsec SAs between the two 435 protected endpoints because the negotiator endpoint has no 436 control over the address of the protected endpoint it establishes 437 on the behalf of. For instance, NAT traversal is not supported. 439 Annex B. Peer Address Notification Format. 441 The following diagram illustrates the content of the Peer Address 442 Notification: 444 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 ! Next Payload !C! RESERVED ! Payload Length ! 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ! Protocol-ID ! SPI Size ! Notify Message Type ! 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ! Address Family ! Port ! 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ~ Address ~ 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 457 and no SPI. The Address Family is from IANA Address Family Numbers 458 (IPv4 is 1 and IPv6 2). The proposed names are PEER-ADDRESS-SOURCE 459 and PEER-ADDRESS-DESTINATION, with 248XX. 461 Annex C. Peer Address Update Payload Format. 463 The next figure 17 shows the format of the Peer Address Update 464 Payload. It is possible to send multiple SPIs in a Peer Address 465 Update payload, however, each SPI MUST be for the same 466 protocol. Mixing of Protocol Identifiers MUST NOT be performed in a 467 the Peer Address Update payload. It is permitted, however, to 468 include multiple Peer Address Update payloads in a single 469 INFORMATIONAL Exchange where each Peer Address Update payload lists 470 SPIs for a different protocol. 472 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but 473 no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the 474 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 475 SPI the sending endpoint would expect in inbound ESP or AH packets. 477 The following diagram illustrates the content of the Peer Address 478 Update Notification: 480 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 ! Next Payload !C! RESERVED ! Payload Length ! 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 !A| Protocol-ID ! SPI Size ! # of SPIs ! 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 ! ! 488 ~ Security Parameter Index(es) (SPI) ~ 489 ! ! 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 o All (1 bit) - MUST be set to one when all SAs (the IKE SA and 493 all non-proxy outgoing IPsec SAs negotiated by it) are 494 updated. In this case the update is for the IKE-SA (Protocol-ID 495 0, SPI size 0, no SPI and number of SPIs 0). MUST be set to zero 496 when an individual SA is updated. 498 o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for 499 ESP, or 2 for AH. 501 o SPI Size (1 octet) - Length in octets of the SPI as defined by 502 the Protocol-Id. Zero for IKE (SPI is in message header) 503 or four for AH and ESP. 505 o # of SPIs (2 octets) - The number of SPIs contained in the Peer 506 Address Update Notification. The size of each SPI is defined by 507 the SPI Size field. 509 o Security Parameter Index(es) (variable length) - Identifies the 510 specific security association(s) to delete. The lengths of these 511 fields are determined by the SPI Size and # of SPIs fields. 513 ESP and AH SAs always exist in pairs, with one SA in each direction. 514 When an SA is updated for a peer address, both members of the pair 515 MUST be updated. When SAs are nested, as when data (and IP headers 516 if in tunnel mode) are encapsulated first with IPcomp, then with 517 ESP, and finally with AH between the same pair of endpoints, all of 518 the SAs MUST be updated together. Each endpoint MUST update the SAs 519 it receives on and allow the other endpoint to update the other SA 520 in each pair. 522 To update a peer address of an SA, an Informational Exchange with 523 one or more peer address update payloads is sent listing the SPIs 524 (as they would be placed in the headers of inbound packets) of the 525 SAs to be updated. The recipient MUST update the designated SAs. 526 Normally, the reply in the Informational Exchange will contain peer 527 address update payloads for the paired SAs going in the other 528 direction. Note there is no special case for update collision. 530 The proposed name is the Update (U) payload. 532 Annex D. PF_KEY version 2 SADB_X_ADDUPD 534 This annex describes an extension to PF_KEYv2 [10] which provides 535 a way to ask a peer address update of an IPsec SA and all its 536 siblings (i.e., an update with the All flag set to one). 537 The format of the message is: 538 539 and is sent the registered socket listeners by or via the kernel. 540 No answer is needed because if it fails it will be done again. 542 New values are needed for SADB_X_ADDUPD and for 543 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST 544 which should have the same layout than SADB_EXT_ADDRESS_*, 545 i.e., sadb_address structure. 547 NOTE: IKE itself needs a PF_KEYv2 extension for individual 548 updating of an IPsec SA.