| MIF Working Group | D.M. Migault |
| Internet-Draft | Francetelecom - Orange |
| Intended status: Standards Track | C.W. Williams |
| Expires: May 09, 2013 | MCSR Labs |
| November 05, 2012 |
IPsec Multiple Interfaces Problem Statement
draft-mglt-mif-security-requirements-03.txt
IKEv2 is the protocol used to set up and negotiate Security Associations between nodes. IKEv2 has not been designed for nodes with multiple interfaces.
This document is focused on IKEv2 ability to set up IPsec protected communications between nodes with multiple interfaces. This document states the problems and provides requirements for IKEv2 to ease IPsec for multiple interface communication.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
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 May 09, 2013.
Copyright (c) 2012 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 (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.
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].
IPsec protocol suite [RFC4301],[RFC5996] is mainly used to:
Currently most devices have multiple interfaces. Mobile phones have most of the time a Wireless LAN (WLAN) and a Radio Access Network (RAN) interface. Laptop can easily have Ethernet / WLAN / RAN with WiMAX interfaces. Furthermore, USB dongle can be plugged to provide additional RAN and WLAN interfaces. Regular PCs, Servers, or CPEs have multiple Ethernet interfaces, with additional WLAN interfaces.
Protocols like SCTP [RFC4960] or MOBIKE [RFC4555] have been designed to use these multiple interfaces for multihoming. Only a single interface is used at a time. The interface used to carry the IP datagrams is called the Primary interface and other interfaces are called Secondary or Alternate interfaces. Alternate interfaces are only expected to be used in case the Primary interface fails.
However, multihoming does not enable the simultaneous use of multiple interfaces which can provide a better use of the available bandwidth. MPTCP [RFC6182] has been designed for that purpose, and SCTP [RFC4960] can also be used for it. Raiciu and al. [Raiciu] showed how using multiple paths improve the performances and robustness of data centers compared to TCP. Furthermore, a communication may be connected simultaneously to different networks with different technologies and takes advantage of their different characteristics. This is typically the case of Offload when ISPs are offloading their RAN communications to a WLAN network. Motivations for offloading is that RAN cannot support all mobile traffic [Cisco]. As a result, with a RAN and a WLAN interface, Mobile phones and ISPs may balance the communications between an unreliable WLAN with economical bandwidth and always connected RAN with expensive bandwidth.
The document focuses on how applications and services protected with IPsec can also take advantage of multiple interfaces. The traditional VPN application with multiple interfaces is the first use case we consider. However, with the offload usage, ISPs are offloading unprotected communications, services from a trusted network - like the RAN - to an untrusted and unreliable network - like the WLAN. This means that the ISP must protect the communications related to these services and applications while being offloaded. IPsec appears to be one way to secure communications transparently to the application.
They are two ways to secure the communications with IPsec. One way is to tunnel the communication to a Security Gateway. The other is to provide end to end security. The document will consider both ways.
Section 3 considers the specific case of VPN with multiple interfaces. Section 4 extends the previous use case by considering the general case of IPsec protected communications using the Tunnel mode. Finally Section 5 considers the case of IPsec protected communications with the Transport mode. For each case, the document details different scenarios that take advantage of multiple interfaces. Then it positions IKEv2 toward each of these scenarios and points out requirements
This section describes the VPN scenario with connectivity described in figure 1, the End User (EU) has multiple interfaces and figure 1 represents 3 interfaces bound to 3 IP addresses EU @IP_outer(i), (i in {1, 2, 3}).
End User Security Gateway
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| EU @IP_inner1---====================---------------
| EU @IP_outer2 SG @IP_outer2 |
| EU @IP_inner2---====================---------------
| EU @IP_outer3 SG @IP_outer3 |
| EU @IP_inner3---====================---------------
| | | |
+---------------------+ +----------+
Figure 1: VPN with Multiple Interfaces
This sections details how the End User with its three interfaces set (EU @IP_outer(i), i in{1, 2, 3}) can set an IPsec configuration as represented in figure 1. We consider the IPsec configuration is set using IKEv2, and that the End User uses only a single IKEv2 channel. In other words, each interface MUST NOT be be considered independently from each other with its own IKEv2 channel an own Security Associations.
One of these End User IP addresses is used to set the IKEv2 channel. This IP address is used to set the IKE_SA as well as for all IKEv2 exchanges. Suppose EU @IP_outer1 is used for the IKE_SA.
Using the IKEv2 channel, the End User requests the inner IP addresses EU @IP_inner(i), i in {1, 2, 3}. If the Security Gateway has multiple interfaces, it advertises the End User, what are the available interfaces.
Once the End User has inner and outer IP addresses, it starts negotiating via the IKEv2 channel the different Security Associations. For each Security Association, the End User and the Security Gateway SHOULD be able to agree on the Traffic Selectors (i.e. the inner IP addresses) as well as the outer IP addresses used for the Tunnel.
This section positions the current IKEv2 specifications toward the scenario described in Section 3.1.1
To request multiple inner IP addresses, the End User can use the IKEv2 with multiple INTERNAL_IP*_ADDRESS Configuration Attributes in the CFG Payload (Section 3.15 [RFC5996]).
Currently IKEv2 does not provide ways for the Security Gateway to announce the End User the available outer IP addresses - SG @IP_outer1, SG @IP_outer2 and SG @IP_outer3. [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] details how this could be mitigated. Note that in the VPN use case, the initiator - that is to say the End User - is more likely to request the Security Gateway outer IP addresses, then the reverse. In other words, there seems very few interest for the responder to know the different outer IP addresses of the End User. However, as detailed in Section 5 the more general case SHOULD consider that both initiator and responder can advertise the available interface when the IKEv2 negotiation is initiated.
IKEv2 makes possible the negotiation of the Security Associations associated to each of the EU @IP_inner(i) IP addresses using a Traffic Selector Payload with one or multiple Traffic Selectors (section 3.13 [RFC5996]). IKEv2 even enables the simultaneous negotiation of Security Associations. However, currently the Security Association negotiation does not specify the outer IP addresses. The outer IP addresses are those used for the IKEv2 channel. In other words, current IKEv2 only considers a single working IP address for both the End User and the Security Gateway. Figure 2 illustrates current IKEv2 capabilities in the VPN use case with different Traffic Selectors associated to a single outer IP address. While negotiating a Security Association, IKEv2 SHOULD be able to specify the source and destination IP addresses.
Note that the benefits of specifying the outer IP addresses provides the End User or Initiator the ability to use simultaneously multiple interfaces. In the specific case of figure 1, the Security Gateway will most likely have a single IP outer IP address. We considered multiple IP addresses on the Security Gateway for the more general case.
Currently, IKEv2 does not provide the ability to negotiate the outer IP addresses of the Tunnel. By default, the outer IP addresses of the Child Security Associations are those used for the IKEv2 channel. This results in the configuration as represented in figure 2. The configuration of figure 1 does not result from an IKEv2 negotiation.
End User Security Gateway
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| EU @IP_inner1---====================---------------
| EU @IP_outer2 ^^ SG @IP_outer2 |
| EU @IP_inner2---vv
| EU @IP_outer3 ^ SG @IP_outer3 |
| EU @IP_inner3--- v
| | | |
+---------------------+ +----------+
Figure 2: VPN with Multiple Interfaces
Current IKEv2 negotiation
In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible:
This section considers how a node with multiple interfaces can modify the value of the outer IP address. In the Tunnel mode, changing the outer IP address results in a mobility, however this should be seen as updating a parameter of the Security Association. Figure 3 illustrates a mobility where EU @IP_outer3 in Figure 1 is updated by EU @IP_outer4.
In fact, the Security Association associated to EU @IP_inner3 includes the outer IP address of the tunnel. The End User and the Security Gateway MUST change this outer IP address from EU @IP_outer3. The End User MUST modify its Security Association so that packets sent to the Security Gateway are using a valid IP address. Similarly, the Security Gateway MUST update its Security Association so that it can send packets to a reachable destination IP address. The notification of the update is performed using the IKEv2 channel, that is to say in our case EU @IP_outer1.
Figure 3 illustrates the case where EU @IP_outer4 is using the same network hardware interface as EU @IP_outer3. This corresponds to the case where, for example, the End User decides to use EU @IP_outer4 instead of EU @IP_outer3 on the same hardware network interface. Other mobility use cases may also consider the EU @IP_outer4 may be associated to a different network hardware, including the one associated to EU @IP_outer(i), i in {1, 2}. Then, EU @IP_outer4 is different from EU @IP_outer3 but may be one of the EU @IP_outer(i), i in {1, 2}.
End User Security Gateway
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| EU @IP_inner1---====================---------------
| EU @IP_outer2 SG @IP_outer2 |
| EU @IP_inner2---====================---------------
| EU @IP_outer4 SG @IP_outer3 |
| EU @IP_inner3---====================---------------
| | | |
+---------------------+ +----------+
Figure 3: VPN Mobility
Currently IKEv2 proposes different alternative to update a Security Association, and modify the outer IP address of the Tunnel. However none of them really address the description provided in Section 3.2.1
MOBIKE [RFC4555] provides an UPDATE_SA_ADDRESSES exchange that updates the outer IP address of the tunnel. As explained in this section MOBIKE cannot be used in the general case described in figure 3 because the updated IP address is necessarily the one associated to the IKEv2 channel. This limitation is due to the fact that MOBIKE has been designed for a single interface.
MOBIKE does not explicitly specify in its message the IP address that has to be updated and the new value for this IP address. The IP address to be updated is the one used by the IKEv2 channel, and the new IP address to consider is the IP address used in the IP header of the UPDATE_SA_ADDRESSES message.
If EU @IP_outer1 is equal to to EU @IP_outer3, then sending an UPDATE_SA_ADDRESSES would update the outer tunnel IP address of the Security Associations using the IP address of the IKEv2 channel, that is at least EU @IP_outer1 and EU @IP_outer3, with EU @IP_outer4. This case is only a specific case and is not applicable when the outer IP address to update is different from the IP address used for the IKEv2 channel.
If EU @IP_outer3 is different from EU @IP_outer1, then, the only way to use MOBIKE is to move the IKEv2 channel to EU @IP_outer3, that is updating EU @IP_outer1 by EU @IP_outer3, and then updating EU @IP_outer3 by EU @IP_outer4. This is not convenient because all traffic on EU @IP_outer1 has been transferred to EU @IP_outer3, and then to EU @IP_outer4. Furthermore, it is only possible for managed mobility, because we need EU @IP_outer3 to be a valid interface until IKEv2 uses EU @IP_outer3. In other words, if EU @IP_outer3 fails suddenly, moving the IKEv2 channel to EU @IP_outer3 is not possible anymore.
As a result MOBIKE cannot be used to handle the mobility described in Section 3.2.1.
A second alternative is to renegotiates a new Security Association between the End User and the Security Gateway. IKEv2 provides the CREATE_CHILD_SA Exchange (Section 1.3 [RFC5996]) to create a new Security Association. Similarly Section 3.1.2 this exchange does not specify the outer IP address of the Tunnel. By default, the outer IP address of the Tunnel is the IP address used for the IKEv2 channel. This does not address the use case described in Section 3.2.1.
If requirements of Section 3.1.3 were fulfilled, that is to say even if the CREATE_CHILD_SA would enable to negotiate the outer IP addresses of the Tunnel, then, using the CREATE_CHILD_SA exchange would be an alternative. However, this alternative would still suffer from several drawbacks:
A fourth alternative consists renegotiating an complete independent IKEv2 channel and a new Security Association. This is out of the scope of this document. This may result as having a IKEv2 channel per interface. Furthermore, independent IKEv2 channels may not simplify IPsec configuration and may result in multiple Security Associations matching a given Traffic Selector, which may cause trouble at least for outbound traffic. Furthermore, in this case, the End User and the Security Gateway must proceed to an authentication.
In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
This section considers how a node can take advantage of multiple interfaces with multihoming. In case one of these interface fails, then another interface can be used instead. Moving the traffic from one interface to the other is called mobility. This section deals with multihoming, that is the two peers agree that in case an interface fails, a mobility should be triggered on the agreed interface.
Suppose, as represented in figure 4, EU @IP_outer3 is not reachable anymore. Applications that are multiple interfaces aware, and also bound to the others EU @IP_inner(i) (i in {1, 2}) IP addresses may handle EU @IP_outer3 non reachability. On the other hand non multiple interfaces aware applications (like regular TCP connections) bound to EU @IP_outer3 are stalled and cannot use the other interfaces.
One way to recover the EU @IP_inner3 unreachability is to reconfigure the Security Association and replace EU @IP_outer3 by EU @IP_outer(i) (i in {1, 2}). Figure 5 shows that EU @IP_outer3 is replaced by EU @IP_outer2. EU @IP_outer2 has been provided as an Alternate IP address of EU @IP_outer3. This means that when one or the other peer notice EU @IP_outer3 is down, it can trigger a mobility with the appropriated outer IP address. More specifically, the Security Gateway can overcome the failure of EU @IP_outer3, if it detects the failure before the End User. The End User and the Security Gateway can also agree on an ordered list of Alternate IP addresses.
End User Security Gateway
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| EU @IP_inner1---====================---------------
| EU @IP_outer2 SG @IP_outer2 |
| EU @IP_inner2---====================---------------
| SG @IP_outer3 |
| EU @IP_inner3--- ---------------
| | | |
+---------------------+ +----------+
Figure 4: VPN with Mobility/Multihoming between
Multiple Interfaces: EU @IP_outer3 unreachable
End User Security Gateway
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| EU @IP_inner1---====================---------------
| EU @IP_outer2 SG @IP_outer2 |
| EU @IP_inner2---====================---------------
| |v| |^| SG @IP_outer3 |
| EU @IP_inner3---v ^==========---------------
| | | |
+---------------------+ +----------+
Figure 5: VPN with Mobility/Multihoming between
Multiple Interfaces: EU @IP_outer2
replaces EU @IP_outer3
Currently Multihoming is handled by MOBIKE with the ADDITIONAL_IP*_ADDRESS Notify Payloads. As with mobility, these payloads are only provided for the interface used by the IKEv2 channel. The main reason is that MOBIKE has been designed for a single interface. In our cas,e MOBIKE would only make possible to provide Alternate IP addresses to EU @IP_outer1.
What happens to packets when the Security Gateway performs Multihoming and the End User has not updated its Security Association? Both End User and Security Gateway Security Associations are configured to use the EU @IP_outer3 IP address. When the Security Gateway notices EU @IP_outer3 is not reachable it updates its Security Association, triggers a mobility exchange and may start sending packets to EU @IP_outer2 before the End User has proceeded to the update of its Security Associations. The End User receives this packet and performs a Security Association match. Outer IP addresses will not performed a match, and the match occurs with the Security Policy Index (SPI). The packet is checked against the Security Policy Databases Selectors. These selectors are based on the inner IP addresses and have not been modified. As a result, packets will not be discarded.
In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
Nodes with multiple interfaces may have some interfaces supporting the VPN whereas other interfaces have not been assigned an IP address. When this interface has been assigned an IP address, the current VPN communication may take advantage of this newly available interface. This section is concerned on how a given communication can take advantage of a newly available interface and set its IPsec settings in an optimal way.
Figure 6 represents the End User with multiple interfaces connected to the Security Gateway. We only represented a single interface for the Security Gateway but more interfaces may be also considered. In figure 7, the Security Gateway has an additional interface that becomes active, it advertises the End User this interface is available. The End User may perform some latency and Round Trip Time measurements and decide to use it. In the figure 7, the End User moves the traffic associated to its interface EU @IP_outer3 to the newly available interface SG @IP_outer2 of the Security Gateway. Moving the traffic is performed through a mobility operation as described in Section 3.2.
End User Security Gateway
+---------------------+ +-------------+
| | | |
| EU @IP_outer1 | |
| EU @IP_inner1---========== ^| | |
| EU @IP_outer2 |v| SG @IP_outer1 |
| EU @IP_inner2---====================---------------
| EU @IP_outer3 |^| | |
| EU @IP_inner3---========== v| | |
| | | |
+---------------------+ +-------------+
Figure 6: Security Gateway with a single Interface
End User Security Gateway
+---------------------+ +-------------+
| | | |
| EU @IP_outer1 | |
| EU @IP_inner1---========== ^| | |
| EU @IP_outer2 |v| SG @IP_outer1 |
| EU @IP_inner2---====================---------------
| EU @IP_outer3 SG @IP_outer2 |
| EU @IP_inner3---====================---------------
| | | |
+---------------------+ +-------------+
Figure 7: Security Gateway adding an Interface
New Interface used by the EU @IP_outer3
Figure 6 and 7 illustrated the case, where the Security Gateway has an additional active interface. In this case, the Security Gateway let the End User decide which interface they prefer to use. By announcing the newly available interfaces no new Security Associations are created. On the other hand, the End User may also want that any service using the other interfaces can use this newly available interface. This requires to derive the Security Associations associated to the new interface from those associated to the already established interfaces. The Security Associations derived for the newly active interface are not created from scratch with a complete negotiation. This case is illustrated by figure 8 and 9.
End User Security Gateway
+---------------------+ +-------------+
| | | |
| EU @IP_outer1 | |
| EU @IP_inner1---========== ^| | |
| EU @IP_outer2 |v| SG @IP_outer1 |
| EU @IP_inner2---====================---------------
| | |
| EU @IP_inner3--- | |
| | | |
+---------------------+ +-------------+
Figure 7: End User with an inactive interface
End User Security Gateway
+---------------------+ +-------------+
| | | |
| EU @IP_outer1 | |
| EU @IP_inner1---========== ^| | |
| EU @IP_outer2 |v| SG @IP_outer1 |
| EU @IP_inner2---====================---------------
| EU @IP_outer3 |^| | |
| EU @IP_inner3---===========v | |
| | | |
+---------------------+ +-------------+
Figure 8: End User with a newly active interface
EU @IP_outer3. All traffic associated to
EU @IP_outer1 and EU @IP_outer2 is able to
use EU @IP_outer3
In our case, the End User already had a specific inner IP address associated to the newly available interface EU @IP_outer3. This makes possible the End User to generate the new IPsec Security Associations and new Security Policies associated to EU @IP_outer3. When the Security Gateway receives the request to add the newly available interface, it may set the newly Security Policies and Security Associations. However, the End User may not have an inner IP address EU @IP_inner3, and may combine the request to the Security Gateway to add the new interface, with a request for a EU @IP_inner3 address. In that case, the Security Gateway first sets the IPsec databases, and the End User sets the IPsec databases when it receives the inner IP address.
When an interface is added, unless otherwise specified, the End User wants that all services, except IKEv2 using the available outer IP addresses (EU @IP_outer1 and @IP_outer2 addresses) may also be configured to use the newly available IP address EU @IP_outer3. By adding an interface the End User is not using a finer granularity than the interface granularity. In other words, it does not want to specify how Security Associations are derived. They should be derived in an automatic way. In return, deriving Security Associations and Security Policies is expect to optimize their creation as opposed to using CREATE_CHILD_SA.
In the example of figure 7 and 8, the End User is likely to create Security Associations derived from those established with the interfaces EU @IP_outer1 and EU @IP_outer2. All services using EU @IP_outer1 or EU @IP_outer2 will be able to use EU @IP_outer3 with the inner IP address EU @IP_inner3.
The idea is to copy the Security Association associated with EU @IP_outer1 replace EU @IP_outer1 by EU @IP_outer3 and EU @IP_inner1 by EU @IP_inner3. SPIs MUST also be changed since there are unique for the Security Association. Then we perform the same with EU @IP_outer2.
Note that it is important to specify an ordered list of EU @IP_outer address from which the new SAs are derived, so to guarantee that these new Security Associations are derived the same way on both peers. Then the new Security Association MUST be created only if there are no already existing matching SPD selectors.
In the most basic case of VPN, we only have one Security Association per interface. All services using EU @IP_inner(i) are tunneled to EU @IP_outer(i) i in{1,2}. Adding EU @IP_outer3 only requires to derive Security Association from one interface EU @IP_outer1 and EU @IP_outer2. Then, the End User needs to specify the inner and outer IP addresses EU @IP_inner3, EU @IP_outer3 and in the specific case represented on figure 7 the outer IP address of the Security Gateway SG @IP_outer3. The resulting exchange may look something like the exchange represented in figure 10. The mandatory parameters are the IP address used for the traffic selectors, and the outer IP address for the Tunnel on the End User. The destination outer IP address of the Tunnel is optional and, if not specified may be the one used by the IKEv2 channel. The list of interfaces from which are derived the Security Associations and the Security Policies may also be optional. A default value for this list may be the ordered list of associated outer IP addresses of the End User. The nonce may be used to create SPIs.
End User Security Gateway
request Add Interface (EU @IP_inner3, --->
EU @IP_outer3, [outer-destination]
[interface-list] [nonce])
normal case <--- N()
error case <--- N(error)
Figure 10: Principle of the Adding Interface
exchange
Currently IPsec does not provide any means for a peer to advertise a new interface is available. MOBIKE makes possible to advertise a Alternate IP address is available. However Alternate IP addresses are only intended to be use in case the Primary Interface is down. In our case, the interface is ready for use. This issue is similar to the one detailed in Section 3.1.2. However, here the announcement corresponds to a dynamic changes, and the list of available IP address does not occurs during the IKE_INIT exchange, but in a regular information exchange.
Currently the only way IKEv2 provides to create new Security Associations is the CREATE_CHILD_SA exchange. Disadvantages of this exchange have been described in Section 3.2.2. The key advantage of adding an interface is to provide an optimized interface management exchange instead of a Security Association management exchange.
In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible:
Nodes with multiple interfaces in dynamic environment may have interfaces that are not reachable anymore. This may trigger mobility or multihoming actions. However, the node may also want to delete the Security Associations bound to this interface either as a Tunnel outer IP address or as a Traffic Selector.
Currently IKEv2 does not make possible to delete an interface from multiple Security Associations. IKEv2 provides a Delete Payload (Section 3.11 [RFC5996] that deletes one or multiple specific Security Associations, identified by their SPI.
In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
This section considers applications that can deal with multiple interfaces. This ability can be done with transport layer protocols like MPTCP or SCTP or with applications using one or multiple UDP / TCP connections over the various interfaces, and that manages how to send the data.
The difference between multiple interfaces aware applications and the VPN use case is that the tunnels are established per services, whereas the VPN tunnel all traffic is tunneled to a unique Security Gateway. This may increase the number of Security Associations between the End User and the Security Gateway. This section details motivation for using the IPsec Tunnel mode with multiple interfaces aware applications and position it to the VPN use case of Section 3.
Applications may use the tunnel mode for end-to-end security and to benefit from the Mobility features provided by the Tunnel mode. More specifically, using the Tunnel mode provides Mobility without breaking the connectivity, if upper layer is not mobility aware.
Other motivations for using the Security Gateway is that the End User chose not to tunnel all its traffic to the Security Gateway, but only the traffic that worth being protected. For example, an End User may chose not to tunnel its "youtube" traffic, as well as some of its "https" traffic (as well as it application layer protected traffic). On the other hand, it may want to tunnel all non-protected "http" (as well as other non protected communications).
If each service proposes different Security Gateways, the use case is very similar to the VPN use case, for each service. The main difference is that Security Association are established with different Traffic Selectors.
If multiple services are using the same Security Gateway, this will result for each interface, in multiple Security Associations established with the same Security Gateway - one per service. This case is very similar to the VPN use case but with multiple Security Associations. If "s" is the number of Services connected on the Security Gateway the number of Security Associations is at least "s" 5services are considered independent). If some applications are using multiple flows, then this number may be even larger. In that case, adding an interface results in at least negotiating "s" new Security Associations. Using the CREATE_CHILD_SA exchange may require "s" exchanges whereas using the Adding interface exchange requires only one exchange. This use case is represented in figure 11.
End User Security Gateway
+----------------------+ +----------+
| Services: S1 - Ss | | |
| EU @IP_outer1 SG @IP_outer1 |
| P EU @IP_inner1 ---====================---------------
| o EU @IP_outer2 SG @IP_outer2 |
| r EU @IP_inner2 ---====================---------------
| t EU @IP_outer3 SG @IP_outer3 |
| s EU @IP_inner3 ---====================---------------
| | | |
+----------------------+ +----------+
Figure 11: MIF aware applications
Requirements of this use case have already been mentioned in the VPN use case.
This Use Case is very similar to the Use Case 2 except that the Transport mode is used instead of the Tunnel mode. The Use Case is illustrated with figure 12.
Unlike in the VPN use case in Section 3 or for multiple interfaces aware applications described in Section 4 using IPsec tunnel mode, the IPsec Transport mode does not involves inner IP addresses.
With Transport mode, we may consider two types of applications. The applications that can handle multiple interfaces. This can be done with transport protocols like MPTCP or SCTP or with a connection manager at the application layer. These applications may have Security Associations on all interfaces. Other Applications with a single using TCP/UDP and without specific connection managers may only deal with a single interface and may only have an Security Association associated to this interface.
End User Server
+---------------------+ +----------+
| Applications | | |
| EU @IP_outer1 S @IP_outer1 |
| MPTCP/TCP --------------------------------------
| EU @IP_outer2 S @IP_outer2 |
| --------------------------------------
| EU @IP_outer3 S @IP_outer3 |
| --------------------------------------
| | | |
+---------------------+ +----------+
Figure 12: MIF aware applications with the
Transport mode
In Figure 12, the End User initiates an IKEv2 negotiation using EU @IP_outer1 and S @IP_outer1. The Server provides the End User the available interfaces (S @IP_outer1 i in {1, 2, 3}). Then the End User negotiates Security Associations between the EU @IP_outer(i) and S @IP_outer(i) i in{1,2,3} using different Traffic Selectors.
Currently IKEv2 does not make possible a node to announce its available interfaces.
The Transport mode, does not involve tunnel outer IP addresses. Current Security Association exchange enables Traffic Selectors negotiation. These Traffic Selectors are used both for the Security Policy Index (Traffic Selectors) for outgoing traffic and for the Security Association Index for incoming traffic. Current IKEv2 specification enables to set IPsec as described in figure 11.
In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible
With regular TCP connection a change of the IP address breaks the connection. Applications may use mobility with the Transport mode with transport protocols that handles with multiple interfaces (like MPTCP or SCTP for example), with multiple independent TCP/UDP connections on the different interfaces. The application manages its connections at the application layer.
Mobility with Transport mode MUST be understood as updating an existing Security Association. The purpose of the IPsec Mobility and the Transport mode is to avoid to create a new Security Association when the IP address of an interface is changing. IPsec configures the layer so that the application can securely go on with its communications. TCP connections are restarted, since changing the IP address will most likely break the existing connection. UDP will start sending on the other interface. Mobility is intended to reduce the time IPsec requires to configure its Security Associations.
With the Tunnel mode, IPsec was in charge of securing and transporting IP datagrams. With the Transport mode, IPsec only secures the communication. Transport of the IP datagrams is shared between the application and the transport layer. Application and IPsec layers are independent and have their own way to handle with mobility. Synchronization between these two layers MUST be performed to avoid that the application moves the traffic on an interface whereas IPsec DISCARD this traffic. Although we do not intend to provide a complete list of how to synchronize these two layers, the list below provides some example where these two layers are synchronized:
The mobility scenario we consider in this section is an application using a single interface EU @IP_outer3 for example. As represented in figure 13, this interface is down. Then the End User get assigned a new IP address EU @IP_outer4 and uses this interface as represented in figure 14. Both End User and Server MUST update Security Policies and Security Associations that used EU @IP_outer3 and replace the value with EU @IP_outer4. Unlike the Tunnel mode, Traffic Selectors also need to be updated.
End User Server
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| --------------------------------------
| EU @IP_outer2 SG @IP_outer2 |
| --------------------------------------
| SG @IP_outer3 |
| Application ---x ---------------
| | | |
+---------------------+ +----------+
Figure 13: Mobility with Transport mode and
Multiple Interfaces: EU @IP_outer3
unreachable.
End User Server
+---------------------+ +----------+
| | | |
| EU @IP_outer1 SG @IP_outer1 |
| --------------------------------------
| EU @IP_outer2 SG @IP_outer2 |
| --------------------------------------
| EU @IP_outer4 SG @IP_outer3 |
| Application --------------------------------------
| | | |
+---------------------+ +----------+
Figure 14: Mobility with Transport mode and
Multiple Interfaces: EU @IP_outer4
replaces EU @IP_outer3.
Currently IKEv2 does not provide extension that perform any mobility operation.
MOBIKE has only been designed for the Tunnel mode.
The CREATE_CHILD_SA suffers for limitations exposed in Section 3.2.2: It is not mandatory in IKEv2 implementation, the exchange requires much resources as updating the Security associations. Most of the time, it requires an addition Delete exchange and is a per Security Association exchange. However, because no tunnel IP address requires to be negotiated, the CREATE_CHILD_SA can set the Security Associations and Policies as described in figure 14.
In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible
Multihoming consists in providing Alternate Interfaces in case a running interface is down, so peers are aware of the parameters to update. Multihoming can be seen as pre-configuring an mobility operation.
With Multihoming, when the End User sets its IPsec configuration as illustrated in figure 12, the End User also specifies for each interface the corresponding Alternate IP address. Although this an be done on a per interface value, we suggest that when multiple interfaces are provided, Alternate IP addresses can be derived automatically and assigned to each interface without being explicitly mentioned. Suppose that in the case of figure 13, for example EU @IP_outer2 is provisioned as the Alternate IP address of EU @IP_outer3.
When EU @IP_outer3 is down, then the End User or the Server triggers a mobility exchange as described in section Section 5.2.1.
Currently IKEv2 does not make possible to provision Alternate IP addresses for the Transport mode. MOBIKE has only been designed for the Tunnel mode, then as mentioned in Section 3.3.2, MOBIKE only assigns the Alternate IP address for the IP address used by the IKEv2 channel. This is because MOBIKE has been designed for a single interface.
Note that with the Transport mode, the Alternate Address is provided to the outer IP address that is also used as a Traffic Selector, whereas in the Tunnel mode, the Alternate IP address is provided for the tunnel outer IP address.
Note also that the IKEv2 channel is a special case where Alternate Address is associated to the Transport mode. In fact the IKEv2 channel uses Transport mode, not the Tunnel mode.
In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible to:
Adding an interface works exactly as described in Section 3.4. The only difference is that when an interface is added with the Transport mode, Traffic Selectors will automatically be associated to this newly added interface, which was not necessarily the case with the Tunnel mode.
Similarly to the addition of a new interface, Deleting an interface works exactly as described in Section 3.5. The only difference is that with the Transport mode, Security Associations and Security Policies to delete are these where the specified interface appears as a Traffic Selector rather than as an outer tunnel IP address.
The whole document sets MIF requirements for a security protocol.
There is no IANA consideration here.
We would like to thank Daniel Palomares, Pierrick Seite, Brian Carpenter, Hui Deng, Jong-Hyouk Lee, Juan Carlos Zuniga and Konstantinos Pentikousis for their useful comments.
| [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. |
| [RFC4960] | Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [RFC6182] | Ford, A., Raiciu, C., Handley, M., Barre, S. and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. |
| [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] | Arora, J and P Kumar, "Alternate Tunnel Addresses for IKEv2", Internet-Draft draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00, April 2010. |
| [Cisco] | Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2010-2015", February 2011. | , "
| [Raiciu] | Arora, C, Barre, S, Plunkte, C, Greenhalgh, A, Wischik, D and M Handley, "Improving datacenter performance and robustness with multipath TCP", SIGCOMM 2011 Toronto, Canada, August 2011. |