Network Working Group                                      R. Singh, Ed.
Internet-Draft                                                G. Kalyani
Intended status: Standards Track                                   Cisco
Expires: March 10, April 14, 2011                                           Y. Nir
                                                             Check Point
                                                                D. Zhang
                                                                  Huawei
                                                       September 6,
                                                        October 11, 2010

           Protocol Support for High Availability IKEv2/IPsec
                 draft-ietf-ipsecme-ipsecha-protocol-00
                 draft-ietf-ipsecme-ipsecha-protocol-01

Abstract

   IKEv2 and IPsec protocols are widely used for deploying VPN.  In
   order to make such VPN highly available available, more scalable and failure-prone, failure-
   prone, these VPNs are implemented as IKEv2/IPsec Highly Available
   (HA) cluster.  But there are many issues in IKEv2/IPsec HA cluster.
   The draft "IPsec Cluster Problem Statement" enumerates all the issues
   encountered in IKEv2/IPsec HA cluster environment.

   This draft document proposes an extension to IKEv2 protocol to solve main
   issues of "IPsec Cluster Problem Statement" in Hot Standby cluster
   and gives implementation advice for other issues.  The main issues to
   be solved are:
   o  IKE  IKEv2 Message Id synchronization : This is done by obtaining the syncing up
      expected send and receive message Id values from with the peer and
      updating the values at the newly active cluster member after the
      failover.
   o  IPsec SA Replay Counter synchronization : This is done by sending
      incremented values of syncing up
      bumped up outgoing SA replay counters by values with peer and
      updating the values at the newly active cluster member to after the peer as expected replay counter value.
      failover.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 10, April 14, 2011.

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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Issues solved from IPsec Cluster Problem Statement . . . . . .  6
   4.  IKEv2/IPsec SA Counter Synchronization Problem . . . . . . . .  6
   5.  IKEv2/IPsec SA Counter Synchronization Solution  . . . . . . .  7  8
   6.  SA counter  IKEv2/IPsec synchronization notify and payload types notification payloads  . . . . . .  9
     6.1.  SYNC_SA_COUNTER_INFO_SUPPORTED .  IKEV2_MESSAGE_ID_SYNC_SUPPORTED  . . . . . . . . . . . . .  9 10
     6.2.  SYNC_SA_COUNTER_INFO  IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED  . . . . . . . . . . . 10
     6.3.  IKEV2_MESSAGE_ID_SYNC  . . . . . . . .  9 . . . . . . . . . . 11
     6.4.  IPSEC_REPLAY_COUNTER_SYNC  . . . . . . . . . . . . . . . . 11
   7.  Details of implementation  . . . . . . . . . . . . . . . . . . 11 12
   8.  Step-by-Step details . . . . . . . . . . . . . . . . . . . . . 12 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13 14
   10. Interaction with other drafts  . . . . . . . . . . . . . . . . 13 14
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14 15
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 16
   13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16
     13.1. Draft  -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
     13.2. Draft  -00 . . . . . . . . . . . . . . . . . . . . . . . . 15 16
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 17
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 17
     14.2. Informative References . . . . . . . . . . . . . . . . . . 15 17
   Appendix A.  IKEv2 Message Id examples . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 18

