draft-ietf-ipsecme-ipsec-ha-01.txt   draft-ietf-ipsecme-ipsec-ha-02.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Informational April 14, 2010 Intended status: Informational April 15, 2010
Expires: October 16, 2010 Expires: October 17, 2010
IPsec High Availability and Load Sharing Problem Statement IPsec High Availability and Load Sharing Problem Statement
draft-ietf-ipsecme-ipsec-ha-01 draft-ietf-ipsecme-ipsec-ha-02
Abstract Abstract
This document describes a requirement from IKE and IPsec to allow for This document describes a requirement from IKE and IPsec to allow for
more scalable and available deployments for VPNs. It defines more scalable and available deployments for VPNs. It defines
terminology for high availability and load sharing clusters terminology for high availability and load sharing clusters
implementing IKE and IPsec, and describes gaps in the existing implementing IKE and IPsec, and describes gaps in the existing
standards. standards.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 6
3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6 3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6
3.2. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.3. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 7
3.4. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.4. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7
3.5. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8 3.5. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8
3.6. Simultaneous use of IKE and IPsec SAs by Different 3.6. Simultaneous use of IKE and IPsec SAs by Different
Members . . . . . . . . . . . . . . . . . . . . . . . . . 8 Members . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6.1. Outbound SAs using counter modes . . . . . . . . . . . 9 3.6.1. Outbound SAs using counter modes . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Informative References . . . . . . . . . . . . . . . . . . . . 10 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as IKEv2, as described in [RFC4306] and [RFC4718], and IPsec, as
described in [RFC4301] and others, allows deployment of VPNs between described in [RFC4301] and others, allows deployment of VPNs between
different sites as well as from VPN clients to protected networks. different sites as well as from VPN clients to protected networks.
As VPNs become increasingly important to the organizations deploying As VPNs become increasingly important to the organizations deploying
them, there is a demand to make IPsec solutions more scalable and them, there is a demand to make IPsec solutions more scalable and
skipping to change at page 5, line 37 skipping to change at page 5, line 37
balancing" is also common, but it implies that the load is actually 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 balanced between the members, and we don't want to even imply that
this is a requirement. this is a requirement.
"Failover" is the event where a one member takes over some load from "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 some other member. In a hot standby cluster, this hapens when a
standby memeber becomes active due to a failure of the former active standby memeber becomes active due to a failure of the former active
member, or because of an administrator command. In a load sharing member, or because of an administrator command. In a load sharing
cluster this usually happens because of a failure of one of the cluster this usually happens because of a failure of one of the
members, but certain load-balancing technologies may allow a members, but certain load-balancing technologies may allow a
particular load (an SA) to move from one member to another to even particular load (such as all the flows associated with a particular
out the load, even without any failures. 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 "Tight Cluster" is a cluster where all the members share an IP
address. This could be accomplished using configured interfaces with address. This could be accomplished using configured interfaces with
specialized protocols or hardware, such as VRRP, or through the use specialized protocols or hardware, such as VRRP, or through the use
of multicast addresses, but in any case, peers need only be of multicast addresses, but in any case, peers need only be
configured with one IP address in the PAD. configured with one IP address in the PAD.
"Loose Cluster" is a cluster where each member has a different IP "Loose Cluster" is a cluster where each member has a different IP
address. Peers find the correct member using some method such as DNS 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 "Synch Channel" is a communications channel among the cluster
members, used to transfer state information. The synch channel may 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 or may not be IP based, may or may not be encrypted, and may work
over short or long distances. The security and physical over short or long distances. The security and physical
characteristics of this channel are out of scope for this document, characteristics of this channel are out of scope for this document,
but it is a requirement that its use be minimized for scalability. but it is a requirement that its use be minimized for scalability.
3. The Problem Statement 3. The Problem Statement
skipping to change at page 10, line 21 skipping to change at page 10, line 22
Moreover, thought must be given to the synching requirements of any Moreover, thought must be given to the synching requirements of any
protocol extension, to make sure that it does not create an protocol extension, to make sure that it does not create an
opportunity for denial of service attacks on the cluster. opportunity for denial of service attacks on the cluster.
As mentioned in Section 3.4, allowing an inbound child SA to fail As mentioned in Section 3.4, allowing an inbound child SA to fail
over to another member has the effect of disabling replay counter over to another member has the effect of disabling replay counter
protection for a short time. Though the threat is arguably low, it protection for a short time. Though the threat is arguably low, it
is a policy decision whether this is acceptable. 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] [COUNTER_MODES]
McGrew, D. and B. Weis, "Using Counter Modes with McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic", Header (AH) to Protect Group Traffic",
draft-ietf-msec-ipsec-group-counter-modes (work in draft-ietf-msec-ipsec-group-counter-modes (work in
progress), March 2010. progress), March 2010.
[CTR] Housley, R., "Using Advanced Encryption Standard (AES) [CTR] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode", RFC 3686, January 2009. Counter Mode", RFC 3686, January 2009.
 End of changes. 9 change blocks. 
12 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/