idnits 2.17.1 draft-mglt-ipsecme-alternate-outer-address-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2013) is 4087 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) == Missing Reference: 'CERTREQ' is mentioned on line 527, but not defined ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Downref: Normative reference to an Informational RFC: RFC 6027 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault (Ed) 3 Internet-Draft Francetelecom - Orange 4 Intended status: Standards Track February 15, 2013 5 Expires: August 19, 2013 7 IKEv2 Alternate Outer IP Address Extension 8 draft-mglt-ipsecme-alternate-outer-address-00.txt 10 Abstract 12 Current IKEv2 protocol has been designed to establish VPNs with the 13 same outer IP addresses as those used for the IKEv2 channel. This 14 describes the alternate outer IP address extension, and IKEv2 15 extension that enables the VPN End User to negotiate a VPN on 16 different interfaces as those used for the IKEv2 channel. 18 Thus, this extension makes possible a VPN End User with multiple 19 interfaces to set an IPsec tunnel on each interface with a Security 20 Gateway by using a single IKEv2 channel instead of using an IKEv2 21 channel per interface. Similarly, for distributed Security Gateways, 22 it also makes possible to split the IKEv2 and IPsec traffic on 23 different interfaces. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 19, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Alternate outer address scenarios . . . . . . . . . . . . . . 4 63 4.1. VPN End User with Multiple Interfaces . . . . . . . . . . 4 64 4.2. Security Gateway with Multiple Interfaces . . . . . . . . 6 65 4.3. Distributed Security Gateways . . . . . . . . . . . . . . 7 66 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Alternate outer IP addresses Transform . . . . . . . . . . 8 68 5.2. Initiator: Sending OADD Transforms in Proposals . . . . . 10 69 5.3. Responder: Receiving OADD Transforms in Proposals . . . . 11 70 5.4. Incompatible Proposal with OADD Transforms . . . . . . . . 11 71 5.5. Supporting alternate outer IP address exchange . . . . . . 11 72 5.6. Basic Exchange . . . . . . . . . . . . . . . . . . . . . . 12 73 6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.1. Outer IP address Transform OADD . . . . . . . . . . . . . 14 75 6.2. IP Attribute with IP addresses . . . . . . . . . . . . . . 15 76 6.3. IP Attribute indicating ANY_IP . . . . . . . . . . . . . . 15 77 6.4. Alternate Outer IP Address Notify Payload . . . . . . . . 16 78 7. NAT considerations . . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. Prohibiting NAT . . . . . . . . . . . . . . . . . . . . . 18 80 7.2. NAT detection . . . . . . . . . . . . . . . . . . . . . . 19 81 7.3. The VPN End User does not know the NATted IP addresses . . 19 82 7.4. The VPN End User does know the NATted IP addresses . . . . 20 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 21 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 88 11.2. Informational References . . . . . . . . . . . . . . . . . 21 89 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 22 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Requirements notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Introduction 100 When a VPN End User establishes a VPN with a Security Gateway, it 101 starts by establishing an authenticated channel for IKEv2. Then the 102 VPN Security Associations [RFC4301] are negotiated via the IKEv2 103 [RFC5996] channel. Once the peers agree on the Security 104 Associations, the VPN can be used. 106 Currently, IKEv2 does not negotiate the outer IP addresses of the 107 VPN. The security Association set these VPN outer IP addresses as 108 the IP addresses used by the IKEv2 channel. 110 These implicit values are perfect for VPN End Users with a single 111 interface. This was the case for a long time, making them 112 unnecessary to be negotiated. However, today's VPN End Users and 113 Security Gateways have multiple interfaces. Relying on the default 114 value of the VPN outer IP addresses makes it hard, - or at least in a 115 non optimal way - to take advantage of multiple interfaces. This 116 document specifies how alternate outer IP addresses can be negotiated 117 during the Security Association negotiation. This involves new 118 signaling, thus the document also specify how the VPN End User and 119 the Security Gateway can optionally inform each other they support 120 the alternate outer IP address extension. 122 The remaining of this document is as follows. Section 3 defines the 123 terminology used in this document. Section 4 provides scenarios that 124 motivate this alternate outer IP address extension. Section 5 125 describes the new protocol, as well as the new involved entities and 126 Section 6 describes the payload format defined for the protocol. In 127 this document, we assumed that no NAT are between the VPN End User 128 and the Security Gateway, however, Section 7 provides some 129 considerations when NAT is used. 131 The alternate outer IP address extension provides VPN End Users and 132 Security Gateway a way to take advantage of multiple interfaces for a 133 VPN service. 135 3. Terminology 137 This section defines terms and acronyms used in this document. 139 - VPN End User: designates the End User that initiates the VPN with 140 a Security Gateway. This End User may be mobile and moves its 141 VPN from on Security Gateway to the other. 143 - Security Gateway: designates a point of attachment for the VPN 144 service. In this document, the VPN service is provided by 145 multiple Security Gateways. Each Security Gateway may be 146 considered as a specific hardware. 148 - Security Association (SA): The Security Association is defined in 149 [RFC4301]. 151 4. Alternate outer address scenarios 153 This section provides scenarios where a VPN End User and a Security 154 Gateways share more than one VPN. For each scenario, the document 155 describes the alternatives that currently exist, their limitations 156 and the motivations for the alternate outer IP address extension. 157 The scenarios herein are a subset of the scenarios described in 158 [I-D.mglt-mif-security-requirements]. 160 4.1. VPN End User with Multiple Interfaces 162 More and more terminals have multiple interfaces, and a VPN End User 163 may take advantage of these multiple interfaces by setting multiple 164 tunnels with its Security Gateways as represented in figure 1. A 165 typical example would be a VPN End User attached to its Radio Access 166 Network via Interface_0 and attached to a WLAN access point via 167 Interface_1. The VPN End User may use one or the other interface 168 according to the Quality of Service or the fees associated to each 169 network. In figure 1. the VPN End User has established two distinct 170 VPNs, one on each of its interfaces. Both VPNs are attached to the 171 same Security Gateway interface. A packet can be sent or received 172 from either one or the other VPN. 174 +------------+ +------------+ 175 | | Interface_0 : VPN_0 | | 176 | =================== | Security | 177 | VPN | v | Gateway | 178 | End User | ============== | 179 | ========================^ | | 180 | | Interface_1 : VPN_1 | | 181 +------------+ +------------+ 183 Figure 1: VPN End User with Multiple Interfaces 185 SAs negotiated for the VPN_0 and VPN_1 have the same network 186 configuration except that the outer interface of VPN_0 on the End 187 User side is Interface_0 whereas VPN_1 has Interface_1. More 188 specifically, these SAs have the same Selectors. 190 [RFC4301] section 4.1 states that parallel SAs are compliant with the 191 IPsec architecture, and that traffic may be sent to one or the other 192 VPN, for example, according to the Differentiated Services Code Point 193 (DSCP). DSCP is called a "classifier" which differs from the 194 Selector. How the End User chooses which interface to use is beyond 195 the scope of this document. 197 As mentioned in [RFC5996] the VPN uses the IP addresses of the IKEv2 198 channel as outer IP addresses. One way to establish these two VPNs 199 is to create an IKEv2 channel for each interface. This results in 200 unnecessary IKE negotiations with multiple authentications 201 Nbr(EU_interfaces) X Nbr(SG_interface) X Nbr(Flows). This number 202 rapidly grows with the number of involved interfaces both on the 203 Security Gateway and on the End User. 205 [RFC6027] section 3.8 mentions that peers using different IP 206 addresses for the VPN and the IKEv2 channel SHOULD be modified unless 207 they may drop the packets. The alternate outer IP address described 208 in this document is described so that any VPN End User can interact 209 with any Security Gateway. 211 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] addresses this issue. 212 The End User VPN indicates during the SA negotiation the outer IP 213 address it wants, and in return the Security Gateway indicates the 214 outer IP address of the Security Gateway. Motivations for 215 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] is a cluster of 216 Security Gateways that splits the IKEv2 traffic and the VPN traffic, 217 so that the VPN traffic avoids overloading some equipments like 218 firewalls or load balancers for example. 220 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] would also address the 221 case of figure 1 because the the path used by the VPN is defined by 222 the interface used by the VPN End User VPN. This results from the 223 fact that the Security Gateway has only one interface. However, 224 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] would need slight 225 modifications in order to address the more general case where VPN End 226 User and the Security Gateways have multiple interfaces. In that 227 case, a path would be defined not by a single interface (as in figure 228 1), but by a pair of interface. 230 In addition to path negotiation, 231 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] uses a Notify Payload 232 that is not bound to a SA Proposal, thus making multiple SA Proposals 233 with different outer IP address difficult. Again this case is very 234 specific to multiple interfaces. Even though the protocol described 235 in this document address these limitations, it remains very closed to 236 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses]. 238 4.2. Security Gateway with Multiple Interfaces 240 In the scenario presented in figure 2, the VPN End User has two 241 interfaces and the VPN End User has a single interface. Like the VPN 242 End User with multiple interfaces presented in Section 4.1, we 243 suppose that the VPNs are established by the VPN End User with the 244 Security Gateway. Unlike the scenarios of Section 4.1, motivations 245 for choosing VPN_0 or VPN_1 are not associated to the interface used 246 by the VPN End User, but the path taken by the packets. As a result, 247 the VPN End User cares about both source and destination outer IP 248 addresses that defines the path. 250 +------------+ +------------+ 251 | | Interface_0 : VPN_0 | | 252 | | ============= Security | 253 | VPN | v | Gateway | 254 | End User =================== | | 255 | | ^ ============ | 256 | | Interface_1 : VPN_1 | | 257 +------------+ +------------+ 259 Figure 2: Security Gateway with Multiple Interfaces 261 Comments of Section 4.1 also applies to this scenario, but this 262 scenario stresses that the choice of the VPN outer IP addresses 263 SHOULD result from a negotiation between the two peers, and both 264 outer IP addresses SHOULD be negotiated. 266 Note that the scenario described in figure 2, considers that all 267 interfaces are used to setup all different VPNs. As described in 268 Section 4.1, if VPN End Users and Security Gateways have both 269 multiple interfaces, setting up all possible tunnels may be 270 unnecessarily heavy. As a result, the VPN End User SHOULD be able to 271 negotiate both outer IP addresses of its VPN. 273 Note that if the VPN End User negotiates the outer IP address used by 274 the Security Gateway, the VPN End User may know in advance what 275 interfaces are available. It is beyond the scope of this document to 276 define how the VPN End User may know this information. MOBIKE 277 [RFC4555] defines the ADDITIONAL_IP*_ADDRESSES Notify Payload, and 278 [I-D.mglt-ipsecme-security-gateway-discovery] defines how these 279 pieces of information may be provided by other Security Gateways. 281 4.3. Distributed Security Gateways 283 The scenario described in figure 3 considers a distributed Security 284 Gateway. The IKEv2 channel and the VPNs are handled by different 285 nodes. As a result the VPN does not uses the same outer IP addresses 286 as the IKEv2 channel. 288 +------------+ +------------+ 289 | | Interface_0 | IKE | 290 | | IKEv2 channel ^------------- Security | 291 | VPN ------------------- ^ | Gateway | 292 | End User =================== v +------------+ 293 | | VPN channel v +------------+ 294 | | v Interface_1| VPN | 295 +------------+ v============= Security | 296 | Gateway | 297 +------------+ 298 ... 299 +------------+ 300 Interface_i| VPN | 301 ============= Security | 302 | Gateway | 303 +------------+ 305 Figure 3: Distributed Security Gateways 307 This scenario is addressed by 308 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] where each part can 309 choose the interface it will use as the outer IP address for the VPN. 310 As mentioned in Section 4.1, being able to specify a single interface 311 is not sufficient to select a path. More specifically, in figure 3, 312 this would not provide the possibility for the VPN End User to choose 313 between Interface_1 and Interface_i. 315 5. Protocol Overview 317 The alternate outer IP address extension, makes possible two peers to 318 negotiate and agree on alternate IP addresses for their VPN. We 319 consider the outer IP addresses as parameters of the Security 320 Association. (Tunnel header IP source and destination address as 321 described in [RFC4301]). As a consequence, the negotiation of these 322 parameters occurs during the negotiation of the Security Association, 323 that is during the IKE_INIT exchange or the CREATE_CHILD_SA exchange 324 as described in [RFC5996]. 326 VPN SA negotiation can be initiated by either VPN End User or the 327 Security Gateway, so in the remaining of the document we simply use 328 initiator and responder, as the peer initiating the negotiation. 330 Note that these negotiations makes possible that any peer can 331 negotiate one, or both outer IP address, that is to say, the outer IP 332 address source and destination. 334 Section 5.1 briefly reminds how the Security Association' parameters 335 are negotiated with IKEv2, and then proposes the new involved 336 payloads to negotiate the outer IP addresses. Basically a new 337 Alternate Outer Address Transform (OADD) and a new IP Attribute are 338 defined. Section 5.2 and Section 5.3 and Section 5.4 are focused on 339 the exchanged when both peers support the alternate outer IP address 340 extension. Section 5.2 describes how the initiator builds a SA 341 Proposal and Section 5.3 defines how the responder handles it. 342 Section 5.4 defines the case where the Proposal MUST be discarded. 343 Although not mandatory, there MAY be an advantage that peers are 344 informed whether the alternate outer IP address is supported or not 345 before sending Proposals. Section 5.5 presents how peers can inform 346 each other the support this extension. At last, Section 5.6 347 illustrates the different exchanged described in the document. 349 5.1. Alternate outer IP addresses Transform 351 This section does not intend to explain how SAs are negotiated, and 352 the reader is expected to refer to [RFC5996] section 3.3. This 353 section briefly sums up the different type of payload involved in 354 order to clarify our purpose. Figure 4 is copied from [RFC5996] to 355 illustrate concepts involved in the Security Association negotiation. 357 SA Payload 358 | 359 +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, 360 | | 7 transforms, SPI = 0x052357bb ) 361 | | 362 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 363 | | +-- Attribute ( Key Length = 128 ) 364 | | 365 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 366 | | +-- Attribute ( Key Length = 192 ) 367 | | 368 | +-- Transform ENCR ( Name = ENCR_AES_CBC ) 369 | | +-- Attribute ( Key Length = 256 ) 370 | | 371 | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 372 | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) 373 | +-- Transform ESN ( Name = ESNs ) 374 | +-- Transform ESN ( Name = No ESNs ) 375 | 376 +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, 377 | 4 transforms, SPI = 0x35a1d6f2 ) 378 | 379 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 380 | +-- Attribute ( Key Length = 128 ) 381 | 382 +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) 383 | +-- Attribute ( Key Length = 256 ) 384 | 385 +-- Transform ESN ( Name = ESNs ) 386 +-- Transform ESN ( Name = No ESNs ) 388 Figure 4: Security Association Payload Structure 390 A Security Association is defined by various parameters such as 391 Encryption (ENCR) or Integrity (INTEG), Pseudorandom Function (PRF), 392 Diffie-Hellman group (D-H) or Extended Sequence Numbers (ESN). These 393 parameters are defined through Transforms and each parameter is a 394 Transform Type. 396 A Security Association is negotiated through the SA Payload which 397 contains one or more Proposals Payloads. Each Proposal contains one 398 or multiple acceptable "values" for each Transformed Type. These 399 "values" can be seen as an OR. The Proposal is accepted if for each 400 Transform Type one of the proposed "value" is accepted by the 401 responder. If the responder cannot choose an acceptable "value" for 402 each Transform Type, the proposition is rejected. A "value" is 403 composed of a Transform ID, like the name of the encryption 404 algorithm, and eventually one or more Attributes, like the key length 405 for example. 407 In our case, we consider a new Transform Type OADD. This Transform 408 Type has two Transform ID (INIT or RESP) that designates the 409 initiator outer IP address (INIT) or the responder outer IP address 410 (RESP). The Attributes associated to each Transform ID is the IP 411 Attribute that can be an IPv4 address, an IPv6 address or a specific 412 value. 414 5.2. Initiator: Sending OADD Transforms in Proposals 416 In Section 5.2 and Section 5.3 we suppose that both the initiator and 417 the responder support the alternate outer IP address extension, that 418 no USE_TRANSPORT_MODE Notify Payload is sent in conjunction of the SA 419 Payload, and that the Proposal Payload as defined in [RFC5996] 420 Section 3.3.1 has its Protocol ID set to AH or ESP. Other cases are 421 discussed in Section 5.4 423 If the initiator wants to propose the Security Gateway to choose 424 among a set of the initiator's interfaces IP_init_0, ..., IP_init_k 425 for the VPN outer IP address, it MUST include k+1 Transforms with 426 Transform Type OADD and Transform ID set to INIT. The Transform is 427 associated to the Attribute of Type IP. Transform Attributes are 428 defined in [RFC5996] 3.3.5. 430 Similarly, if the initiator wants to select on the Security Gateway 431 one interface among a set of interface IP_resp_0, ..., IP_resp_l, it 432 MUST include l+1 OADD Transform with Transform ID set to RESP, and an 433 Attribute of Type IP. 435 If the initiator does not know the interface that the responder may 436 choose, it may indicate the responder to define the most appropriated 437 interface with a OADD Transform with Transform ID set to RESP and an 438 Attribute of Type with the specific value ANY_IP. 440 If no OADD Transform with Transform ID set to INIT (Respectively 441 RESP) are provided in the Proposal, the default value for the outer 442 IP address is the one used by the IKEv2 channel. More specifically, 443 if the initiator considers the interface used for the IKEv2 channel 444 as an alternative to other IP addresses, a OADD Transform with this 445 IP address MUST explicitly be in the Proposal. 447 Note that a Proposal does not need to have both OADD Transform with 448 Transform ID INIT and RESP. The initiator can choose to have only 449 OADD Transforms with Transform ID INIT (respectively RESP). 451 5.3. Responder: Receiving OADD Transforms in Proposals 453 As mentioned in Section 5.2, we suppose the responder supports the 454 alternate outer IP address extension. If a Proposal contains one or 455 multiple OADD with a Transform ID set to INIT (respectively RESP), 456 the responder choose one of these. If selected OADD Transform (INIT 457 or RESP) with an IP Attribute, the responder returns the Transform 458 without modification. Otherwise, if selected OADD Transform is with 459 an ANY_IP Attribute, the responder returns a IP Attribute with the 460 correct value. 462 If the responder has no OADD Transform with Transform ID INIT 463 (respectively RESP), then by default the outer IP address of the VPN 464 is equal to the IP address used by the IKEv2 channel. 466 5.4. Incompatible Proposal with OADD Transforms 468 The alternate outer IP address extension only makes sense for the 469 IPsec tunnel mode. The SA Payload with Proposals that contains one 470 or more OADD Transforms MUST NOT be used with a USE_TRANSPORT_MODE 471 Notify Payload. Responder MUST reject these Proposals. 473 Similarly, Proposals with a Protocol other than AH or ESP, (that is 474 to say IKE), MUST NOT be used with OADD Transforms. Responder MUST 475 reject these Proposals. 477 As mentioned in [RFC5996] Section 3.3.6, a responder that does not 478 support the alternate outer IP address extension MUST reject any 479 Proposal that contains a Transform with a Transform Type OADD. If 480 the responder rejects all Proposals, it MUST send a 481 NO_PROPOSAL_CHOSEN Notify Payload. 483 5.5. Supporting alternate outer IP address exchange 485 This section describes an informational exchange where each peer 486 informs the other that it supports the alternate outer IP address 487 extension. This exchange is not mandatory, but is recommended as it 488 MAY ease to format the Proposals for the Security Association 489 negotiation. 491 In fact the negotiation of the alternate outer IP address is included 492 in SA negotiation. As described in Section 5.1, this introduces new 493 Transform Type and new Attributes. [RFC5996] Section 3.3.6 mentions 494 that a peer does not understand the new Transform Type or the new 495 Attributes, it MUST reject the Proposal. As a result, if the 496 initiator does not know if the responder supports the alternate outer 497 IP address extension, it SHOULD include proposals without the 498 associated Transform Type and Attributes to avoid that all Proposals 499 are rejected by the responder and receives a NO_PROPOSAL_CHOSEN 500 Notify Payload. 502 To limit the number of proposals to be sent by the initiator during 503 the SA negotiation, we define the supporting alternate outer IP 504 address exchange where the initiator can advertise it supports the 505 alternate outer IP address extension by sending a 506 ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload. When a node 507 receives this Notify Payload and support the alternate outer IP 508 address extension, it MUST send back the same Notify Payload. 510 5.6. Basic Exchange 512 Figure 5 provides a basic exchange. The initiator and the responder 513 agree on supporting the alternate outer IP address extension. This 514 exchange is optional but recommended. In Figure 5 this exchange 515 occurs during the IKE_INIT exchange, but it MAY occur anytime. 517 The SA negotiation consists in sending multiple Proposals. In figure 518 5, the OADD Transform specify the initiator and responder's IP 519 address. The responder choose one of the proposed transformed. 521 Initiator Responder 522 ------------------------------------------------------------------- 523 HDR, SAi1, KEi, Ni --> 524 N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED) 525 N(NAT_DETECTION_SOURCE_IP), 526 N(NAT_DETECTION_DESTINATION_IP) 527 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 528 N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED) 529 N(NAT_DETECTION_SOURCE_IP), 530 N(NAT_DETECTION_DESTINATION_IP) 532 ==== From this exchange: 533 - the Initiator and the Responder support the alternate 534 outer IP address extension 535 - no NAT has been detected ===== 537 HDR, SK {IDi, [CERT,] [CERTREQ,] 538 [IDr,] AUTH, TSi, TSr 539 SAi2( Proposal(ENCR, INTEG, ESN, < proposes IP1, IP2 for 540 OADD(INIT, IP1), the init., ANY IP for 541 OADD(INIT, IP2), the resp. 542 OADD(RESP, ANY_IP)) 543 Proposal(ENCR, INTEG, ESN))) < proposes to use IKEv2 IP 544 } --> for the VPN outer IP 546 <-- HDR, SK {IDr, [CERT,] AUTH, TSi, TSr, 547 SAr2(Proposal(ENCR, INTEG, ESN, 548 OADD(INIT, IP1), 549 OADD(RESP, IPr))) 550 } 552 Figure 5: Basic Exchange for VPN alternate outer 553 IP addresses negotiation 555 6. Payload Formats 557 As mentioned in Section 5 this document introduces a new Transform of 558 Transform Type OADD. The associated Transform ID are INIT for the 559 initiator outer IP address and RESP for the responder's IP address. 560 These Transforms are associated a Attributes that are either carrying 561 an IP address (IPv4 or IPv6) or associated to a specific value like 562 ANY_IP. 564 This document also introduces the 565 ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload, so peers can 566 inform the other they support the alternate outer IP address 567 extension. 569 This section describes the format of all new payload introduced for 570 the outer IP address extension. 572 6.1. Outer IP address Transform OADD 574 This section specifies the Transform structure as defined in 575 [RFC5996] Section 3.3.2. 577 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | 0 (last) or 3 | RESERVED | Transform Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |Transform Type | RESERVED | Transform ID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | | 585 ~ Transform Attributes ~ 586 | | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Figure 6: OADD Transform Substructure 591 - 0 (last) or 3 (more) (1 octet): Specifies whether this is the last 592 Transform Substructure in the Proposal. 594 - RESERVED (1 octet): MUST be sent as zero; MUST be ignored on 595 receipt. 597 - Transform Length (2 octets): The length (in octets) of the 598 Transform Substructure including Header and Attributes. 600 - Transform Type (2 octets): The type of transform being specified 601 in this transform. Set to OADD in this document. 603 - Transform ID (2 octets): he specific instance of the Transform 604 Type being proposed. Set to INIT or RESP in this document. 606 - Transform Attributes (variable length): The IP Attribute in this 607 document. 609 6.2. IP Attribute with IP addresses 611 This section specifies the Attribute structure as defined in 612 [RFC5996] Section 3.3.5. 614 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |A| Attribute Type | AF=0 Attribute Length | 618 |F| | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 ~ IP Address ~ 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 7: IP Attribute with IP address 627 - Attribute Format (AF) (1 bit): Set to 0, indicating a TLV format. 629 - Attribute Type (15 bits): Set to IP in this document. 631 - Attribute Length (16 bits): The length is either 8 to designate 632 the length of an IPv4 or 20 to designate the length of on IPv6 633 address. The length includes the headers of 4 octets. 635 6.3. IP Attribute indicating ANY_IP 637 This section specifies the Attribute structure as defined in 638 [RFC5996] Section 3.3.5. 640 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 |A| Attribute Type | AF=1 Attribute Value | 644 |F| | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Figure 8: IP Attribute set to ANY_ IP 649 - Attribute Format (AF) (1 bit): Set to 1, Attribute Value. 651 - Attribute Value (15 bits): Set to ANY_IP in this document. 653 6.4. Alternate Outer IP Address Notify Payload 655 This section presents the Notify Payload as defined in [RFC5996] 656 Section 3.10. 658 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Next Payload |C| RESERVED | Payload Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Protocol ID | SPI Size = 0 | Notify Message Type | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 9: Alternate Outer IP Address Notify Payload 668 - Next Payload (1 octet): Identifier for the payload type of the 669 next payload in the message. If the current payload is the 670 last in the message, then this field will be 0. 672 - Critical (1 bit): MUST be set to zero for payload types defined in 673 this document. 675 - RESERVED (7 bits): MUST be sent as zero; MUST be ignored on 676 receipt. 678 - Payload Length (2 octets, unsigned integer): Length in octets of 679 the current payload, including the generic payload header. Set 680 to 16 in this document. 682 - Protocol ID (1 octet): This field MUST be sent as zero and MUST 683 be ignored on receipt. 685 - Notify Message Type (2 octets): Set to 686 ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED in this document. 688 7. NAT considerations 690 In the document we assumed that there were no NAT between the VPN End 691 User and the Security Gateway. This means that the VPN End User and 692 the Security Gateway know 1) the interface they are receiving data on 693 is the interface used as a destination by the other peer and 2) the 694 interface set as destination is the interface used by the other peer 695 to receive the data. As a result, if the VPN End User (respectively 696 the Security Gateway) is behind a NAT, the VPN End User may be seen 697 by the Security Gateway (respectively the VPN End User) with another 698 IP address unknown to the VPN End User (respectively the Security 699 Gateway). 701 NATs impact the alternate outer IP address extensions in two ways: 703 - IPsec configuration: The alternate outer IP addresses the two 704 peers are negotiating may not be the ones in the Security 705 Associations. More specifically, suppose the VPN End User and 706 the Security Gateway depicted in figure 10 have negotiated the 707 alternate outer IP addresses src_0, dst_1. src_0 is NATted with 708 NAT_0, and may be unreachable, the outer IP address in the 709 Security Gateway SA should be src_nat_0 instead. 711 - NAT traversal: NATs may make an IP address behind it reachable 712 only if this IP address has initiated a connection. More 713 specifically, suppose the VPN End User and the Security Gateway 714 depicted in figure 10 have established an IKEv2 channel between 715 src_0 and dst_1 and are MOBIKE enabled. Suppose the VPN End 716 User sends the Security Gateway an ADDITIONAL_IP*_ADDRESS with 717 src_1 or eventually with src_nat_1. Unless NAT_1 has been 718 configured to forward the traffic from the Security Gateway to 719 the VPN End User, this traffic will most likely be discarded by 720 NAT_1. Similarly, if the Security Gateway moves the VPN from 721 dst_0 to dst_1, the VPN may be broken. Note that we use MOBIKE 722 to illustrate the problems of reachability through NATs, but 723 these operations are discussed more in depth in [RFC4555]. 725 This section does not intend to discussed all NATs configuration as 726 described in [RFC5389]. Instead the only NAT scenario we consider is 727 a single NAT and the VPN End User behind that NAT initiates the 728 alternate outer IP address exchange. The architecture this section 729 considers is depicted in figure 10. Furthermore, this section does 730 not consider the NAT traversal aspect. We assume that the VPN End 731 User is NAT aware and perform the necessary actions to make/configure 732 the NATs so that they do not block the traffic. 734 Section 7.1 defines how the End User MAY prohibit the alternate outer 735 IP address extension if a NAT is detected. Then, in Section 7.2 how 736 the VPN End User can detect the presence of NAT. Section 7.3 737 discusses the case where the VPN End User does not know the values of 738 the NATted IP addresses and Section 7.4 discusses the case where the 739 VPN End User knows all NATted IP addresses values. 741 +---+ 742 +------------+ | I | +------------+ 743 | | src_0 +-------+ src_nat_0 | N | dst_0 | | 744 | =========| NAT_0 |===========| T |=======| Security | 745 | VPN | +-------+ | E | | Gateway | 746 | End User | src_1 +-------+ src_nat_1 | R | dst_1 | | 747 | =========| NAT_1 |===========| N |=======| | 748 | | +-------+ | E | | | 749 +------------+ | T | +------------+ 750 +---+ 751 Figure 10: VPN End User behind a NAT scenario 753 7.1. Prohibiting NAT 755 This section considers that the VPN End User does not want to use the 756 alternate outer IP address extension if a NAT is detected. This 757 section differs from the NAT detection because it both detects the 758 existence of a NAT and provide an indication that some supported 759 functionalities like MOBIKE SHOULD NOT be used if a NAT is detected. 761 The NO_NATS_ALLOWED Notify Payload is defined in [RFC4555]. If the 762 VPN End User supports MOBIKE, it MAY send a NO_NATS_ALLOWED Notify 763 Payload with the original IP addresses and ports. When the Notify 764 Payload is received by the Security Gateway, it checks the IP 765 addresses values in the IP header and in the Payload, in case of 766 mismatch, a UNEXPECTED_NAT_DETECTED Notify Payload is returned. 768 In our case, the NO_NATS_ALLOWED MAY be used by the VPN End User if 769 both the VPN End User and the Security Gateway support MOBIKE. When 770 the Security Gateway receives the NO_NATS_ALLOWED Notify Payload, it 771 MUST NOT use MOBIKE and SHOULD NOT use the alternate outer IP address 772 extension. 774 There are corner cases that are not considered by this policy. 775 First, a VPN End User or a Security Gateway that do not support 776 MOBIKE cannot use the NO_NATS_ALLOWED Notify Payload. However, it 777 seems hardly possible that peers supporting the alternate outer IP 778 address extension support MOBIKE. Second, a VPN End User using the 779 NO_NATS_ALLOWED applies the same policy for MOBIKE and the alternate 780 outer address extension. Here again, it seems unlikely that NAT 781 policies differ. Furthermore, the NO_NATS_ALLOWED exchange only 782 prevent the Security Gateway to initiate a MOBIKE or alternate outer 783 IP address negotiation. The VPN End User can still use one or the 784 other extension. From our experience, this constraint seems 785 acceptable. 787 7.2. NAT detection 789 This section details how NAT can be detailed with IKEv2 extensions. 790 We do not consider here other mechanisms like ICE described in 791 [RFC5768] or STUN [RFC5389]. 793 The VPN End User can detect the NAT by using the 794 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP Notify 795 Payload as described in [RFC5996]. These Notify Payloads carry the 796 SHA-1 of the source (respectively the destination) IP address. At 797 the reception, the Security Gateway can compare their contend with 798 the SHA-1 of the IP addresses in the IP header. A mismatch between 799 the two values indicates the presence of a NAT, but do not provide 800 the value of the original IP address. Usually, this exchange is 801 performed during the IKE_INIT exchange to decide whether or not IKEv2 802 should proceed to UDP encapsulation. 804 Note that with the NAT detection exchange, the NAT is detected on the 805 IKEv2 channel. If the IKEv2 channel is using src_0, the NAT 806 detection exchange will detect NAT_0. To detect NAT_1 using IKEv2, 807 the VPN End User SHOULD move the IKEv2 channel on src_1 with MOBIKE 808 for example. Since the UPDATE_SA Notify Payload is initiated by the 809 VPN End User, NAT_1 is expected to accept the traffic from the 810 Security Gateway. Note also that the NAT detection exchange does not 811 provide the value of the src_nat* IP addresses. 813 7.3. The VPN End User does not know the NATted IP addresses 815 This section analyses how the alternate outer IP address extension 816 can be used when the VPN End User does not know the values of the 817 NATted IP addresses, i.e. src_nat_0 and src_nat_1. 819 In that case, the VPN End User MAY only select the destination outer 820 IP address corresponding to the Security Gateway IP addresses. How 821 the VPN End User gets these IP addresses is out of scope of the 822 document, however, if the VPN End User and the Security Gateway 823 support MOBIKE, the MOBIKE ADDITIONAL_IP*_ADDRESS Notify Payload MAY 824 be used for that purpose. It is recommended that the VPN End User 825 does not provide the outer source IP, in which case, the one from the 826 IKEv2 channel will be considered by default. More specifically, the 827 VPN End User cannot provide the Security Gateway its alternate IP 828 addresses. 830 The VPN End User MAY use the ANY_IP IP Attribute for the source outer 831 IP address. This would enable the Security Gateway to select an 832 alternate IP address that differs from the one used by the IKEv2 833 channel. In order to select the IP addresses associated to the VPN 834 End User, the Security Gateway has to be aware of the NATted IP 835 addresses depicted as src_nat_0 and src_nat_1. One possibility is 836 that the Security Gateway log the IP addresses used by the VPN End 837 User when it moves from src_0 to src_1. This also means that the VPN 838 is being negotiated with a CREATE_CHILD_SA exchange after the initial 839 IKE_INIT exchange. 841 7.4. The VPN End User does know the NATted IP addresses 843 In this section the VPN End User knows the NATted IP addresses 844 src_nat_0 and src_nat_1. How the End User get these values is out of 845 scope of the document. This case should be considered only if the 846 VPN End User exactly know what it is doing. 848 In this case, the VPN End User can proceed as if no NAT exist. The 849 VPN End User considers in the alternate outer IP address negotiation 850 that its IP addresses are the NATted IP addresses that is src_nat_0 851 and src_nat_1. On the other hand, the VPN End User MUST configure 852 properly its SAs with src_0 if src_nat_0 is selected or with src_1 if 853 src_nat_1 is selected. 855 The VPN End User is also responsible to make the NAT Traversal 856 possible. 858 8. IANA Considerations 860 The new fields and number are the following: 862 IKEv2 Notify Message Types - Status Types 863 ----------------------------------------- 864 ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED TBD 866 Transform Attribute Types 867 ------------------------- 868 OADD TBD 870 Transform Type OADD IDs 871 ----------------------- 872 INIT TBD 873 RESP TBD 875 Attribute Type 876 -------------- 877 IP TBD 879 IP Attribute Type Values 880 ------------------------ 881 ANY_IP TBD 883 9. Security Considerations 885 The exchange described in this document is protected by the IKEv2 886 channel. 888 10. Acknowledgment 890 The author would like to thank Yoav Nir for its helpful comments. 892 11. References 894 11.1. Normative References 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 900 Internet Protocol", RFC 4301, December 2005. 902 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 903 (MOBIKE)", RFC 4555, June 2006. 905 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 906 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 907 October 2008. 909 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 910 Connectivity Establishment (ICE) in the Session Initiation 911 Protocol (SIP)", RFC 5768, April 2010. 913 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 914 "Internet Key Exchange Protocol Version 2 (IKEv2)", 915 RFC 5996, September 2010. 917 [RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, 918 October 2010. 920 11.2. Informational References 922 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] 923 Arora, J. and P. Kumar, "Alternate Tunnel Addresses for 924 IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 925 (work in progress), April 2010. 927 [I-D.mglt-ipsecme-security-gateway-discovery] 928 Migault, D. and K. Pentikousis, "IKEv2 Security Gateway 929 Discovery", 930 draft-mglt-ipsecme-security-gateway-discovery-00 (work in 931 progress), February 2013. 933 [I-D.mglt-mif-security-requirements] 934 Migault, D. and C. Williams, "IPsec Multiple Interfaces 935 Problem Statement", 936 draft-mglt-mif-security-requirements-03 (work in 937 progress), November 2012. 939 Appendix A. Document Change Log 941 [RFC Editor: This section is to be removed before publication] 943 -00: First version published. 945 Author's Address 947 Daniel Migault 948 Francetelecom - Orange 949 38 rue du General Leclerc 950 92794 Issy-les-Moulineaux Cedex 9 951 France 953 Phone: +33 1 45 29 60 52 954 Email: mglt.ietf@gmail.com