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