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]