1.  Introduction

   IKEv2 is used for deploying IPsec-based VPNs.  In order to make such
   VPN highly available available, more scalable and failure-prone, these VPNs are inplemented
   implemented as IKEv2/IPsec Highly Available (HA) cluster.  But there
   are many issues in IKEv2/IPsec HA cluster.  The draft "IPsec Cluster
   Problem Statement" enumerates all the issues encountered in IKEv2/IPsec IKEv2/
   IPsec HA cluster.

   In case of Hot Standby cluster implementaion implementation of IKEv2/IPsec based
   VPNs, the IKEv2/IPsec session gets established with the peer and the
   active member of cluster.  After that, the active member syncs/
   updates the IKE/IPsec SA state to the standby member of the cluster.
   This primary SA state sync-up is done on SA bring up and/or rekey.
   Doing SA state synchronization/updation between active and peer
   member for each IKE and IPsec message standby cluster is very costly,
   so normally its done periodically.  So, when "failover" event happens
   in the cluster, first "failover' is detected by the standby member
   and then it becomes active member and it takes considerable time.
   During the time of failover and standby member becoming newly active
   member, the peer is unaware of failover and keeps sending IKE request
   and IPsec packets to the cluster which is allowed as per IKEv2 and
   IPsec windowing feature.  Now, newly active member after coming up
   finds the mismtach in IKE message id's Id's and IPsec replay counters.
   Please see Section 4 for more details.

   This draft document proposes an extension to IKEv2 protocol to solve main
   issues of IKE message id sync and IPsec SA replay counter sync and
   gives implementation advice for others.  Here is summary of solutions
   provided in this draft:

   IKE document:

   IKEv2 Message Id synchronization : This :This is done by obtaining the syncing up expected
   send and receive message Id values from with the peer and updating the
   values at the newly active cluster member after the failover.

   IPsec SA Replay Counter synchronization : This is done by sending
   incremented values of syncing up
   bumped up outgoing SA replay counters by values with peer and updating
   the values at the newly active cluster member to after the peer as expected replay counter value. failover

   Though this draft document describes the IKEv2/IPsec SA IKEv2 message Id sync and IPsec
   replay counter
   synchronisation synchronization in context of hot standby cluster.  This IPsec HA cluster, the
   solution provided is genetic and can be used in other scenarios where IKEv2/IPsec
   IKEv2 message Id sync or IPsec SA replay counters are mis-
   matched and couner sync is needed.

   There were required.

   While some concerns about the current window sync process.  The
   concern was to make IKEv2 window sync optional but we beleive IPsec HA implementation suffers from IKEv2
   window sync will be mandatory.

   [[ message Id
   synchronization problem, some other implementation suffers from IPsec
   replay counter synchronization.  Both of these problem are handled
   separately, using separate notify for each problem.  This topic needs to be discussed further on provides
   the WG mailing list.
   ]] flexibility of implementing IKEv2 message Id synchronization or
   IPsec replay counter synchronization or both.

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 RFC 2119 [RFC2119].

   "SA Counter SYNC Request" is the information exchange request defined
   in this draft document to synchronize the IKEv2/IPsec SA counter
   information between member of the cluster and the peer.

   "SA Counter SYNC Response" is the information exchange response
   defined in this draft document to synchronize the IKEv2/IPsec SA counter
   information between member of the cluster and the peer.

   Below are the terms taken from [IPsec Cluster Problem Statement] with
   added information in context of this draft. document.

   "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", whereas the other(s) are referred to as
   "standbys".  VRRP ([RFC5798]) is one method of building such a
   cluster.  The goal of Hot Standby Cluster is that it creates illusion
   of single virtual gateway to the peer(s).

   "Active Member" is the primary member in the Hot Standby cluster.  It
   is responsible for forwarding packets for the virtual gateway.

   "Standby Member" is the primary backup router.  The member takes
   control i.e. becomes active member after the "failover" event.

   "Peer" is the IKEv2/IPsec endpoint which establishes VPN connection
   with Hot Standby cluster.  The Peer knows Hot Standby Cluster by
   single cluster's IP address.  In case of "failover", the standby
   member of the cluster becomes active, so the peer normally doesn't
   notice that "failover" has occured occurred in the cluster.

   "Multiple failover" is the situation when in a cluster with three or
   more nodes failover happens in rapid succession.  The protocol and
   implementation must be able to handle multiple failover i.e. able to
   handle new failover even if they are still processing the old
   failover.

   "Simultaneous failover" is the situation when in a cluster the
   failover happens at the both ends at the same time.  The protocol and
   implementation must be able to handle simultaneous failover.

   The generic term IKEv1/IPsec IKEv2/IPsec SA counters is used throughout.  By
   IKEv2 SA counter stands for IKEv2 message ids and IPsec SA counter
   stands for IPsec SA replay counters which are used to provide
   optional anti-replay feature.

