Internet DRAFT - draft-mglt-ipsecme-alternate-outer-address
draft-mglt-ipsecme-alternate-outer-address
IPSECME D. Migault (Ed)
Internet-Draft Francetelecom - Orange
Intended status: Standards Track February 15, 2013
Expires: August 19, 2013
IKEv2 Alternate Outer IP Address Extension
draft-mglt-ipsecme-alternate-outer-address-00.txt
Abstract
Current IKEv2 protocol has been designed to establish VPNs with the
same outer IP addresses as those used for the IKEv2 channel. This
describes the alternate outer IP address extension, and IKEv2
extension that enables the VPN End User to negotiate a VPN on
different interfaces as those used for the IKEv2 channel.
Thus, this extension makes possible a VPN End User with multiple
interfaces to set an IPsec tunnel on each interface with a Security
Gateway by using a single IKEv2 channel instead of using an IKEv2
channel per interface. Similarly, for distributed Security Gateways,
it also makes possible to split the IKEv2 and IPsec traffic on
different interfaces.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Migault (Ed) Expires August 19, 2013 [Page 1]
Internet-Draft Alternate Outer IP Address Extension February 2013
(http://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.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Alternate outer address scenarios . . . . . . . . . . . . . . 4
4.1. VPN End User with Multiple Interfaces . . . . . . . . . . 4
4.2. Security Gateway with Multiple Interfaces . . . . . . . . 6
4.3. Distributed Security Gateways . . . . . . . . . . . . . . 7
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Alternate outer IP addresses Transform . . . . . . . . . . 8
5.2. Initiator: Sending OADD Transforms in Proposals . . . . . 10
5.3. Responder: Receiving OADD Transforms in Proposals . . . . 11
5.4. Incompatible Proposal with OADD Transforms . . . . . . . . 11
5.5. Supporting alternate outer IP address exchange . . . . . . 11
5.6. Basic Exchange . . . . . . . . . . . . . . . . . . . . . . 12
6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Outer IP address Transform OADD . . . . . . . . . . . . . 14
6.2. IP Attribute with IP addresses . . . . . . . . . . . . . . 15
6.3. IP Attribute indicating ANY_IP . . . . . . . . . . . . . . 15
6.4. Alternate Outer IP Address Notify Payload . . . . . . . . 16
7. NAT considerations . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Prohibiting NAT . . . . . . . . . . . . . . . . . . . . . 18
7.2. NAT detection . . . . . . . . . . . . . . . . . . . . . . 19
7.3. The VPN End User does not know the NATted IP addresses . . 19
7.4. The VPN End User does know the NATted IP addresses . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informational References . . . . . . . . . . . . . . . . . 21
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Migault (Ed) Expires August 19, 2013 [Page 2]
Internet-Draft Alternate Outer IP Address Extension February 2013
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
When a VPN End User establishes a VPN with a Security Gateway, it
starts by establishing an authenticated channel for IKEv2. Then the
VPN Security Associations [RFC4301] are negotiated via the IKEv2
[RFC5996] channel. Once the peers agree on the Security
Associations, the VPN can be used.
Currently, IKEv2 does not negotiate the outer IP addresses of the
VPN. The security Association set these VPN outer IP addresses as
the IP addresses used by the IKEv2 channel.
These implicit values are perfect for VPN End Users with a single
interface. This was the case for a long time, making them
unnecessary to be negotiated. However, today's VPN End Users and
Security Gateways have multiple interfaces. Relying on the default
value of the VPN outer IP addresses makes it hard, - or at least in a
non optimal way - to take advantage of multiple interfaces. This
document specifies how alternate outer IP addresses can be negotiated
during the Security Association negotiation. This involves new
signaling, thus the document also specify how the VPN End User and
the Security Gateway can optionally inform each other they support
the alternate outer IP address extension.
The remaining of this document is as follows. Section 3 defines the
terminology used in this document. Section 4 provides scenarios that
motivate this alternate outer IP address extension. Section 5
describes the new protocol, as well as the new involved entities and
Section 6 describes the payload format defined for the protocol. In
this document, we assumed that no NAT are between the VPN End User
and the Security Gateway, however, Section 7 provides some
considerations when NAT is used.
The alternate outer IP address extension provides VPN End Users and
Security Gateway a way to take advantage of multiple interfaces for a
VPN service.
3. Terminology
This section defines terms and acronyms used in this document.
Migault (Ed) Expires August 19, 2013 [Page 3]
Internet-Draft Alternate Outer IP Address Extension February 2013
- VPN End User: designates the End User that initiates the VPN with
a Security Gateway. This End User may be mobile and moves its
VPN from on Security Gateway to the other.
- Security Gateway: designates a point of attachment for the VPN
service. In this document, the VPN service is provided by
multiple Security Gateways. Each Security Gateway may be
considered as a specific hardware.
- Security Association (SA): The Security Association is defined in
[RFC4301].
4. Alternate outer address scenarios
This section provides scenarios where a VPN End User and a Security
Gateways share more than one VPN. For each scenario, the document
describes the alternatives that currently exist, their limitations
and the motivations for the alternate outer IP address extension.
The scenarios herein are a subset of the scenarios described in
[I-D.mglt-mif-security-requirements].
4.1. VPN End User with Multiple Interfaces
More and more terminals have multiple interfaces, and a VPN End User
may take advantage of these multiple interfaces by setting multiple
tunnels with its Security Gateways as represented in figure 1. A
typical example would be a VPN End User attached to its Radio Access
Network via Interface_0 and attached to a WLAN access point via
Interface_1. The VPN End User may use one or the other interface
according to the Quality of Service or the fees associated to each
network. In figure 1. the VPN End User has established two distinct
VPNs, one on each of its interfaces. Both VPNs are attached to the
same Security Gateway interface. A packet can be sent or received
from either one or the other VPN.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| =================== | Security |
| VPN | v | Gateway |
| End User | ============== |
| ========================^ | |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 1: VPN End User with Multiple Interfaces
SAs negotiated for the VPN_0 and VPN_1 have the same network
Migault (Ed) Expires August 19, 2013 [Page 4]
Internet-Draft Alternate Outer IP Address Extension February 2013
configuration except that the outer interface of VPN_0 on the End
User side is Interface_0 whereas VPN_1 has Interface_1. More
specifically, these SAs have the same Selectors.
[RFC4301] section 4.1 states that parallel SAs are compliant with the
IPsec architecture, and that traffic may be sent to one or the other
VPN, for example, according to the Differentiated Services Code Point
(DSCP). DSCP is called a "classifier" which differs from the
Selector. How the End User chooses which interface to use is beyond
the scope of this document.
As mentioned in [RFC5996] the VPN uses the IP addresses of the IKEv2
channel as outer IP addresses. One way to establish these two VPNs
is to create an IKEv2 channel for each interface. This results in
unnecessary IKE negotiations with multiple authentications
Nbr(EU_interfaces) X Nbr(SG_interface) X Nbr(Flows). This number
rapidly grows with the number of involved interfaces both on the
Security Gateway and on the End User.
[RFC6027] section 3.8 mentions that peers using different IP
addresses for the VPN and the IKEv2 channel SHOULD be modified unless
they may drop the packets. The alternate outer IP address described
in this document is described so that any VPN End User can interact
with any Security Gateway.
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] addresses this issue.
The End User VPN indicates during the SA negotiation the outer IP
address it wants, and in return the Security Gateway indicates the
outer IP address of the Security Gateway. Motivations for
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] is a cluster of
Security Gateways that splits the IKEv2 traffic and the VPN traffic,
so that the VPN traffic avoids overloading some equipments like
firewalls or load balancers for example.
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] would also address the
case of figure 1 because the the path used by the VPN is defined by
the interface used by the VPN End User VPN. This results from the
fact that the Security Gateway has only one interface. However,
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] would need slight
modifications in order to address the more general case where VPN End
User and the Security Gateways have multiple interfaces. In that
case, a path would be defined not by a single interface (as in figure
1), but by a pair of interface.
In addition to path negotiation,
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] uses a Notify Payload
that is not bound to a SA Proposal, thus making multiple SA Proposals
with different outer IP address difficult. Again this case is very
Migault (Ed) Expires August 19, 2013 [Page 5]
Internet-Draft Alternate Outer IP Address Extension February 2013
specific to multiple interfaces. Even though the protocol described
in this document address these limitations, it remains very closed to
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses].
4.2. Security Gateway with Multiple Interfaces
In the scenario presented in figure 2, the VPN End User has two
interfaces and the VPN End User has a single interface. Like the VPN
End User with multiple interfaces presented in Section 4.1, we
suppose that the VPNs are established by the VPN End User with the
Security Gateway. Unlike the scenarios of Section 4.1, motivations
for choosing VPN_0 or VPN_1 are not associated to the interface used
by the VPN End User, but the path taken by the packets. As a result,
the VPN End User cares about both source and destination outer IP
addresses that defines the path.
+------------+ +------------+
| | Interface_0 : VPN_0 | |
| | ============= Security |
| VPN | v | Gateway |
| End User =================== | |
| | ^ ============ |
| | Interface_1 : VPN_1 | |
+------------+ +------------+
Figure 2: Security Gateway with Multiple Interfaces
Comments of Section 4.1 also applies to this scenario, but this
scenario stresses that the choice of the VPN outer IP addresses
SHOULD result from a negotiation between the two peers, and both
outer IP addresses SHOULD be negotiated.
Note that the scenario described in figure 2, considers that all
interfaces are used to setup all different VPNs. As described in
Section 4.1, if VPN End Users and Security Gateways have both
multiple interfaces, setting up all possible tunnels may be
unnecessarily heavy. As a result, the VPN End User SHOULD be able to
negotiate both outer IP addresses of its VPN.
Note that if the VPN End User negotiates the outer IP address used by
the Security Gateway, the VPN End User may know in advance what
interfaces are available. It is beyond the scope of this document to
define how the VPN End User may know this information. MOBIKE
[RFC4555] defines the ADDITIONAL_IP*_ADDRESSES Notify Payload, and
[I-D.mglt-ipsecme-security-gateway-discovery] defines how these
pieces of information may be provided by other Security Gateways.
Migault (Ed) Expires August 19, 2013 [Page 6]
Internet-Draft Alternate Outer IP Address Extension February 2013
4.3. Distributed Security Gateways
The scenario described in figure 3 considers a distributed Security
Gateway. The IKEv2 channel and the VPNs are handled by different
nodes. As a result the VPN does not uses the same outer IP addresses
as the IKEv2 channel.
+------------+ +------------+
| | Interface_0 | IKE |
| | IKEv2 channel ^------------- Security |
| VPN ------------------- ^ | Gateway |
| End User =================== v +------------+
| | VPN channel v +------------+
| | v Interface_1| VPN |
+------------+ v============= Security |
| Gateway |
+------------+
...
+------------+
Interface_i| VPN |
============= Security |
| Gateway |
+------------+
Figure 3: Distributed Security Gateways
This scenario is addressed by
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] where each part can
choose the interface it will use as the outer IP address for the VPN.
As mentioned in Section 4.1, being able to specify a single interface
is not sufficient to select a path. More specifically, in figure 3,
this would not provide the possibility for the VPN End User to choose
between Interface_1 and Interface_i.
5. Protocol Overview
The alternate outer IP address extension, makes possible two peers to
negotiate and agree on alternate IP addresses for their VPN. We
consider the outer IP addresses as parameters of the Security
Association. (Tunnel header IP source and destination address as
described in [RFC4301]). As a consequence, the negotiation of these
parameters occurs during the negotiation of the Security Association,
that is during the IKE_INIT exchange or the CREATE_CHILD_SA exchange
as described in [RFC5996].
VPN SA negotiation can be initiated by either VPN End User or the
Security Gateway, so in the remaining of the document we simply use
Migault (Ed) Expires August 19, 2013 [Page 7]
Internet-Draft Alternate Outer IP Address Extension February 2013
initiator and responder, as the peer initiating the negotiation.
Note that these negotiations makes possible that any peer can
negotiate one, or both outer IP address, that is to say, the outer IP
address source and destination.
Section 5.1 briefly reminds how the Security Association' parameters
are negotiated with IKEv2, and then proposes the new involved
payloads to negotiate the outer IP addresses. Basically a new
Alternate Outer Address Transform (OADD) and a new IP Attribute are
defined. Section 5.2 and Section 5.3 and Section 5.4 are focused on
the exchanged when both peers support the alternate outer IP address
extension. Section 5.2 describes how the initiator builds a SA
Proposal and Section 5.3 defines how the responder handles it.
Section 5.4 defines the case where the Proposal MUST be discarded.
Although not mandatory, there MAY be an advantage that peers are
informed whether the alternate outer IP address is supported or not
before sending Proposals. Section 5.5 presents how peers can inform
each other the support this extension. At last, Section 5.6
illustrates the different exchanged described in the document.
5.1. Alternate outer IP addresses Transform
This section does not intend to explain how SAs are negotiated, and
the reader is expected to refer to [RFC5996] section 3.3. This
section briefly sums up the different type of payload involved in
order to clarify our purpose. Figure 4 is copied from [RFC5996] to
illustrate concepts involved in the Security Association negotiation.
Migault (Ed) Expires August 19, 2013 [Page 8]
Internet-Draft Alternate Outer IP Address Extension February 2013
SA Payload
|
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| |
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
| +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
| +-- Transform ESN ( Name = ESNs )
| +-- Transform ESN ( Name = No ESNs )
|
+--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
| 4 transforms, SPI = 0x35a1d6f2 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 128 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform ESN ( Name = ESNs )
+-- Transform ESN ( Name = No ESNs )
Figure 4: Security Association Payload Structure
A Security Association is defined by various parameters such as
Encryption (ENCR) or Integrity (INTEG), Pseudorandom Function (PRF),
Diffie-Hellman group (D-H) or Extended Sequence Numbers (ESN). These
parameters are defined through Transforms and each parameter is a
Transform Type.
A Security Association is negotiated through the SA Payload which
contains one or more Proposals Payloads. Each Proposal contains one
or multiple acceptable "values" for each Transformed Type. These
"values" can be seen as an OR. The Proposal is accepted if for each
Transform Type one of the proposed "value" is accepted by the
responder. If the responder cannot choose an acceptable "value" for
each Transform Type, the proposition is rejected. A "value" is
composed of a Transform ID, like the name of the encryption
algorithm, and eventually one or more Attributes, like the key length
Migault (Ed) Expires August 19, 2013 [Page 9]
Internet-Draft Alternate Outer IP Address Extension February 2013
for example.
In our case, we consider a new Transform Type OADD. This Transform
Type has two Transform ID (INIT or RESP) that designates the
initiator outer IP address (INIT) or the responder outer IP address
(RESP). The Attributes associated to each Transform ID is the IP
Attribute that can be an IPv4 address, an IPv6 address or a specific
value.
5.2. Initiator: Sending OADD Transforms in Proposals
In Section 5.2 and Section 5.3 we suppose that both the initiator and
the responder support the alternate outer IP address extension, that
no USE_TRANSPORT_MODE Notify Payload is sent in conjunction of the SA
Payload, and that the Proposal Payload as defined in [RFC5996]
Section 3.3.1 has its Protocol ID set to AH or ESP. Other cases are
discussed in Section 5.4
If the initiator wants to propose the Security Gateway to choose
among a set of the initiator's interfaces IP_init_0, ..., IP_init_k
for the VPN outer IP address, it MUST include k+1 Transforms with
Transform Type OADD and Transform ID set to INIT. The Transform is
associated to the Attribute of Type IP. Transform Attributes are
defined in [RFC5996] 3.3.5.
Similarly, if the initiator wants to select on the Security Gateway
one interface among a set of interface IP_resp_0, ..., IP_resp_l, it
MUST include l+1 OADD Transform with Transform ID set to RESP, and an
Attribute of Type IP.
If the initiator does not know the interface that the responder may
choose, it may indicate the responder to define the most appropriated
interface with a OADD Transform with Transform ID set to RESP and an
Attribute of Type with the specific value ANY_IP.
If no OADD Transform with Transform ID set to INIT (Respectively
RESP) are provided in the Proposal, the default value for the outer
IP address is the one used by the IKEv2 channel. More specifically,
if the initiator considers the interface used for the IKEv2 channel
as an alternative to other IP addresses, a OADD Transform with this
IP address MUST explicitly be in the Proposal.
Note that a Proposal does not need to have both OADD Transform with
Transform ID INIT and RESP. The initiator can choose to have only
OADD Transforms with Transform ID INIT (respectively RESP).
Migault (Ed) Expires August 19, 2013 [Page 10]
Internet-Draft Alternate Outer IP Address Extension February 2013
5.3. Responder: Receiving OADD Transforms in Proposals
As mentioned in Section 5.2, we suppose the responder supports the
alternate outer IP address extension. If a Proposal contains one or
multiple OADD with a Transform ID set to INIT (respectively RESP),
the responder choose one of these. If selected OADD Transform (INIT
or RESP) with an IP Attribute, the responder returns the Transform
without modification. Otherwise, if selected OADD Transform is with
an ANY_IP Attribute, the responder returns a IP Attribute with the
correct value.
If the responder has no OADD Transform with Transform ID INIT
(respectively RESP), then by default the outer IP address of the VPN
is equal to the IP address used by the IKEv2 channel.
5.4. Incompatible Proposal with OADD Transforms
The alternate outer IP address extension only makes sense for the
IPsec tunnel mode. The SA Payload with Proposals that contains one
or more OADD Transforms MUST NOT be used with a USE_TRANSPORT_MODE
Notify Payload. Responder MUST reject these Proposals.
Similarly, Proposals with a Protocol other than AH or ESP, (that is
to say IKE), MUST NOT be used with OADD Transforms. Responder MUST
reject these Proposals.
As mentioned in [RFC5996] Section 3.3.6, a responder that does not
support the alternate outer IP address extension MUST reject any
Proposal that contains a Transform with a Transform Type OADD. If
the responder rejects all Proposals, it MUST send a
NO_PROPOSAL_CHOSEN Notify Payload.
5.5. Supporting alternate outer IP address exchange
This section describes an informational exchange where each peer
informs the other that it supports the alternate outer IP address
extension. This exchange is not mandatory, but is recommended as it
MAY ease to format the Proposals for the Security Association
negotiation.
In fact the negotiation of the alternate outer IP address is included
in SA negotiation. As described in Section 5.1, this introduces new
Transform Type and new Attributes. [RFC5996] Section 3.3.6 mentions
that a peer does not understand the new Transform Type or the new
Attributes, it MUST reject the Proposal. As a result, if the
initiator does not know if the responder supports the alternate outer
IP address extension, it SHOULD include proposals without the
associated Transform Type and Attributes to avoid that all Proposals
Migault (Ed) Expires August 19, 2013 [Page 11]
Internet-Draft Alternate Outer IP Address Extension February 2013
are rejected by the responder and receives a NO_PROPOSAL_CHOSEN
Notify Payload.
To limit the number of proposals to be sent by the initiator during
the SA negotiation, we define the supporting alternate outer IP
address exchange where the initiator can advertise it supports the
alternate outer IP address extension by sending a
ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload. When a node
receives this Notify Payload and support the alternate outer IP
address extension, it MUST send back the same Notify Payload.
5.6. Basic Exchange
Figure 5 provides a basic exchange. The initiator and the responder
agree on supporting the alternate outer IP address extension. This
exchange is optional but recommended. In Figure 5 this exchange
occurs during the IKE_INIT exchange, but it MAY occur anytime.
The SA negotiation consists in sending multiple Proposals. In figure
5, the OADD Transform specify the initiator and responder's IP
address. The responder choose one of the proposed transformed.
Migault (Ed) Expires August 19, 2013 [Page 12]
Internet-Draft Alternate Outer IP Address Extension February 2013
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED)
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED)
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
==== From this exchange:
- the Initiator and the Responder support the alternate
outer IP address extension
- no NAT has been detected =====
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, TSi, TSr
SAi2( Proposal(ENCR, INTEG, ESN, < proposes IP1, IP2 for
OADD(INIT, IP1), the init., ANY IP for
OADD(INIT, IP2), the resp.
OADD(RESP, ANY_IP))
Proposal(ENCR, INTEG, ESN))) < proposes to use IKEv2 IP
} --> for the VPN outer IP
<-- HDR, SK {IDr, [CERT,] AUTH, TSi, TSr,
SAr2(Proposal(ENCR, INTEG, ESN,
OADD(INIT, IP1),
OADD(RESP, IPr)))
}
Figure 5: Basic Exchange for VPN alternate outer
IP addresses negotiation
6. Payload Formats
As mentioned in Section 5 this document introduces a new Transform of
Transform Type OADD. The associated Transform ID are INIT for the
initiator outer IP address and RESP for the responder's IP address.
These Transforms are associated a Attributes that are either carrying
an IP address (IPv4 or IPv6) or associated to a specific value like
ANY_IP.
This document also introduces the
ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload, so peers can
Migault (Ed) Expires August 19, 2013 [Page 13]
Internet-Draft Alternate Outer IP Address Extension February 2013
inform the other they support the alternate outer IP address
extension.
This section describes the format of all new payload introduced for
the outer IP address extension.
6.1. Outer IP address Transform OADD
This section specifies the Transform structure as defined in
[RFC5996] Section 3.3.2.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OADD Transform Substructure
- 0 (last) or 3 (more) (1 octet): Specifies whether this is the last
Transform Substructure in the Proposal.
- RESERVED (1 octet): MUST be sent as zero; MUST be ignored on
receipt.
- Transform Length (2 octets): The length (in octets) of the
Transform Substructure including Header and Attributes.
- Transform Type (2 octets): The type of transform being specified
in this transform. Set to OADD in this document.
- Transform ID (2 octets): he specific instance of the Transform
Type being proposed. Set to INIT or RESP in this document.
- Transform Attributes (variable length): The IP Attribute in this
document.
Migault (Ed) Expires August 19, 2013 [Page 14]
Internet-Draft Alternate Outer IP Address Extension February 2013
6.2. IP Attribute with IP addresses
This section specifies the Attribute structure as defined in
[RFC5996] Section 3.3.5.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Attribute Type | AF=0 Attribute Length |
|F| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IP Attribute with IP address
- Attribute Format (AF) (1 bit): Set to 0, indicating a TLV format.
- Attribute Type (15 bits): Set to IP in this document.
- Attribute Length (16 bits): The length is either 8 to designate
the length of an IPv4 or 20 to designate the length of on IPv6
address. The length includes the headers of 4 octets.
6.3. IP Attribute indicating ANY_IP
This section specifies the Attribute structure as defined in
[RFC5996] Section 3.3.5.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Attribute Type | AF=1 Attribute Value |
|F| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IP Attribute set to ANY_ IP
- Attribute Format (AF) (1 bit): Set to 1, Attribute Value.
- Attribute Value (15 bits): Set to ANY_IP in this document.
Migault (Ed) Expires August 19, 2013 [Page 15]
Internet-Draft Alternate Outer IP Address Extension February 2013
6.4. Alternate Outer IP Address Notify Payload
This section presents the Notify Payload as defined in [RFC5996]
Section 3.10.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size = 0 | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Alternate Outer IP Address Notify Payload
- Next Payload (1 octet): Identifier for the payload type of the
next payload in the message. If the current payload is the
last in the message, then this field will be 0.
- Critical (1 bit): MUST be set to zero for payload types defined in
this document.
- RESERVED (7 bits): MUST be sent as zero; MUST be ignored on
receipt.
- Payload Length (2 octets, unsigned integer): Length in octets of
the current payload, including the generic payload header. Set
to 16 in this document.
- Protocol ID (1 octet): This field MUST be sent as zero and MUST
be ignored on receipt.
- Notify Message Type (2 octets): Set to
ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED in this document.
7. NAT considerations
In the document we assumed that there were no NAT between the VPN End
User and the Security Gateway. This means that the VPN End User and
the Security Gateway know 1) the interface they are receiving data on
is the interface used as a destination by the other peer and 2) the
interface set as destination is the interface used by the other peer
to receive the data. As a result, if the VPN End User (respectively
the Security Gateway) is behind a NAT, the VPN End User may be seen
by the Security Gateway (respectively the VPN End User) with another
IP address unknown to the VPN End User (respectively the Security
Gateway).
Migault (Ed) Expires August 19, 2013 [Page 16]
Internet-Draft Alternate Outer IP Address Extension February 2013
NATs impact the alternate outer IP address extensions in two ways:
- IPsec configuration: The alternate outer IP addresses the two
peers are negotiating may not be the ones in the Security
Associations. More specifically, suppose the VPN End User and
the Security Gateway depicted in figure 10 have negotiated the
alternate outer IP addresses src_0, dst_1. src_0 is NATted with
NAT_0, and may be unreachable, the outer IP address in the
Security Gateway SA should be src_nat_0 instead.
- NAT traversal: NATs may make an IP address behind it reachable
only if this IP address has initiated a connection. More
specifically, suppose the VPN End User and the Security Gateway
depicted in figure 10 have established an IKEv2 channel between
src_0 and dst_1 and are MOBIKE enabled. Suppose the VPN End
User sends the Security Gateway an ADDITIONAL_IP*_ADDRESS with
src_1 or eventually with src_nat_1. Unless NAT_1 has been
configured to forward the traffic from the Security Gateway to
the VPN End User, this traffic will most likely be discarded by
NAT_1. Similarly, if the Security Gateway moves the VPN from
dst_0 to dst_1, the VPN may be broken. Note that we use MOBIKE
to illustrate the problems of reachability through NATs, but
these operations are discussed more in depth in [RFC4555].
This section does not intend to discussed all NATs configuration as
described in [RFC5389]. Instead the only NAT scenario we consider is
a single NAT and the VPN End User behind that NAT initiates the
alternate outer IP address exchange. The architecture this section
considers is depicted in figure 10. Furthermore, this section does
not consider the NAT traversal aspect. We assume that the VPN End
User is NAT aware and perform the necessary actions to make/configure
the NATs so that they do not block the traffic.
Section 7.1 defines how the End User MAY prohibit the alternate outer
IP address extension if a NAT is detected. Then, in Section 7.2 how
the VPN End User can detect the presence of NAT. Section 7.3
discusses the case where the VPN End User does not know the values of
the NATted IP addresses and Section 7.4 discusses the case where the
VPN End User knows all NATted IP addresses values.
Migault (Ed) Expires August 19, 2013 [Page 17]
Internet-Draft Alternate Outer IP Address Extension February 2013
+---+
+------------+ | I | +------------+
| | src_0 +-------+ src_nat_0 | N | dst_0 | |
| =========| NAT_0 |===========| T |=======| Security |
| VPN | +-------+ | E | | Gateway |
| End User | src_1 +-------+ src_nat_1 | R | dst_1 | |
| =========| NAT_1 |===========| N |=======| |
| | +-------+ | E | | |
+------------+ | T | +------------+
+---+
Figure 10: VPN End User behind a NAT scenario
7.1. Prohibiting NAT
This section considers that the VPN End User does not want to use the
alternate outer IP address extension if a NAT is detected. This
section differs from the NAT detection because it both detects the
existence of a NAT and provide an indication that some supported
functionalities like MOBIKE SHOULD NOT be used if a NAT is detected.
The NO_NATS_ALLOWED Notify Payload is defined in [RFC4555]. If the
VPN End User supports MOBIKE, it MAY send a NO_NATS_ALLOWED Notify
Payload with the original IP addresses and ports. When the Notify
Payload is received by the Security Gateway, it checks the IP
addresses values in the IP header and in the Payload, in case of
mismatch, a UNEXPECTED_NAT_DETECTED Notify Payload is returned.
In our case, the NO_NATS_ALLOWED MAY be used by the VPN End User if
both the VPN End User and the Security Gateway support MOBIKE. When
the Security Gateway receives the NO_NATS_ALLOWED Notify Payload, it
MUST NOT use MOBIKE and SHOULD NOT use the alternate outer IP address
extension.
There are corner cases that are not considered by this policy.
First, a VPN End User or a Security Gateway that do not support
MOBIKE cannot use the NO_NATS_ALLOWED Notify Payload. However, it
seems hardly possible that peers supporting the alternate outer IP
address extension support MOBIKE. Second, a VPN End User using the
NO_NATS_ALLOWED applies the same policy for MOBIKE and the alternate
outer address extension. Here again, it seems unlikely that NAT
policies differ. Furthermore, the NO_NATS_ALLOWED exchange only
prevent the Security Gateway to initiate a MOBIKE or alternate outer
IP address negotiation. The VPN End User can still use one or the
other extension. From our experience, this constraint seems
acceptable.
Migault (Ed) Expires August 19, 2013 [Page 18]
Internet-Draft Alternate Outer IP Address Extension February 2013
7.2. NAT detection
This section details how NAT can be detailed with IKEv2 extensions.
We do not consider here other mechanisms like ICE described in
[RFC5768] or STUN [RFC5389].
The VPN End User can detect the NAT by using the
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP Notify
Payload as described in [RFC5996]. These Notify Payloads carry the
SHA-1 of the source (respectively the destination) IP address. At
the reception, the Security Gateway can compare their contend with
the SHA-1 of the IP addresses in the IP header. A mismatch between
the two values indicates the presence of a NAT, but do not provide
the value of the original IP address. Usually, this exchange is
performed during the IKE_INIT exchange to decide whether or not IKEv2
should proceed to UDP encapsulation.
Note that with the NAT detection exchange, the NAT is detected on the
IKEv2 channel. If the IKEv2 channel is using src_0, the NAT
detection exchange will detect NAT_0. To detect NAT_1 using IKEv2,
the VPN End User SHOULD move the IKEv2 channel on src_1 with MOBIKE
for example. Since the UPDATE_SA Notify Payload is initiated by the
VPN End User, NAT_1 is expected to accept the traffic from the
Security Gateway. Note also that the NAT detection exchange does not
provide the value of the src_nat* IP addresses.
7.3. The VPN End User does not know the NATted IP addresses
This section analyses how the alternate outer IP address extension
can be used when the VPN End User does not know the values of the
NATted IP addresses, i.e. src_nat_0 and src_nat_1.
In that case, the VPN End User MAY only select the destination outer
IP address corresponding to the Security Gateway IP addresses. How
the VPN End User gets these IP addresses is out of scope of the
document, however, if the VPN End User and the Security Gateway
support MOBIKE, the MOBIKE ADDITIONAL_IP*_ADDRESS Notify Payload MAY
be used for that purpose. It is recommended that the VPN End User
does not provide the outer source IP, in which case, the one from the
IKEv2 channel will be considered by default. More specifically, the
VPN End User cannot provide the Security Gateway its alternate IP
addresses.
The VPN End User MAY use the ANY_IP IP Attribute for the source outer
IP address. This would enable the Security Gateway to select an
alternate IP address that differs from the one used by the IKEv2
channel. In order to select the IP addresses associated to the VPN
End User, the Security Gateway has to be aware of the NATted IP
Migault (Ed) Expires August 19, 2013 [Page 19]
Internet-Draft Alternate Outer IP Address Extension February 2013
addresses depicted as src_nat_0 and src_nat_1. One possibility is
that the Security Gateway log the IP addresses used by the VPN End
User when it moves from src_0 to src_1. This also means that the VPN
is being negotiated with a CREATE_CHILD_SA exchange after the initial
IKE_INIT exchange.
7.4. The VPN End User does know the NATted IP addresses
In this section the VPN End User knows the NATted IP addresses
src_nat_0 and src_nat_1. How the End User get these values is out of
scope of the document. This case should be considered only if the
VPN End User exactly know what it is doing.
In this case, the VPN End User can proceed as if no NAT exist. The
VPN End User considers in the alternate outer IP address negotiation
that its IP addresses are the NATted IP addresses that is src_nat_0
and src_nat_1. On the other hand, the VPN End User MUST configure
properly its SAs with src_0 if src_nat_0 is selected or with src_1 if
src_nat_1 is selected.
The VPN End User is also responsible to make the NAT Traversal
possible.
8. IANA Considerations
The new fields and number are the following:
IKEv2 Notify Message Types - Status Types
-----------------------------------------
ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED TBD
Transform Attribute Types
-------------------------
OADD TBD
Transform Type OADD IDs
-----------------------
INIT TBD
RESP TBD
Attribute Type
--------------
IP TBD
IP Attribute Type Values
------------------------
Migault (Ed) Expires August 19, 2013 [Page 20]
Internet-Draft Alternate Outer IP Address Extension February 2013
ANY_IP TBD
9. Security Considerations
The exchange described in this document is protected by the IKEv2
channel.
10. Acknowledgment
The author would like to thank Yoav Nir for its helpful comments.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, April 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
October 2010.
11.2. Informational References
[I-D.arora-ipsecme-ikev2-alt-tunnel-addresses]
Arora, J. and P. Kumar, "Alternate Tunnel Addresses for
IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00
(work in progress), April 2010.
Migault (Ed) Expires August 19, 2013 [Page 21]
Internet-Draft Alternate Outer IP Address Extension February 2013
[I-D.mglt-ipsecme-security-gateway-discovery]
Migault, D. and K. Pentikousis, "IKEv2 Security Gateway
Discovery",
draft-mglt-ipsecme-security-gateway-discovery-00 (work in
progress), February 2013.
[I-D.mglt-mif-security-requirements]
Migault, D. and C. Williams, "IPsec Multiple Interfaces
Problem Statement",
draft-mglt-mif-security-requirements-03 (work in
progress), November 2012.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-00: First version published.
Author's Address
Daniel Migault
Francetelecom - Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: mglt.ietf@gmail.com
Migault (Ed) Expires August 19, 2013 [Page 22]
