| MIF Working Group | D.M. Migault |
| Internet-Draft | Francetelecom - Orange |
| Intended status: Standards Track | C.W. Williams |
| Expires: December 31, 2012 | MCSR Labs |
| July 2012 |
IPsec Multiple Interfaces Requirements
draft-mglt-mif-security-requirements-02.txt
Multiple Interface Nodes (MIF Nodes) may use their Multiple Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes may also manage traffic between these Multiple Interfaces. Because IPsec has not been designed for Multiple Interfaces, MIF Nodes have difficulties to benefit from MIF features with IPsec protected communications.
This document provides use cases where IPsec protected communications would take advantage of MIF features. From these uses cases, we identify the different IPsec features MIF Nodes would require. Then, we expose the limitations of the IPsec related protocols IKEv2 and MOBIKE regarding to these MIF features before listing the MIF IPsec Security Requirements that should be address by a extension of IKEv2 or MOBIKE.
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 December 31, 2012.
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:
IPsec [RFC4301], [RFC5996] and its tunnel mode Mobility and Multihoming extension MOBIKE [RFC4555] have not been designed for Multiple Interface environment. As such MIF Nodes cannot take full advantage of MIF features with IPsec protected communications. In order to may IPsec protected communications compatible with MIF features, IPsec / IKEv2 extensions MUST be designed so:
The following document is structured as follows: Section 4 provides the use cases that motivated this document. This use cases show how IPsec currently do not fit with MIF features. From Section 4, this document identify IPsec MIF features in Section 5. For each feature, this document points how IPsec is impacted. Follows Section 6 with describes the problem statement by showing the current limitation of IKEv2 and MOBIKE protocols over the IPsec MIF features. Finally Section 7 provides the MIF IPsec requirements that should be considered by an IPsec / IKEv2 extension so that IPsec communications can take full advantage of the MIF features.
In this document, we use the following terminology:
Note that IPsec Node, MIF Node, Mobile Node and Correspondent Node are independent designations, and that a given Node can be designated with more than one designation.
This section provides various use cases where MIF nodes would like to take advantage of MIF features for IPsec communications.
Radio Access Network (RAN) are not expected to be able to support the demand for mobile data. As such, ISPs are looking to offload the communications currently supported by RAN to WLAN networks. RAN and WLAN have different characteristics, and the Mobile Node is expected to overcome these differences:
In this section, we consider that the ISP offload Internet Access by providing the Mobile Nodes a Security Gateway as a security entry point to the ISP trusted network. The Mobile Node builds an IPsec tunnel to the Security Gateway. This IPsec tunnel extends the trusted Network over the WLAN untrusted Network, and thus overcome the WLAN untrusted issue.
To overcome the Mobility issue, the Mobile Node is able to update the IP address provided by the WLAN Access Point. Note that in this section, because the communication is tunneled to the Security Gateway, Mobility is performed by updating the outer IP address. The outer IP address is defined by IPsec and so Mobility can be performed by updating the IPsec configuration. Updating the outer IP address of the tunnel results in Hard Handover Mobility and does not require Multiple Interfaces. On the other hand, Soft Handover Mobility requires Multiple Interfaces. Soft Handover Mobility may be performed before the new Interface is available, similarly to the Hard Handover. We note, in this document, UPDATE and SOFT_HAND_OVER the respective Hard Handover and Soft Handover Mobility. On the other hand, Soft Handover may also be performed once the Mobile Node has at least two active Interfaces. In fact, in most cases, the Mobile Node may not know which Interface is going to be used, so it may be wise to use Multiple Interfaces, and provide time to the connection manager to decide which Interfaces are to be used or removed.
In order to take advantage of the Multiple Interfaces, when the Mobile Node detects a new Access Point and is assigned a new IP address, it may be able to select a communication and be able to ADD this Interface to it. Similarly, it also may be able to REMOVE this Interface from the communication.
Note that IPsec is using a ordered Security Policy Database (SPD). Unless the system has been designed with per Interface SPD, the Interface used by the outgoing tunnel is defined by the first SPD match. Outgoing packets with the same IP source and destination will always match a single Security Policy and use the same Interface. As a result, to take full advantage of Multiple Interfaces, SCTP or MPTCP should be used so to enable different source IP. More details are provided in Section 4.2.
In addition to the MPTCP / SCTP Multiple Interface features, the Mobile Node overcome WLAN unreliability with Multihoming and Traffic Selections. Multihoming makes possible the Mobile Node to inform its Correspond Node Alternate IP addresses. These IP addresses MUST be used if the currently used IP address is not reachable anymore. Traffic Selection makes possible connection managers to spread traffic among multiple Interfaces and to select the Access Network for each ongoing communications. SELECTORs are used to define the communication the UPDATE, ADD or REMOVE action is performed.
In this section we consider end-to-end security. With Offloading Internet Access, only the segment between the Mobile Node and the Security Gateway is secured with IPsec. With end-to-end security, the communication from the Mobile Node to the Correspondent Node is secured with IPsec. End-to-end security can be set both with the IPsec tunnel mode or with the IPsec transport mode. Using the IPsec transport mode ovoids the tunnel overhead, and makes the system more dynamic. This makes the IPsec transport mode preferred for applications with real time constraints. Compared to the Security Gateway architecture, end-to-end security avoids routing indirections, makes IPsec platforms deployed on a per services base which eases their load control and resource allocation.
When end-to-end Security is provided with the IPsec tunnel mode, one can refer to Section 4.1.2. In the remaining of this section, we consider the IPsec transport mode is used.
Unlike the Security Gateway architecture that uses the IPsec tunnel mode, the transport mode cannot perform Mobility. Mobility has to be performed by other protocols. SCTP and MPTCP are examples of protocols that may make Mobility possible with Multiple Interfaces. Other mechanisms like session resumption mechanisms can also be performed, for example, at the application layer. These upper layer mechanisms provide the ability to UPDATE, ADD or REMOVE an Interface to a given communication.
Thus, with the IPsec transport mode, IPsec Multiple Interface features should be seen as configuring the IPsec layer so these upper layer mechanisms can be applied on a IPsec protected communication. As a result, our Mobile Node is expected to be able to select an IPsec protected communication identified by its Security Association. For that selected communication, the Mobile Node MUST be able to UPDATE the IP addresses so that Hard Handover Mobility can be performed by upper layer mechanisms. The Mobile is also expected to ADD or REMOVE an Interface so that upper layer mechanisms can perform Mobility Soft Handover or perform traffic management between the various Interfaces.
Companies usually extends their private network by using IPsec VPN. The architecture used for VPN is very similar to the one described in Section 4.1.2. The architecture is the same, that is a Mobile Node tunnels is being assigned a private IP address by the Security Gateway, and the communication between the private destination or private proxy is tunneled in an IPsec tunnel between the untrusted WLAN Access Point to the Security Gateway.
The main difference with the case described in Section 4.1.2, is that WLAN is not considered as an alternative to the Radio Access Network, and the VPN is intentionally initiated by the Mobile Node. Thus, the main use case is an employee located outside its company that set up the VPN to access the company's internal resources from its PC. The Mobile Node as long been expected to be nomadic, rather than Mobile, and MOBIKE addressed this use case with Hard Handover Mobility. MOBIKE has been standardized in 2008, before iPhone has been available (2009), and now VPN end users do not only want to access their companies resources from a nomadic PC but also from Smartphones that have been widely available. Considering Smartphones rather than PCs considerably increases the Mobility Requirements of the today's VPN use case over the one in 2008. More specifically, Smartphones are always connected, and sessions are constantly exchanging packets. During a Hard Handover Mobility, packets may be lost. With an increasing number of sessions, and more and more exchanged data, the number of lost packets make reach the Replay Window counter. If the Security Gateway and the VPN client implements [RFC6311], the VPN client may renegotiate its IPsec counter. This adds an additional negotiation delay to the delay introduced by the lost packets. Without this mechanism the VPN is broken and MUST be re-established. Soft Handover Mobility would reduce the number of lost packets over a Hard Handover Mobility and avoids the client VPN to renegotiate the IPsec counters.
Now, the VPN use case considers taking advantage of Multiple Interfaces in order to perform bandwidth aggregation and Soft Handover Mobility. Similarly to the use case described in Section 4.1.2, when the Mobile Node detects a new Access Point and is assigned a new IP address, it MUST be able to ADD this Interface to the VPN. Similarly, it also MUST be able to REMOVE this Interface from the VPN, to perform a Soft Handover Mobility or a Hard Handover Mobility.
As mentioned in Section 4.1.2, to fully take advantage of the Multiple Interface features, like bandwidth aggregation or Soft Handover Mobility, it is recommended to use protocols like MPTCP in combination with IPsec. However, regular VPN using TCP can still benefit from using Multiple Interfaces.
First, if a Mobile Node is using MPTCP detects a new Interface, it can ADD this new Interface to the MPTCP session. ADDing this Interface to the IPsec layer means that we consider two tunnels one that tunnels the packets from the old interface, and one that considers the packets from the new Interface. Which Interface will be used as the outer IP address will be defined by the Security Association. If the Mobile Node is using TCP, the new Interface cannot be added to the TCP session. Using the two Interfaces would mean that the IPsec Security Association would alternatively use one or the other Interface. This MAY be done by using Security Policy Databases per Interface in conjunction of a traffic load balancer that would balance the traffic between the two Interfaces. However, current system uses a centralized Security Database which is an order database. Security Associations are mainly indexed with IP addresses and ports. In the case of TCP these values does not change, and a single Security Association is chosen, thus making all traffic going to a single Interface. With TCP, ADDing an Interface would mean creating a Security Association that tunnels the TCP session to the new Interface. This Security Association SHOULD have a lower order than the Security Association tunneling the TCP session to the old Interface, which prevent the TCP session to be interrupted during the negotiation. Once set, the Mobile Node is sending the TCP session packet to the old Interface, but is likely to receive IPsec packets on both Interfaces. This is the property we use to perform Soft Handover Mobility by changing the order between the two Security Associations. This prevents packet lost.
Some companies are using IPsec to secure their private network and prevent unauthorized hosts to be connected to the servers. The IPsec property used in that case is the authentication part rather than the confidentiality and encryption part. Similarly end-to-end security is usually using the IPsec transport mode. Resources MAY be accessed by PCs and Smartphones connected over WLAN Access Points.
When these devices are assigned new IP addresses, they currently cannot update their IPsec Security Association and need to re-negotiate a new IPsec Association. Negotiation and authentication interrupts or delay the ongoing session. Updating the IPsec configuration would avoid to perform the re-authentication. Multiple Interface properties would make possible Soft Handover. Currently none of this actions can be performed, and MOBIKE has only considered Mobility Hard Handover for the IPsec tunnel mode.
With Cloud computing, multiple security domains may be hosted on various pieces of hardware connected via IPsec. As a result these different pieces of hardware are exchanging information using multiple IPsec sessions - at least one per security domain. When a piece of hardware is changing its IP address, or when it acquires a additional Interface, it currently needs to renegotiate each IPsec connection separately. With the tunnel mode and MOBIKE, re-authentication can be avoided. MOBIKE makes possible Multihoming, Hard Handover Mobility. All other operations requires a per Security Association negotiation, which may include or not a re-authentication.
In this case, hosts want to be able to update Security Association in IPsec transport mode and in Tunnel mode. Then the hosts want to be able to announce Interface changes in a single announcement, avoiding the per Security Association announcement. On the other hand, load balancing the resources may also require mobility, to be performed only for a subtraffic. Soft Handover Mobility may also be used for traffic management, so the hosts need to be able to select some IPsec communications.
From the different use cases detailed in Section 4, we identify the following IPsec MIF features.
Multihoming is the ability to provision Interfaces in case the running Interface is not reachable anymore. For an IPsec secure communication, the EU wants to provide one or a range of Alternate IP addresses that MUST be used in case the Primary Interface is not reachable. The difference with ADDing an interface to an given communication is that with Multihoming the Alternate MUST be used only if the Primary Interface is not reachable.
On an IPsec point of view, it means that IPsec MUST be configured to DISCARD any packets of the communication unless the Primary Interface is not reachable. When the Primary Interface is not reachable, then IPsec MUST be configured to PROTECT or BYPASS the traffic for the given communication.
Hard handover Mobility is the ability for a host to update an Interface with another.
On an IPsec point of view, Mobility Hard Handover consists in modifying an existing Security Association. More specifically, the IP addresses used as the selectors of the Security Association MUST be modified when the transport mode is used. When the tunnel mode is used, the tunnel IP addresses MUST be modified.
Soft Handover Mobility is the ability for a host to smoothly move traffic from one Interface to the other. Soft Handover requires that the host is able to handle two Interfaces.
On an IPsec point of view, Soft Handover Mobility consists in ADDing an new Security Association that is derived from an existing established Security Association and then REMOVing the existing Security Association.
When the IPsec transport mode is used, Soft Handover MUST be performed in conjunction with upper layer mechanisms like those provided by SCTP, MPTCP or session resumption.
Dynamic addition of an Interface is the ability for a host to send traffic of an ongoing communication to a additional and newly added Interface
On an IPsec point of view, dynamic addition of an Interface requires to create a new Security Association derived from an existing Security Association.
Dynamic removal of an Interface is the ability for a host to configure all its sessions so that traffic is not sent or received from an still existing or not anymore existing Interface.
On an IPsec point of view, this consists of removing all or a subset of Security Association that concerns a given Interface and discarding the traffic sent to or received on this Interface.
Traffic Selection consists in selecting a single, a set or all communications in order to perform an action.
On an IPsec point of view, Traffic Selection consist in selecting a the single, a set or all Security Association associated between two hosts. This makes possible to apply a IPsec action on a given subtraffic as well as to configure multiple Security Associations in a single exchange.
MOBIKE [RFC4555] is the IKEv2 extension that has been designed to handle Mobility and Multihoming. However, it presents the following limitations:
IKEv2 [RFC5996] has been designed to negotiate Security Associations. It has neither been designed to handle Mobility nor Multihoming. Multiple Interface operations like ADD REMOVE and therefore SOFT_HAND_OVER can be considered as a IKEv2 or combinations of IKEv2 operations.
When a new interface is detected by the end user, it may add it to the current communication by negotiating a new Security Association, independent from the Security Associations that already exist. A complete IKEv2 exchange that includes the authentication can be initiated. However, this includes a 4 message exchange, with an authentication that may delay of a few seconds the Security Association negotiation. To avoid re-authentication, the CREATE_CHILD exchange can be used for that purpose. However, the CREATE_CHILD exchange presents the following limitations:
To REMOVE an Interface, IKEv2 provides the DELETE Notify Payload. This exchange is quite straight forward but:
SOFT_HAND_OVER can be considered as a combination of ADD and REMOVE actions. However neither IKEV2 does not provide the ability to perform them with a single message exchange. For performance issues, we want that Soft Handover Mobility can be performed with a single message exchange (SOFT_HAND_OVER).
IKEV2 does not provide the ability to select a set or all Security Associations associated to an Interface. Traffic Selectors are negotiated to define the traffic selectors associated to an Security Association. As a result IKEv2 only provides the granularity for a single Security Association or for all Security Association associated to an IKEv2 channel or IKEv2 session. This granularity does not ease traffic management based on Interfaces.
Finally, MIF requires IPsec /IKEv2 / MOBIKE to be extended so:
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. |
| [RFC6311] | Singh, R., Kalyani, G., Nir, Y., Sheffer, Y. and D. Zhang, "Protocol Support for High Availability of IKEv2/IPsec", RFC 6311, July 2011. |
| [RFC6182] | Ford, A., Raiciu, C., Handley, M., Barre, S. and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. |