GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6311

Internet Engineering Task Force (IETF) R. Singh, Ed. Request for Comments: 6311 G. Kalyani Category: Standards Track Cisco ISSN: 2070-1721 Y. Nir

                                                           Check Point
                                                            Y. Sheffer
                                                              Porticor
                                                              D. Zhang
                                                                Huawei
                                                             July 2011
       Protocol Support for High Availability of IKEv2/IPsec

Abstract

 The IPsec protocol suite is widely used for business-critical network
 traffic.  In order to make IPsec deployments highly available, more
 scalable, and failure-resistant, they are often implemented as IPsec
 High Availability (HA) clusters.  However, there are many issues in
 IPsec HA clustering, and in particular in Internet Key Exchange
 Protocol version 2 (IKEv2) clustering.  An earlier document, "IPsec
 Cluster Problem Statement", enumerates the issues encountered in the
 IKEv2/IPsec HA cluster environment.  This document resolves these
 issues with the least possible change to the protocol.
 This document defines an extension to the IKEv2 protocol to solve the
 main issues of "IPsec Cluster Problem Statement" in the commonly
 deployed hot standby cluster, and provides implementation advice for
 other issues.  The main issues solved are the synchronization of
 IKEv2 Message ID counters, and of IPsec replay counters.

Status of This Memo

 This is an Internet Standards Track document.
 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).  Further information on
 Internet Standards is available in 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/rfc6311.

Singh, et al. Standards Track [Page 1] RFC 6311 High Availability in IKEv2/IPsec July 2011

Copyright Notice

 Copyright (c) 2011 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.

Singh, et al. Standards Track [Page 2] RFC 6311 High Availability in IKEv2/IPsec July 2011

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................5
 3. Issues Resolved from IPsec Cluster Problem Statement ............7
    3.1. Large Amount of State ......................................8
    3.2. Multiple Members Using the Same SA .........................9
    3.3. Avoiding Collisions in SPI Number Allocation ...............9
    3.4. Interaction with Counter Modes .............................9
 4. The IKEv2/IPsec SA Counter Synchronization Problem .............10
 5. SA Counter Synchronization Solution ............................11
    5.1. Processing Rules for IKE Message ID Synchronization .......13
    5.2. Processing Rules for IPsec Replay Counter
         Synchronization ...........................................14
 6. IKEv2/IPsec Synchronization Notification Payloads ..............14
    6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ..........15
    6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification ......15
    6.3. The IKEV2_MESSAGE_ID_SYNC Notification ....................16
    6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification ................16
 7. Implementation Details .........................................17
 8. IKE SA and IPsec SA Message Sequencing .........................18
    8.1. Handling of Pending IKE Messages ..........................18
    8.2. Handling of Pending IPsec Messages ........................18
    8.3. IKE SA Inconsistencies ....................................19
 9. Step-by-Step Details ...........................................19
 10. Interaction with Other Specifications .........................20
 11. Security Considerations .......................................21
 12. IANA Considerations ...........................................21
 13. Acknowledgements ..............................................22
 14. References ....................................................22
    14.1. Normative References .....................................22
    14.2. Informative References ...................................22
 Appendix A. IKEv2 Message ID Sync Examples ........................24
   A.1. Normal Failover -- Example 1 ...............................24
   A.2. Normal Failover -- Example 2 ...............................24
   A.3. Normal Failover -- Example 3 ...............................25
   A.4. Simultaneous Failover ......................................25

1. Introduction

 The IPsec protocol suite, including the Internet Key Exchange
 Protocol version 2 (IKEv2), is a major building block of virtual
 private networks (VPNs).  In order to make such VPNs highly
 available, more scalable, and failure-resistant, these VPNs are
 implemented as IKEv2/IPsec Highly Available (HA) clusters.  However,

Singh, et al. Standards Track [Page 3] RFC 6311 High Availability in IKEv2/IPsec July 2011

 there are many issues with the IKEv2/IPsec HA cluster.  Sections 3
 and 4 below expand on the issues around the IKEv2/IPsec HA cluster
 solution, issues which were first described in the problem
 statement [6].
 In the case of a hot standby cluster implementation of IKEv2/
 IPsec-based VPNs, the IKEv2/IPsec session is first established
 between the peer and the active member of the cluster.  Later, the
 active member continuously syncs/updates the IKE/IPsec security
 association (SA) state to the standby member of the cluster.  This
 primary SA state sync-up takes place upon each SA bring-up and/or
 rekey.  Performing the SA state synchronization/update for every
 single IKE and IPsec message is very costly, so normally it is done
 periodically.  As a result, when the failover event happens, this is
 first detected by the standby member and, possibly after a
 considerable amount of time, it becomes the active member.  During
 this failover process, the peer is unaware of the failover event, and
 keeps sending IKE requests and IPsec packets to the cluster, as in
 fact it is allowed to do because of the IKEv2 windowing feature.
 After the newly active member starts, it detects the mismatch in IKE
 Message ID values and IPsec replay counters and needs to resolve this
 situation.  Please see Section 4 for more details of the problem.
 This document defines an extension to the IKEv2 protocol to solve the
 main issues of IKE Message ID synchronization and IPsec SA replay
 counter synchronization, and gives implementation advice to address
 other issues.  Following is a summary of the solutions provided in
 this document:
 o  IKEv2 Message ID synchronization: This is done by syncing up the
    expected send and receive Message ID values with the peer, and
    updating the values at the newly active cluster member.
 o  IPsec replay counter synchronization: This is done by incrementing
    the cluster's outgoing SA replay counter values by a "large"
    number; in addition, the newly active member requests the peer to
    increment the replay counter values it is using for the peer's
    outgoing traffic.
 Although this document describes the IKEv2 Message ID and IPsec
 replay counter synchronization in the context of an IPsec HA cluster,
 the solution provided is generic and can be used in other scenarios
 where IKEv2 Message ID or IPsec SA replay counter synchronization may
 be required.

