wdiff draft-ietf-ipsecme-ipsecha-protocol-01.txt draft-ietf-ipsecme-ipsecha-protocol-02.txt

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

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

Abstract

IKEv2 and

The IPsec protocols are protocol suite is widely used for deploying VPN. the deployment of virtual
private networks (VPNs). In order to make such VPN VPNs highly
available, more scalable and failure-
prone, failure-resistant, these VPNs are
implemented as IKEv2/IPsec Highly Available IPsec High Availability (HA) cluster. But clusters. However there
are many issues in IKEv2/IPsec IPsec HA cluster.
The draft clustering, and in particular in IKEv2
clustering. An earlier document, "IPsec Cluster Problem Statement" Statement",
enumerates all the issues encountered in the IKEv2/IPsec HA cluster
environment. This document attempts to resolve these issues with the
least possible change to the protocol.

This document proposes an extension to the IKEv2 protocol to solve
the main issues of "IPsec Cluster Problem Statement" in Hot Standby cluster the commonly
deployed hot-standby cluster, and gives provides implementation advice for
other issues. The main issues to be solved are:
o are the synchronization
of IKEv2 Message Id synchronization : This is done by syncing up
expected send and receive message Id values with the peer ID counters, and
updating the values at the newly active cluster member after the
failover.
o of IPsec Replay Counter synchronization : This is done by syncing up
bumped up outgoing SA replay counters values with peer and
updating the values at the newly active cluster member after the
failover. Counters.

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 April 14, 28, 2011.

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 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
3. Issues solved Resolved from IPsec Cluster Problem Statement . . . . . . 6 5
4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . . . 6 5
5. IKEv2/IPsec SA Counter Synchronization Solution . . . . . . . 8 . . . . . . . . 7
6. IKEv2/IPsec synchronization notification payloads Synchronization Notification Payloads . . . . . . 9
6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED . . . . . . . . . . . . . 10 9
6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED . . . . . . . . . . . 10
6.3. IKEV2_MESSAGE_ID_SYNC . . . . . . . . . . . . . . . . . . 11 10
6.4. IPSEC_REPLAY_COUNTER_SYNC . . . . . . . . . . . . . . . . 11
7. Implementation Details of implementation . . . . . . . . . . . . . . . . . . . . 12
8. Step-by-Step details Step by Step Details . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Interaction with other drafts . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 15
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 15
13.1. Draft -01 -02 . . . . . . . . . . . . . . . . . . . . . . . . 16
13.2. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
13.3. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. IKEv2 Message Id examples ID Sync Examples . . . . . . . . . . . 17
A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 17
Authors' Addresses
A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 18
A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 18

1. Introduction

IKEv2 is used for deploying IPsec-based VPNs. In order to make such
VPN highly available, more scalable and failure-prone,
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction

The IPsec protocol suite, including 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) cluster. But However
there are many issues in with the IKEv2/IPsec HA cluster. The problem
statement draft "IPsec Cluster
Problem Statement" Section 4 enumerates all the issues encountered in around the IKEv2/
IPsec HA cluster. cluster solution.

In the case of Hot Standby a hot-standby cluster implementation of IKEv2/IPsec
based VPNs, the IKEv2/IPsec session gets is first established with between the
peer and the active member of the cluster. After that, Later, the active member syncs/
updates
continuously syncs/updates the IKE/IPsec SA state to the standby
member of the cluster. This primary SA state sync-up is done on takes place
upon each SA bring up bring-up and/or rekey.
Doing Performing the SA state synchronization/updation between active and peer
member
synchronization/update for each every single IKE and IPsec message standby cluster is very
costly, so normally its it is done periodically. So, As a result, when "failover" event happens
in the cluster, first "failover'
failover event happens, this is first detected by the standby member
and then
and, possibly after a considerable amount of time, it becomes the
active member and it takes considerable time. member. During the time of this failover and standby member becoming newly active
member, process the peer is unaware of
the failover event, and keeps sending IKE request requests and IPsec packets
to the cluster which cluster, as in fact it is allowed as per to do because of the IKEv2 and
IPsec
windowing feature. Now, newly active After the newly-active member after coming up
finds starts, it detects
the mismtach mismatch in IKE message Id's Message ID values and IPsec replay counters. counters and
needs to resolve this situation. Please see Section 4 for more details.
details of the problem.

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

