idnits 2.17.1 draft-dupont-ikev2-addrmgmt-04.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-25) 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 ([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 197: '... a request MUST be sent to the sourc...' RFC 2119 keyword, line 210: '...esses. So a peer MAY retransmit an IKE...' RFC 2119 keyword, line 226: '... REQUIRED, the defaults SHOULD be:...' RFC 2119 keyword, line 235: '...ly and an operation code. They MUST be...' RFC 2119 keyword, line 240: '... address MUST include at least one p...' (11 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 (February 2003) is 7740 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) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 == Outdated reference: A later version (-01) exists of draft-vilhuber-hcoesp-00 == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-pki-profile-03 == Outdated reference: A later version (-04) exists of draft-dupont-transient-pseudonat-03 Summary: 6 errors (**), 0 flaws (~~), 5 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 GET/ENST Bretagne 3 Expires in August 2004 February 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, and fulfill mobike working group 39 [2] goals 1, 2, 3, 4, and 6 (for goal 5 look at [3]). 41 1. Introduction 43 In this document, the addresses used to transport IKE messages are 44 named the "peer addresses" (term introduced by [4]). These peer 45 addresses should no more be directly or indirectly included in 46 identities ([5] and [6]) as it is commonly done for IKEv1. 48 The current IKEv2 draft [1] often makes the assumption that an 49 address identifies a node when nodes behind a NAT can share the 50 same address and a node can use many different addresses. This 51 must be taken into account in implementations, for instance by 52 reading this document before writing code... 54 This document describes the goals of an address management for 55 IKEv2, including the requirements for multi-homing and mobility 56 support, and finishes by a concrete proposal. 58 In this document, open questions are introduced by the word NOTE. 60 2. Goals 62 The goals of the address management proposed in the document can be 63 divided in some general goals and in requirements for the three 64 mechanisms which can change the peer addresses. 66 2.1 Simplicity, Performance and Security 68 The address management should be as simple as possible, i.e., it 69 should introduce minimal additions to the current IKEv2 draft [1] 70 and each addition should be justified. 72 The performance is an important criterion. For instance, rekeying 73 can update the peer addresses of an IKE SA or 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 [7]). 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 today in IPv6. 85 An other example of an insecure mechanism is to use the addresses 86 in IP headers of CREATE_CHILD_SA messages as the endpoint 87 addresses of the new IPsec SAs without further control on them: 88 peer addresses must be managed. 90 2.2 Terminology 92 The addresses of the two peers are named "peer addresses". The 93 primary peer address of a peer is initialized to the address used 94 to transport messages of the initial exchanges, other addresses 95 are "alternate peer addresses". 97 The proxy case is the setup of transport mode IPsec SAs on the 98 behalf of another party, i.e., transport mode IPsec SAs where the 99 traffic selectors do not match the primary peer addresses. 101 2.3 Multi-homing requirements 103 In this document, the support of multi-homing is the support of 104 nodes with several global addresses. Some of the addresses can be 105 "better" than others, or "better" for some destinations. Some can, 106 from time to time, be unavailable. 108 The main requirement for the support of multi-homing is the 109 management of a set of peer addresses for each peer. The set can 110 be partially ordered or some subset can be loosely associated with 111 some destinations (i.e., some subset of the other peer address 112 set). 114 For the communication between multi-addressed hosts, the support 115 of the proxy case can be useful because it provides an easy way to 116 setup transport mode IPsec SAs with different addresses from one 117 IKE SA. In such cases the other party is in fact the same host, 118 this dramatically simplifies the authorization issue. 120 2.4 Mobility requirements 122 In the context of Mobile IPv6 ([8] and for the special case of 123 Home Agents [9]), the interaction of Mobility and IPsec was 124 analyzed in another document [10]. This document assumes an IPv6 125 context as Mobile IPv6 is the most powerful mobility proposal 126 available today. 128 An IPv6 mobile node is another type of multi-addressed node with: 129 - a care-of address in a prefix of the visited link. 130 The care-of address is used to route packets. 131 - the home address in a prefix of the home link. 132 The home address is used to identify the mobile node. 134 The care-of address is transient and usually the mobile node can 135 not provide a proof that it is the node using it. So it must be 136 trusted and a return routability check (i.e., an enforced answer 137 from this address) should be used if it is not. 139 With a common correspondent, the mobility is transparent and 140 there is no reason to use another address than the home address. 141 For optimized schemes, without an implementation of header 142 compression in ESP tunnel mode (mobile's goal 5 [2]) the choice 143 between a transport mode using triangular routing (IPsec can be 144 used to verify home address options) and a tunnel mode with 145 routing optimization is not clear. But this case does not add 146 new requirement, i.e., the home agent case includes them. 148 With the home agent, there are three main cases (c.f. [9]): 150 - The mobility signaling which is mandatory protected and 151 raises a specific issue in its initial phase: the IKE SA 152 must be setup using the care-of address as the peer address 153 but this IKE SA is used to build an IPsec SA pair with 154 the home address as traffic selector. This IPsec SA will 155 protect the home registration which will make the home 156 address available. This can be considered as a specialized 157 proxy case. 159 - Other genuine communications between the home agent and 160 the mobile node can be covered by the proxy case support 161 too. Note this is the only case at the exception of signaling 162 where mobility behaves in a different way than a mobile IPsec 163 VPN (so we proposed to relax the corresponding rule in a 164 future version of [8] and [9]). 166 - The traffic relayed by the home agent through a tunnel with the 167 mobile node can be partially or fully protected by IPsec SA 168 pair(s). Encapsulation should be performed only once, including 169 for degenerated (but not for free) encapsulation like the home 170 address option or the mobility routing header. 172 In all cases of interaction with the home agent, the mobile node 173 peer address should be a care-of address. When the mobile node 174 moves, another care-of address is used and some SAs, including the 175 IKE SA, must be updated to use the new address. 177 Usually the previous peer address is no more usable. In order to 178 avoid a trivial denial of services, a strong sequencing of updates 179 is required with a way to cancel possible pending updates when 180 fast multiple handoff happen. 182 The IPsec pair which protects the mobility signaling uses the home 183 address as its traffic selector for the mobile node. It must not 184 be updated at each handoff. The update mechanism must provide a 185 fine grain (i.e., per SA) update. 187 3. Proposal 189 The proposal for an address management in IKEv2 is spawn from the 190 NAT traversal mechanisms, mainly with a new peer address update 191 payload. But there are some points that have to be kept as they 192 are in the current IKEv2 draft [1]. 194 3.1 Kept points from draft 06 196 The peer addresses are used to transport messages. The reply to 197 a request MUST be sent to the source of the request from the 198 destination request, i.e., addresses and ports are reversed 199 between the request and its reply. There is no exception to this 200 rule. 202 For tunnel mode IPsec SAs, the endpoint addresses are the primary 203 peer addresses. We don't propose an alternate way to specify them. 204 The same requirement applies to transport mode IPsec SAs at the 205 exception of the proxy case. 207 3.2 Small points 209 In retransmission of requests or responses, copies of messages do 210 not include peer addresses. So a peer MAY retransmit an IKE message 211 from or to a different address. 213 The primary peer addresses are IKE SA parameters and are specified 214 by the IKE_SA_INIT exchange. Note that when NAT traversal is not 215 active, they are implicitly protected by the NAT_DETECTION 216 notifications. 218 All the text below applies only to the case where NAT traversal 219 is not active. 221 In the proxy case, the initiator is acting as a client negotiator 222 on the behalf of another party. The address of this other party is 223 sent in the initiator traffic selector and will become the address 224 of this end of the transport mode IPsec SA pair. A proper 225 authorization in the local policy of the responder is 226 REQUIRED, the defaults SHOULD be: 227 - using an alternate peer address set is permitted 228 - other cases are denied. 230 3.3 Peer address notifications 232 The peer address notifications are copied from the current 233 NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP 234 notifications. They includes the peer source or destination 235 address with its family and an operation code. They MUST be 236 in an encrypted payload. Operations are PRIMARY, ADD and 237 DELETE (last two for alternate addresses). 239 All messages after the first exchange involving an alternate peer 240 address MUST include at least one peer address notification for 241 each peer, i.e., at least one for the source and at least one for 242 the destination. 244 Such messages belong to IKE_AUTH or CREATE_CHILD_SA exchanges, 245 or carry the peer address update payload defined below. 247 They provide a cryptographically proof of no alteration en-route 248 of the peer addresses and operations on the sets of peer addresses, 249 i.e., change of the primary peer address of a peer, addition to 250 and deletion from the peer address set of a peer. 252 When the peer address notifications are not supported, the 253 capability to use an alternate peer address, and only this, 254 is lost. 256 3.4 Explicit peer address update payload 258 A new payload has to be defined for an explicit peer address 259 update mechanism. We propose to copy it from the delete payload, 260 see Annex B. 262 The new peer address update payload has strong sequencing 263 requirements. IKEv2 messages have a protected sequence number so 264 the only sequencing issues are the window of processing and 265 pending exchanges. Any messages with a peer address update payload 266 MUST be processed in order. 268 When the receiver of an update request has to check the validity 269 of the new primary peer address, it MAY use a return routability 270 check sending an informational request at the new address and 271 waiting for an answer. As informational exchanges are protected 272 no more is needed. 274 Example of a return routability check: 276 I --- address update request --> R 277 I <-- informational RR request - R 278 I --- informational RR reply --> R 279 now the responder knows the initiator should be where it 280 claimed to be. 281 I <--- address update reply ---- R 283 As for the delete payload, the peer address update payload 284 specifies the SPIs of the IPsec and IKE SAs it applies to. But 285 a simple way to specify all SAs (i.e., the IKE SA and all the 286 tunnel mode IPsec SAs it negotiated) is needed so is provided. 288 4. Security Considerations 290 Great care was used to avoid to introduce security threats. 292 The NAT traversal feature comes with a security flaw (the transient 293 pseudo-NAT attack [7]) which can not be easily avoid. IMHO the NAT 294 traversal feature should be enabled only when the presence of NATs 295 is likely/possible. 297 When the NAT traversal feature is disabled, the address of the 298 other peer can not be changed en-route by an attacker but the 299 proofs the peer is really at its address are: 300 - the trust in the peer 301 - the proof that the peer can receive messages sent to its address 302 The second (a.k.a. the return routability check) works only with at 303 least three messages, i.e., for the initial exchange (with the 304 address stability requirement) and for the explicit optional 305 checks. IMHO these checks SHOULD be required by default. 307 5. Acknowledgments 309 The rare people in the Mobility world with IPsec interests, or in 310 the IPsec world with Mobility interest, should receive all thanks 311 because without them we (me and all the future co-authors) have 312 given up for a long time. 314 Tero Kivinen helped to improve the NAT traversal part of this 315 proposal. Tero and Jari Arkko proposed another form of peer 316 address update based on the IKE SA addresses. 318 7. Normative References 320 None? 322 8. Informative References 324 [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", 325 draft-ietf-ipsec-ikev2-12.txt, January 2004. 327 [2] IKEv2 Mobility and Multihoming (mobike), "charter", 328 http://www.ietf.org/html.charters/mobike-charter.html. 330 [3] J. Vilhuber, "IP header compression in IPsec ESP", 331 draft-vilhuber-hcoesp-00.txt, January 2003. 333 [4] B. Korver, E. Rescorla, "The Internet IP Security PKI 334 Profile of ISAKMP and PKIX", 335 draft-ietf-ipsec-pki-profile-03.txt, July 2003. 337 [5] P. Hoffman, "Adding revised identities to IKEv2", 338 http://www.vpnc.org/ietf-ipsec/, 339 Message-Id: , 340 November 2002. 342 [6] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", 343 RFC 2956, October 2000. 345 [7] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks 346 or how NATs are even more evil than you believed", 347 draft-dupont-transient-pseudonat-03.txt, February 2004. 349 [8] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", 350 draft-ietf-mobileip-ipv6-24.txt, June 2003. 352 [9] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect 353 Mobile IPv6 Signaling between Mobile Nodes and Home Agents", 354 draft-ietf-mobileip-mipv6-ha-ipsec-06.txt, June 2003. 356 [10] F. Dupont, W. Haddad, "How to make IPsec more mobile IPv6 357 friendly", draft-dupont-ipsec-mipv6-05.txt, February 2004. 359 [11] D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, 360 Version 2", RFC 2367, July 1998. 362 9. Author's Address 364 Francis Dupont 365 ENST Bretagne 366 Campus de Rennes 367 2, rue de la Chataigneraie 368 CS 17607 369 35576 Cesson-Sevigne Cedex 370 FRANCE 371 Fax: +33 2 99 12 70 30 372 EMail: Francis.Dupont@enst-bretagne.fr 374 Annex A. Peer Address Notification Format. 376 The following diagram illustrates the content of the Peer Address 377 Notification: 379 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 ! Next Payload !C! RESERVED ! Payload Length ! 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ! Protocol-ID ! SPI Size ! Notify Message Type ! 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 ! Address Family ! Operation ! 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 ~ Address ~ 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 The notification header is for IKE SA (Protocol-ID 0, SPI Size 0 392 and no SPI. The Address Family is from IANA Address Family Numbers 393 (IPv4 is 1 and IPv6 2). The proposed names are PEER-ADDRESS-SOURCE 394 and PEER-ADDRESS-DESTINATION, with 248XX. Operation codes are: 395 - PRIMARY (1): the address is the primary peer address. The 396 peer address update payload MUST be used to change it. 397 - ADD (2): add a new alternate peer address to the set. 398 - DELETE (3): delete an alternate peer address from the set. 400 Annex B. Peer Address Update Payload Format. 402 The next figure 17 shows the format of the Peer Address Update 403 Payload. It is possible to send multiple SPIs in a Peer Address 404 Update payload, however, each SPI MUST be for the same 405 protocol. Mixing of Protocol Identifiers MUST NOT be performed in a 406 the Peer Address Update payload. It is permitted, however, to 407 include multiple Peer Address Update payloads in a single 408 INFORMATIONAL Exchange where each Peer Address Update payload lists 409 SPIs for a different protocol. 411 Update of the IKE_SA is indicated by a Protocol_Id of 0 (IKE) but 412 no SPIs. Update of a CHILD_SA, such as ESP or AH, will contain the 413 Protocol_Id of that protocol (1 for ESP, 2 for AH) and the SPI is the 414 SPI the sending endpoint would expect in inbound ESP or AH packets. 416 The following diagram illustrates the content of the Peer Address 417 Update Notification: 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 ! Next Payload !C! RESERVED ! Payload Length ! 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 !A| Protocol-ID ! SPI Size ! # of SPIs ! 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 ! ! 427 ~ Security Parameter Index(es) (SPI) ~ 428 ! ! 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 o All (1 bit) - MUST be set to one when all SAs (the IKE SA and 432 all tunnel mode outgoing IPsec SAs negotiated by it) are 433 updated. In this case the update is for the IKE-SA (Protocol-ID 434 0, SPI size 0, no SPI and number of SPIs 0). MUST be set to zero 435 when an individual SA is updated. 437 o Protocol_Id (7 bits) - Must be zero for an IKE_SA, 1 for 438 ESP, or 2 for AH. 440 o SPI Size (1 octet) - Length in octets of the SPI as defined by 441 the Protocol-Id. Zero for IKE (SPI is in message header) 442 or four for AH and ESP. 444 o # of SPIs (2 octets) - The number of SPIs contained in the Peer 445 Address Update Notification. The size of each SPI is defined by 446 the SPI Size field. 448 o Security Parameter Index(es) (variable length) - Identifies the 449 specific security association(s) to delete. The lengths of these 450 fields are determined by the SPI Size and # of SPIs fields. 452 ESP and AH SAs always exist in pairs, with one SA in each direction. 453 When an SA is updated for a peer address, both members of the pair 454 MUST be updated. When SAs are nested, as when data (and IP headers 455 if in tunnel mode) are encapsulated first with IPcomp, then with 456 ESP, and finally with AH between the same pair of endpoints, all of 457 the SAs MUST be updated together. Each endpoint MUST update the SAs 458 it receives on and allow the other endpoint to update the other SA 459 in each pair. 461 To update a peer address of an SA, an Informational Exchange with 462 one or more peer address update payloads is sent listing the SPIs 463 (as they would be placed in the headers of inbound packets) of the 464 SAs to be updated, and with a peer address notification setting 465 the primary peer address. The recipient MUST update the designated 466 SAs. Normally, the reply in the Informational Exchange will 467 contain peer address update payloads for the paired SAs going in 468 the other direction. Note there is no special case for update 469 collision. 471 The proposed name is the Update (U) payload. 473 Annex C. PF_KEY version 2 SADB_X_ADDUPD 475 This annex describes an extension to PF_KEYv2 [11] which provides 476 a way to ask a peer address update of an IPsec SA and all its 477 siblings (i.e., an update with the All flag set to one). 479 The format of the message is: 480 481 and is sent the registered socket listeners by or via the kernel. 482 No answer is needed because if it fails it will be done again. 484 New values are needed for SADB_X_ADDUPD and for 485 SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST 486 which should have the same layout than SADB_EXT_ADDRESS_*, 487 i.e., sadb_address structure. 489 NOTE: IKE itself needs a PF_KEYv2 extension for individual 490 updating of an IPsec SA.