Singh, et al. Standards Track [Page 4] RFC 6311 High Availability in IKEv2/IPsec July 2011

 Implementations differ on the need to synchronize the IKEv2 Message
 ID and/or IPsec replay counters.  Both of these problems are handled
 separately, using a separate notification for each capability.  This
 provides the flexibility of implementing either or both of these
 solutions.

2. Terminology

 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 [1].
 "SA Counter Synchronization" is the informational exchange defined in
 this document to synchronize the IKEv2/IPsec SA counter information
 between one member of the cluster and the peer.
 Some of the terms listed below are reused from [6] with further
 clarification in the context of the current document.
 o  "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 "standby" members.  The Virtual Router Redundancy
    Protocol (VRRP) [7] is one method of building such a cluster.  The
    goal of the hot standby cluster is to create the illusion of a
    single virtual gateway to the peer(s).
 o  "Active Member" is the primary member in the hot standby cluster.
    It is responsible for forwarding packets on behalf of the virtual
    gateway.
 o  "Standby Member" is the primary backup member.  This member takes
    control, i.e., becomes the active member, after the failover
    event.
 o  "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec
    connection with the hot standby cluster.  The peer identifies the
    cluster by the cluster's (single) IP address.  If a failover event
    occurs, the standby member of the cluster becomes active, and the
    peer normally doesn't notice that failover has taken place.
    Although we treat the peer as a single entity, it may also be a
    cluster.

Singh, et al. Standards Track [Page 5] RFC 6311 High Availability in IKEv2/IPsec July 2011

 o  "Multiple failover" is the situation where, in a cluster with
    three or more members, multiple failover events happen in rapid
    succession, e.g., from M1 to M2, and then to M3.  It is our goal
    that the implementation should be able to handle this situation,
    i.e., to handle the new failover event even if it is still
    processing the old failover.
 o  "Simultaneous failover" is the situation where two clusters have
    an IPsec connection between them, and failover happens at both
    ends at the same time.  It is our goal that implementations should
    be able to handle simultaneous failover.
 o  "IPsec replay counter" is the Encapsulating Security Payload (ESP)
    Sequence Number or Extended Sequence Number (Section 2.2 of [2]),
    or the respective field in the Authentication Header (AH) protocol
    (Section 2.5 of [3]).
 The generic term "IKEv2/IPsec SA Counters" is used throughout this
 document.  This term refers to both IKEv2 Message ID counters and
 IPsec replay counters.  According to the IPsec standards, the IKEv2
 Message ID counter is mandatory, and used to ensure reliable delivery
 as well as to protect against message replay in IKEv2; the IPsec SA
 replay counters are optional, and are used to provide the IPsec anti-
 replay feature.

Singh, et al. Standards Track [Page 6] RFC 6311 High Availability in IKEv2/IPsec July 2011

 Some of these terms are used in the following architectural diagram.
                                                 +---------------+
                                                 |               |
                                                 | Hot Standby   |
                                                 |   Cluster     |
                                                 |               |
                                                 |   +---------+ |
                                                 |   |         | |
                                                 |   | Active  | |
                                                 |   |         | |
                                                 |   | Member  | |
                                                 |   |         | |
                                                 |   +---------+ |
                                                 |          ^    |
     +---------+                                 |  Synch   |    |
     |         |                                 |  Channel |    |
     |  IPsec  |       IKE/IPsec Traffic         |          |    |
     |         | <=============================> |          |    |
     |   Peer  |                                 |          |    |
     |         |                                 |          |    |
     +---------+                                 |          |    |
                                                 |          v    |
                                                 |   +---------+ |
                                                 |   |         | |
                                                 |   | Standby | |
                                                 |   |         | |
                                                 |   | Member  | |
                                                 |   |         | |
                                                 |   +---------+ |
                                                 +---------------+
                     An IPsec Hot Standby Cluster

3. Issues Resolved from IPsec Cluster Problem Statement

 "IPsec Cluster Problem Statement" [6] enumerates the problems raised
 by IPsec clusters.  The following table lists the problem statement's
 sections that are resolved by this document.
 o  3.2.  A Lot of Long-Lived State
 o  3.3.  IKE Counters
 o  3.4.  Outbound SA Counters
 o  3.5.  Inbound SA Counters
 o  3.6.  Missing Synch Messages

