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/ |