o IKEv2 Message Id synchronization :This ID synchronization: this is done by syncing up the
expected send and receive message Id Message ID values with the peer peer, and
updating the values at the newly active cluster member after the failover. member.
o IPsec Replay Counter synchronization : This synchronization: this is done by syncing up
bumped up incrementing
the cluster's outgoing SA replay counters counter values with peer by a "large"
number, and updating
the synchronizing these values at with the newly active cluster member after peer. The peer
send its outgoing SA reply counter in the failover

Though response.

Although this document describes the IKEv2 message Id sync Message ID and IPsec
replay counter synchronization in the context of an IPsec HA cluster,
the solution provided is genetic generic and can be used in other scenarios
where IKEv2 message Id sync Message ID or IPsec SA replay counters sync is required.

While some IPsec HA implementation suffers from IKEv2 message Id counter synchronization problem, some other implementation suffers from may
be required.

Implementations differ on the need to synchronize the IKEv2 Message
ID and/or IPsec replay counter synchronization. counters. Both of these problem are handled
separately, using a separate notify notification for each problem. capability. This
provides the flexibility of implementing IKEv2 message Id synchronization or
IPsec replay counter synchronization either or both. 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 RFC 2119 [RFC2119].

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

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

Below are

Some of the terms taken listed below are reused from [IPsec Cluster Problem Statement] [RFC6027] with
added information further
clarification in the context of this 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", "active" member, whereas the other(s) are
referred to as
"standbys". "standby" members. VRRP ([RFC5798]) [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).
o "Active Member" is the primary member in the Hot Standby Hot-Standby cluster.
It is responsible for forwarding packets for on behalf of the virtual
gateway.
o "Standby Member" is the primary backup router. The member. This member takes
control
control, i.e. becomes the active member member, after the "failover" failover event.
o "Peer" is the an IKEv2/IPsec endpoint which establishes that maintains a VPN connection
with Hot Standby the Hot-Standby cluster. The Peer knows Hot Standby Cluster identifies the cluster by
single
the cluster's (single) IP address. In case of "failover", If a failover event occurs,
the standby member of the cluster becomes active, so and the peer
normally doesn't notice that "failover" failover has occurred taken place.
o "Failover Count" is a global failover event counter maintained by
the HA cluster and incremented by 1 upon each failover event in
the HA cluster. All members of the HA cluster share the failover
count.
o "Multiple failover" is the situation when where, in a cluster with
three or more nodes members, failover happens in rapid succession. The protocol and It
is our goal that the implementation must should be able to handle multiple failover this
situation, i.e. able to handle the new failover event even if they are it is
still processing the old failover.
o "Simultaneous failover" is the situation when in where two clusters have a cluster the
VPN connection between them, and failover happens at the both ends
at the same time. The protocol and It is our goal that implementation must should be
able to handle simultaneous failover.

The generic term IKEv2/IPsec "IKEv2/IPsec SA counters Counters" is used throughout. By
IKEv2 SA counter stands for throughout this
document. This term refers to both IKEv2 Message ID counters
(mandatory, and used to ensure reliable delivery as well as to
protect against message ids replay in IKEv2) and IPsec SA counter
stands for IPsec SA replay counters which are
(optional, and used to provide
optional the IPsec anti-replay feature. feature).

3. Issues solved Resolved from IPsec Cluster Problem Statement

The IPsec Cluster Problem Statement defines [RFC6027] enumerates the problems encountered in
raised by IPsec Clusters. . clusters. The problems along with their section names as
given in the statement following table lists the problem
statement's sections that are as follows. resolved by this document.
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 Synchronization 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 document solves the

