Multiple Path IP Security
draft-zhang-ipsecme-multi-path-ipsec-01

Network Working Group                                         X. Zhang
Internet-Draft                                                 Juniper  
Intended status: Experimental                                   T.Tsou
Expires: January 14, 2013                  Futurewei Technologies, Inc
                                                                W. Liu
                                                   Huawei Technologies            
                                                         July 13, 2012  
   
   
                      Multiple Path IP Security 
                draft-zhang-ipsecme-multi-path-ipsec-01

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
   Juniper Networks
   1194 N. Mathilda Ave,
   Sunnyvale, CA 94089
   USA
   Phone: 
   Email: vzhang2008@yahoo.com

   Tina Tsou
   Futurewei Technologies
   2330 Central Expressway
   Santa Clara, California  95051
   USA
   Phone: +1-408-859-4996
   Email: tina.tsou.zouting@huawei.com

   Will Liu
   Huawei Technologies
   Bantian, Longgang DIST
   Shenzhen  518129
   P.R. China
   Phone: +86 755 28972315
   Email: liushucheng@huawei.com

Zhang                  Expires October 1, 2012               [Page 7]