Singh, et al. Standards Track [Page 7] RFC 6311 High Availability in IKEv2/IPsec July 2011

 o  3.7.  Simultaneous Use of IKE and IPsec SAs by Different Members
    *  3.7.1.  Outbound SAs Using Counter Modes
 o  3.8.  Different IP Addresses for IKE and IPsec
 o  3.9.  Allocation of SPIs
 The main problem areas are solved using the protocol extension
 defined below, starting with Section 5; additionally, this section
 provides implementation advice for other issues in the following
 subsections.  Implementers should note that these subsections include
 a number of new security-critical requirements.

3.1. Large Amount of State

 Section 3.2 of the problem statement [6] mentions that a lot of state
 needs to be synchronized for a cluster to be transparent.  The actual
 volume of that data is very much implementation-dependent, and even
 for the same implementation, the amounts of data may vary wildly.  An
 IPsec gateway used for inter-domain VPN with a dozen other gateways,
 and having SAs that are rekeyed every 8 hours, will need a lot less
 synchronization traffic than a similar gateway used for remote
 access, and supporting 10,000 clients.  This is because counter
 synchronization is proportional to the number of SAs and requires
 little data, and the setting up of an SA requires a lot of data.
 Additionally, remote access IKE and IPsec SA setup tend to happen at
 a particular time of day, so the example gateway with the 10,000
 clients may see 30-50 IKE SA setups per second at 9:00 AM.  This
 would require very heavy synchronization traffic over that short
 period of time.
 If a large volume of traffic is necessary, it may be advisable to use
 a dedicated high-speed network interface for synch traffic.  When
 packet loss can be made extremely low, it may be advisable to use a
 stateless transport such as UDP, to minimize network overhead.
 If these methods are insufficient, it may be prudent that for some
 SAs the entire state is not synchronized.  Instead, only an
 indication of the SA's existence is synchronized.  This, in
 combination with a sticky solution (as described in Section 3.7 of
 the problem statement [6]) ensures that the traffic from a particular
 peer does not reach a different member before an actual failover
 happens.  When that happens, the method described in [8] can be used
 to quickly force the peer to set up a new SA.

Singh, et al. Standards Track [Page 8] RFC 6311 High Availability in IKEv2/IPsec July 2011

3.2. Multiple Members Using the Same SA

 In a load-sharing cluster of the "duplicate" variety (see Section 3.7
 of the problem statement [6]), multiple members may need to send
 traffic with the same selectors.  To actually use the same SA, the
 cluster would have to synchronize the replay counter after every
 packet, and that would impose unreasonable requirements on the synch
 connection.
 A far better solution would be to not synchronize the outbound SA,
 and create multiple outbound SAs, one for each member.  The problem
 with this option is that the peer might view these multiple parallel
 SAs as redundant, and tear down all but one of them.
 Section 2.8 of [4] specifically allows multiple parallel SAs, but the
 reason given for this is to have multiple SAs with different Quality
 of Service (QoS) attributes.  So while this is not a new requirement
 of IKEv2 implementations working with QoS, we re-iterate here that
 IPsec peers MUST accept the long-term existence of multiple parallel
 SAs, even when QoS mechanisms are not in use.

3.3. Avoiding Collisions in SPI Number Allocation

 Section 3.9 of the problem statement [6] describes the problem of two
 cluster members allocating the same Security Parameter Index (SPI)
 number for two different SAs.  This behavior would violate
 Section 4.4.2.1 of [5].  There are several schemes to allow
 implementations to avoid such collisions, such as partitioning the
 SPI space, a request-response over the synch channel, and locking
 mechanisms.  We believe that these are sufficiently robust and
 available so that we don't need to make an exception to the rules in
 Section 4.4.2.1 of RFC 4301 [5], and we can leave this problem for
 the implementations to solve.  Cluster members must not generate
 multiple inbound SAs with the same SPI.

3.4. Interaction with Counter Modes

 For SAs involving counter mode ciphers such as Counter Mode (CTR) [9]
 or Galois/Counter Mode (GCM) [10], there is yet another complication.
 The initial vector for such modes MUST NOT be repeated, and senders
 may use methods such as counters or linear feedback shift registers
 (LFSRs) to ensure this property.  For an SA shared between multiple
 active members (load-sharing cases), implementations MUST ensure that
 no initial vector is ever repeated.  Similar concerns apply to an SA
 failing over from one member to another.  See [11] for a discussion
 of this problem in another context.

Singh, et al. Standards Track [Page 9] RFC 6311 High Availability in IKEv2/IPsec July 2011

 Just as in the SPI collision problem, there are ways to avoid a
 collision of initial vectors, and this is left up to implementations.
 In the context of load sharing, parallel SAs are a simple solution to
 this problem as well.