The main issues problem areas are solved using the protocol extension, extension
defined below, and additionally this document provides implementation
advice for other issues, given as follows.
o 3.2 This section mentions that there's lots there is a large amount of state
that needs to be synchronized. If However if state is not
synchronized, it's this is not really an interesting cluster - cluster: failover will be just like
is equivalent to a reboot, reboot of the cluster member, and so the issue
need not be solved with protocol extensions.
o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see
Section 4, for more details.
o 3.7 is the an implementation problem that needs to be solved while
building IPsec clusters. However, the peers should be mandated required to
accept multiple parallel SAs for
3.7.1 3.7.1.
o 3.8 can be solved by using the IKEv2 Redirect Mechanism [RFC-5685]. mechanism [RFC5685].
o 3.9 is discusses the problem about avoiding collision avoidance of same SPI's among collisions where the same SPI value
is used by multiple cluster members. This is outside the
document's scope of the document since this has the problem needs to be solved within the context of internally
to the cluster and does not with involve the peer.

4. The IKEv2/IPsec SA Counter Synchronization Problem

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

As per the protocol, all

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

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

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

Similar despite the periodic update between the
cluster members.

A similar issue is also observed in with IPsec anti-replay counters also if
anti-replay protection/ESN is implemented. Even with implemented, which is commonly the best efforts
case. Regardless of syncing how well the ESP and AH SA counter numbers counters are
synchronized from the active to stand by member , the standby member, there is a chance
that the stand-by standby member would have end up with stale counter values. The
standby member would then send the use those stale counter
numbers. values when sending
IPsec packets. The peer would reject/drop such packets since in case of when
the anti-replay protection feature, feature is enabled, duplicate use of
counters are is not allowed. In case of Note that IPsec it is OK allows the sender to skip
some counter values and
start continue sending with the higher counter values.

Hence

We conclude that a mechanism is required in HA to ensure that the standby
member has correct values of message Id values Message ID and IPsec counters, counter values when it
becomes active, so that sessions are not torn down just because as a result of mismatching
mismatched counters.

5. IKEv2/IPsec SA Counter Synchronization Solution

When

In general, when the standby member becomes the active member after failover
event in
the cluster, failover event, the standby member would send sends an authenticated IKEv2
request to the peer peer, asking it to send its values of SA counters. counter values.

The standby member would then update updates its values of own SA counters counter values and
then start sending/receiving the requests. can
resume normally sending and receiving protocol messages.

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

Similarly

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

Peer Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
N[IKEV2_MESSAGE_ID_SYNC_SUPPORTED],
N[IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED],
[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],
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] SAr2, TSi, TSr}

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

After the failover event, when the standby member becomes the active
member, active, it
has to request the peer for the SA counters. Standby counters from the peer. The newly-active
member would initiate initiates the SYNC Request synchronization request with an INFORMATIONAL Informational
exchange with message Id Message ID zero containing either the notify notification
IKEV2_MESSAGE_ID_SYNC or
IPSEC_REPLAY_COUNTER_SYNC or both the two notifications IKEV2_MESSAGE_ID_SYNC
and IPSEC_REPLAY_COUNTER_SYNC, depending on whether the
synchronization needs is to be done for IKEv2 message Ids, Message IDs or for both IKEv2
Message IDs and IPsec replay
counters, or both. counters. If the active member has only
negotiated synchronization of IPsec Replay Counters, the request is
sent as a regular IKEv2 Informational exchange (i.e. with a non-zero
Message ID) containing the notification IPSEC_REPLAY_COUNTER_SYNC.

The initiator of the IKEv2 message Id sync Message ID synchronization request sends
its expected send and receive message Id Message ID values and "failover count"
in a IKEV2_MESSAGE_ID_SYNC notify. notification. The responder of the request compares the
received values with the available its local values. For both send and receive
values, The higher
among both between the cluster member's and the local value
is selected selected, and sent as sync in the response message with notify the notification
IKEV2_MESSAGE_ID_SYNC. The initiator now updates its send and
receive IKEv2 message Ids Message IDs to the values received in sync the response and
can now start a normal IKEv2 message exchange.