3.  Issues solved from IPsec Cluster Problem Statement

   IPsec Cluster Problem Statement defines the problems encountered in
   IPsec Clusters. .  The problems along with their section names as
   given in the statement are as follows.
   o  3.2.  Lots 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
   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

   This draft document solves the main issues using the protocol extention, extension,
   and provides implementation advice for other issues, given as
   follows.
   o  3.2 This section mentions that there's lots of state that needs to
      be synchronized.  If state is not synchronized, it's not really an
      interesting cluster - failover will be just like a reboot, so the
      issue need not be solved with protocol extensions.
   o  3.3, 3.4,3.5, and 3.6 are solved by this draft. document.  Please see
      Section 4, for more details.
   o  3.7 is the problem to be solved while building clusters.  However,
      the peers should be mandated to accept multiple parallel SAs for
      3.7.1
   o  3.8 can be solved by using IKEv2 Redirect Mechanism [RFC-5685].
   o  3.9 is the problem about avoiding collision of same SPI's among
      the cluster members.  This is outside the scope of the document
      since this has to be solved within the context of the cluster and
      not with the peer.

4.  IKEv2/IPsec SA Counter Synchronization Problem

   IKEv2 RFC states that "An IKE endpoint MUST NOT exceed the peer's
   stated window size for transmitted IKE requests".

   As per the protocol, all IKEv2 packets follows 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
   window does not move until the oldest message sent from one peer to
   another is acknowledged.  Loss of even a single packet leads to
   repeated retransmissions re-transmissions followed by an IKEv2 SA teardown if the
   retransmissions re-
   transmissions are unacknowledged.

   IPsec Hot Standby Cluster is required to ensure that in case of
   failover of active member, the standby member becomes active
   immediately.  The standby member is expected to have the exact values
   of message id fields of active member before failover.  Even with the
   best efforts to update the message Id values from active to standby
   member, the values at standby member can be stale due to following
   reasons:
   o  Standby member is unaware of the last message that was received
      and acknowledged by the older active member as failover could have
      happened before the standby could be updated.
   o  Standby member does not have information about on-going
      unackowledged
      unacknowledged requests of active member before the failover
      event.  So after failover event when standby member becomes
      active, it can not re-transmit those requests.

   When a standby member takes over as the active member, it would start
   the message id ranges from previously updated values.  This would
   make it reject requests from the peer, since the values would be
   stale.  As a sender, the standby member may end up reusing a stale
   message id which will 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 mis-match
   and re-transmission of requests.  This is not a desirable feature of
   HA.  Even after updating standby memeber member periodically the cluster can
   loose IKE and so all IPsec SA due to message id i.e.  SA counter
   mismatch.

   Similar issue is observed in IPsec counters also if anti-replay
   protection/ESN is implemented.  Even with the best efforts of syncing
   the ESP and AH SA counter numbers from active to stand by member ,
   there is a chance that the stand-by member would have stale counter
   values.  The standby member would then send the stale counter
   numbers.  The peer would reject reject/drop such packets since in case of anti-
   replay
   anti-replay protection feature, duplicate use of counters are not
   allowed.  In case of IPsec it is ok OK to skip some counter values and
   start with the highr higher counter values.

   Hence a mechanism is required in HA to ensure that the standby member
   has correct values of message Id values and IPsec counters, so that
   sessions are not torn down just because of window ranges. mismatching counters.

5.  IKEv2/IPsec SA Counter Synchronization Solution

   After

   When the standby member becomes the active member after failover
   event in the cluster, the standby member would send an authenticated
   IKEv2 request to the peer to send its values of SA counters.

   The standby member would then update its values of SA counters and
   then start sending/receiving the requests.

   The

   First, the peer MUST negotiate its ability to support SA counter IKEv2 message
   Id synchronization information with active member of the cluster by
   sending the
   SYNC_SA_COUNTER_INFO_SUPPORTED IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in IKE_AUTH
   exchange.

   Similarly to support IPsec replay counter synchronization, the peer
   MUST negotiate its ability to support IPsec replay counter
   synchronization with active member of the cluster by sending
   IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notification in IKE_AUTH
   exchange.

Peer                                                  Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
     N[SYNC_SA_COUNTER_INFO_SUPPORTED],
  N[IKEV2_MESSAGE_ID_SYNC_SUPPORTED],
  N[IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED],
  SAi2, TSi, TSr} ---------->