4. The IKEv2/IPsec SA Counter Synchronization Problem

 The IKEv2 protocol [4] states that "An IKE endpoint MUST NOT exceed
 the peer's stated window size for transmitted IKE requests".
 All IKEv2 messages are required to follow a request-response
 paradigm.  The initiator of an IKEv2 request MUST retransmit the
 request, until it has received a response from the peer.  IKEv2
 introduces a windowing mechanism that allows multiple requests to be
 outstanding at a given point of time, but mandates that the sender's
 window should not move until the oldest message it has sent is
 acknowledged.  Loss of even a single message leads to repeated
 retransmissions followed by an IKEv2 SA teardown if the
 retransmissions remain unacknowledged.
 An IPsec hot standby cluster is required to ensure that in the case
 of failover, the standby member becomes active immediately.  The
 standby member is expected to have the exact value of the Message ID
 counter as the active member had before failover.  Even assuming the
 best effort to update the Message ID values from active to standby
 member, the values at the standby member can still be stale due to
 the following reasons:
 o  The standby member is unaware of the last message that was
    received and acknowledged by the previously active member, as the
    failover event could have happened before the standby member could
    be updated.
 o  The standby member does not have information about on-going
    unacknowledged requests sent by the previously active member.  As
    a result, after the failover event, the newly active member cannot
    retransmit those requests.
 When a standby member takes over as the active member, it can only
 initialize the Message ID values from the previously updated values.
 This would make it reject requests from the peer when these values
 are stale.  Conversely, the standby member may end up reusing a stale
 Message ID value, which would cause the peer to drop the request.
 Eventually, there is a high probability of the IKEv2 and
 corresponding IPsec SAs getting torn down simply because of a
 transitory Message ID mismatch and retransmission of requests,
 negating the benefits of the high-availability cluster despite the
 periodic update between the cluster members.

Singh, et al. Standards Track [Page 10] RFC 6311 High Availability in IKEv2/IPsec July 2011

 A similar issue is also observed with IPsec anti-replay counters if
 anti-replay protection is enabled, which is commonly the case.
 Regardless of how well the ESP and AH SA counters are synchronized
 from the active to the standby member, there is a chance that the
 standby member would end up with stale counter values.  The standby
 member would then use those stale counter values when sending IPsec
 packets.  The peer would drop such packets, since when the anti-
 replay protection feature is enabled, duplicate use of counters is
 not allowed.  Note that IPsec allows the sender to skip some counter
 values and continue sending with higher counter values.
 We conclude that a mechanism is required to ensure that the standby
 member has correct Message ID and IPsec counter values when it
 becomes active, so that sessions are not torn down as a result of
 mismatched counters.

5. SA Counter Synchronization Solution

 This document defines two separate approaches to resolving the issues
 of mismatched IKE Message ID values and IPsec counter values.
 o  In the case of IKE Message ID values, the newly active cluster
    member and the peer negotiate a pair of new values so that future
    IKE messages will not be dropped.
 o  For IPsec counter values, the newly active member and the peer
    both increment their respective counter values, "skipping forward"
    by a large number, to ensure that no IPsec counters are ever
    reused.
 Although conceptually separate, the two synchronization processes
 would typically take place simultaneously.
 First, the peer and the active member of the cluster negotiate their
 ability to support IKEv2 Message ID synchronization and/or IPsec
 replay counter synchronization.  This is done by exchanging one or
 both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and
 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH
 exchange.  When negotiating these capabilities, the responder MUST
 NOT assert support of a capability unless such support was asserted
 by the initiator.  Only a capability whose support was asserted by
 both parties can be used during the lifetime of the SA.  The peer's
 capabilities with regard to this extension are part of the IKEv2 SA
 state, and thus MUST be shared between the cluster members.
 This per-IKE SA information is shared with the other cluster members.