The initiator of an IPsec replay counter sync Replay Counter synchronization sends bumped the
incremented outgoing IPsec SA reply counter value and a "failover
count" in a IPSEC_REPLAY_COUNTER_SYNC notify. notification in IKEv2
INFORMATIONAL exchange. The responder of the request updates its incoming IPsec SA
counter values and according to the received value. The responder now
sends its bumped own incremented outgoing IPsec SA replay counter Replay Counter value in sync a
synchronization response message, with
IPSEC_REPLAY_COUNTER_SYNC. the same
IPSEC_REPLAY_COUNTER_SYNC notification. The initiator can now updates update
its incoming IPsec SA counter to values received in sync the response
message and can start normal IPsec data traffic.

Both the notify types

The IKEV2_MESSAGE_ID_SYNC and
IPSEC_REPLAY_COUNTER_SYNC contain Nonce Data in the notification payload contain nonce data to
avoid
DOS a denial-of-service (DoS) attack due to replay of SA counter sync request/response.
synchronization response. The
Nonce nonce values are defined per notify selected randomly on
each new notification and MUST be validated. validated by the receiver. The Nonce
nonce data sent in the response MUST match with the nonce data sent by the
newly-active member in its request. If the nonce data received in
the response does not match
with the request's nonce data sent in request, data, the standby i.e. newly-active cluster
member MUST silently discard this response, and SHOULD revert to
normal IKEv2 behavior of re-
transmitting retransmitting the request and waiting for a
genuine a reply from the peer
SHOULD follow, before tearing down peer. Eventually this might result in the
SA being torn down because of re-transmits. excessive retransmissions.

Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {N[IKEV2_MESSAGE_ID_SYNC ],
N[IPSEC_REPLAY_COUNTER_SYNC]} {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
<--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]}

Alternatively, if only IPsec Replay Counter synchronization is
desired, a normal Information exchange is used, where the Message ID
is non-zero:

Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->

<--------- HDR, SK {N[IKEV2_MESSAGE_ID_SYNC ],
N[IPSEC_REPLAY_COUNTER_SYNC]} {N(IPSEC_REPLAY_COUNTER_SYNC)}

6. IKEv2/IPsec synchronization notification payloads

Below are Synchronization Notification Payloads

This section lists the new notify and payload notification payloads types that are defined by
this extension.

6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED

IKEV2_MESSAGE_ID_SYNC_SUPPORTED: This notify notification payload is
included in the IKE_AUTH request/response to indicate support for of the
IKEv2 message Id Message ID synchronization mechanism described in this
document.

The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
'Notify Message Type' fields are the same as described in Section 3
of [RFC5996]. [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. 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 the
IKEV2_MESSAGE_ID_SYNC_SUPPORTED payload.
IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data
associated with this notification.

6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED

IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED: This notify notification payload is
included in the IKE_AUTH request/response to indicate support for the
IPsec SA replay
counter Replay Counter synchronization mechanism described in this
document.

The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
'Notify Message Type' fields are the same as described in Section 3
of [RFC5996]. [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. 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 the
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED payload.
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no
data associated with this notification.

6.3. IKEV2_MESSAGE_ID_SYNC

IKEV2_MESSAGE_ID_SYNC : This notification payload type (value TBD by
IANA) is defined to sync synchronize the IKEv2 message Ids among Message ID values between
the newly-active [standby] (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 | RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failover count Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_SEND_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_RECV_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains the following data.
o Failover count Count (4 octets) : The failover octets): a running count within the cluster, of failover events
between cluster members, it increases with is initialized to 0 when the cluster
is first set up, and incremented by 1 upon each failover event in HA cluster. event.
o Nonce Data (4 octets) : The octets): the random nonce data. It The data should be sent
same
identical in the SYNC Request synchronization request and Response. The nonce data is used to
counter the replay of IKEV2_MESSAGE_ID_SYNC response by the
attacker. response.
o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets) : This MUST be present
only if protocol ID is IKE. This octets): this field is used by the
sender of this notify, notification payload to indicate the message Id Message ID it
will use in the next
request, request that it will send to the other side
protocol peer.
o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets) : This octets): this field is used by the
sender of this notify, notification payload to indicate the message Id Message ID it can
accept
is expecting in the next request, request to be received from the other side
protocol peer.

