Network Working Group X. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track T. Tsou
Expires: April 25, 2013 Futurewei Technologies
W. Liu
Huawei Technologies
October 22, 2012
Multiple Path IP Security
draft-zhang-ipsecme-multi-path-ipsec-02
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.
Status of this Memo
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 April 25, 2013.
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
Zhang, et al. Expires April 25, 2013 [Page 1]
Internet-Draft IPsec-multipath October 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multiple Path IPsec . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The SA setup . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The outbound packet processing . . . . . . . . . . . . . . 4
3.3. The inbound packet processing . . . . . . . . . . . . . . . 5
3.4. The SA expiration . . . . . . . . . . . . . . . . . . . . . 5
3.5. Multiple paths . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 5
3.7. Reorder packets . . . . . . . . . . . . . . . . . . . . . . 6
4. The benefit for SA cluster . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zhang, et al. Expires April 25, 2013 [Page 2]
Internet-Draft IPsec-multipath October 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.
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. In this
document, the new method also makes use of multiple SPIs.
Nevertheless, it enhances the security service in different way from
SA.
2. Terminology
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].
3. 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. 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. One IP
packet is still protected by one single SA. 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
Zhang, et al. Expires April 25, 2013 [Page 3]
Internet-Draft IPsec-multipath October 2012
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 --------
3.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.
3.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
Zhang, et al. Expires April 25, 2013 [Page 4]
Internet-Draft IPsec-multipath October 2012
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.
3.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.
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.
3.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.
3.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.
3.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.
Zhang, et al. Expires April 25, 2013 [Page 5]
Internet-Draft IPsec-multipath October 2012
3.7. Reorder packets
The solution of multipath introduces the issue of the possibility of
out of order delivery. Actually, this is the only solution which
causes the disorder problem. Even with single SA, it can also bring
in the out of order problem. Technically, the reorder process be can
be done at aggregate node or end host, based on the topology of
network, just like TCP reorder or IP reassembly [RFC5236][Zhang02].
The reorder algorithm is out the scope of this document.
4. 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.
5. Acknowledgements
Wait for comments.
6. Security Considerations
This document intends to enhance the security service which IPsec
provides. 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.
7. IANA Considerations
None.
8. References
Zhang, et al. Expires April 25, 2013 [Page 6]
Internet-Draft IPsec-multipath October 2012
8.1. Normative References
[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.
8.2. Informative References
[Piratla06]
N. M. Piratla, et al., "Reordering of Packets due to
Multipath Forwarding - An Analysis", 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R.
Whitner, "Improved Packet Reordering Metrics", RFC 5236,
June 2008.
[Zhang02] M. Zhang, et al., "Improving TCP's Performance under
Reordering with DSACK", 2002.
Authors' Addresses
Xiangyang Zhang
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
USA
Email: vzhang2008@yahoo.com
Tina Tsou
Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Zhang, et al. Expires April 25, 2013 [Page 7]
Internet-Draft IPsec-multipath October 2012
Will Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Zhang, et al. Expires April 25, 2013 [Page 8]