Singh, et al. Standards Track [Page 11] RFC 6311 High Availability in IKEv2/IPsec July 2011

 Peer                                                  Active Member
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
      [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
      [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
      SAi2, TSi, TSr} ---------->
 <-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
                [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
                [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
                SAr2, TSi, TSr}
 After a failover event, the standby member MAY use the IKE Message ID
 and/or IPsec replay counter synchronization capability when it
 becomes the active member, and provided support for the capabilities
 used has been negotiated.  Following that, the peer MUST respond to
 any synchronization message it receives from the newly active cluster
 member, subject to the rules noted below.
 After the failover event, when the standby member becomes active, it
 has to synchronize its SA counters with the peer.  There are now four
 possible cases:
 1.  The cluster member wishes to only perform IKE Message ID value
     synchronization.  In this case, it initiates an Informational
     exchange, with Message ID zero and the sole notification
     IKEV2_MESSAGE_ID_SYNC.
 2.  If the newly active member wishes to perform only IPsec replay
     counter synchronization, it generates a regular IKEv2
     Informational exchange using the current Message ID values, and
     containing the IPSEC_REPLAY_COUNTER_SYNC notification.
 3.  If synchronization of both counters is needed, the cluster member
     generates a zero-Message ID message as in case #1, and includes
     both notifications in this message.
 4.  Lastly, the peer may not support this extension.  This is known
     to the newly active member (because the cluster members must
     share this information, as noted earlier).  This case is the
     existing IKEv2 behavior, and the IKE and IPsec SAs may or may not
     survive the failover, depending on the exact state on the peer
     and the cluster member.
 This figure contains the IKE message exchange used for SA counter
 synchronization.  The following subsections describe the details of
 the sender and receiver processing of each message.

Singh, et al. Standards Track [Page 12] RFC 6311 High Availability in IKEv2/IPsec July 2011

 Standby [Newly Active] Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
      [N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
              <--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}
 Alternatively, if only IPsec replay counter synchronization is
 desired, a normal Informational exchange is used, where the Message
 ID is non-zero:
 Standby [Newly Active] Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->
              <--------- HDR

5.1. Processing Rules for IKE Message ID Synchronization

 The newly active member sends a request containing two counter
 values, one for the member (itself) and another for the peer, as well
 as a random nonce.  We denote the values M1 and P1.  The peer
 responds with a message containing two counter values, M2 and P2
 (note that the values appear in the opposite order in the
 notification's payload).  The goal of the rules below is to prevent
 an attacker from replaying a synchronization message and thereby
 invalidating IKE messages that are currently in process.
 o  M1 is the next sender's Message ID to be used by the member.  M1
    MUST be chosen so that it is larger than any value known to have
    been used.  It is RECOMMENDED to increment the known value at
    least by the size of the IKE sender window.
 o  P1 SHOULD be 1 more than the last Message ID value received from
    the peer, but may be any higher value.
 o  The member SHOULD communicate the sent values to the other cluster
    members, so that if a second failover event takes place, the
    synchronization message is not replayed.  Such a replay would
    result in the eventual deletion of the IKE SA (see below).
 o  The peer MUST silently drop any received synchronization message
    if M1 is lower than or equal to the highest value it has seen from
    the cluster.  This includes any previous received synchronization
    messages.

Singh, et al. Standards Track [Page 13] RFC 6311 High Availability in IKEv2/IPsec July 2011

 o  M2 MUST be at least the higher of the received M1, and one more
    than the highest sender value received from the cluster.  This
    includes any previous received synchronization messages.
 o  P2 MUST be the higher of the received P1 value, and one more than
    the highest sender value used by the peer.
 o  The request contains a Nonce field.  This field MUST be returned
    in the response, unchanged.  A response MUST be silently dropped
    if the received nonce does not match the one that was sent.
 o  Both the request and the response MUST NOT contain any additional
    payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC
    notification in the request.
 o  The request and the response MUST both be sent with a Message ID
    value of zero.

5.2. Processing Rules for IPsec Replay Counter Synchronization

 Upon failover, the newly active member MUST increment its own replay
 counter (the counter used for outgoing traffic), so as to prevent the
 case of its traffic being dropped by the peer as replay.  We note
 that IPsec allows the replay counter to skip forward by any amount.
 The estimate is based on the outgoing IPsec bandwidth and the
 frequency of synchronization between cluster members.  In those
 implementations where it is difficult to estimate this value, the
 counter can be incremented by a very large number, e.g., 2**30.  In
 the latter case, a rekey SHOULD follow shortly afterwards, to ensure
 that the counter never wraps around.
 Next, the cluster member estimates the number of incoming messages it
 might have missed, using similar logic.  The member sends out an
 IPSEC_REPLAY_COUNTER_SYNC notification, either stand-alone or
 together with an IKEV2_MESSAGE_ID_SYNC notification.
 If the IPSEC_REPLAY_COUNTER_SYNC is included in the same message as
 IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID
 notification first (which might cause the entire message to be
 dropped as a replay).  Then, it MUST increment the replay counters
 for all Child SAs associated with the current IKE SA by the amount
 requested by the cluster member.

6. IKEv2/IPsec Synchronization Notification Payloads

 This section lists the new notification payload types defined by this
 extension.

Singh, et al. Standards Track [Page 14] RFC 6311 High Availability in IKEv2/IPsec July 2011

 All multi-octet fields representing integers are laid out in big
 endian order (also known as "most significant byte first", or
 "network byte order").

6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification

 This notification payload is included in the IKE_AUTH request/
 response to indicate support of the IKEv2 Message ID synchronization
 mechanism described in this document.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Payload  |C|  RESERVED   |         Payload Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
 'Notify Message Type' fields are the same as described in Section 3
 of [4].  The 'SPI Size' field MUST be set to 0 to indicate that the
 SPI is not present in this message.  The 'Protocol ID' MUST be set to
 0, since the notification is not specific to a particular security
 association.  The 'Payload Length' field is set to the length in
 octets of the entire payload, including the generic payload header.
 The 'Notify Message Type' field is set to indicate
 IKEV2_MESSAGE_ID_SYNC_SUPPORTED (16420).  There is no data associated
 with this notification.

6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification

 This notification payload is included in the IKE_AUTH request/
 response to indicate support for the IPsec SA replay counter
 synchronization mechanism described in this document.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Payload  |C|  RESERVED   |         Payload Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
 'Notify Message Type' fields are the same as described in Section 3
 of [4] .  The 'SPI Size' field MUST be set to 0 to indicate that the
 SPI is not present in this message.  The 'Protocol ID' MUST be set to
 0, since the notification is not specific to a particular security

Singh, et al. Standards Track [Page 15] RFC 6311 High Availability in IKEv2/IPsec July 2011

 association.  The 'Payload Length' field is set to the length in
 octets of the entire payload, including the generic payload header.
 The 'Notify Message Type' field is set to indicate
 IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (16421).  There is no data
 associated with this notification.

6.3. The IKEV2_MESSAGE_ID_SYNC Notification

 This notification payload type (16422) is defined to synchronize the
 IKEv2 Message ID values between the newly active (formerly standby)
 cluster member and the peer.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Payload  |C|  RESERVED   |         Payload Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Nonce Data                                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             EXPECTED_SEND_REQ_MESSAGE_ID                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             EXPECTED_RECV_REQ_MESSAGE_ID                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 It contains the following data.
 o  Nonce Data (4 octets): The random nonce data.  The data should be
    identical in the synchronization request and response.
 o  EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): This field is used by the
    sender of this notification payload to indicate the Message ID it
    will use in the next request that it will send to the other
    protocol peer.
 o  EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): This field is used by the
    sender of this notification payload to indicate the Message ID it
    is expecting in the next request to be received from the other
    protocol peer.

6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification

 This notification payload type (16423) is defined to synchronize the
 IPsec SA replay counters between the newly active (formerly standby)
 cluster member and the peer.  Since there may be numerous IPsec SAs

Singh, et al. Standards Track [Page 16] RFC 6311 High Availability in IKEv2/IPsec July 2011

 established under a single IKE SA, we do not directly synchronize the
 value of each one.  Instead, a delta value is sent, and all replay
 counters for Child SAs of this IKE SA are incremented by the same
 value.  Note that this solution requires that either all Child SAs
 use Extended Sequence Numbers (ESNs) or else that no Child SA uses
 ESNs.  This notification is only sent by the cluster.
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Payload  |C|  RESERVED   |         Payload Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                 Incoming IPsec SA delta value                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The notification payload contains the following data.
 o  Incoming IPsec SA delta value (4 or 8 octets): The sender requests
    that the peer should increment all the Child SA replay counters
    for the sender's incoming (the peer's outgoing) traffic by this
    value.  The size of this field depends on the ESN bit associated
    with the Child SAs: if the ESN bit is 1, the field's size is 8
    octets; otherwise, it is 4 octets.  We note that this constrains
    the Child SAs of each IKE SA to either all have the ESN bit on
    or off.

