IPsec Cluster Problem Statement
RFC 6027
Document | Type | RFC - Informational (October 2010; No errata) | |
---|---|---|---|
Author | Yoav Nir | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6027 (Informational) | |
Action Holders |
(None)
|
||
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 is more volatile. Section 2 defines terminology for use in this document and in the envisioned solution documents. In general, deploying IKE and IPsec in a cluster requires such aShow full document text