idnits 2.17.1 draft-zhang-ipsecme-multi-path-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4301' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'Piratla06' is defined on line 269, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track T. Tsou 5 Expires: April 25, 2013 Futurewei Technologies 6 W. Liu 7 Huawei Technologies 8 October 22, 2012 10 Multiple Path IP Security 11 draft-zhang-ipsecme-multi-path-ipsec-02 13 Abstract 15 This document presents one approach to enhance data protection when 16 transmitting IPsec datagrams across the insecure networks. The 17 method affords the stronger protection to the traffic by splitting it 18 among a set of sub-tunnels. All the Security Associations (SAs) are 19 set up independently for all sub-tunnels. Both the sending and 20 receiving entity combine all the sub-tunnels to one clustered tunnel. 21 As different sub-tunnel uses different crypto key materials and 22 processing parameters, it may achieve the stronger protection of the 23 traffic across the insecure networks. In addition, it could possibly 24 bring more benefits in terms of the network control. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Multiple Path IPsec . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. The SA setup . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. The outbound packet processing . . . . . . . . . . . . . . 4 65 3.3. The inbound packet processing . . . . . . . . . . . . . . . 5 66 3.4. The SA expiration . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. Multiple paths . . . . . . . . . . . . . . . . . . . . . . 5 68 3.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 5 69 3.7. Reorder packets . . . . . . . . . . . . . . . . . . . . . . 6 70 4. The benefit for SA cluster . . . . . . . . . . . . . . . . . . 6 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 IPsec protocols suite specifies the base architecture for IPsec- 82 compliant systems. It describes how to provide a set of security 83 services for traffic at the IP layer, in both the IPv4 and IPv6 84 environments. It defines security association (SA) as the 85 fundamental concept to IPsec, which defines a simplex "connection" 86 that affords security services to the traffic carried by it. 87 Security services are afforded to an SA by the use of AH [RFC4302], 88 or ESP [RFC4303], but not both. If both AH and ESP protection are 89 applied to a traffic stream, then two SAs must be created and 90 coordinated to effect protection through iterated application of the 91 security protocols. 93 Since one SA is used to carry uni-cast traffic, a pair of SAs must be 94 established in point-to-point communication. The two SAs create one 95 uni-cast IPsec tunnel between two security gateways. In order to 96 differentiate different SAs, the Security Parameters Index (SPI), one 97 32-bit value, is used by a receiver to identify the SA to which an 98 incoming packet should be bound. The SPI assignment is done at the 99 creator of the SA, or usually the receiving side. At the sending 100 side, additional destination IP address information can be used to 101 resolve the SPI conflict. In this way, the sending side can select 102 the correct SA under which IP packet will be processed. In this 103 document, the new method also makes use of multiple SPIs. 104 Nevertheless, it enhances the security service in different way from 105 SA. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Multiple Path IPsec 115 Data confidentiality is the protection of transmitted data from 116 passive attacks, such as eavesdropping. In current IPsec 117 implementation, all the IP datagrams transmitted inside one IPsec 118 tunnel are afforded protection by one SA. In order to enhance the 119 confidential security service, we use a set of SAs to protect the 120 traffic. We propose to set up multiple tunnels between two entities 121 and then cluster them together to form one clustered tunnel. One IP 122 packet is still protected by one single SA. The sending entity just 123 splits the traffic among all these SAs. The receiving entity must 124 multiplex the traffic from the different IPsec tunnels. All these 125 tunnels clustered together are termed "sub-tunnels". The SAs for 126 these sub-tunnels are termed "sub-SA". The IP traffic, which should 127 be protected inside one clustered tunnel, is split among all the sub- 128 tunnels. The term "security association cluster", or "SA cluster", 129 is used to describe the combination of SAs through which the traffic 130 must be processed to satisfy a security policy. 132 As multiple sub-tunnels are set up for the same flow of traffic 133 between two secure entities, the physical paths may be different. 134 The processing order of these clustered SAs is only local matter as 135 all these SAs are not nested SAs. 137 -------- R1 -------- 138 / \ 139 / \ 140 +---+-----+ +-------+-----+ 141 Hosts --+-- SGW1 -+ +---- SGW2 ---+-- hosts/router 142 | sequence| | anti-replay | 143 | number | | bitmap | 144 +---+-----+ +-------+-----+ 145 \ / 146 \ / 147 -------- R2 -------- 149 3.1. The SA setup 151 The SA cluster setup consists of multiple sub-SA setups. All these 152 sub-tunnels are set up independently. After setup, the sub-tunnel 153 can be added to the cluster one by one. But it is the local matter 154 as how to add the sub-SAs into the SA cluster. All the collaborative 155 sub-tunnels have different SPI values. There is no limitation on how 156 many sub-tunnels can be used for one clustered tunnel. Both the 157 sending entity and receiving entity agree on SA cluster which will be 158 used before any IPsec traffic goes through any of these sub-tunnels. 159 After the traffic flows inside clustered tunnel, new SA can still be 160 able to set up and join the SA cluster. 162 Even though all the sub-tunnels are independent, they share only one 163 sequence number source. The IPsec packet carried inside the 164 clustered tunnel has unique sequence number. 166 3.2. The outbound packet processing 168 The sending entity splits or alternates the IPsec traffic through 169 different sub-tunnels. When the SA cluster is selected for the 170 traffic processing based on security policy configuration, one sub-SA 171 is chosen for outbound IPsec processing only for that packet. It is 172 the local implementation that determines which SA should be applied 173 to the specific IP packet. Except that the sequence number is shared 174 among all sub-SAs, all the other processing procedures are not 175 altered. A local implementation at sending entity can choose any 176 method to obtain the sequence number for this packet, which is 177 independent of sub-SA. 179 3.3. The inbound packet processing 181 The selection of sub-SA is the same as the selection of single SA, 182 which is based on SPI and IP address information. Except that the 183 sequence number processing is a bit different, all other aspects are 184 not changed. 186 With the use of multiple sub-tunnels, by its nature, it could cause 187 out-of-order delivery of IPsec packets for the secure communication 188 channel between two entities. As the remedy, the sequence number in 189 IPsec header can be used if the receiving entity needs to maintain 190 the sending order. 192 If anti-replay is enabled, all these sub-tunnels will use one shared 193 anti-replay bitmap at the receiving entity. The anti-replay check is 194 done against the SA cluster instead of sub-SA. But it does not 195 change how anti-replay is done. 197 3.4. The SA expiration 199 If sub-SA is negotiated through IKE negotiation, it may have its own 200 soft and hard lifetime. But there is no lifetime for SA cluster. 201 There is no change as to maintenance of each sub-SA. 203 If one sub-SA becomes invalid, it could not be used for further 204 packet processing. If SA cluster does not hold any valid sub-SA, it 205 becomes invalid too. 207 3.5. Multiple paths 209 All these sub-tunnels are set up independently. The traffic through 210 the different sub-tunnels can go the same route. It can also go the 211 different routes based on the routing policy. The path selection 212 algorithm is out the scope of this document. 214 3.6. Interoperability 216 In case that SA cluster contains only one sub-SA, it must not have 217 any interoperability issue with the current IPsec implementation if 218 the current one does not support SA cluster. 220 3.7. Reorder packets 222 The solution of multipath introduces the issue of the possibility of 223 out of order delivery. Actually, this is the only solution which 224 causes the disorder problem. Even with single SA, it can also bring 225 in the out of order problem. Technically, the reorder process be can 226 be done at aggregate node or end host, based on the topology of 227 network, just like TCP reorder or IP reassembly [RFC5236][Zhang02]. 228 The reorder algorithm is out the scope of this document. 230 4. The benefit for SA cluster 232 The method enhances the security service by spreading the traffic 233 onto multiple paths. For example, it makes it harder for the 234 attacker to intercept all the packets if different routes are used. 235 Even with the same route used, it is harder for the attacker to know 236 which set of SAs are clustered SA, thus harder to decrypt the 237 intercepted packets. With multiple paths selected, it provides high 238 reliability especially in case of link failure. It also provides the 239 option for optimized performance and optimal network control, which 240 is not covered in this document. 242 5. Acknowledgements 244 Wait for comments. 246 6. Security Considerations 248 This document intends to enhance the security service which IPsec 249 provides. SA cluster provides the option to perform the different 250 cryptographic transformation on the different packet. In addition, 251 it also provides the option to transmit the packets along the 252 different paths. 254 7. IANA Considerations 256 None. 258 8. References 259 8.1. Normative References 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 265 Internet Protocol", RFC 4301, December 2005. 267 8.2. Informative References 269 [Piratla06] 270 N. M. Piratla, et al., "Reordering of Packets due to 271 Multipath Forwarding - An Analysis", 2006. 273 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 274 December 2005. 276 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 277 RFC 4303, December 2005. 279 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 280 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 281 June 2008. 283 [Zhang02] M. Zhang, et al., "Improving TCP's Performance under 284 Reordering with DSACK", 2002. 286 Authors' Addresses 288 Xiangyang Zhang 289 Juniper Networks 290 1194 N. Mathilda Ave 291 Sunnyvale, CA 94089 292 USA 294 Email: vzhang2008@yahoo.com 296 Tina Tsou 297 Futurewei Technologies 298 2330 Central Expressway 299 Santa Clara, CA 95050 300 USA 302 Phone: +1 408 330 4424 303 Email: tina.tsou.zouting@huawei.com 304 Will Liu 305 Huawei Technologies 306 Bantian, Longgang District 307 Shenzhen 518129 308 P.R. China 310 Email: liushucheng@huawei.com