7. Implementation Details

 This protocol does not change any of the existing IKEv2 rules
 regarding Message ID values.
 The standby member can initiate the synchronization of IKEv2 Message
 IDs under different circumstances.
 o  When it receives a problematic IKEv2/IPsec packet, i.e., a packet
    outside its expected receive window.
 o  When it has to send the first IKEv2/IPsec packet after a failover
    event.
 o  When it has just received control from the active member and
    wishes to update the values proactively, so that it need not start
    this exchange later, when sending or receiving the request.

Singh, et al. Standards Track [Page 17] RFC 6311 High Availability in IKEv2/IPsec July 2011

 To clarify the first alternative: the normal IKE behavior of
 rejecting out-of-window messages is not changed, but such messages
 can still be a valid trigger for the exchange defined in this
 document.  To avoid denial-of-service (DoS) attacks resulting from
 replayed messages, the peer MUST NOT initiate counter synchronization
 for any particular IKE SA more than once per failover event.
 The standby member can initiate the synchronization of IPsec SA
 replay counters:
 o  If there has been traffic using the IPsec SA in the recent past
    and the standby member suspects that its replay counter may be
    stale.
 Since there can be a large number of sessions at the standby member,
 and sending synchronization exchanges for all of them may result in
 overload, the standby member can choose to initiate the exchange in a
 "lazy" fashion: only when it has to send or expects to receive
 traffic from each peer.  In general, the standby member is free to
 initiate this exchange at its discretion.  Implementation
 considerations include the ability to survive a certain amount of
 traffic loss, and the capacity of a cluster member to initiate
 counter synchronization simultaneously with a large number of peers.

8. IKE SA and IPsec SA Message Sequencing

 The straightforward definitions of message sequence numbers,
 retransmissions, and replay protection in IPsec and IKEv2 are
 strained by the failover scenarios described in this document.  This
 section describes some policy choices that need to be made by
 implementations in this setting.

8.1. Handling of Pending IKE Messages

 After sending its "receive" counter, the cluster member MUST reject
 (silently drop) any incoming IKE messages that are outside its
 declared window.  A similar rule applies to the peer.  Local policies
 vary, and strict implementations will reject any incoming IKE message
 arriving before Message ID synchronization is complete.

8.2. Handling of Pending IPsec Messages

 For IPsec, there is often a trade-off between security and
 reliability of the protected protocols.  Here again, there is some
 leeway for local policy.  Some implementations might accept incoming

Singh, et al. Standards Track [Page 18] RFC 6311 High Availability in IKEv2/IPsec July 2011

 traffic that is outside the replay window for some time after the
 failover event, and until the counters had been synchronized.  Strict
 implementations will only accept traffic that's inside the "safe"
 window.

8.3. IKE SA Inconsistencies

 IKEv2 is normally a reliable protocol.  As long as an IKE SA is
 valid, both peers share a single, consistent view of the IKE SA and
 all associated Child SAs.  Failover situations as described in this
 document may involve forced deletion of IKE messages, resulting in
 inconsistencies, such as Child SAs that exist on only one of the
 peers.  Such SAs might cause an INVALID_SPI to be returned when used
 by that peer.  Note that Section 1.5 of [4] allows but does not
 mandate sending an INVALID_SPI notification in this case.
 The IPsecME Working Group discussed at some point a proposed set of
 rules for dealing with such situations.  However, we believe that
 these situations should be rare in practice; as a result, the
 "default" behavior of tearing down the entire IKE SA is to be
 preferred over the complexity of dealing with a multitude of edge
 cases.

