doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6027.txt b/doc/rfc/rfc6027.txt
new file mode 100644
index 0000000..811462a
--- /dev/null
+++ b/doc/rfc/rfc6027.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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 a
+   large amount of information to be synchronized among the members of
+   the cluster that it becomes impractical.  Alternatively, if less
+   information is synchronized, failover would mean a prolonged and
+   intensive recovery phase, which negates the scalability and
+   availability promises of using clusters.  In Section 3, we will
+   describe this in more detail.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Terminology
+
+   "Single Gateway" is an implementation of IKE and IPsec enforcing a
+   certain policy, as described in [RFC4301].
+
+   "Cluster" is a set of two or more gateways, implementing the same
+   security policy, and protecting the same domain.  Clusters exist to
+   provide both high availability through redundancy and scalability
+   through load sharing.
+
+   "Member" is one gateway in a cluster.
+
+   "Availability" is a measure of a system's ability to perform the
+   service for which it was designed.  It is measured as the percentage
+   of time a service is available from the time it is supposed to be
+
+
+
+Nir                           Informational                     [Page 3]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   available.  Colloquially, availability is sometimes expressed in
+   "nines" rather than percentage, with 3 "nines" meaning 99.9%
+   availability, 4 "nines" meaning 99.99% availability, etc.
+
+   "High Availability" is a property of a system, not a configuration
+   type.  A system is said to have high availability if its expected
+   down time is low.  High availability can be achieved in various ways,
+   one of which is clustering.  All the clusters described in this
+   document achieve high availability.  What "high" means depends on the
+   application, but usually is 4 to 6 "nines" (at most 0.5-50 minutes of
+   down time per year in a system that is supposed to be available all
+   the time.
+
+   "Fault Tolerance" is a property related to high availability, where a
+   system maintains service availability, even when a specified set of
+   fault conditions occur.  In clusters, we expect the system to
+   maintain service availability, when one or more of the cluster
+   members fails.
+
+   "Completely Transparent Cluster" is a cluster where the occurrence of
+   a fault is never visible to the peers.
+
+   "Partially Transparent Cluster" is a cluster where the occurrence of
+   a fault may be visible to the peers.
+
+   "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of
+   the members is active at any one time.  This member is also referred
+   to as the "active" member, whereas the other(s) are referred to as
+   "standbys".  The Virtual Router Redundancy Protocol (VRRP)
+   ([RFC5798]) is one method of building such a cluster.
+
+   "Load Sharing Cluster", or "LS Cluster" is a cluster where more than
+   one of the members may be active at the same time.  The term "load
+   balancing" is also common, but it implies that the load is actually
+   balanced between the members, and this is not a requirement.
+
+   "Failover" is the event where one member takes over some load from
+   some other member.  In a hot standby cluster, this happens when a
+   standby member becomes active due to a failure of the former active
+   member, or because of an administrator command.  In a load sharing
+   cluster, this usually happens because of a failure of one of the
+   members, but certain load-balancing technologies may allow a
+   particular load (such as all the flows associated with a particular
+   child Security Association (SA)) to move from one member to another
+   to even out the load, even without any failures.
+
+
+
+
+
+
+Nir                           Informational                     [Page 4]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   "Tight Cluster" is a cluster where all the members share an IP
+   address.  This could be accomplished using configured interfaces with
+   specialized protocols or hardware, such as VRRP, or through the use
+   of multicast addresses, but in any case, peers need only be
+   configured with one IP address in the Peer Authentication Database.
+
+   "Loose Cluster" is a cluster where each member has a different IP
+   address.  Peers find the correct member using some method such as DNS
+   queries or the IKEv2 redirect mechanism ([RFC5685]).  In some cases,
+   a member's IP address(es) may be allocated to another member at
+   failover.
+
+   "Synch Channel" is a communications channel among the cluster
+   members, which is used to transfer state information.  The synch
+   channel may or may not be IP based, may or may not be encrypted, and
+   may work over short or long distances.  The security and physical
+   characteristics of this channel are out of scope for this document,
+   but it is a requirement that its use be minimized for scalability.
+
+3.  The Problem Statement
+
+   This section starts by scoping the problem, and goes on to list each
+   of the issues encountered while setting up a cluster of IPsec VPN
+   gateways.
+
+3.1.  Scope
+
+   This document will make no attempt to describe the problems in
+   setting up a generic cluster.  It describes only problems related to
+   the IKE/IPsec protocols.
+
+   The problem of synchronizing the policy between cluster members is
+   out of scope, as this is an administrative issue that is not
+   particular to either clusters or to IPsec.
+
+   The interesting scenario here is VPN, whether inter-domain or remote
+   access.  Host-to-host transport mode is not expected to benefit from
+   this work.
+
+   We do not describe in full the problems of the communication channel
+   between cluster members (the Synch Channel), nor do we intend to
+   specify anything in this space later.  Specifically, mixed-vendor
+   clusters are out of scope.
+
+   The problem statement anticipates possible protocol-level solutions
+   between IKE/IPsec peers in order to improve the availability and/or
+   performance of VPN clusters.  One vendor's IPsec endpoint should be
+   able to work, optimally, with another vendor's cluster.
+
+
+
+Nir                           Informational                     [Page 5]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+3.2.  A Lot of Long-Lived State
+
+   IKE and IPsec have a lot of long-lived state:
+
+   o  IKE SAs last for minutes, hours, or days, and carry keys and other
+      information.  Some gateways may carry thousands to hundreds of
+      thousands of IKE SAs.
+
+   o  IPsec SAs last for minutes or hours, and carry keys, selectors,
+      and other information.  Some gateways may carry hundreds of
+      thousands of such IPsec SAs.
+
+   o  SPD (Security Policy Database) cache entries.  While the SPD is
+      unchanging, the SPD cache changes on the fly due to narrowing.
+      Entries last at least as long as the SAD (Security Association
+      Database) entries, but tend to last even longer than that.
+
+   A naive implementation of a cluster would have no synchronized state,
+   and a failover would produce an effect similar to that of a rebooted
+   gateway.  [RFC5723] describes how new IKE and IPsec SAs can be
+   recreated in such a case.
+
+3.3.  IKE Counters
+
+   We can overcome the first problem described in Section 3.2, by
+   synchronizing states -- whenever an SA is created, we can synch this
+   new state to all other members.  However, those states are not only
+   long lived, they are also ever changing.
+
+   IKE has message counters.  A peer MUST NOT process message n until
+   after it has processed message n-1.  Skipping message IDs is not
+   allowed.  So a newly active member needs to know the last message IDs
+   both received and transmitted.
+
+   One possible solution is to synchronize information about the IKE
+   message counters after every IKE exchange.  This way, the newly
+   active member knows what messages it is allowed to process, and what
+   message IDs to use on IKE requests, so that peers process them.  This
+   solution may be appropriate in some cases, but may be too onerous in
+   systems with a lot of SAs.  It also has the drawback that it never
+   recovers from the missing synch message problem, which is described
+   in Section 3.6.
+
+3.4.  Outbound SA Counters
+
+   The Encapsulating Security Payload (ESP) and Authentication Header
+   (AH) have an optional anti-replay feature, where every protected
+   packet carries a counter number.  Repeating counter numbers is
+
+
+
+Nir                           Informational                     [Page 6]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   considered an attack, so the newly active member MUST NOT use a
+   replay counter number that has already been used.  The peer will drop
+   those packets as duplicates and/or warn of an attack.
+
+   Though it may be feasible to synchronize the IKE message counters, it
+   is almost never feasible to synchronize the IPsec packet counters for
+   every IPsec packet transmitted.  So we have to assume that at least
+   for IPsec, the replay counter will not be up to date on the newly
+   active member, and the newly active member may repeat a counter.
+
+   A possible solution is to synch replay counter information, not for
+   each packet emitted, but only at regular intervals, say, every 10,000
+   packets or every 0.5 seconds.  After a failover, the newly active
+   member advances the counters for outbound IPsec SAs by 10,000
+   packets.  To the peer, this looks like up to 10,000 packets were
+   lost, but this should be acceptable, as neither ESP nor AH guarantee
+   reliable delivery.
+
+3.5.  Inbound SA Counters
+
+   An even tougher issue is the synchronization of packet counters for
+   inbound IPsec SAs.  If a packet arrives at a newly active member,
+   there is no way to determine whether or not this packet is a replay.
+   The periodic synch does not solve this problem at all, because
+   suppose we synchronize every 10,000 packets, and the last synch
+   before the failover had the counter at 170,000.  It is probable,
+   though not certain, that packet number 180,000 has not yet been
+   processed, but if packet 175,000 arrives at the newly active member,
+   it has no way of determining whether or not that packet has already
+   been processed.  The synchronization does prevent the processing of
+   really old packets, such as those with counter number 165,000.
+   Ignoring all counters below 180,000 won't work either, because that's
+   up to 10,000 dropped packets, which may be very noticeable.
+
+   The easiest solution is to learn the replay counter from the incoming
+   traffic.  This is allowed by the standards, because replay counter
+   verification is an optional feature (see Section 3.2 in [RFC4301]).
+   The case can even be made that it is relatively secure, because non-
+   attack traffic will reset the counters to what they should be, so an
+   attacker faces the dual challenge of a very narrow window for attack,
+   and the need to time the attack to a failover event.  Unless the
+   attacker can actually cause the failover, this would be very
+   difficult.  It should be noted, though, that although this solution
+   is acceptable as far as RFC 4301 goes, it is a matter of policy
+   whether this is acceptable.
+
+
+
+
+
+
+Nir                           Informational                     [Page 7]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   Another possible solution to the inbound IPsec SA problem is to rekey
+   all child SAs following a failover.  This may or may not be feasible
+   depending on the implementation and the configuration.
+
+3.6.  Missing Synch Messages
+
+   The synch channel is very likely not to be infallible.  Before
+   failover is detected, some synchronization messages may have been
+   missed.  For example, the active member may have created a new child
+   SA using message n.  The new information (entry in the SAD and update
+   to counters of the IKE SA) is sent on the synch channel.  Still, with
+   every possible technology, the update may be missed before the
+   failover.
+
+   This is a bad situation, because the IKE SA is doomed.  The newly
+   active member has two problems:
+
+   o  It does not have the new IPsec SA pair.  It will drop all incoming
+      packets protected with such an SA.  This could be fixed by sending
+      some DELETEs and INVALID_SPI notifications, if it wasn't for the
+      other problem.
+
+   o  The counters for the IKE SA show that only request n-1 has been
+      sent.  The next request will get the message ID n, but that will
+      be rejected by the peer.  After a sufficient number of
+      retransmissions and rejections, the whole IKE SA with all
+      associated IPsec SAs will get dropped.
+
+   The above scenario may be rare enough that it is acceptable that on a
+   configuration with thousands of IKE SAs, a few will need to be
+   recreated from scratch or using session resumption techniques.
+   However, detecting this may take a long time (several minutes) and
+   this negates the goal of creating a cluster in the first place.
+
+3.7.  Simultaneous Use of IKE and IPsec SAs by Different Members
+
+   For load sharing clusters, all active members may need to use the
+   same SAs, both IKE and IPsec.  This is an even greater problem than
+   in the case of hot standby clusters, because consecutive packets may
+   need to be sent by different members to the same peer gateway.
+
+   The solution to the IKE SA issue is up to the implementation.  It's
+   possible to create some locking mechanism over the synch channel, or
+   else have one member "own" the IKE SA and manage the child SAs for
+   all other members.  For IPsec, solutions fall into two broad
+   categories.
+
+
+
+
+
+Nir                           Informational                     [Page 8]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   The first is the "sticky" category, where all communications with a
+   single peer, or all communications involving a certain SPD cache
+   entry go through a single peer.  In this case, all packets that match
+   any particular SA go through the same member, so no synchronization
+   of the replay counter needs to be done.  Inbound processing is a
+   "sticky" issue (no pun intended), because the packets have to be
+   processed by the correct member based on peer and the Security
+   Parameter Index (SPI), and most load balancers will not be able to
+   match the SPIs to the correct member, unless stickiness extends to
+   all traffic with a particular peer.  Another disadvantage of sticky
+   solutions is that the load tends to not distribute evenly, especially
+   if one SA covers a significant portion of IPsec traffic.
+
+   The second is the "duplicate" category, where the child SA is
+   duplicated for each pair of IPsec SAs for each active member.
+   Different packets for the same peer go through different members, and
+   get protected using different SAs with the same selectors and
+   matching the same entries in the SPD cache.  This has some
+   shortcomings:
+
+   o  It requires multiple parallel SAs, for which the peer has no use.
+      Section 2.8 of [RFC5996] specifically allows this, but some
+      implementation might have a policy against long-term maintenance
+      of redundant SAs.
+
+   o  Different packets that belong to the same flow may be protected by
+      different SAs, which may seem "weird" to the peer gateway,
+      especially if it is integrated with some deep-inspection
+      middleware such as a firewall.  It is not known whether this will
+      cause problems with current gateways.  It is also impossible to
+      mandate against this, because the definition of "flow" varies from
+      one implementation to another.
+
+   o  Reply packets may arrive with an IPsec SA that is not "matched" to
+      the one used for the outgoing packets.  Also, they might arrive at
+      a different member.  This problem is beyond the scope of this
+      document and should be solved by the application, perhaps by
+      forwarding misdirected packets to the correct gateway for deep
+      inspection.
+
+3.7.1.  Outbound SAs Using Counter Modes
+
+   For SAs involving counter mode ciphers such as Counter Mode (CTR)
+   ([RFC3686]) or Galois/Counter Mode (GCM) ([RFC4106]) there is yet
+   another complication.  The initial vector for such modes MUST NOT be
+   repeated, and senders use methods such as counters or linear feedback
+   shift registers (LFSRs) to ensure this.  For an SA shared between
+   more than one active member, or even failing over from one member to
+
+
+
+Nir                           Informational                     [Page 9]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   another, the cluster members need to make sure that they do not
+   generate the same initial vector.  See [COUNTER_MODES] for a
+   discussion of this problem in another context.
+
+3.8.  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.  This may be done so that IPsec traffic
+   bypasses the load balancer for greater scalability.  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.  Unmodified peers may
+   drop such 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, and will not reduce load on the balancer.
+
+   [ARORA] discusses this problem in greater depth, and proposes another
+   solution, that does involve protocol changes.
+
+3.9.  Allocation of SPIs
+
+   The SPI associated with each child SA, and with each IKE SA, MUST be
+   unique relative to the peer of the SA.  Thus, in the context of a
+   cluster, each cluster member MUST generate SPIs in a fashion that
+   avoids collisions (with other cluster members) for these SPI values.
+   The means by which cluster members achieve this requirement is a
+   local matter, outside the scope of this document.
+
+4.  Security Considerations
+
+   Implementations running on clusters MUST be as secure as
+   implementations running on single gateways.  In other words, no
+   extension or interpretation used to allow operation in a cluster may
+   facilitate attacks that are not possible for single gateways.
+
+   Moreover, thought must be given to the synching requirements of any
+   protocol extension to make sure that it does not create an
+   opportunity for denial-of-service attacks on the cluster.
+
+
+
+
+
+
+
+Nir                           Informational                    [Page 10]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   As mentioned in Section 3.5, allowing an inbound child SA to failover
+   to another member has the effect of disabling replay counter
+   protection for a short time.  Though the threat is arguably low, it
+   is a policy decision whether this is acceptable.
+
+   Section 3.7 describes the problem of the two directions of a flow
+   being protected by two SAs that are not part of a matched pair or
+   that are not even being processed by the same cluster member.  This
+   is not a security problem as far as IPsec is concerned because IPsec
+   has policy at the IP, protocol and port level only.  However, many
+   IPsec implementations are integrated with stateful firewalls, which
+   need to see both sides of a flow.  Such implementations may have to
+   forward packets to other members for the firewall to properly inspect
+   the traffic.
+
+5.  Acknowledgements
+
+   This document is the collective work, and includes contribution from
+   many people who participate in the IPsecME working group.
+
+   The editor would particularly like to acknowledge the extensive
+   contribution of the following people (in alphabetical order):
+   Jitender Arora, Jean-Michel Combes, Dan Harkins, David Harrington,
+   Steve Kent, Tero Kivinen, Alexey Melnikov, Yaron Sheffer, Melinda
+   Shore, and Rodney Van Meter.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              September 2010.
+
+6.2.  Informative References
+
+   [ARORA]    Arora, J. and P. Kumar, "Alternate Tunnel Addresses for
+              IKEv2", Work in Progress, April 2010.
+
+
+
+
+
+
+
+Nir                           Informational                    [Page 11]
+
+RFC 6027             IPsec Cluster Problem Statement        October 2010
+
+
+   [COUNTER_MODES]
+              McGrew, D. and B. Weis, "Using Counter Modes with
+              Encapsulating Security Payload (ESP) and Authentication
+              Header (AH) to Protect Group Traffic", Work in Progress,
+              March 2010.
+
+   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
+              Counter Mode", RFC 3686, January 2009.
+
+   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
+              (GCM) in IPsec Encapsulating Security Payload (ESP)",
+              RFC 4106, June 2005.
+
+   [RFC5685]  Devarapalli, V. and K. Weniger, "Redirect Mechanism for
+              IKEv2", RFC 5685, November 2009.
+
+   [RFC5723]  Sheffer, Y. and H. Tschofenig, "IKEv2 Session Resumption",
+              RFC 5723, January 2010.
+
+   [RFC5798]  Nadas, S., "Virtual Router Redundancy Protocol (VRRP)",
+              RFC 5798, March 2010.
+
+Author's Address
+
+   Yoav Nir
+   Check Point Software Technologies Ltd.
+   5 Hasolelim st.
+   Tel Aviv  67897
+   Israel
+
+   EMail: ynir@checkpoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nir                           Informational                    [Page 12]
+