6.4. IPSEC_REPLAY_COUNTER_SYNC

IPSEC_REPLAY_COUNTER_SYNC: This notification payload type (value TBD
by IANA) is defined to sync synchronize the IPsec SA replay counters among Replay Counters
between the newly-active [standby] (formerly standby) cluster member and the
peer. Since there may be numerous IPsec SAs 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 all these Child SAs either use or do not use
Extended Sequence Numbers [RFC4301].

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| |E| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Failover count Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing IPsec SA counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The notification payload contains the following data.
o ESN E (1 bit) : bit): The ESN bit bit. This MUST be ON 1 if the IPsec SA SAs were
established with Extended Sequence Numbers.
o Failover count (4 octets) : The failover count within the cluster,
it increases with each failover event in HA cluster.
o Outgoing IPsec SA counter delta value (4 octets or 8 octect) : octects): The outgoing
IPsec SA counter is sender will
increment the all the bumped-up outgoing IPsec SA replay counter
value considering ALL Child SA under the IKEv2 SA. Replay Counters for its outgoing
traffic by this value. The size of
outgoing IPsec SA counter this field depends on ESN bit. If bit:
if the ESN bit is ON,
it is 1, its size of is 8 octets else octets, otherwise it is 4
octets.

7. Implementation Details of implementation

The message Id used IKEV2_MESSAGE_ID_SYNC Message ID value used in the Informational exchange that contains
the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not
validated upon receipt as per required by normal IKEv2 windowing. The
Message Id ID zero MUST be permitted accepted only for informational in an Informational exchange
that would have NOTIFY contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any
INFORMATIONAL
Informational exchange uses the message Id Zero, without having has a Message ID zero, but not this
Notify, then
notification type, such packets messages MUST be discarded upon decryption
and the INVALID_SYNTAX notify notification SHOULD be sent. No other Other payloads are allowed
MUST NOT be sent in this Informational exchange. Whenever an
IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notify notification
payload is received with an invalid failover count or invalid nonce
data, the event SHOULD be logged.

The standby member can initiate the synchronization of IKEv2 Message
Id's
ID's under different circumstances.
o When it receives the bad a problematic IKEv2/IPsec packet. The 'bad" IKEv2/
IPsec packet means packet, i.e. a packet
outside its expected receive window.
o When it has to send an the first IKEv2/IPsec packet after a failover
event.
o It When it has just got the received control from active member and would require wishes to
update the values before-hand, proactively, so that it need not start this
exchange at the time of sending/receiving later, when sending or receiving the request.

The standby member can initiate the synchronization of IPsec SA
Counters
Replay Counters:
o If there is has been traffic using the IPsec SA in the recent past
and
there could be stale replay counter at the standby member suspects that its Replay Counter may be
stale.

Since there can be many a large number of sessions at Standby the standby member,
and sending synchronization exchanges from for all of the sessions can cause throttling, 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 receive the request. Thus In
general, the trigger standby member is free to initiate this exchange
depends on the requirement/discretion of the standby member.

The at its
discretion.

A cluster member which has not announced its capability by using
IKEV2_MESSAGE_ID_SYNC_SUPPORTED MUST NOT send/receive send or accept the notify
notification IKEV2_MESSAGE_ID_SYNC.

The

A cluster member which has not announced its capability by using
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED MUST NOT send/receive send or accept the notify
notification IPSEC_REPLAY_COUNTER_SYNC.

If a peer gets receives a IKEV2_MESSAGE_ID_SYNC or
IPSEC_REPLAY_COUNTER_SYNC request even though although it did had not announce its announced the
appropriate capability in the IKE_AUTH exchange, then it MUST
silently ignore this message.