9. Step-by-Step Details

 This section goes through the sequence of steps of a typical failover
 event, looking at a case where the IKEv2 Message ID values are
 synchronized.
 o  The active cluster member and the peer device establish the
    session.  They both announce the capability to synchronize counter
    information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED
    notification in the IKE_AUTH exchange.
 o  Some time later, the active member dies, and a standby member
    takes over.  The standby member sends its own idea of the IKE
    Message IDs (both incoming and outgoing) to the peer in an
    Informational message exchange with Message ID zero.
 o  The peer first authenticates the message.  The peer compares the
    received values with the values available locally and picks the
    higher value.  It then updates its Message IDs with the higher
    values and also proposes the same values in its response.
 o  The peer should not wait for any pending responses while
    responding with the new Message ID values.  For example, if the
    window size is 5 and the peer's window is 3-7, and if the peer has
    sent requests 3, 4, 5, 6, and 7 and received responses only for 4,

Singh, et al. Standards Track [Page 19] RFC 6311 High Availability in IKEv2/IPsec July 2011

    5, 6, and 7 but not for 3, then it should include the value 8 in
    its EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a
    response to message 3 any more.
 o  Similarly, the peer should also not wait for pending (incoming)
    requests.  For example, if the window size is 5 and the peer's
    window is 3-7, and if the peer has received requests 4, 5, 6, and
    7 but not 3, then it should send the value 8 in the
    EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to
    receive message 3 any more.

10. Interaction with Other Specifications

 The usage scenario of this IKEv2/IPsec SA counter synchronization
 solution is that an IKEv2 SA has been established between the active
 member of a hot standby cluster and a peer, followed by a failover
 event occurring and the standby member becoming active.  The solution
 further assumes that the IKEv2 SA state was continuously synchronized
 between the active and standby members of the cluster before the
 failover event.
 o  Session resumption [12] assumes that a peer (client or initiator)
    detects the need to re-establish the session.  In IKEv2/IPsec SA
    counter synchronization, it is the newly active member (a gateway
    or responder) that detects the need to synchronize the SA counter
    after the failover event.  Also, in a hot standby cluster, the
    peer establishes the IKEv2/IPsec session with a single IP address
    that represents the whole cluster, so the peer normally does not
    detect the event of failover in the cluster unless the standby
    member takes too long to become active and the IKEv2 SA times out
    by use of the IKEv2 liveness check mechanism.  To conclude,
    session resumption and SA counter synchronization after failover
    are mutually exclusive: they are not expected to be used together,
    and both features can coexist within the same implementation
    without affecting each other.
 o  The IKEv2 Redirect mechanism for load balancing [13] can be used
    either during the initial stages of SA setup (the IKE_SA_INIT and
    IKE_AUTH exchanges) or after session establishment.  SA counter
    synchronization is only useful after the IKE SA has been
    established and a failover event has occurred.  So, unlike
    Redirect, it is irrelevant during the first two exchanges.
    Redirect after the session has been established is mostly useful

Singh, et al. Standards Track [Page 20] RFC 6311 High Availability in IKEv2/IPsec July 2011

    for timed or planned shutdown/maintenance.  A real failover event
    cannot be detected by the active member ahead of time, and so
    using Redirect after session establishment is not possible in the
    case of failover.  So, Redirect and SA counter synchronization
    after failover are mutually exclusive, in the sense described
    above.
 o  IKEv2 Failure Detection [8] solves a similar problem where the
    peer can rapidly detect that a cluster member has crashed based on
    a token.  It is unrelated to the current scenario, because the
    goal in failover is for the peer not to notice that a failure has
    occurred.

11. Security Considerations

 Since Message ID synchronization messages need to be sent with
 Message ID zero, they are potentially vulnerable to replay attacks.
 Because of the semantics of this protocol, these can only be denial-
 of-service (DoS) attacks, and we are aware of two variants.
 o  Replay of Message ID synchronization request: This is countered by
    the requirement that the Send counter sent by the cluster member
    should always be monotonically increasing, a rule that the peer
    enforces by silently dropping messages that contradict it.
 o  Replay of the Message ID synchronization response: This is
    countered by sending the nonce data along with the synchronization
    payload.  The same nonce data has to be returned in the response.
    Thus, the standby member will accept a reply only for the current
    request.  After it receives a valid response, it MUST NOT process
    the same response again and MUST discard any additional responses.
 As mentioned in Section 7, triggering counter synchronization by out-
 of-window, potentially replayed messages could open a DoS
 vulnerability.  This risk is mitigated by the solution described in
 that section.

12. IANA Considerations

 This document introduces four new IKEv2 Notification Message types as
 described in Section 6.  The new Notify Message Types have been
 assigned values as follows.

Singh, et al. Standards Track [Page 21] RFC 6311 High Availability in IKEv2/IPsec July 2011

            +-------------------------------------+-------+
            | Name                                | Value |
            +-------------------------------------+-------+
            | IKEV2_MESSAGE_ID_SYNC_SUPPORTED     | 16420 |
            | IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | 16421 |
            | IKEV2_MESSAGE_ID_SYNC               | 16422 |
            | IPSEC_REPLAY_COUNTER_SYNC           | 16423 |
            +-------------------------------------+-------+

13. Acknowledgements

 We would like to thank Pratima Sethi and Frederic Detienne for their
 review comments and valuable suggestions for the initial version of
 the document.
 We would also like to thank the following people (in alphabetical
 order) for their review comments and valuable suggestions: Dan
 Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and
 Pekka Riikonen.

