draft-ietf-ipsecme-ipsecha-protocol-02.txt   draft-ietf-ipsecme-ipsecha-protocol-03.txt 
Network Working Group R. Singh, Ed. Network Working Group R. Singh, Ed.
Internet-Draft G. Kalyani Internet-Draft G. Kalyani
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: April 28, 2011 Y. Nir Expires: August 12, 2011 Y. Nir
Check Point Check Point
Y. Sheffer
Independent
D. Zhang D. Zhang
Huawei Huawei
October 25, 2010 February 8, 2011
Protocol Support for High Availability of IKEv2/IPsec Protocol Support for High Availability of IKEv2/IPsec
draft-ietf-ipsecme-ipsecha-protocol-02 draft-ietf-ipsecme-ipsecha-protocol-03
Abstract Abstract
The IPsec protocol suite is widely used for the deployment of virtual The IPsec protocol suite is widely used for business-critical network
private networks (VPNs). In order to make such VPNs highly traffic. In order to make IPsec deployments highly available, more
available, more scalable and failure-resistant, these VPNs are scalable and failure-resistant, they are often implemented as IPsec
implemented as IPsec High Availability (HA) clusters. However there High Availability (HA) clusters. However there are many issues in
are many issues in IPsec HA clustering, and in particular in IKEv2 IPsec HA clustering, and in particular in IKEv2 clustering. An
clustering. An earlier document, "IPsec Cluster Problem Statement", earlier document, "IPsec Cluster Problem Statement", enumerates the
enumerates the issues encountered in the IKEv2/IPsec HA cluster issues encountered in the IKEv2/IPsec HA cluster environment. This
environment. This document attempts to resolve these issues with the document attempts to resolve these issues with the least possible
least possible change to the protocol. change to the protocol.
This document proposes an extension to the IKEv2 protocol to solve This document proposes an extension to the IKEv2 protocol to solve
the main issues of "IPsec Cluster Problem Statement" in the commonly the main issues of "IPsec Cluster Problem Statement" in the commonly
deployed hot-standby cluster, and provides implementation advice for deployed hot-standby cluster, and provides implementation advice for
other issues. The main issues to be solved are the synchronization other issues. The main issues to be solved are the synchronization
of IKEv2 Message ID counters, and of IPsec Replay Counters. of IKEv2 Message ID counters, and of IPsec Replay Counters.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2011.
This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 5 3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6
4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 5 4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 7
5. Counter Synchronization Solution . . . . . . . . . . . . . . . 7 5. SA Counter Synchronization Solution . . . . . . . . . . . . . 8
6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 9 5.1. Processing Rules for IKE Message ID Synchronization . . . 10
6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED . . . . . . . . . . . . . 9 5.2. Processing Rules for IPsec Replay Counter
6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED . . . . . . . . . . . 10 Synchronization . . . . . . . . . . . . . . . . . . . . . 11
6.3. IKEV2_MESSAGE_ID_SYNC . . . . . . . . . . . . . . . . . . 10 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 11
6.4. IPSEC_REPLAY_COUNTER_SYNC . . . . . . . . . . . . . . . . 11 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 11
7. Implementation Details . . . . . . . . . . . . . . . . . . . . 12 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 12
8. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 13 6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 13
10. Interaction with other drafts . . . . . . . . . . . . . . . . 14 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 15
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 15
13.1. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 15
13.2. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 15
13.3. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Interaction with other drafts . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 17 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 17 14.1. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 18 14.2. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 18 14.3. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 14.4. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.1. Normative References . . . . . . . . . . . . . . . . . . . 19
15.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 20
A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 20
A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 20
A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The IPsec protocol suite, including IKEv2, is a major building block The IPsec protocol suite, including IKEv2, is a major building block
of virtual private networks (VPNs). In order to make such VPNs of virtual private networks (VPNs). In order to make such VPNs
highly available, more scalable and failure-resistant, these VPNs are highly available, more scalable and failure-resistant, these VPNs are
implemented as IKEv2/IPsec Highly Available (HA) cluster. However implemented as IKEv2/IPsec Highly Available (HA) cluster. However
there are many issues with the IKEv2/IPsec HA cluster. The problem there are many issues with the IKEv2/IPsec HA cluster. The problem
statement draft Section 4 enumerates the issues around the IKEv2/ statement draft Section 4 enumerates the issues around the IKEv2/
IPsec HA cluster solution. IPsec HA cluster solution.
skipping to change at page 3, line 34 skipping to change at page 4, line 34
and, possibly after a considerable amount of time, it becomes the and, possibly after a considerable amount of time, it becomes the
active member. During this failover process the peer is unaware of active member. During this failover process the peer is unaware of
the failover event, and keeps sending IKE requests and IPsec packets the failover event, and keeps sending IKE requests and IPsec packets
to the cluster, as in fact it is allowed to do because of the IKEv2 to the cluster, as in fact it is allowed to do because of the IKEv2
windowing feature. After the newly-active member starts, it detects windowing feature. After the newly-active member starts, it detects
the mismatch in IKE Message ID values and IPsec replay counters and the mismatch in IKE Message ID values and IPsec replay counters and
needs to resolve this situation. Please see Section 4 for more needs to resolve this situation. Please see Section 4 for more
details of the problem. details of the problem.
This document proposes an extension to the IKEv2 protocol to solve This document proposes an extension to the IKEv2 protocol to solve
main issues of IKE Message ID synchronization and IPsec SA replay the main issues of IKE Message ID synchronization and IPsec SA replay
counter synchronization and gives implementation advice for others. counter synchronization and gives implementation advice for others.
Following is a summary of the solutions provided in this document: Following is a summary of the solutions provided in this document:
o IKEv2 Message ID synchronization: this is done by syncing up the o IKEv2 Message ID synchronization: this is done by syncing up the
expected send and receive Message ID values with the peer, and expected send and receive Message ID values with the peer, and
updating the values at the newly active cluster member. updating the values at the newly active cluster member.
o IPsec Replay Counter synchronization: this is done by incrementing o IPsec Replay Counter synchronization: this is done by incrementing
the cluster's outgoing SA replay counter values by a "large" the cluster's outgoing SA replay counter values by a "large"
number, and synchronizing these values with the peer. The peer number; in addition, the newly-active member requests the peer to
send its outgoing SA reply counter in the response. increment the replay counter values it is using for the peer's
outgoing traffic.
Although this document describes the IKEv2 Message ID and IPsec Although this document describes the IKEv2 Message ID and IPsec
replay counter synchronization in the context of an IPsec HA cluster, replay counter synchronization in the context of an IPsec HA cluster,
the solution provided is generic and can be used in other scenarios the solution provided is generic and can be used in other scenarios
where IKEv2 Message ID or IPsec SA replay counter synchronization may where IKEv2 Message ID or IPsec SA replay counter synchronization may
be required. be required.
Implementations differ on the need to synchronize the IKEv2 Message Implementations differ on the need to synchronize the IKEv2 Message
ID and/or IPsec replay counters. Both of these problem are handled ID and/or IPsec replay counters. Both of these problems are handled
separately, using a separate notification for each capability. This separately, using a separate notification for each capability. This
provides the flexibility of implementing either or both of these provides the flexibility of implementing either or both of these
solutions. solutions.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [1].
"SA Counter Synchronization Request/Response" are the request viz. "SA Counter Synchronization Request/Response" are the request viz.
response of the information exchange defined in this document to response of the informational exchange defined in this document to
synchronize the IKEv2/IPsec SA counter information between one member synchronize the IKEv2/IPsec SA counter information between one member
of the cluster and the peer. of the cluster and the peer.
Some of the terms listed below are reused from [RFC6027] with further Some of the terms listed below are reused from [2] with further
clarification in the context of the current document. clarification in the context of the current document.
o "Hot Standby Cluster", or "HS Cluster" is a cluster where only one 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 of the members is active at any one time. This member is also
referred to as the "active" member, whereas the other(s) are referred to as the "active" member, whereas the other(s) are
referred to as "standby" members. VRRP [RFC5798] is one method of referred to as "standby" members. VRRP [5] is one method of
building such a cluster. The goal of Hot Standby Cluster is that building such a cluster. The goal of the Hot Standby Cluster is
it creates illusion of single virtual gateway to the peer(s). to create the illusion of a single virtual gateway to the peer(s).
o "Active Member" is the primary member in the Hot-Standby cluster. o "Active Member" is the primary member in the Hot-Standby cluster.
It is responsible for forwarding packets on behalf of the virtual It is responsible for forwarding packets on behalf of the virtual
gateway. gateway.
o "Standby Member" is the primary backup member. This member takes o "Standby Member" is the primary backup member. This member takes
control, i.e. becomes the active member, after the failover event. control, i.e. becomes the active member, after the failover event.
o "Peer" is an IKEv2/IPsec endpoint that maintains a VPN connection o "Peer" is an IKEv2/IPsec endpoint that maintains an IPsec
with the Hot-Standby cluster. The Peer identifies the cluster by connection with the Hot-Standby cluster. The Peer identifies the
the cluster's (single) IP address. If a failover event occurs, cluster by the cluster's (single) IP address. If a failover event
the standby member of the cluster becomes active, and the peer occurs, the standby member of the cluster becomes active, and the
normally doesn't notice that failover has taken place. peer normally doesn't notice that failover has taken place.
o "Failover Count" is a global failover event counter maintained by Although we treat the peer as a single entity, it may also be a
the HA cluster and incremented by 1 upon each failover event in cluster.
the HA cluster. All members of the HA cluster share the failover
count.
o "Multiple failover" is the situation where, in a cluster with o "Multiple failover" is the situation where, in a cluster with
three or more members, failover happens in rapid succession. It three or more members, multiple failover events happen in rapid
is our goal that the implementation should be able to handle this succession, e.g. from M1 to M2, and then to M3. It is our goal
situation, i.e. to handle the new failover event even if it is that the implementation should be able to handle this situation,
still processing the old failover. i.e. to handle the new failover event even if it is still
o "Simultaneous failover" is the situation where two clusters have a processing the old failover.
VPN connection between them, and failover happens at the both ends o "Simultaneous failover" is the situation where two clusters have
at the same time. It is our goal that implementation should be an IPsec connection between them, and failover happens at both
able to handle simultaneous failover. ends at the same time. It is our goal that implementations should
be able to handle simultaneous failover.
The generic term "IKEv2/IPsec SA Counters" is used throughout this The generic term "IKEv2/IPsec SA Counters" is used throughout this
document. This term refers to both IKEv2 Message ID counters document. This term refers to both IKEv2 Message ID counters and
(mandatory, and used to ensure reliable delivery as well as to IPsec replay counters. According to the IPsec standards, the IKEv2
protect against message replay in IKEv2) and IPsec SA replay counters Message ID counter is mandatory, and used to ensure reliable delivery
(optional, and used to provide the IPsec anti-replay feature). as well as to protect against message replay in IKEv2; the IPsec SA
replay counters are optional, and are used to provide the IPsec anti-
replay feature.
3. Issues Resolved from IPsec Cluster Problem Statement 3. Issues Resolved from IPsec Cluster Problem Statement
The IPsec Cluster Problem Statement [RFC6027] enumerates the problems The IPsec Cluster Problem Statement [2] enumerates the problems
raised by IPsec clusters. The following table lists the problem raised by IPsec clusters. The following table lists the problem
statement's sections that are resolved by this document. statement's sections that are resolved by this document.
o 3.2. Lots of Long Lived State o 3.2. Lots of Long Lived State
o 3.3. IKE Counters o 3.3. IKE Counters
o 3.4. Outbound SA Counters o 3.4. Outbound SA Counters
o 3.5. Inbound SA Counters o 3.5. Inbound SA Counters
o 3.6. Missing Synchronization Messages o 3.6. Missing Synchronization Messages
o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members o 3.7. Simultaneous use of IKE and IPsec SAs by Different Members
* 3.7.1. Outbound SAs using counter modes * 3.7.1. Outbound SAs using counter modes
o 3.8. Different IP addresses for IKE and IPsec o 3.8. Different IP addresses for IKE and IPsec
o 3.9. Allocation of SPIs o 3.9. Allocation of SPIs
The main problem areas are solved using the protocol extension The main problem areas are solved using the protocol extension
defined below, and additionally this document provides implementation defined below; additionally, this document provides implementation
advice for other issues, given as follows. advice for other issues, as follows.
o 3.2 This section mentions that there is a large amount of state o Section 3.2 of the Problem Statement mentions that there is a
that needs to be synchronized. However if state is not large amount of state that needs to be synchronized. However if
synchronized, this is not really an interesting cluster: failover state is not synchronized, this is not really an interesting
is equivalent to a reboot of the cluster member, and so the issue cluster: failover is equivalent to a reboot of the cluster member,
need not be solved with protocol extensions. and so the issue need not be solved with a protocol extension.
o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see
Section 4, for more details. Section 4, for more details.
o 3.7 is an implementation problem that needs to be solved while o 3.7 is an implementation problem that needs to be solved while
building IPsec clusters. However, the peers should be required to building IPsec clusters. However, the peers should be required to
accept multiple parallel SAs for 3.7.1. accept multiple parallel SAs for 3.7.1.
o 3.8 can be solved by using the IKEv2 Redirect mechanism [RFC5685]. o 3.8 can be solved by using the IKEv2 Redirect mechanism [6].
o 3.9 discusses the avoidance of collisions where the same SPI value o 3.9 discusses the avoidance of collisions where the same SPI value
is used by multiple cluster members. This is outside the is used by multiple cluster members. This is outside the
document's scope since the problem needs to be solved internally document's scope since the problem needs to be solved internally
to the cluster and does not involve the peer. to the cluster and does not involve the peer.
4. The IKEv2/IPsec SA Counter Synchronization Problem 4. The IKEv2/IPsec SA Counter Synchronization Problem
The IKEv2 protocol [RFC5996] states that "An IKE endpoint MUST NOT The IKEv2 protocol [3] states that "An IKE endpoint MUST NOT exceed
exceed the peer's stated window size for transmitted IKE requests". the peer's stated window size for transmitted IKE requests".
All IKEv2 messages are required to follow a request-response All IKEv2 messages are required to follow a request-response
paradigm. The initiator of an IKEv2 request MUST retransmit the paradigm. The initiator of an IKEv2 request MUST retransmit the
request, until it has received a response from the peer. IKEv2 request, until it has received a response from the peer. IKEv2
introduces a windowing mechanism that allows multiple requests to be introduces a windowing mechanism that allows multiple requests to be
outstanding at a given point of time, but mandates that the sender outstanding at a given point of time, but mandates that the sender's
window should not move until the oldest message sent from one peer to window should not move until the oldest message it has sent is
another is acknowledged. Loss of even a single message leads to acknowledged. Loss of even a single message leads to repeated
repeated retransmissions followed by an IKEv2 SA teardown if the retransmissions followed by an IKEv2 SA teardown if the
retransmissions are unacknowledged. retransmissions remain unacknowledged.
An IPsec Hot Standby Cluster is required to ensure that in the case An IPsec Hot Standby Cluster is required to ensure that in the case
of failover, the standby member becomes active immediately. The of failover, the standby member becomes active immediately. The
standby member is expected to have the exact value of the Message ID standby member is expected to have the exact value of the Message ID
counter as the active member had before failover. Even assuming the counter as the active member had before failover. Even assuming the
best effort to update the Message ID values from active to standby best effort to update the Message ID values from active to standby
member, the values at the standby member can still be stale due to member, the values at the standby member can still be stale due to
the following reasons: the following reasons:
o The standby member is unaware of the last message that was o The standby member is unaware of the last message that was
received and acknowledged by the previously active member, as the received and acknowledged by the previously active member, as the
failover event could have happened before the standby member could failover event could have happened before the standby member could
be updated. be updated.
o The standby member does not have information about on-going o The standby member does not have information about on-going
unacknowledged requests received by the previously active member. unacknowledged requests sent by the previously active member. As
As a result after the failover event, the newly active member a result after the failover event, the newly active member cannot
cannot retransmit those requests. retransmit those requests.
When a standby member takes over as the active member, it can only When a standby member takes over as the active member, it can only
initialize the Message ID values from the previously updated values. initialize the Message ID values from the previously updated values.
This would make it reject requests from the peer when these values This would make it reject requests from the peer when these values
are stale. Conversely, the standby member may end up reusing a stale are stale. Conversely, the standby member may end up reusing a stale
Message ID value which would cause the peer to drop the request. Message ID value which would cause the peer to drop the request.
Eventually there is a high probability of the IKEv2 and corresponding Eventually there is a high probability of the IKEv2 and corresponding
IPsec SAs getting torn down simply because of a transitory Message ID IPsec SAs getting torn down simply because of a transitory Message ID
mismatch and retransmission of requests, negating the benefits of the mismatch and retransmission of requests, negating the benefits of the
high availability cluster despite the periodic update between the high availability cluster despite the periodic update between the
cluster members. cluster members.
A similar issue is also observed with IPsec anti-replay counters if A similar issue is also observed with IPsec anti-replay counters if
anti-replay protection/ESN is implemented, which is commonly the anti-replay protection is enabled, which is commonly the case.
case. Regardless of how well the ESP and AH SA counters are Regardless of how well the ESP and AH SA counters are synchronized
synchronized from the active to the standby member, there is a chance from the active to the standby member, there is a chance that the
that the standby member would end up with stale counter values. The standby member would end up with stale counter values. The standby
standby member would then use those stale counter values when sending member would then use those stale counter values when sending IPsec
IPsec packets. The peer would reject/drop such packets since when packets. The peer would reject/drop such packets since when the
the anti-replay protection feature is enabled, duplicate use of anti-replay protection feature is enabled, duplicate use of counters
counters is not allowed. Note that IPsec allows the sender to skip is not allowed. Note that IPsec allows the sender to skip some
some counter values and continue sending with higher counter values. counter values and continue sending with higher counter values.
We conclude that a mechanism is required to ensure that the standby We conclude that a mechanism is required to ensure that the standby
member has correct Message ID and IPsec counter values when it member has correct Message ID and IPsec counter values when it
becomes active, so that sessions are not torn down as a result of becomes active, so that sessions are not torn down as a result of
mismatched counters. mismatched counters.
5. Counter Synchronization Solution 5. SA Counter Synchronization Solution
In general, when the standby member becomes the active member after This document proposes two separate approaches to resolving the
the failover event, the standby member sends an authenticated IKEv2 issues of mismatched IKE Message ID values and IPsec counter values.
request to the peer, asking it to send its SA counter values.
The standby member then updates its own SA counter values and can o In the case of IKE Message ID values, the newly active cluster
resume normally sending and receiving protocol messages. member and the peer negotiate a pair of new values so that future
IKE messages will not be dropped.
o For IPsec counter values, the newly-active member and the peer
both increment their respective counter values, "skipping forward"
by a large number, to ensure that no IPsec counters are ever
reused.
First, the peer MUST negotiate its ability to support IKEv2 Message Although conceptually separate, the two synchronization processes
ID synchronization with the active member of the cluster by sending would typically take place simultaneously.
the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in the IKE_AUTH
exchange.
Similarly, to support IPsec Replay Counter synchronization, the peer First, the peer and the active member of the cluster negotiate their
MUST negotiate this capability with the active member of the cluster ability to support IKEv2 Message ID synchronization and/or IPsec
by sending the IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notification in Replay Counter synchronization. This is done by exchanging one or
the IKE_AUTH exchange. both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH
exchange. When negotiating these capabilities, the responder MUST
NOT assert support of a capability unless such support was asserted
by the initiator. Only a capability whose support was asserted by
both parties can be used during the lifetime of the SA.
This per-IKE SA information is shared with the other cluster members.
Peer Active Member Peer Active Member
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH, HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
SAi2, TSi, TSr} ----------> SAi2, TSi, TSr} ---------->
<-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH, <-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
[N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),] [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
[N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] SAr2, TSi, TSr} [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),] SAr2, TSi, TSr}
When the peer and active member both support SA counter After a failover event, the standby member MAY use the IKE Message ID
synchronization, the active member MUST inform the standby member of and/or IPsec Replay Counter synchronization capability when it
the SA counter synchronization capability after the establishment of becomes the active member, and provided support for the capabilities
the IKE SA. The standby member can then use this capability when it used has been negotiated. Following that, the peer MUST respond to
becomes the active member after a failover event. any synchronization message it receives from the newly-active cluster
member, subject to the rules noted below.
After the failover event, when the standby member becomes active, it After the failover event, when the standby member becomes active, it
has to request the SA counters from the peer. The newly-active has to synchronize its SA counters with the peer. There are now
member initiates the synchronization request with an Informational three possible cases:
exchange with Message ID zero containing either the notification
IKEV2_MESSAGE_ID_SYNC or the two notifications IKEV2_MESSAGE_ID_SYNC
and IPSEC_REPLAY_COUNTER_SYNC, depending on whether the
synchronization is to be done for IKEv2 Message IDs or for both IKEv2
Message IDs and IPsec replay 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 synchronization request sends
its expected send and receive Message ID values and "failover count"
in a IKEV2_MESSAGE_ID_SYNC notification. The responder compares the
received values with its local values. For both send and receive
values, The higher between the cluster member's and the local value
is selected, and sent in the response message with the notification
IKEV2_MESSAGE_ID_SYNC. The initiator now updates its send and
receive IKEv2 Message IDs to the values received in the response and
can now start a normal IKEv2 message exchange.
The initiator of an IPsec Replay Counter synchronization sends the 1. The cluster member wishes to only perform IKE Message ID value
incremented outgoing IPsec SA reply counter value and a "failover synchronization. In this case it initiates an Informational
count" in a IPSEC_REPLAY_COUNTER_SYNC notification in IKEv2 exchange, with Message ID zero and the sole notification
INFORMATIONAL exchange. The responder updates its incoming IPsec SA IKEV2_MESSAGE_ID_SYNC.
counter values according to the received value. The responder now 2. If the newly-active member wishes to perform only IPsec replay
sends its own incremented outgoing IPsec SA Replay Counter value in a counter synchronization, it generates a regular IKEv2
synchronization response message, with the same Informational exchange using the current Message ID values, and
IPSEC_REPLAY_COUNTER_SYNC notification. The initiator can now update containing the IPSEC_REPLAY_COUNTER_SYNC notification.
its incoming IPsec SA counter to values received in the response 3. If synchronization of both counters is needed, the cluster member
message and can start normal IPsec data traffic. generates a zero-Message ID message as in case #1, and includes
both notifications in this message.
The IKEV2_MESSAGE_ID_SYNC notification payload contain nonce data to This figure contains the IKE message exchange used for SA counter
avoid a denial-of-service (DoS) attack due to replay of SA counter synchronization. The following subsections describe the details of
synchronization response. The nonce values are selected randomly on the sender and receiver processing of each message.
each new notification and MUST be validated by the receiver. The
nonce data sent in the response MUST match the nonce data sent by the
newly-active member in its request. If the nonce data received in
the response does not match the request's nonce data, the cluster
member MUST silently discard this response, and SHOULD revert to
normal IKEv2 behavior of retransmitting the request and waiting for a
genuine a reply from the peer. Eventually this might result in the
SA being torn down because of excessive retransmissions.
Standby [Newly Active] Member Peer Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK {N(IKEV2_MESSAGE_ID_SYNC), HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} --------> [N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->
<--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
[N(IPSEC_REPLAY_COUNTER_SYNC)]} <--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}
Alternatively, if only IPsec Replay Counter synchronization is Alternatively, if only IPsec Replay Counter synchronization is
desired, a normal Information exchange is used, where the Message ID desired, a normal Informational exchange is used, where the Message
is non-zero: ID is non-zero:
Standby [Newly Active] Member Peer Standby [Newly Active] Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} --------> HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->
<--------- HDR, SK {N(IPSEC_REPLAY_COUNTER_SYNC)} <--------- HDR
5.1. Processing Rules for IKE Message ID Synchronization
The newly-active member sends a request containing two counter value,
one for the member (itself) and another for the peer, as well as a
random nonce. We denote the values M1 and P1. The peer responds
with a message containing two counter values, M2 and P2. The goal of
the rules below is to prevent an attacker from replaying a
synchronization message, thereby invalidating IKE messages that are
currently in process.
o M1 is the next sender's Message ID to be used by the member. M1
MUST be chosen so that it is larger than any value known to have
been used. It is RECOMMENDED to increment the known value at
least by the size of the IKE sender window.
o P1 SHOULD be 1 more than the last Message ID value received from
the peer, but may be any higher value.
o The member SHOULD communicate the sent values to the other cluster
members, so that if a second failover event takes place, the
synchronization message is not replayed. Such a replay would
result in the eventual deletion of the IKE SA (see below).
o The peer MUST reject any received synchronization message if M1 is
lower than or equal to the highest value it has seen from the
cluster. This includes any previous received synchronization
messages.
o M2 MUST be at least the higher of the received M1, and one more
than the highest sender value received from the cluster. This
includes any previous received synchronization messages.
o P2 MUST be the higher of the received P1 value, and one more than
the highest sender value used by the peer.
o The request contains a Nonce field. This field MUST be returned
in the response, unchanged. A response MUST be silently dropped
if the received Nonce does not match the one that was sent.
o Both the request and the response MUST NOT contain any additional
payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC
notification in the request.
o The request and the response MUST both be sent with a Message ID
value of zero.
5.2. Processing Rules for IPsec Replay Counter Synchronization
Upon failover, the newly-active member MUST increment its own Replay
Counter (the counter used for outgoing traffic), so as to prevent the
case of its traffic being dropped by the peer as replay. We note
that IPsec allows the replay counter to skip forward by any amount.
The estimate is based on the outgoing IPsec bandwidth and the
frequency of synchronization between cluster members. In those
implementations where it is difficult to estimate this value, the
counter can be incremented by a very large number, e.g. 2**30. In
the latter case, a rekey SHOULD follow shortly afterwards, to ensure
that the counter never wraps around.
Next, the cluster member estimates the number of incoming messages it
might have missed, using similar logic. The member sends out a
IPSEC_REPLAY_COUNTER_SYNC notification, either stand-alone or
together with a IKEV2_MESSAGE_ID_SYNC notification.
If the IPSEC_REPLAY_COUNTER_SYNC is included in the same message as
IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID
notification first (which might cause the entire message to be
dropped as a replay). Then, it MUST increment the replay counters
for all Child SAs associated with the current IKE SA by the amount
requested by the cluster member.
6. IKEv2/IPsec Synchronization Notification Payloads 6. IKEv2/IPsec Synchronization Notification Payloads
This section lists the new notification payloads types defined by This section lists the new notification payload types defined by this
this extension. extension.
6.1. IKEV2_MESSAGE_ID_SYNC_SUPPORTED 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification
IKEV2_MESSAGE_ID_SYNC_SUPPORTED: This notification payload is This notification payload is included in the IKE_AUTH request/
included in the IKE_AUTH request/response to indicate support of the response to indicate support of the IKEv2 Message ID synchronization
IKEv2 Message ID synchronization mechanism described in this mechanism described in this document.
document.
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
'Notify Message Type' fields are the same as described in Section 3 'Notify Message Type' fields are the same as described in Section 3
of [RFC5996] . The 'SPI Size' field MUST be set to 0 to indicate of [3]. The 'SPI Size' field MUST be set to 0 to indicate that the
that the SPI is not present in this message. The 'Protocol ID' MUST SPI is not present in this message. The 'Protocol ID' MUST be set to
be set to 0, since the notification is not specific to a particular 0, since the notification is not specific to a particular security
security association. The 'Payload Length' field is set to the association. The 'Payload Length' field is set to the length in
length in octets of the entire payload, including the generic payload octets of the entire payload, including the generic payload header.
header. The 'Notify Message Type' field is set to indicate The 'Notify Message Type' field is set to indicate
IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data IKEV2_MESSAGE_ID_SYNC_SUPPORTED, value TBD by IANA. There is no data
associated with this notification. associated with this notification.
6.2. IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED: This notification payload is This notification payload is included in the IKE_AUTH request/
included in the IKE_AUTH request/response to indicate support for the response to indicate support for the IPsec SA Replay Counter
IPsec SA Replay Counter synchronization mechanism described in this synchronization mechanism described in this document.
document.
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size', and
'Notify Message Type' fields are the same as described in Section 3 'Notify Message Type' fields are the same as described in Section 3
of [RFC5996] . The 'SPI Size' field MUST be set to 0 to indicate of [3] . The 'SPI Size' field MUST be set to 0 to indicate that the
that the SPI is not present in this message. The 'Protocol ID' MUST SPI is not present in this message. The 'Protocol ID' MUST be set to
be set to 0, since the notification is not specific to a particular 0, since the notification is not specific to a particular security
security association. The 'Payload Length' field is set to the association. The 'Payload Length' field is set to the length in
length in octets of the entire payload, including the generic payload octets of the entire payload, including the generic payload header.
header. The 'Notify Message Type' field is set to indicate The 'Notify Message Type' field is set to indicate
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED, value TBD by IANA. There is no
data associated with this notification. data associated with this notification.
6.3. IKEV2_MESSAGE_ID_SYNC 6.3. The IKEV2_MESSAGE_ID_SYNC Notification
IKEV2_MESSAGE_ID_SYNC : This notification payload type (value TBD by This notification payload type (value TBD by IANA) is defined to
IANA) is defined to synchronize the IKEv2 Message ID values between synchronize the IKEv2 Message ID values between the newly-active
the newly-active (formerly standby) cluster member and the peer. (formerly standby) cluster member and the peer.
1 2 3 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 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 | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failover Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce Data | | Nonce Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_SEND_REQ_MESSAGE_ID | | EXPECTED_SEND_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPECTED_RECV_REQ_MESSAGE_ID | | EXPECTED_RECV_REQ_MESSAGE_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It contains the following data. It contains the following data.
o Failover Count (4 octets): a running count of failover events
between cluster members, it is initialized to 0 when the cluster
is first set up, and incremented by 1 upon each failover event.
o Nonce Data (4 octets): the random nonce data. The data should be o Nonce Data (4 octets): the random nonce data. The data should be
identical in the synchronization request and response. identical in the synchronization request and response.
o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): this field is used by the o EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): this field is used by the
sender of this notification payload to indicate the Message ID it sender of this notification payload to indicate the Message ID it
will use in the next request that it will send to the other will use in the next request that it will send to the other
protocol peer. protocol peer.
o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): this field is used by the o EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): this field is used by the
sender of this notification payload to indicate the Message ID it sender of this notification payload to indicate the Message ID it
is expecting in the next request to be received from the other is expecting in the next request to be received from the other
protocol peer. protocol peer.
6.4. IPSEC_REPLAY_COUNTER_SYNC 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification
IPSEC_REPLAY_COUNTER_SYNC: This notification payload type (value TBD This notification payload type (value TBD by IANA) is defined to
by IANA) is defined to synchronize the IPsec SA Replay Counters synchronize the IPsec SA Replay Counters between the newly-active
between the newly-active (formerly standby) cluster member and the (formerly standby) cluster member and the peer. Since there may be
peer. Since there may be numerous IPsec SAs established under a numerous IPsec SAs established under a single IKE SA, we do not
single IKE SA, we do not directly synchronize the value of each one. directly synchronize the value of each one. Instead, a delta value
Instead, a delta value is sent and all Replay Counters for child SAs is sent and all Replay Counters for Child SAs of this IKE SA are
of this IKE SA are incremented by the same value. Note that this incremented by the same value. Note that this solution requires that
solution requires that all these Child SAs either use or do not use all these Child SAs either use or do not use Extended Sequence
Extended Sequence Numbers [RFC4301]. Numbers [4]. This notification is only sent by the cluster.
1 2 3 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 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 |E| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing IPsec SA counter | | Incoming IPsec SA delta value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The notification payload contains the following data. The notification payload contains the following data.
o E (1 bit): The ESN bit. This MUST be 1 if the IPsec SAs were o Incoming IPsec SA delta value (4 or 8 octets): The sender requests
established with Extended Sequence Numbers. that the peer should increment all the Child SA Replay Counters
o Outgoing IPsec SA delta value (4 or 8 octects): The sender will for the sender's incoming (the peer's outgoing) traffic by this
increment the all the Child SA Replay Counters for its outgoing value. The size of this field depends on the ESN bit associated
traffic by this value. The size of this field depends on ESN bit: with the Child SAs: if the ESN bit is 1, the field's size is 8
if the ESN bit is 1, its size is 8 octets, otherwise it is 4 octets, otherwise it is 4 octets. We note that this constrains
octets. the Child SAs of each IKE SA to either all have the ESN bit on or
off.
7. Implementation Details 7. Implementation Details
The Message ID value used in the Informational exchange that contains This protocol does not change any of the existing IKEv2 rules
the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not regarding Message ID values.
validated upon receipt as required by normal IKEv2 windowing. The
Message ID zero MUST be accepted only in an Informational exchange
that contains a notification of type IKEV2_MESSAGE_ID_SYNC. If any
Informational exchange has a Message ID zero, but not this
notification type, such messages MUST be discarded upon decryption
and the INVALID_SYNTAX notification SHOULD be sent. Other payloads
MUST NOT be sent in this Informational exchange. Whenever an
IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC 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 The standby member can initiate the synchronization of IKEv2 Message
ID's under different circumstances. ID's under different circumstances.
o When it receives a problematic IKEv2/IPsec packet, i.e. a packet o When it receives a problematic IKEv2/IPsec packet, i.e. a packet
outside its expected receive window. outside its expected receive window.
o When it has to send the first IKEv2/IPsec packet after a failover o When it has to send the first IKEv2/IPsec packet after a failover
event. event.
o When it has just received control from active member and wishes to o When it has just received control from the active member and
update the values proactively, so that it need not start this wishes to update the values proactively, so that it need not start
exchange later, when sending or receiving the request. this exchange later, when sending or receiving the request.
The standby member can initiate the synchronization of IPsec SA The standby member can initiate the synchronization of IPsec SA
Replay Counters: Replay Counters:
o If there has been traffic using the IPsec SA in the recent past o If there has been traffic using the IPsec SA in the recent past
and the standby member suspects that its Replay Counter may be and the standby member suspects that its Replay Counter may be
stale. stale.
Since there can be a large number of sessions at the standby member, Since there can be a large number of sessions at the standby member,
and sending synchronization exchanges for all of them may result in and sending synchronization exchanges for all of them may result in
overload, the standby member can choose to initiate the exchange in a overload, the standby member can choose to initiate the exchange in a
"lazy" fashion: only when it has to send or receive the request. In "lazy" fashion: only when it has to send or receive the request. In
general, the standby member is free to initiate this exchange at its general, the standby member is free to initiate this exchange at its
discretion. discretion.
A cluster member which has not announced its capability by using 8. IKE SA and IPsec SA Message Sequencing
IKEV2_MESSAGE_ID_SYNC_SUPPORTED MUST NOT send or accept the
notification IKEV2_MESSAGE_ID_SYNC.
A cluster member which has not announced its capability by using The straightforward definitions of message sequence numbers,
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED MUST NOT send or accept the retransmissions and replay protection in IPsec and IKEv2 are strained
notification IPSEC_REPLAY_COUNTER_SYNC. by the failover scenarios described in this document. This section
describes some policy choices that need to be made by implementations
in this setting.
If a peer receives a IKEV2_MESSAGE_ID_SYNC or 8.1. Handling of Pending IKE Messages
IPSEC_REPLAY_COUNTER_SYNC request although it had not announced the
appropriate capability in the IKE_AUTH exchange, then it MUST
silently ignore this message.
As usual in IKEv2, if any of the notification payloads defined here After sending its "receive" counter, the cluster member MUST reject
is malformed, the receiver must announce this fact using the any incoming IKE messages that are outside its declared window. A
INVALID_SYNTAX notification. similar rule applies to the peer. Local policies vary, and strict
implementations will reject any incoming IKE message arriving before
Message ID synchronization is complete.
8. Step by Step Details 8.2. Handling of Pending IPsec Messages
For IPsec, there is often a trade-off between security and
reliability of the protected protocols. Here again there is some
leeway for local policy. Some implementations might accept incoming
traffic that is outside the replay window for some time after the
failover event. Strict implementations will only accept traffic
that's inside the "safe" window.
8.3. IKE SA Inconsistencies
IKEv2 is normally a reliable protocol. As long as an IKE SA is
valid, both peers share a single, consistent view of the IKE SA and
all associated Child SAs. Failover situations as described in this
document may involve forced deletion of IKE messages, resulting in
inconsistencies, such as Child SAs that exist on only one of the
peers. Such SAs would cause an INVALID_SPI to be returned when used
by that peer.
The Working Group discussed at some point a proposed set of rules for
dealing with such situations. However we believe that these
situations should be rare in practice; as a result the "default"
behavior of tearing down the entire IKE SA is to be preferred over
the complexity of dealing with a multitude of edge cases.
9. Step by Step Details
This section goes through the sequence of steps of a typical failover This section goes through the sequence of steps of a typical failover
event, where the IKEv2 Message ID values are synchronized. event, looking at a case where the IKEv2 Message ID values are
synchronized.
o The active cluster member and the peer device establish the o The active cluster member and the peer device establish the
session. They both announce the capability to synchronize counter session. They both announce the capability to synchronize counter
information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED information by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED
notification in the IKE_AUTH Exchange. notification in the IKE_AUTH Exchange.
o The active member dies, and a standby member takes over. The o Some time later, the active member dies, and a standby member
standby member sends its own idea of the IKE Message IDs (both takes over. The standby member sends its own idea of the IKE
incoming and outgoing) to the peer in an Informational message Message IDs (both incoming and outgoing) to the peer in an
exchange with Message ID zero. Informational message exchange with Message ID zero.
o The peer first authenticates the message and then validates the
failover count. The peer compares the received values with the o The peer first authenticates the message. The peer compares the
values available locally and picks the higher value. It then received values with the values available locally and picks the
updates its Message IDs with the higher values and also propose higher value. It then updates its Message IDs with the higher
the same values in its response. values and also propose the same values in its response.
o The peer should not wait for any pending responses while o The peer should not wait for any pending responses while
responding with the new Message ID values. For example, if the responding with the new Message ID values. For example, if the
window size is 5 and the peer's window is 3-7, and if the peer has window size is 5 and the peer's window is 3-7, and if the peer has
sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5, sent requests 3, 4, 5, 6, 7 and received responses only for 4, 5,
6, 7 but not for 3, then it should include the value 8 in its 6, 7 but not for 3, then it should include the value 8 in its
EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a EXPECTED_SEND_REQ_MESSAGE_ID payload and should not wait for a
response to message 3 anymore. response to message 3 anymore.
o Similarly, the peer should also not wait for pending (incoming) o Similarly, the peer should also not wait for pending (incoming)
requests. For example if the window size is 5 and the peer's requests. For example if the window size is 5 and the peer's
window is 3-7 and if the peer has received requests 4, 5, 6, 7 but window is 3-7 and if the peer has received requests 4, 5, 6, 7 but
not 3, then it should send the value 8 in the not 3, then it should send the value 8 in the
EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to EXPECTED_RECV_REQ_MESSAGE_ID payload, and should not expect to
receive message 3 anymore. receive message 3 anymore.
In case multiple successive failover events and sync request getting
lost, the failover count value at peer will not be updated and new
standby member will become active with incremented failover count
value. So, peer can receive valid failover count value which is not
just incremented by 1 in case of multiple failover. Accepting
incremented failover count within a range is allowed and increases
interoperability.
9. Security Considerations
Since Message ID synchronization messages need to be sent with
Message ID zero, they are potentially vulnerable to replay attacks.
Because of the semantics of this protocol, these can only be denial-
of-service (DoS) attacks, and we are aware of two variants.
o Replay of Message ID synchronization request: This is countered by
use of the Failover Count, since synchronization starts after the
failover event and each member of the cluster needs to be aware of
the failover event. The receiver of the synchronization request
should verify the received Failover Count and maintain its own
copy of it. If a peer receives a synchronization request with an
already observed Failover Count, it can 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 ID synchronization response: This is
countered by sending the nonce data along with the synchronization
payload. The same nonce data has to be returned in response.
Thus the standby member will accept a reply only for the current
request. After it receives a valid response, it MUST NOT process
the same response again and MUST discard any additional responses.
10. Interaction with other drafts 10. Interaction with other drafts
The usage scenario of the IKEv2/IPsec SA counter synchronization The usage scenario of the IKEv2/IPsec SA counter synchronization
proposal is that an IKEv2 SA has been established between the active proposal is that an IKEv2 SA has been established between the active
member of a hot-standby cluster and a peer, then a failover event member of a hot-standby cluster and a peer, then a failover event
occurred with the standby member becoming active. The proposal occurred with the standby member becoming active. The proposal
further assumes that the IKEv2 SA state was continuously synchronized further assumes that the IKEv2 SA state was continuously synchronized
between the active and standby members of the cluster before the between the active and standby members of the cluster before the
failover event. failover event.
o Session resumption [RFC5723] assumes that a peer (client or o Session resumption [7] assumes that a peer (client or initiator)
initiator) detects the need to re-establish the session. In detects the need to re-establish the session. In IKEv2/IPsec SA
IKEv2/IPsec SA counter synchronization, it is the newly-active counter synchronization, it is the newly-active member (a gateway
member (a gateway or responder) that detects the need to or responder) that detects the need to synchronize the SA counter
synchronize the SA counter after the failover event. Also in a after the failover event. Also in a hot-standby cluster, the peer
hot-standby cluster, the peer establishes the IKEv2/IPsec session establishes the IKEv2/IPsec session with a single IP address that
with a single IP address that represents the whole cluster, so the represents the whole cluster, so the peer normally does not detect
peer normally does not detect the event of failover in the cluster the event of failover in the cluster unless the standby member
unless the standby member takes too long to become active and the takes too long to become active and the IKEv2 SA times out by use
IKEv2 SA times out by use of the IKEv2 liveness check mechanism. of the IKEv2 liveness check mechanism. To conclude, session
To conclude, session resumption and SA counter synchronization resumption and SA counter synchronization after failover are
after failover are mutually exclusive. mutually exclusive.
o The IKEv2 Redirect mechanism for load-balancing [RFC5685] can be o The IKEv2 Redirect mechanism for load-balancing [6] can be used
used either during the initial stages of SA setup (the IKE_SA_INIT either during the initial stages of SA setup (the IKE_SA_INIT and
and IKE_AUTH exchanges) or after session establishment. SA IKE_AUTH exchanges) or after session establishment. SA counter
counter synchronization is only useful after the IKE SA has been synchronization is only useful after the IKE SA has been
established and a failover event has occurred. So, unlike established and a failover event has occurred. So, unlike
Redirect, it is irrelevant during the first two exchanges. Redirect, it is irrelevant during the first two exchanges.
Redirect after the session has been established is mostly useful Redirect after the session has been established is mostly useful
for timed or planned shutdown/maintenance. A real failover event for timed or planned shutdown/maintenance. A real failover event
cannot be detected by the active member ahead of time, and so cannot be detected by the active member ahead of time, and so
using Redirect after session establishment is not possible in the using Redirect after session establishment is not possible in the
case of failover. So, Redirect and SA counter synchronization case of failover. So, Redirect and SA counter synchronization
after failover are mutually exclusive. after failover are mutually exclusive.
o IKEv2 Failure Detection [I-D.ietf-ipsecme-failure-detection] o IKEv2 Failure Detection [8] solves a similar problem where the
solves a similar problem where the peer can rapidly detect that a peer can rapidly detect that a cluster member has crashed based on
cluster member has crashed based on a token. It is unrelated to a token. It is unrelated to the current scenario because the goal
the current scenario because the goal in failover is for the peer in failover is for the peer not to notice that a failure has
not to notice that a failure has occurred. occurred.
11. IANA Considerations 11. Security Considerations
Since Message ID synchronization messages need to be sent with
Message ID zero, they are potentially vulnerable to replay attacks.
Because of the semantics of this protocol, these can only be denial-
of-service (DoS) attacks, and we are aware of two variants.
o Replay of Message ID synchronization request: This is countered by
the requirement that the Send counter sent by the cluster member
should always be monotonically increasing, a rule that the peer
enforces by silently dropping messages that contradict it.
o Replay of the Message ID synchronization response: This is
countered by sending the nonce data along with the synchronization
payload. The same nonce data has to be returned in the response.
Thus the standby member will accept a reply only for the current
request. After it receives a valid response, it MUST NOT process
the same response again and MUST discard any additional responses.
12. IANA Considerations
This document introduces four new IKEv2 Notification Message types as This document introduces four new IKEv2 Notification Message types as
described in Section 6.The new Notify Message Types must be assigned described in Section 6. The new Notify Message Types must be
values between 16396 and 40959. 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 +-------------------------------------+-------------+
| Name | Value |
+-------------------------------------+-------------+
| IKEV2_MESSAGE_ID_SYNC_SUPPORTED | TBD by IANA |
| IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | TBD by IANA |
| IKEV2_MESSAGE_ID_SYNC | TBD by IANA |
| IPSEC_REPLAY_COUNTER_SYNC | TBD by IANA |
+-------------------------------------+-------------+
13. Acknowledgements
We would like to thank Pratima Sethi and Frederic Detienne for their We would like to thank Pratima Sethi and Frederic Detienne for their
review comments and valuable suggestions for the initial version of review comments and valuable suggestions for the initial version of
the document. the document.
We would also like to thank the following people (in alphabetical We would also like to thank the following people (in alphabetical
order) for their review comments and valuable suggestions: Dan order) for their review comments and valuable suggestions: Dan
Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, Pekka Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and
Riikonen, and Yaron Sheffer. Pekka Riikonen.
13. Change Log 14. Change Log
This section lists all the changes in this document. This section lists all the changes in this document.
NOTE TO RFC EDITOR: Please remove this section before publication. NOTE TO RFC EDITOR: Please remove this section before publication.
13.1. Draft -02 14.1. Draft -03
Clarified the rules for Message ID sync, so that replay attacks can
be avoided without a failover counter.
Added wording regarding inconsistent IKE state (basically choosing to
ignore the problem) and further rules dealing with pending traffic.
The IPsec replay counter delta value now refers to incoming traffic.
The associated notification is only sent from the cluster to the
peer, and not back.
14.2. Draft -02
Addressed comments by Yaron Sheffer posted on the WG mailing list. Addressed comments by Yaron Sheffer posted on the WG mailing list.
Numerous editorial changes. Numerous editorial changes.
13.2. Draft -01 14.3. Draft -01
Added "Multiple and Simultaneous failover' scenarios as pointed out Added "Multiple and Simultaneous failover' scenarios as pointed out
by Pekka Riikonen. by Pekka Riikonen.
Now document provides a mechanism to sync either IKEv2 message or Now document provides a mechanism to sync either IKEv2 message or
IPsec replay counter or both to cater different types of IPsec replay counter or both to cater different types of
implementations. implementations.
HA cluster's "failover count' is used to encounter replay of sync HA cluster's "failover count' is used to encounter replay of sync
requests by attacker. requests by attacker.
The sync of IPsec SA replay counter optimized to to have just one 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 global bumped-up outgoing IPsec SA counter of ALL Child SAs under an
IKEv2 SA. IKEv2 SA.
The examples added for IKEv2 Message ID sync to provide more clarity. The examples added for IKEv2 Message ID sync to provide more clarity.
Some edits as per comments on mailing list to enhance clarity. Some edits as per comments on mailing list to enhance clarity.
13.3. Draft -00 14.4. Draft -00
Version 00 is identical to Version 00 is identical to
draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document. draft-kagarigi-ipsecme-ikev2-windowsync-04, started as WG document.
Added IPSECME WG HA design team members as authors. Added IPSECME WG HA design team members as authors.
Added comment in Introduction to discuss the window sync process on Added comment in Introduction to discuss the window sync process on
WG mailing list to solve some concerns. WG mailing list to solve some concerns.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Requirement Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [2] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
Internet Protocol", RFC 4301, December 2005. October 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
"Internet Key Exchange Protocol Version 2 (IKEv2)", Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
RFC 5996, September 2010.
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, [4] Kent, S. and K. Seo, "Security Architecture for the Internet
October 2010. Protocol", RFC 4301, December 2005.
14.2. Informative References 15.2. Informative References
[I-D.ietf-ipsecme-failure-detection] [5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3
Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A for IPv4 and IPv6", RFC 5798, March 2010.
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 [6] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the
the Internet Key Exchange Protocol Version 2 (IKEv2)", Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,
RFC 5685, November 2009. November 2009.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [7] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
January 2010.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) [8] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick
Version 3 for IPv4 and IPv6", RFC 5798, March 2010. Crash Detection Method for IKE",
draft-ietf-ipsecme-failure-detection-03 (work in progress),
January 2011.
Appendix A. IKEv2 Message ID Sync Examples Appendix A. IKEv2 Message ID Sync Examples
This (non-normative) section presents some examples that illustrate This (non-normative) section presents some examples that illustrate
how the IKEv2 Message ID values are synchronized. We use a tuple how the IKEv2 Message ID values are synchronized. We use a tuple
notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and notation, denoting the two counters EXPECTED_SEND_REQ_MESSAGE_ID and
EXPECTED_RECV_REQ_MESSAGE_ID on a member as EXPECTED_RECV_REQ_MESSAGE_ID on a member as
(EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID). (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID).
A.1. Normal Failover - Example 1 A.1. Normal Failover - Example 1
Standby (Newly Active) Member Peer Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 3) --------> Sync Request (2, 3) -------->
Peer has the values (4, 5) so it sends Peer has the values (4, 5) so it sends
<------------- (4, 5) as the Sync Response <------------- (4, 5) as the Sync Response
A.2. Normal Failover - Example 2 A.2. Normal Failover - Example 2
Standby (Newly Active) Member Peer Standby (Newly Active) Member Peer
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sync Request (2, 5) --------> Sync Request (2, 5) -------->
Peer has the values (2, 4) so it sends Peer has the values (2, 4) so it sends
<-------------(5, 4) as the Sync Response <-------------(5, 4) as the Sync Response
A.3. Simultaneous Failover A.3. Simultaneous Failover
skipping to change at page 19, line 20 skipping to change at page 22, line 4
Phone: +91 80 4426 4831 Phone: +91 80 4426 4831
Email: kagarigi@cisco.com Email: kagarigi@cisco.com
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
Tel Aviv 67897 Tel Aviv 67897
Israel Israel
Email: ynir@checkpoint.com Email: ynir@checkpoint.com
Yaron Sheffer
Independent
Email: yaronf.ietf@gmail.com
Dacheng Zhang Dacheng Zhang
Huawei Technologies Ltd. Huawei Technologies Ltd.
Email: zhangdacheng@huawei.com Email: zhangdacheng@huawei.com
 End of changes. 91 change blocks. 
357 lines changed or deleted 426 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/