As usual in IKEv2, if any of the Notify or the SYNC request/response notification payloads defined here
is malformed, then
it is treated as the receiver must announce this fact using the
INVALID_SYNTAX message. notification.

8. Step-by-Step details

The step Step by step details of Step Details

This section goes through the synchronization sequence of IKE message Id is
as follows. steps of a typical failover
event, where the IKEv2 Message ID values are synchronized.
o Active The active cluster member and the peer device establish the session .
session. They both announce the capability to sync the synchronize counter info
information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notify
notification in the IKE_AUTH Exchange.
o Active The active member dies dies, and Stand-by a standby member takes over. Standby Member The
standby member sends its own idea of the IKE Message ID (its side) IDs (both
incoming and outgoing) to the peer in an
INFORMATIONAL Informational message
exchange with message Id Message ID zero.
o The peer first authenticates the message and then validates that the
failover count. The peer will compare compares the received values with the
values available locally and finally picks the higher value. It then
updates its message Id's Message IDs with the higher values and also propose
the same values in Response. its response.
o The peer should not wait for any pending response responses while
responding with this message Id the new Message ID values. For example example, if the
window size is 5 and
peer the peer's window is 3-7 3-7, and if the peer has
sent requests 3, 4,5,6,7 4, 5, 6, 7 and
but got response received responses only for 4,5,6,7 4, 5,
6, 7 but not 3 for 3, then it should send include the EXPECTED_SEND_REQ_MESSAGE_ID as value 8 in its
EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a
response of to message 3 anymore.
o The Similarly, the peer should also not wait for pending request also. (incoming)
requests. For example if the window size is 5 and peer the peer's
window is 3-7 and if the peer has received requests 4,5,6,7 4, 5, 6, 7 but
not 3 3, then it should send the
EXPECTED_RECV_REQ_MESSAGE_ID as value 8 in the
EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not wait for expect to
receive message 3 anymore.

There is corner

In case with "failover count' and multiple failover.
What if "failover count" is successive failover events and sync request getting
lost, the failover count value at peer will not be updated on a member, and next
"failover" happened, then "failover count" new
standby member will become active with incremented failover count
value. So, peer can receive valid failover count value which is updated on other side
but not on this member. [[ This need to be discussed on mailing list.
]]
just incremented by 1 in case of multiple failover. Accepting
incremented failover count within a range is allowed and increases
interoperability.

9. Security Considerations

There

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 two types denial-
of-service (DoS) attacks, and we are aware of DOS attacks. two variants.
o Replay of Message SYNC Request. ID synchronization request: This is countered by "failover
count",
use of the Failover Count, since synchronization starts after the
failover event and each member of the cluster is needs to be aware of
the failover event. The receiver of
sync the synchronization request
should verify the received Failover Count and maintain failover count. its own
copy of it. If a peer
again receives a sync synchronization request with same "failover count', an
already observed Failover Count, it can safely safely discard the request
if it has already received valid IKEv2 request/response from other
side peer after sync exchange. The peer will be not be aware that
sync response has reached to other side till it receives a valid
IKEv2 request/response from other side. The peer can send the
cached response for sync request till it has not received valid
request/response from other side peer or failover count has not
increased.
o Replay of the Message SYNC Response. ID synchronization response: This is
countered by sending the
NONCE nonce data along with the sync notify. synchronization
payload. The same NONCE nonce data has to be returned in response.
Thus the standby member can will accept the a reply only for the current
request. After it receives the a valid response, it MUST NOT process
the same response again and MUST discard
the response. any additional responses.

10. Interaction with other drafts

