draft-ietf-ipsecme-ipsec-ha-02.txt   draft-ietf-ipsecme-ipsec-ha-03.txt 
Network Working Group Y. Nir Network Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Informational April 15, 2010 Intended status: Informational May 12, 2010
Expires: October 17, 2010 Expires: November 13, 2010
IPsec High Availability and Load Sharing Problem Statement IPsec High Availability and Load Sharing Problem Statement
draft-ietf-ipsecme-ipsec-ha-02 draft-ietf-ipsecme-ipsec-ha-03
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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on November 13, 2010.
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 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3. The Problem Statement . . . . . . . . . . . . . . . . . . . . 5
3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 6 3.1. Lots of Long Lived State . . . . . . . . . . . . . . . . . 5
3.2. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. IKE Counters . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.3. Outbound SA Counters . . . . . . . . . . . . . . . . . . . 6
3.4. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 7 3.4. Inbound SA Counters . . . . . . . . . . . . . . . . . . . 6
3.5. Missing Synch Messages . . . . . . . . . . . . . . . . . . 8 3.5. Missing Synch Messages . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6.1. Outbound SAs using counter modes . . . . . . . . . . . 9 3.6.1. Outbound SAs using counter modes . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 3.7. Different IP addresses for IKE and IPsec . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. 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 10, line 6 skipping to change at page 9, line 6
3.6.1. Outbound SAs using counter modes 3.6.1. Outbound SAs using counter modes
For SAs involving counter mode ciphers such as [CTR] or [GCM] there For SAs involving counter mode ciphers such as [CTR] or [GCM] there
is yet another complication. The initial vector for such modes must is yet another complication. The initial vector for such modes must
never be repeated, and senders use methods such as counters or LFSRs never be repeated, and senders use methods such as counters or LFSRs
to ensure this. An SA shared between more than one active member, or to ensure this. An SA shared between more than one active member, or
even failing over from one member to another need to make sure that even failing over from one member to another need to make sure that
they do not generate the same initial vector. See [COUNTER_MODES] they do not generate the same initial vector. See [COUNTER_MODES]
for a discussion of this problem in another context. for a discussion of this problem in another context.
3.7. Different IP addresses for IKE and IPsec
In many implementations there are separate IP addresses for the
cluster, and for each member. While the packets protected by tunnel
mode child SAs are encapsulated in IP headers with the cluster IP
address, the IKE packets originate from a specific member, and carry
that member's IP address. For the peer, this looks weird, as the
usual thing is for the IPsec packets to come from the same IP address
as the IKE packets.
One obvious solution, is to use some fancy capability of the IKE host
to change things so that IKE packets also come out of the cluster IP
address. This can be achieved through NAT or through assigning
multiple addresses to interfaces. This is not, however, possible for
all implementations.
[ARORA] discusses this problem in greater depth, and proposes another
solution, that does involve protocol changes.
4. Security Considerations 4. Security Considerations
Implementations running on clusters MUST be as secure as Implementations running on clusters MUST be as secure as
implementations running on single gateways. In other words, no implementations running on single gateways. In other words, no
extension or interpretation used to allow operation in a cluster may extension or interpretation used to allow operation in a cluster may
facilitate attacks that are not possible for single gateways. facilitate attacks that are not possible for single gateways.
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. Acknowledgements 5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
This document is the collective work, and includes contribution from This document is the collective work, and includes contribution from
many people who participate in the IPsecME working group. many people who participate in the IPsecME working group.
The editor would particularly like to acknowledge the extensive The editor would particularly like to acknowledge the extensive
contribution of the following people (in alphabetical order): Dan contribution of the following people (in alphabetical order):
Harkins, Steve Kent, Tero Kivinen, Yaron Sheffer, Melinda Shore, and Jitender Arora, Dan Harkins, Steve Kent, Tero Kivinen, Yaron Sheffer,
Rodney Van Meter. Melinda Shore, and Rodney Van Meter.
6. Change Log 7. Change Log
NOTE TO RFC EDITOR: REMOVE THIS SECTION BEFORE PUBLICATION NOTE TO RFC EDITOR: REMOVE THIS SECTION BEFORE PUBLICATION
Version 00 was identical to draft-nir-ipsecme-ipsecha-ps-00, re-spun Version 00 was identical to draft-nir-ipsecme-ipsecha-ps-00, re-spun
as an WG document. as an WG document.
Version 01 included closing issues 177, 178 and 180, with updates to Version 01 included closing issues 177, 178 and 180, with updates to
terminology, and added discussion of inbound SAs and the CTR issue. terminology, and added discussion of inbound SAs and the CTR issue.
Version 02 includes comments by Yaron Sheffer and the acknowledgement Version 02 includes comments by Yaron Sheffer and the acknowledgement
section. section.
7. Informative References Version 03 fixes some ID-nitsi, and adds the problem presented by
Jitender Arora in [ARORA].
8. Informative References
[ARORA] Arora, J. and P. Kumar, "Alternate Tunnel Addresses for
IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses
(work in progress), April 2010.
[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.
skipping to change at page 11, line 33 skipping to change at page 11, line 15
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[VRRP] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", [VRRP] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004. RFC 5798, March 2010.
[resumption] [resumption]
Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption", Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption",
RFC 5723, January 2010. RFC 5723, January 2010.
Author's Address Author's Address
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
 End of changes. 14 change blocks. 
50 lines changed or deleted 64 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/