IPsec Cluster Problem Statement
RFC 6027
|
| Document |
Type |
|
RFC - Informational
(October 2010; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6027 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Sean Turner
|
|
Send notices to |
|
(None)
|
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6027 Check Point
Category: Informational October 2010
ISSN: 2070-1721
IPsec Cluster Problem Statement
Abstract
This document defines the terminology, problem statement, and
requirements for implementing Internet Key Exchange (IKE) and IPsec
on clusters. It also describes gaps in existing standards and their
implementation that need to be filled in order to allow peers to
interoperate with clusters from different vendors. Agreed upon
terminology, problem statement, and requirements will allow IETF
working groups to consider development of IPsec/IKEv2 mechanisms to
simplify cluster implementations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6027.
Nir Informational [Page 1]
RFC 6027 IPsec Cluster Problem Statement October 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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Terminology .....................................................3
3. The Problem Statement ...........................................5
3.1. Scope ......................................................5
3.2. A Lot of Long-Lived State ..................................6
3.3. IKE Counters ...............................................6
3.4. Outbound SA Counters .......................................6
3.5. Inbound SA Counters ........................................7
3.6. Missing Synch Messages .....................................8
3.7. Simultaneous Use of IKE and IPsec SAs by Different
Members ....................................................8
3.7.1. Outbound SAs Using Counter Modes ....................9
3.8. Different IP Addresses for IKE and IPsec ..................10
3.9. Allocation of SPIs ........................................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................11
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Nir Informational [Page 2]
RFC 6027 IPsec Cluster Problem Statement October 2010
1. Introduction
IKEv2, as described in [RFC5996], 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
less prone to down time, by using more than one physical gateway to
either share the load or back each other up, forming a "cluster" (see
Section 2). Similar demands have been made in the past for other
critical pieces of an organization's infrastructure, such as DHCP and
DNS servers, Web servers, databases, and others.
IKE and IPsec are, in particular, less friendly to clustering than
these other protocols, because they store more state, and that state
Show full document text