Network Working Group Xiangyang Zhang Internet-Draft Intended status: Experimental Futurewei Technologies, Inc Expires: October 1, 2012 April 2, 2012 Multiple Path IP Security draft-zhang-ipsecme-multi-path-ipsec-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. This Internet-Draft will expire on October 1, 2012. Copyright Notice 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. Zhang Expires October 1, 2012 [Page 1] Internet-Draft Multi-Path IPsec April 2012 Abstract This document presents one approach to enhance data protection when transmitting IPsec datagrams across the insecure networks. The method affords the stronger protection to the traffic by splitting it among a set of sub-tunnels. All the Security Associations (SAs) are set up independently for all sub-tunnels. Both the sending and receiving entity combine all the sub-tunnels to one clustered tunnel. As different sub-tunnel uses different crypto key materials and processing parameters, it may achieve the stronger protection of the traffic across the insecure networks. In addition, it could possibly bring more benefits in terms of the network control. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Keyword Definitions . . . . . . . . . . . . . . . . . . . 3 2. Multiple Path IPsec . . . . . . . . . . . . . . . . . . . . . 4 2.1. The SA setup . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. The outbound packet processing . . . . . . . . . . . . . . 5 2.3. The inbound packet processing . . . . . . . . . . . . . . 5 2.4. The SA expiration . . . . . . . . . . . . . . . . . . . . 6 2.5. Multiple paths . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 6 3. The benefit for the SA cluster . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhang Expires October 1, 2012 [Page 2] Internet-Draft Multi-Path IPsec April 2012 1. Introduction IPsec protocols suite specifies the base architecture for IPsec- compliant systems. It describes how to provide a set of security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. It defines security association (SA) as the fundamental concept to IPsec, which defines a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH [RFC4302], or ESP [RFC4303], but not both. If both AH and ESP protection are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. In this case, the local implementation is required to support nested security association, or called "SA bundle" in RFC4301 [RFC4301]. SA bundle increases the management complexity and degrades the IPsec processing performance. Because all the traffics are secured with the same SA bundle (or the same key materials), it is less assured that single SA could not achieve the enough protection in certain environment. Since one SA is used to carry uni-cast traffic, a pair of SAs must be established in point-to-point communication. The two SAs create one uni-cast IPsec tunnel between two security gateways. In order to differentiate different SAs, the Security Parameters Index (SPI), one 32-bit value, is used by a receiver to identify the SA to which an incoming packet should be bound. The SPI assignment is done at the creator of the SA, or usually the receiving side. At the sending side, additional destination IP address information can be used to resolve the SPI conflict. In this way, the sending side can select the correct SA under which IP packet will be processed. For SA bundle, it has nested SAs, which therefore has multiple SPI values. One packet must undergo multiple processing for every SA in the SA bundle. In this document, the new method also makes use of multiple SPIs. Nevertheless, it enhances the security service in different way from SA bundle. 1.1. Keyword Definitions 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 RFC 2119 [RFC2119]. Zhang Expires October 1, 2012 [Page 3] Internet-Draft Multi-Path IPsec April 2012 2. Multiple Path IPsec Data confidentiality is the protection of transmitted data from passive attacks, such as eavesdropping. In current IPsec implementation, all the IP datagrams transmitted inside one IPsec tunnel are afforded protection by one SA (or SA bundle). In order to enhance the confidential security service, we use a set of SAs to protect the traffic. We propose to set up multiple tunnels between two entities and then cluster them together to form one clustered tunnel. Unlike SA bundle, one IP packet is still protected by one single SA instead of nested SAs. The sending entity just splits the traffic among all these SAs. The receiving entity must multiplex the traffic from the different IPsec tunnels. All these tunnels clustered together are termed "sub-tunnels". The SAs for these sub-tunnels are termed "sub-SA". The IP traffic, which should be protected inside one clustered tunnel, is split among all the sub-tunnels. The term "security association cluster", or "SA cluster", is used to describe the combination of SAs through which the traffic must be processed to satisfy a security policy. As multiple sub-tunnels are set up for the same flow of traffic between two secure entities, the physical paths may be different. The processing order of these clustered SAs is only local matter as all these SAs are not nested SAs. -------- R1 -------- / \ / \ +---+-----+ +-------+-----+ Hosts --+-- SGW1 -+ +---- SGW2 ---+-- hosts/router | sequence| | anti-replay | | number | | bitmap | +---+-----+ +-------+-----+ \ / \ / -------- R2 -------- Zhang Expires October 1, 2012 [Page 4] Internet-Draft Multi-Path IPsec April 2012 2.1. The SA setup: The SA cluster setup consists of multiple sub-SA setups. All these sub-tunnels are set up independently. After setup, the sub-tunnel can be added to the cluster one by one. But it is the local matter as how to add the sub-SAs into the SA cluster. All the collaborative sub-tunnels have different SPI values. There is no limitation on how many sub-tunnels can be used for one clustered tunnel. Both the sending entity and receiving entity agree on SA cluster which will be used before any IPsec traffic goes through any of these sub-tunnels. After the traffic flows inside clustered tunnel, new SA can still be able to set up and join the SA cluster. Even though all the sub-tunnels are independent, they share only one sequence number source. The IPsec packet carried inside the clustered tunnel has unique sequence number. 2.2. The outbound packet processing: The sending entity splits or alternates the IPsec traffic through different sub-tunnels. When the SA cluster is selected for the traffic processing based on security policy configuration, one sub-SA is chosen for outbound IPsec processing only for that packet. It is the local implementation that determines which SA should be applied to the specific IP packet. Except that the sequence number is shared among all sub-SAs, all the other processing procedures are not altered. A local implementation at sending entity can choose any method to obtain the sequence number for this packet, which is independent of sub-SA. 2.3. The inbound packet processing: The selection of sub-SA is the same as the selection of single SA, which is based on SPI and IP address information. Except that the sequence number processing is a bit different, all other aspects are not changed. With the use of multiple sub-tunnels, by its nature, it could cause out-of-order delivery of IPsec packets for the secure communication channel between two entities. As the remedy, the sequence number in IPsec header can be used if the receiving entity needs to maintain the sending order. Zhang Expires October 1, 2012 [Page 5] Internet-Draft Multi-Path IPsec April 2012 If anti-replay is enabled, all these sub-tunnels will use one shared anti-replay bitmap at the receiving entity. The anti-replay check is done against the SA cluster instead of sub-SA. But it does not change how anti-replay is done. 2.4. The SA expiration: If sub-SA is negotiated through IKE negotiation, it may have its own soft and hard lifetime. But there is no lifetime for SA cluster. There is no change as to maintenance of each sub-SA. If one sub-SA becomes invalid, it could not be used for further packet processing. If SA cluster does not hold any valid sub-SA, it becomes invalid too. 2.5. Multiple paths All these sub-tunnels are set up independently. The traffic through the different sub-tunnels can go the same route. It can also go the different routes based on the routing policy. The path selection algorithm is out the scope of this document. 2.6. Interoperability In case that SA cluster contains only one sub-SA, it must not have any interoperability issue with the current IPsec implementation if the current one does not support SA cluster. 3. The benefit for SA cluster The method enhances the security service by spreading the traffic onto multiple paths. For example, it makes it harder for the attacker to intercept all the packets if different routes are used. Even with the same route used, it is harder for the attacker to know which set of SAs are clustered SA, thus harder to decrypt the intercepted packets. With multiple paths selected, it provides high reliability especially in case of link failure. It also provides the option for optimized performance and optimal network control, which is not covered in this document. Zhang Expires October 1, 2012 [Page 6] Internet-Draft Multi-Path IPsec April 2012 4. Acknowledgements Wait for comments. 5. Security considerations This document intends to enhance the security service which IPsec provides. Unlike SA bundle, which makes use of the different security protocols (AH or ESP) on the same packet, SA cluster provides the option to perform the different cryptographic transformation on the different packet. In addition, it also provides the option to transmit the packets along the different paths. 6. IANA Considerations None. 7. Normative References 7.1. Normative References [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 7.2. Informative References [RFC4302] "IP Authentication Header", RFC 4302. [RFC4303] "IP Encapsulating Security Payload (ESP)", RFC 4303. Author's address Xiangyang Zhang Futurewei Technologies 2330 Central Expressway Santa Clara, California 95051 USA Phone: +1-408-330-4545 Email: vzhang2008@yahoo.com Zhang Expires October 1, 2012 [Page 7]