14. References

14.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
       December 2005.
 [3]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.
 [4]   Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
       Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
 [5]   Kent, S. and K. Seo, "Security Architecture for the Internet
       Protocol", RFC 4301, December 2005.

14.2. Informative References

 [6]   Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
       October 2010.
 [7]   Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
       Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

Singh, et al. Standards Track [Page 22] RFC 6311 High Availability in IKEv2/IPsec July 2011

 [8]   Nir, Y., Ed., Wierbowski, D., Detienne, F., and P. Sethi, "A
       Quick Crash Detection Method for the Internet Key Exchange
       Protocol (IKE)", RFC 6290, June 2011.
 [9]   Housley, R., "Using Advanced Encryption Standard (AES) Counter
       Mode With IPsec Encapsulating Security Payload (ESP)",
       RFC 3686, January 2004.
 [10]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
       in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
       June 2005.
 [11]  McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating
       Security Payload (ESP) and Authentication Header (AH) to
       Protect Group Traffic", RFC 6054, November 2010.
 [12]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol
       Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
 [13]  Devarapalli, V. and K. Weniger, "Redirect Mechanism for the
       Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,
       November 2009.

Singh, et al. Standards Track [Page 23] RFC 6311 High Availability in IKEv2/IPsec July 2011

Appendix A. IKEv2 Message ID Sync Examples

 This (non-normative) section presents some examples that illustrate
 how the IKEv2 Message ID values are synchronized.  We use a tuple
 notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and
 EXPECTED_RECV_REQ_MESSAGE_ID on each protocol party as
 (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
 Note that if the IKE message counters are already synchronized (as in
 the first example), we expect the numbers to be reversed between the
 two sides.  If one protocol party intends to send the next request as
 4, then the other expects the next received request to be 4.

A.1. Normal Failover – Example 1

 Standby (Newly Active) Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Sync Request (0, 5) -------->
                           Peer has the values (5, 0), so it sends
              <------------- (5, 0) as the Sync Response
 In this example, the peer has most recently sent an IKE request with
 Message ID 4, and has never received a request.  So the peer's
 expected values for the next pair of messages are (5, 0).  These are
 the same values as received from the member, and therefore they are
 sent as-is.

A.2. Normal Failover – Example 2

 Standby (Newly Active) Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Sync Request (2, 3) -------->
                           Peer has the values (4, 5), so it sends
              <------------- (4, 5) as the Sync Response
 In this example, the peer has most recently sent an IKE message with
 the Message ID 3, and received one with ID 4.  So the peer's expected
 values for the next pair of messages are (4, 5).  These are both
 higher than the corresponding values just received from the member
 (the order of tuple members is reversed when doing this comparison!),
 and therefore they are sent as-is.

Singh, et al. Standards Track [Page 24] RFC 6311 High Availability in IKEv2/IPsec July 2011

A.3. Normal Failover – Example 3

 Standby (Newly Active) Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Sync Request (2, 5) -------->
                           Peer has the values (2, 4), so it sends
              <-------------(5, 4) as the Sync Response
 In this example, the newly active member expects to send the next IKE
 message with ID 2.  It sends an expected receive value of 5, which is
 higher than the last ID value it has seen from the peer, because it
 believes some incoming messages may have been lost.  The peer has
 last sent a message with ID 1, and received one with ID 3, indicating
 that a couple of messages sent by the previously active member had
 not been synchronized into the other member.  So the peer's next
 expected (send, receive) values are (2, 4).  The peer replies with
 the maximum of the received and the expected value for both send and
 receive counters: (max(2, 5), max(4, 2)) = (5, 4).

A.4. Simultaneous Failover

 In the case of simultaneous failover, both sides send their
 synchronization requests simultaneously.  The eventual outcome of
 synchronization consists of the higher counter values.  This is
 demonstrated in the following figure.
 Standby (Newly Active) Member                            Peer
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Sync Request (4,4)     ----->
                  <-------------- Sync Request (5,5)
 Sync Response (5,5)    ---->
                      <--------  Sync Response (5,5)

Singh, et al. Standards Track [Page 25] RFC 6311 High Availability in IKEv2/IPsec July 2011

Authors' Addresses

 Raj Singh (editor)
 Cisco Systems, Inc.
 Divyashree Chambers, B Wing, O'Shaugnessy Road
 Bangalore, Karnataka  560025
 India
 Phone: +91 80 4301 3320
 EMail: rsj@cisco.com
 Kalyani Garigipati
 Cisco Systems, Inc.
 Divyashree Chambers, B Wing, O'Shaugnessy Road
 Bangalore, Karnataka  560025
 India
 Phone: +91 80 4426 4831
 EMail: kagarigi@cisco.com
 Yoav Nir
 Check Point Software Technologies Ltd.
 5 Hasolelim St.
 Tel Aviv  67897
 Israel
 EMail: ynir@checkpoint.com
 Yaron Sheffer
 Porticor Cloud Security
 EMail: yaronf.ietf@gmail.com
 Dacheng Zhang
 Huawei Technologies Ltd.
 EMail: zhangdacheng@huawei.com

Singh, et al. Standards Track [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6311.txt · Last modified: 2011/07/14 00:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki