--- 1/draft-ietf-ipsecme-ipsec-ha-01.txt 2010-04-15 08:11:37.000000000 +0200 +++ 2/draft-ietf-ipsecme-ipsec-ha-02.txt 2010-04-15 08:11:37.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group Y. Nir Internet-Draft Check Point -Intended status: Informational April 14, 2010 -Expires: October 16, 2010 +Intended status: Informational April 15, 2010 +Expires: October 17, 2010 IPsec High Availability and Load Sharing Problem Statement - draft-ietf-ipsecme-ipsec-ha-01 + draft-ietf-ipsecme-ipsec-ha-02 Abstract This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines terminology for high availability and load sharing clusters implementing IKE and IPsec, and describes gaps in the existing standards. Status of this Memo @@ -29,21 +29,21 @@ 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. - This Internet-Draft will expire on October 16, 2010. + This Internet-Draft will expire on October 17, 2010. Copyright Notice Copyright (c) 2010 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 @@ -73,22 +73,23 @@ 3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6 3.2. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.4. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.5. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8 3.6. Simultaneous use of IKE and IPsec SAs by Different Members . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6.1. Outbound SAs using counter modes . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Informative References . . . . . . . . . . . . . . . . . . . . 10 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as described in [RFC4301] and others, allows deployment of VPNs between different sites as well as from VPN clients to protected networks. As VPNs become increasingly important to the organizations deploying them, there is a demand to make IPsec solutions more scalable and @@ -157,32 +158,34 @@ balancing" is also common, but it implies that the load is actually balanced between the members, and we don't want to even imply that this is a requirement. "Failover" is the event where a one member takes over some load from some other member. In a hot standby cluster, this hapens when a standby memeber becomes active due to a failure of the former active member, or because of an administrator command. In a load sharing cluster this usually happens because of a failure of one of the members, but certain load-balancing technologies may allow a - particular load (an SA) to move from one member to another to even - out the load, even without any failures. + particular load (such as all the flows associated with a particular + child SA) to move from one member to another to even out the load, + even without any failures. "Tight Cluster" is a cluster where all the members share an IP address. This could be accomplished using configured interfaces with specialized protocols or hardware, such as VRRP, or through the use of multicast addresses, but in any case, peers need only be configured with one IP address in the PAD. "Loose Cluster" is a cluster where each member has a different IP address. Peers find the correct member using some method such as DNS - queries or [REDIRECT]. + queries or [REDIRECT]. In some cases, members IP addresses may be + allocated to other members at failover. "Synch Channel" is a communications channel among the cluster members, used to transfer state information. The synch channel may or may not be IP based, may or may not be encrypted, and may work over short or long distances. The security and physical characteristics of this channel are out of scope for this document, but it is a requirement that its use be minimized for scalability. 3. The Problem Statement @@ -380,25 +383,44 @@ Moreover, thought must be given to the synching requirements of any protocol extension, to make sure that it does not create an opportunity for denial of service attacks on the cluster. As mentioned in Section 3.4, allowing an inbound child SA to fail over to another member has the effect of disabling replay counter protection for a short time. Though the threat is arguably low, it is a policy decision whether this is acceptable. -5. Change Log +5. Acknowledgements - This is the first version, re-spun as an WG document + This document is the collective work, and includes contribution from + many people who participate in the IPsecME working group. -6. Informative References + The editor would particularly like to acknowledge the extensive + contribution of the following people (in alphabetical order): Dan + Harkins, Steve Kent, Tero Kivinen, Yaron Sheffer, Melinda Shore, and + Rodney Van Meter. + +6. Change Log + + NOTE TO RFC EDITOR: REMOVE THIS SECTION BEFORE PUBLICATION + + Version 00 was identical to draft-nir-ipsecme-ipsecha-ps-00, re-spun + as an WG document. + + Version 01 included closing issues 177, 178 and 180, with updates to + terminology, and added discussion of inbound SAs and the CTR issue. + + Version 02 includes comments by Yaron Sheffer and the acknowledgement + section. + +7. Informative References [COUNTER_MODES] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", draft-ietf-msec-ipsec-group-counter-modes (work in progress), March 2010. [CTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode", RFC 3686, January 2009.