<---------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
                     N[SYNC_SA_COUNTER_INFO_SUPPORTED],
                 N[IKEV2_MESSAGE_ID_SYNC_SUPPORTED],
                 N[IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED], SAr2, TSi, TSr}

   When peer and active member both support SA counter synchronization,
   the active member MUST sync/update SA counter synchronization
   capability to the standby member after the establishment of the IKE
   SA.
   SA .  So that standby member is aware of the capability and can use
   it when it becomes the active member after failover event.

   After failover event, when the standby member becomes the active
   member, it has to request the peer for the SA counters.  Standby
   member would initiate the SYNC Request with an INFORMATIONAL exchange
   with message Id zero containing the notify SYNC_SA_COUNTER_INFO.  The SYNC_SA_COUNTER_INFO
   information can IKEV2_MESSAGE_ID_SYNC or
   IPSEC_REPLAY_COUNTER_SYNC or both depending on whether the
   synchronization needs to be used done for update IKEv2 counters i.e. message ids
   and also Ids, IPsec SA replay counters.

   If there are many IPsec SAs and all IPsec SA counters cannot be
   synchronized with a single counter sync exchange, then another
   counter
   counters, or both.

   The initiator of IKEv2 message Id sync exchange SHOULD be request sends its expected
   send for remaining IPsec SAs, but for
   this exchange message id would be synced IKE and receive message id after first
   counter sync exchnage NOT zero. Id values and "failover count" in
   IKEV2_MESSAGE_ID_SYNC notify.  The peer will respond back with responder of the notify SYNC_SA_COUNTER_INFO.  The
   SYNC_SA_COUNTER_INFO request contains NONCE compares
   the received values with the available local values.  The higher
   among both is selected and sent as sync response with notify
   IKEV2_MESSAGE_ID_SYNC.  The initiator now updates send and receive
   IKEv2 message Ids to the values received in sync response and can
   start normal IKEv2 message exchange.

   The initiator of IPsec replay counter sync sends bumped outgoing
   IPsec SA reply counter value and "failover count" in
   IPSEC_REPLAY_COUNTER_SYNC notify.  The responder of the request
   updates its incoming IPsec SA counter values and sends its bumped
   outgoing IPsec SA replay counter value in sync response with
   IPSEC_REPLAY_COUNTER_SYNC.  The initiator now updates its incoming
   IPsec SA counter to values received in sync response and can start
   normal IPsec data traffic.

   Both the notify types IKEV2_MESSAGE_ID_SYNC and
   IPSEC_REPLAY_COUNTER_SYNC contain Nonce Data in the payload to avoid
   DOS attack due to replay of SA counter sync response. request/response.  The
   Nonce are defined per notify and MUST be validated.  The Nonce data send
   sent in
   SYNC_SA_COUNTER_INFO response MUST match with nonce data sent by newly-active
   member in SYNC_SA_COUNTER_INFO request.  If nonce data received in SYNC_SA_COUNTER_INFO response does not match
   with nonce data sent in SYNC_SA_COUNTER_INFO request, the standby i.e. newly-
   active newly-active member
   MUST discard this SYNC_SA_COUNTER_INFO response, and normal IKEv2 behaviour behavior of re-transmitting re-
   transmitting the request and waiting for genuine reply from the peer
   SHOULD follow, before tearing down the SA
   becuase because of re-transmits.

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HDR, SK {N[SYNC_SA_COUNTER_INFO]+} {N[IKEV2_MESSAGE_ID_SYNC ],
                  N[IPSEC_REPLAY_COUNTER_SYNC]} -------->

                <--------- HDR, SK {N[SYNC_SA_COUNTER_INFO]+} {N[IKEV2_MESSAGE_ID_SYNC ],
                  N[IPSEC_REPLAY_COUNTER_SYNC]}

6.  SA counter  IKEv2/IPsec synchronization notify and payload types notification payloads

   Below are the new notify and payload types that are defined

6.1.  SYNC_SA_COUNTER_INFO_SUPPORTED

   SYNC_SA_COUNTER_INFO_SUPPORTED:  IKEV2_MESSAGE_ID_SYNC_SUPPORTED

   IKEV2_MESSAGE_ID_SYNC_SUPPORTED: This notify is included in the
   IKE_AUTH request by the peer request/response to indicate the support for IKEv2/IPsec
   SA counter 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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      SYNC_SA_COUNTER_INFO_SUPPORTED

   The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
   'Notify Message Type' fields are the same as described in Section 3
   of [IKEv2bis]. [RFC5996].  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.  '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 the
   SYNC_SA_COUNTER_INFO_SUPPORTED
   IKEV2_MESSAGE_ID_SYNC_SUPPORTED payload.