The primary assumption usage scenario of the IKEv2/IPsec SA Counter Synchronization counter synchronization
proposal is that an IKEv2 SA has been established between the active
member of
Hot Standby Cluster a hot-standby cluster and a peer, after that the then a failover event
occurred
and now with the standby member has "become" becoming active. It also The proposal
further assumes that the IKEv2 SA state was synced continuously synchronized
between the active and standby member members of the
Hot Standby Cluster cluster before the
failover event.
o Session Resumption. Session resumption [RFC5723] assumes that a peer i.e.
client (client or initiator
initiator) detects the need to re-establish the session. In
IKEv2/IPsec SA counter synchronization, standby it is the newly-active
member which
becomes active i.e. (a gateway or responder responder) that detects the need to
synchronize the SA counter after the failover event. Also in Hot
Standby Cluster, a
hot-standby cluster, the 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, that represents 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 whole cluster, so the peers
peer normally does not detect the event of failover in the cluster
unless the standby member takes too long to become active and the group
IKEv2 SA times out by use of gateways that
constitute the cluster. IKEv2 liveness check mechanism.
To conclude, session resumption and SA counter synchronization
after failover are mutually exclusive.
o Redirect. The IKEv2 Redirect mechanism for load-balancing [RFC5685] can be
used either during init (IKE_SA_INIT) and auth (IKE_AUTH) the initial stages of SA setup (the IKE_SA_INIT
and IKE_AUTH exchanges) or after session establishment. While SA
counter sync synchronization is used only useful after the IKE SA has been
established and a failover event has occurred. So So, unlike
Redirect, it is
mutually exclusive with redirect irrelevant during init and auth. The
redirect the first two exchanges.
Redirect after the session has been established is used mostly useful
for timed or planned shutdown/maintenance. The A real failover event can not
cannot be detected on by the active member beforehand ahead of time, and so
using redirect Redirect after session establishment is not possible in the
case of failover. So, Redirect and SA counter synchronization
after failover are mutually exclusive.
o Crash detection. Solves the IKEv2 Failure Detection [I-D.ietf-ipsecme-failure-detection]
solves a similar problem where the peer can rapidly detect that a
cluster member has crashed based on a token. It is mutually
exclusive with HA with SA counter sync. unrelated to
the current scenario because the goal in failover is for the peer
not to notice that a failure has occurred.

11. IANA Considerations

This document introduces 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 IKEV2_MESSAGE_ID_SYNC_SUPPORTED.
o IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED.
o IKEV2_MESSAGE_ID_SYNC.
o IPSEC_REPLAY_COUNTER_SYNC.

12. Acknowledgements

We would like to thank Pratima Sethi and Frederic Detienne for their
reviews
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, Pekka
Riikonen, and Yaron Sheffar. Sheffer.

13. Change Log

This section lists all the changes in this document.

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

13.1. Draft -02

Addressed comments by Yaron Sheffer posted on the WG mailing list.

Numerous editorial changes.

13.2. Draft -01

Added "Multiple and Simultaneous failover' scenarios. scenarios as pointed out
by Pekka Riikonen.

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 Message ID sync to provide more clarity.

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

13.2.

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

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

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

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

[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
October 2010.

14.2. Informative References

[I-D.ietf-ipsecme-failure-detection]
Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
Quick Crash Detection Method for IKE",
draft-ietf-ipsecme-failure-detection-01 (work in
progress), October 2010.

[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
IKEv2",
the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5685, November 2009.

[RFC5723] Sheffer, Y. and H. Tschofenig, "IKEv2 "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
January 2010.

[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

Appendix A. IKEv2 Message Id examples

Below are the ID Sync Examples

This (non-normative) section presents some examples to that illustrate
how the IKEv2 message Id Message ID values are synced. The notation used to denote synchronized. We use a tuple
notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and
EXPECTED_RECV_REQ_MESSAGE_ID on a member is as
(EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).

A.1. Normal failover Failover - Example 1

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

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

A.2. Normal failover Failover - Example 2

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

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

A.3. Simultaneous failover Failover

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

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

request SYNC

Sync Request (4,4) ----->

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

response SYNC

Sync Response (5,5) ---->

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

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. St.
Tel Aviv 67897
Israel

Email: ynir@checkpoint.com

Dacheng Zhang
Huawei Technologies Ltd.

Email: zhangdacheng@huawei.com