idnits 2.17.1 draft-ietf-ipsecme-ipsec-ha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2010) is 5173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3768 (ref. 'VRRP') (Obsoleted by RFC 5798) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Informational February 25, 2010 5 Expires: August 29, 2010 7 IPsec High Availability and Load Sharing Problem Statement 8 draft-ietf-ipsecme-ipsec-ha-00 10 Abstract 12 This document describes a requirement from IKE and IPsec to allow for 13 more scalable and available deployments for VPNs. It defines 14 terminology for high availability and load sharing clusters 15 implementing IKE and IPsec, and describes gaps in the existing 16 standards. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 29, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Conventions Used in This Document . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. The Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 5 75 3.2. IKE and IPsec Counters . . . . . . . . . . . . . . . . . . 6 76 3.3. Missing Synch Messages . . . . . . . . . . . . . . . . . . 7 77 3.4. Simultaneous use of IKE and IPsec SAs by Different 78 Members . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as 87 described in [RFC4301] and others, allows deployment of VPNs between 88 different sites as well as from VPN clients to protected networks. 90 As VPNs become increasingly important to the organizations deploying 91 them, there is a demand to make IPsec solutions more scalable and 92 less prone to down time, by using more than one physical gateway to 93 either share the load or back each other up. Similar demands have 94 been made in the past for other critical pieces of an organizations's 95 infrastructure, such as DHCP and DNS servers, web servers, databases 96 and others. 98 IKE and IPsec are in particular less friendly to clustering than 99 these other protocols, because they store more state, and that state 100 is more volatile. Section 2 defines terminology for use in this 101 document, and in the envisioned solution documents. 103 In general, deploying IKE and IPsec in a cluster requires such a 104 large amount of information to be synchronized among the members of 105 the cluster, that it becomes impractical. Alternatively, if less 106 information is synchronized, failover would mean a prolonged and 107 intensive recovery phase, which negates the scalability and 108 availability promises of using clusters. In Section 3 we will 109 describe this in more detail. 111 1.1. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Terminology 119 "Single Gateway" is an implementation of IKE and IPsec enforcing a 120 certain policy, as described in [RFC4301]. 122 "Cluster" is a set of two or more gateways, implementing the same 123 security policy, and protecting the same domain. 125 "Member" is one gateway in a cluster. 127 "High Availability Cluster", or "HA Cluster" is a cluster where only 128 one of the members is active at any one time. This member is also 129 referred to as the the "active", whereas the others are referred to 130 as "stand-bys". 132 "Load Sharing Cluster", or "LS Cluster" is a cluster where more than 133 one of the members may be active at the same time. 135 "Failover" is the event where a stand-by member becomes active, and 136 the formerly active member becomes a stand-by. 138 "Tight Cluster" is a cluster where all the members share an IP 139 address. This could be accomplished using configured interfaces with 140 specialized protocols or hardware, such as [VRRP], or through the use 141 of multicast addresses, but in any case, peers need only be 142 configured with one IP address in the PAD. 144 "Loose Cluster" is a cluster where each member has a different IP 145 address. Peers find the correct member using some method such as DNS 146 queries or [REDIRECT]. 148 "Synch Channel" is a communications channel among the cluster 149 members, used to transfer state information. The synch channel may 150 or may not be IP based, may or may not be encrypted, and may work 151 over short or long distances. The security and physical 152 characteristics of this channel are out of scope for this document, 153 but it is a requirement that its use be minimized for scalability. 155 3. The Problem Statement 157 This document will make no attempt to describe the problems in 158 setting up a cluster. The following subsections describe the 159 problems related to the protocol itself. 161 We also ignore the problem of synchronizing the policy between 162 cluster members, as this is an administrative issue that is not 163 particular to either clusters or to IPsec. 165 Note that the interesting scenario here is VPN, whether tunneled 166 site-to-site or remote access. host-to-host transport mode is not 167 expected to benefit from this work. 169 3.1. Lots of Long Lived State 171 IKE and IPsec have a lot of long lived state: 172 o IKE SAs last for minutes, hours, or days, and carry keys and other 173 information. Some gateways may carry thousands to hundreds of 174 thousands of IKE SAs. 175 o IPsec SAs last for minutes or hours, and carry keys, selectors and 176 other information. Some gateways may carry hundreds of thousands 177 such IPsec SAs. 179 o SPD Cache entries. While the SPD is unchanging, the SPD cache 180 changes on the fly due to narrowing. Entries last at least as 181 long as the SAD entries, but tend to last even longer than that 183 A naive implementation of a high availability cluster would have no 184 synchronized state, and a failover would produce an effect similar to 185 that of a rebooted gateway. [resumption] describes how new IKE and 186 IPsec SAs can be recreated in such a case. 188 3.2. IKE and IPsec Counters 190 We can overcome the first problem described in Section 3.1, by 191 synchronizing states - whenever an SA is created, we can share this 192 new state with all other members. There is, however, another 193 problem. Those states are not only long-lived, but they are ever 194 changing. 196 IKE has message counters. A peer may not process message n until 197 after it has processed message n-1. Skipping message IDs is not 198 allowed. So a newly-active member needs to know the last message IDs 199 both received and transmitted. 201 ESP and AH have an anti-replay feature, where every encrypted packet 202 carries a counter number. Repeating counter numbers is considered an 203 attack, so the newly-active member SHOULD NOT use a replay counter 204 number that has already been used. 206 In some cases, it is feasible to synchronize the IKE message counters 207 for every IKE exchange, but it is almost never feasible to 208 synchronize the IPsec message counters for every IPsec packet 209 transmitted or received. So we have to assume that at least for 210 IPsec, the replay counter will not be up-to-date on the newly-active 211 member. 213 A possible solution to the IPsec problem is to send replay counter 214 information not for each packet processed, but only at regular 215 intervals, say, every 10,000 packets. After a failover, the newly- 216 active member advances the counters for outbound SAs by 10,000. To 217 the peer this looks like up to 10,000 packets were lost, but this 218 should be acceptable, as neither ESP nor AH are reliable protocols. 219 This still has the problem of what to do with inbound IPsec packets, 220 for which the newly-active member is unable to determine if they are 221 replayed or not. 223 Another possible solution to the IPsec problem is to rekey all child 224 SAs following a failover. This may or may not be feasible depending 225 on the implementation and the configuration. 227 3.3. Missing Synch Messages 229 The synch channel is very likely not to be infallible. Before 230 failover is detected, some synchronization messages may have been 231 missed. For example, the active member may have created a new Child 232 SA using message n. The new information (entry in the SAD and update 233 to counters of the IKE SA) is sent on the synch channel. Still, with 234 every possible technology, the update may be missed before the 235 failover. 237 This is a bad situation, because the IKE SA is doomed. the newly- 238 active member has two problems: 239 o It does not have the new IPsec SA pair. It will drop all incoming 240 packets protected with such an SA. This could be fixed by sending 241 some DELETEs and INVALID_SPI notifications, if it wasn't for the 242 other problem... 243 o The counters for the IKE SA show that only request n-1 has been 244 sent. The next request will get the message ID n, but that will 245 be rejected by the peer. After a sufficient number of 246 retransmissions and rejections, the whole IKE SA with all 247 associated IPsec SAs will get dropped. 249 The above scenario may be rare enough that it is acceptable that on a 250 configuration with thousands of IKE SAs, a few will need to be 251 recreated from scratch or using session resumption techniques. 252 However, detecting this may take a long time (several minutes) and 253 this negates the goal of creating a high availability cluster in the 254 first place. 256 3.4. Simultaneous use of IKE and IPsec SAs by Different Members 258 For load sharing clusters, all active members may need to use the 259 same SAs, both IKE and IPsec. This is an even greater problem than 260 in the case of HA, because consecutive packets may need to be sent by 261 different members to the same peer gateway. 263 The solution to the IKE SA issue is up to the application. It's 264 possible to create some locking mechanism over the synch channel, or 265 else have one member "own" the IKE SA and manage the child SAs for 266 all other members. For IPsec, solutions fall into two broad 267 categories. 269 The first is the "sticky" category, where all communications with a 270 single peer, or all communications involving a certain SPD cache 271 entry go through a single peer. In this case, all packets that match 272 any particular SA go through the same member, so no synchronization 273 of the replay counter needs to be done. Inbound processing is a 274 "sticky" issue, because the packets have to be processed by the 275 correct member based on peer and SPI. Another issue is that 276 commodity load balancers will not be able to match the SPIs of the 277 encrypted side to the clear traffic, and so the wrong member may get 278 the the other half of the flow. 280 The other way, is to duplicate the child SAs, and have a pair of 281 IPsec SAs for each active member. Different packets for the same 282 peer go through different members, and get protected using different 283 SAs with the same selectors and matching the same entries in the SPD 284 cache. This has some shortcomings: 285 o It requires multiple parallel SAs, which the peer has no use for. 286 Section 2.8 or [RFC4306] specifically allows this, but some 287 implementation might have a policy against long term maintenance 288 of redundant SAs. 289 o Different packets that belong to the same flow may be protected by 290 different SAs, which may seem "weird" to the peer gateway, 291 especially if it is integrated with some deep inspection 292 middleware such as a firewall. It is not known whether this will 293 cause problems with current gateways. It is also impossible to 294 mandate against this, because the definition of "flow" varies from 295 one implementation to another. 296 o Reply packets may arrive with an IPsec SA that is not "matched" to 297 the one used for the outgoing packets. Also, they might arrive at 298 a different member. This problem is beyond the scope of this 299 document and should be solved by the application, perhaps by 300 forwarding misdirected packets to the correct gateway for deep 301 inspection. 303 4. Security Considerations 305 Implementations running on clusters MUST be as secure as 306 implementations running on single gateways. In other words, no 307 extension or interpretation used to allow operation in a cluster may 308 facilitate attacks that are not possible for single gateways. 310 Moreover, thought must be given to the synching requirements of any 311 protocol extension, to make sure that it does not create an 312 opportunity for denial of service attacks on the cluster. 314 5. Change Log 316 This is the first version, re-spun as an WG document 318 6. Informative References 320 [REDIRECT] 321 Devarapalli, V. and K. Weniger, "Redirect Mechanism for 322 IKEv2", draft-ietf-ipsecme-ikev2-redirect (work in 323 progress), August 2009. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 329 Internet Protocol", RFC 4301, December 2005. 331 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 332 RFC 4306, December 2005. 334 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 335 Implementation Guidelines", RFC 4718, October 2006. 337 [VRRP] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 338 RFC 3768, April 2004. 340 [resumption] 341 Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption", 342 draft-ietf-ipsecme-ikev2-resumption (work in progress), 343 June 2009. 345 Author's Address 347 Yoav Nir 348 Check Point Software Technologies Ltd. 349 5 Hasolelim st. 350 Tel Aviv 67897 351 Israel 353 Email: ynir@checkpoint.com