6.2.  SYNC_SA_COUNTER_INFO

   SYNC_SA_COUNTER_INFO :  IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED

   IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED: This payload type notify is defined to sync the SA
   counter information among newly-active [standby] member and the peer.
   The SYNC_SA_COUNTER_INFO payload can be used to synchronize IKE SA
   counter and IPsec SA counters as well.  So, multiple payloads of this
   type can be used included in the single exchange where one payload is used
   IKE_AUTH request/response to
   sync the IKE indicate support for IPsec SA replay
   counter information, another payload can be used to
   sync the Child SA [ e.g.  ESP, AH etc] information. 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  |M|  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID    | ID(=0)| SPI Size (=0) | # of SPI's    |Counter Size   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   ~                     Nonce Data                                ~
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_SEND_REQ_MESSAGE_ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_RECV_REQ_MESSAGE_ID      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            SPI                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~            Last Counter                                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           SYNC_SA_COUNTER_INFO

   It contains

   The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
   'Notify Message Type' fields are the following data.
   o  Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
      for ESP.
   o  SPI Size (1 octet) - Length same as described in octets Section 3
   of the SPI as defined by the
      protocol ID.  It [RFC5996].  The 'SPI Size' field MUST be zero for IKE or four for AH and ESP.
   o  # of SPIs (1 octet) - The number of SPIs contained set to 0 to indicate that
   the SPI is not present in this
      payload. message.  The size of each SPI is defined by the SPI Size field.
      It 'Protocol ID' MUST be zero if protocol
   set to 0, since the notification is IKE.
   o  Counter Size (1 octet) not specific to a particular
   security association.  'Payload Length' field is set to the size of IPsec SA counter length in octets.
      It is 4 if
   octets of the Extended Sequence Numbers option entire payload, including the generic payload header.
   The 'Notify Message Type' field is not set for to indicate the
      SAs described in this payload, or
   IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED payload.

6.3.  IKEV2_MESSAGE_ID_SYNC

   IKEV2_MESSAGE_ID_SYNC : This payload type is defined to sync the
   IKEv2 message Ids among newly-active [standby] 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 otherwise. 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |    RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Failover count                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Nonce Data                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_SEND_REQ_MESSAGE_ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_RECV_REQ_MESSAGE_ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It MUST be zero if
      protocol is IKE. contains the following data.
   o  Failover count (4 octets) : The failover count within the cluster,
      it increases with each failover event in HA cluster.
   o  Nonce Data (16 (4 octets) - : The random nonce data MUST data.  It should be present if
      protocol is IKE. sent
      same in the SYNC Request and Response.  The nonce data is used to
      counter the replay of
      SYNC_SA_COUNTER_INFO IKEV2_MESSAGE_ID_SYNC response by the
      attacker.
   o  EXPECTED_SEND_REQ_MESSAGE_ID (4 octets) : This MUST be present
      only if protocol ID is IKE.  This field is used by the sender of
      this notify, to indicate the message Id it will use in the next
      request, t that it will send to the other side peer.  It MUST be present only
      in SA counter synchronization response and MUST be ignored in SA
      counter synchronization request.
   o  EXPECTED_RECV_REQ_MESSAGE_ID(4  EXPECTED_RECV_REQ_MESSAGE_ID (4 octets) : This field is used by
      the sender of this notify, to indicate the message Id it can
      accept in the next request, received from the peer.This data MUST be present
      only in response other side peer.

6.4.  IPSEC_REPLAY_COUNTER_SYNC

   IPSEC_REPLAY_COUNTER_SYNC: This payload type is defined to sync the
   IPsec SA replay counters among newly-active [standby] 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  |ESN| RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Failover count                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Outgoing IPsec SA  counter                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   It contains the following data.
   o  ESN (1 bit) : The ESN bit MUST be ignored if present in REQUEST.This
      MUST be present only ON if protocol ID is IKE. IPsec SA were established
      with Extended Sequence Numbers.
   o  SPI  Failover count (4 octets) is the Security Parameter Index of the outbound SA
      for the sender, or the inbound SA for : The failover count within the receiver. cluster,
      it increases with each failover event in HA cluster.
   o  Last Counter  Outgoing IPsec SA counter (4 octets or 8 octets) octect) : The outgoing
      IPsec SA counter is the bumped-up outgoing IPsec SA replay counter number of
      value considering ALL Child SA under the last
      packet sent. IKEv2 SA.  The receiver MUST drop any size of
      outgoing IPsec packet with replay SA counter lower than this.
   o  M (More - 1 bit) - This flag MUST be set when there are some IPsec
      are left to be synced, but can not be send due to packet size or
      some other limitation.  When M depends on ESN bit.  If ESN bit is zero it, ON,
      it tell is size of 8 octets else it is last
      SA counter sync message. 4 octets.

7.  Details of implementation

   The message Id used in this IKEV2_MESSAGE_ID_SYNC exchange MUST be zero so
   that it is not
   vaildated validated upon receipt. receipt as per IKEv2 windowing.
   Message Id zero MUST be permitted only for informational exchange
   that would have NOTIFY of type
   SYNC_SA_COUNTER_INFO. IKEV2_MESSAGE_ID_SYNC.  If any packet
   INFORMATIONAL exchange uses the message Id Zero, without having this Notify along with the Nonce payload,
   Notify, then such packets MUST be discarded upon decryption. decryption and
   INVALID_SYNTAX notify SHOULD be sent.  No other payloads are allowed
   in this Informational exchange.  Whenever IKEV2_MESSAGE_ID_SYNC or
   IPSEC_REPLAY_COUNTER_SYNC notify is received with invalid failover
   count or nonce data, the event SHOULD be logged.

   The standby member can initiate the synchronization of IKEv2 Message
   Id's
   o  When it receives the bad IKEv2/IPsec packet.  The 'bad" IKEv2/
      IPsec packet means a packet outside receive window.
   o  When it has to send an IKEv2/IPsec packet after failover event.
   o  It has just got the control from active member and would require
      to update the values before-hand, so that it need not start this
      exchange at the time of sending/receiving the request.

   The standby member can initiate the synchronization of IPsec SA
   Counters
   o  If there is traffic using the IPsec SA in the recent past and
      there could be stale replay counter at standby member

   Since there can be many sessions at Standby member, and sending
   exchanges from all of the sessions can cause throttling, the standby
   member can choose to initiate the exchange when it has to send or
   receive the request.  Thus the trigger to initiate this exchange
   depends on the requirement/discretion of the standby member.

   The member which has not announced its capability
   SYNC_SA_COUNTER_INFO_SUPPORTED
   IKEV2_MESSAGE_ID_SYNC_SUPPORTED MUST NOT send/receive the notify
   IKEV2_MESSAGE_ID_SYNC.

   The member which has not announced its capability
   IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED MUST NOT send/receive the notify
   SYNC_SA_COUNTER_INFO.
   IPSEC_REPLAY_COUNTER_SYNC.

   If a peer gets SYNC_SA_COUNTER_INFO IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC
   request even though it did not announce its capability in IKE_AUTH
   exchange, then it MUST ignore this message.

   If any of the Notify or the SYNC request/response is malformed, then
   it is treated as INVALID_SYNTAX message.

8.  Step-by-Step details

   The step by step details of the synchronisation synchronization of IKE message Id is
   as follows.
   o  Active member and peer device establish the session .  They
      announce the capability to sync the counter info by sending
      SYNC_SA_COUNTER_INFO_SUPPORTED
      IKEV2_MESSAGE_ID_SYNC_SUPPORTED notify in AUTH IKE_AUTH Exchange.
   o  Active member dies and Stand-by member takes over. .  Stand-by  Standby Member
      sends its own idea of the IKE Message ID (its side) to
      peer. peer in an
      INFORMATIONAL message exchange with message Id zero.
   o  The peer will send its EXPECTED_SEND_REQ_MESSAGE_ID and
      EXPECTED_RECV_REQ_MESSAGE_ID.  Since first authenticates the message Id values and then validates that
      failover count.  The peer will compare the received are higher than values at with
      the stand-by member , itwould
      update its local values of available locally and finally picks the higher value.
      It then updates its message Id's with the received values. higher values and also
      propose the same in Response.
   o  The peer should not wait for pending response while responding
      with this message Id values.  For example if window size is 5 and
      peer window is 3-7 and if peer has sent requests 3, 4,5,6,7 and
      but got response only for 4,5,6,7 but not 3 then it should send
      the EXPECTED_SEND_REQ_MESSAGE_ID as 8 and should not wait for
      response of 3 anymore.
   o  The peer should not wait for pending request also.  For example if
      window size is 5 and peer window is 3-7 and if peer has received
      requests 4,5,6,7 but not 3 then it should send the
      EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for 3
      anymore.

   The step by step details of the synchronisation of IPsec SA Counter
   synchronization is as follows.
   o  Active member and peer device establish the session .  They
      announce the capability to sync the counter info by sending
      SYNC_SA_COUNTER_INFO_SUPPORTED notify in AUTH Exchange.
   o  Active member dies and Stand-by member takes over.  Stand-by
      Member increments its values of Outbound SA Counters for each
      IPsec SA and sends them to the peer. EXPECTED_SEND_REQ_MESSAGE_ID as 8 and should not wait for
      response of 3 anymore.

   o  The peer will update its Inbound SA Counter corresponding to each
      IPsec SA should not wait for pending request also.  For example if
      window size is 5 and peer window is 3-7 and if peer has received
      requests 4,5,6,7 but not 3 then it should send its Outbound SA Counter value the
      EXPECTED_RECV_REQ_MESSAGE_ID as 8 and should not wait for each IPsec SA 3
      anymore.

   There is corner case with "failover count' and multiple failover.
   What if "failover count" is not updated on it.
   o  If replay counters were bumped by large amount, we MAY slowly do
      child sa rekey to reset counter when member a member, and next
   "failover" happened, then "failover count" is less loaded after
      failover event. updated on other side
   but not on this member. [[ This need to be discussed on mailing list.
   ]]

9.  Security Considerations

   There can be two types of DOS attacks.
   o  Replay of Message SYNC Request.  This can be is countered by rate
      limiting "failover
      count", since synchronization starts after failover event and each
      member of the number cluster is aware of such requests failover event.  The receiver of
      sync request should verify and maintain failover count.  If a peer
      again receives a sync request with same "failover count', it can receive.
      safely safely discard the request if it has received valid
      request/response from other side peer after sync exchange.  The rate
      limiting
      peer can be done either by number or send the time delay between
      which Message SYNC cached response for sync request can be till it has not
      received valid request/response from other side peer or both.These options
      are configurable. failover
      count has not increased.
   o  Replay of Message SYNC Response.  This can be is countered by sending the
      NONCE data along with the SYNC_SA_COUNTER_INFO sync notify.  The same NONCE data has to
      be returned in response.  Thus the standby member can accept the
      reply only for the current request.  After it receives the valid
      response, it MUST not accept the NOT process same response again and MUST drop discard
      the response.

10.  Interaction with other drafts

   The primary assumption of IKEv2/IPsec SA Counter Synchronization
   prososal
   proposal is IKEv2 SA has been established between active member of
   Hot Standby Cluster and peer, after that the failover event occurred
   and now standby member has "become" active.  It also assumes the
   IKEv2 SA state was synced between active and standby member of the
   Hot Standby Cluster before the failover event.
   o  Session Resumption.  Session resumption assumes that peer i.e.
      client or initiator detects the need to re-establish the session.
      In IKEv2/IPsec SA counter cynchronization, synchronization, standby member which
      becomes active i.e. gateway or responder detects the need to
      synchronize the SA counter after the failover event.  Also in Hot
      Standby Cluster, peer establishes the IKEv2/IPsec session with
      single cluster's IP address, so peer normally does not detect the
      event of failover in the cluster until standby member took very
      long to become active and IKEv2 SA times out via liveness check.
      So, session resumption and SA counter synchronization after
      failover are mutually exclusive.
   o  This document describes the operation of tightly coupled clusters,
      which are the common way of building IPsec clusters.  In these
      clusters, all members appear to the peer as one gateway,
      specifically they share a single IP address.  High availability
      can also be provided by loosely coupled clusters (for lack of a
      better term), which are a group of gateways that do not share an
      IP address and do not synchronize state.  In this architecture,
      the client can use Session Resumption to fail-over from one
      cluster member to another.  Specifically this requires:
      *  Support of session resumption on peers and gateways.
      *  A common session resumption ticket format on all gateways (not
         currently standardized).
      *  Configuration on the peers of the group of gateways that
         constitute the cluster.
   o  Redirect.  Redirect mechanism for load-balancing can be used
      during init (IKE_SA_INIT) and auth (IKE_AUTH) and after session
      establishment.  While SA counter sync is used after IKE SA has
      been established and failover event has occurred.  So it is
      mutually exclusive with redirect during init and auth.  The
      redirect after session established is used for timed or planned
      shutdown/maintenance.  The failover event can not be detected on
      active member beforehand and so using redirect after session
      establishment is not possible in case of failover.  So, Redirect
      and SA counter synchronization after failover are mutually
      exclusive.
   o  Crash detection.  Solves the similar problem where peer detect
      that cluster member has crashed based on a token.  It is mutualy mutually
      exclusive with HA with SA counter sync.

11.  IANA Considerations

   This document introduces two four new IKEv2 Notification Message types as
   described in Section 6.The new Notify Message Types must be assigned
   values between 16396 and 40959.
   o  SYNC_SA_COUNTER_INFO_SUPPORTED  IKEV2_MESSAGE_ID_SYNC_SUPPORTED.
   o  IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED.
   o  SYNC_SA_COUNTER_INFO  IKEV2_MESSAGE_ID_SYNC.
   o  IPSEC_REPLAY_COUNTER_SYNC.

12.  Acknowledgements

   We would like to thank Pratima Sethi and Frederic Detienne for their
   reviews comments and valuable suggestions for initial version of the
   document.

   We would also like to thank following people (in alphabetical order)
   for their review comments and valuable suggestions: Dan Harkins, Paul
   Hoffman, Steve Kent, Tero Kivinen, David McGrew, Pekka Riikonen, and
   Yaron Sheffar.

13.  Change Log

   This section lists all the changes in this document.

   NOTE TO RFC EDITOR: Please remove this section in before final RFC publication.

13.1.  Draft  -01

   Added "Multiple and Simultaneous failover' scenarios.

   Now document provides a mechanism to sync either IKEv2 message or
   IPsec replay counter or both to cater different types of
   implementations.

   HA cluster's "failover count' is used to encounter replay of sync
   requests by attacker.

   The sync of IPsec SA replay counter optimized to to have just one
   global bumped-up outgoing IPsec SA counter of ALL Child SAs under an
   IKEv2 SA.

   The examples added for IKEv2 message Id sync to provide more clarity.

   Some edits as per comments on mailing list to enhance clarity.

13.2.  Draft  -00

   Version 00 is identical to
   draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document.

   Added IPSECME WG HA design team members as authors.

   Added comment in Introduction to discuss the window sync process on
   WG mailing list to solve some concerns.

14.  References

14.1.  Normative References

   [IKEv2bis]
              Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol: IKEv2",
              draft-ietf-IPsecme-ikev2bis (work in progress), May 2010.

   [IPsec Cluster Problem Statement]
              Nir, Y., "IPsec Cluster Problem Statement", July 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol: IKEv2", RFC 5996,
              September 2010.

14.2.  Informative References

   [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.

Appendix A.  IKEv2 Message Id examples

   Below are the examples to illustrate how the IKEv2 message Id values
   are synced.  The notation used to denote EXPECTED_SEND_REQ_MESSAGE_ID
   and EXPECTED_RECV_REQ_MESSAGE_ID on a member is
   (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).

   Normal failover - Example 1

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Request SYNC (2, 3) -------->

                             Peer has values as (4, 5) so it sends
                < -------------( 4, 5) Response SYNC

   Normal failover - Example 2

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Request SYNC (2, 5) -------->
                             Peer has values as (2, 4) so it sends
                < -------------( 5, 4) Response SYNC

   Simultaneous failover

   In case of simultaneous failover, both the sides send the SYNC
   request, but whichever side has the higher value will be eventually
   synced.

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   request SYNC (4,4)     ----->

                    <-------------- request SYNC (5,5)

       response SYNC (5,5)    ---->

                  <--------  response SYNC (5,5)

Authors' Addresses

   Raj Singh (Editor)
   Cisco Systems, Inc.
   Divyashree Chambers, B Wing, O'Shaugnessy Road
   Bangalore, Karnataka  560025
   India

   Phone: +91 80 4426 4833 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

   Dacheng Zhang
   Huawei Technologies Ltd.

   Email: zhangdacheng@huawei.com