draft-ietf-ipsecme-ipsecha-protocol-03.txt   draft-ietf-ipsecme-ipsecha-protocol-04.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: August 12, 2011 Y. Nir Expires: September 3, 2011 Y. Nir
Check Point Check Point
Y. Sheffer Y. Sheffer
Independent Independent
D. Zhang D. Zhang
Huawei Huawei
February 8, 2011 March 2, 2011
Protocol Support for High Availability of IKEv2/IPsec Protocol Support for High Availability of IKEv2/IPsec
draft-ietf-ipsecme-ipsecha-protocol-03 draft-ietf-ipsecme-ipsecha-protocol-04
Abstract Abstract
The IPsec protocol suite is widely used for business-critical network The IPsec protocol suite is widely used for business-critical network
traffic. In order to make IPsec deployments highly available, more traffic. In order to make IPsec deployments highly available, more
scalable and failure-resistant, they are often implemented as IPsec scalable and failure-resistant, they are often implemented as IPsec
High Availability (HA) clusters. However there are many issues in High Availability (HA) clusters. However there are many issues in
IPsec HA clustering, and in particular in IKEv2 clustering. An IPsec HA clustering, and in particular in IKEv2 clustering. An
earlier document, "IPsec Cluster Problem Statement", enumerates the earlier document, "IPsec Cluster Problem Statement", enumerates the
issues encountered in the IKEv2/IPsec HA cluster environment. This issues encountered in the IKEv2/IPsec HA cluster environment. This
skipping to change at page 2, line 4 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 September 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6 3. Issues Resolved from IPsec Cluster Problem Statement . . . . . 6
4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 7 3.1. Large Amount of State . . . . . . . . . . . . . . . . . . 6
5. SA Counter Synchronization Solution . . . . . . . . . . . . . 8 3.2. Multiple Members Using the Same SA . . . . . . . . . . . . 7
5.1. Processing Rules for IKE Message ID Synchronization . . . 10 3.3. Avoiding Collisions in SPI Number Allocation . . . . . . . 7
3.4. Interaction with Counter Modes . . . . . . . . . . . . . . 8
4. The IKEv2/IPsec SA Counter Synchronization Problem . . . . . . 8
5. SA Counter Synchronization Solution . . . . . . . . . . . . . 9
5.1. Processing Rules for IKE Message ID Synchronization . . . 11
5.2. Processing Rules for IPsec Replay Counter 5.2. Processing Rules for IPsec Replay Counter
Synchronization . . . . . . . . . . . . . . . . . . . . . 11 Synchronization . . . . . . . . . . . . . . . . . . . . . 12
6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 11 6. IKEv2/IPsec Synchronization Notification Payloads . . . . . . 12
6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 11 6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification . . . . . 12
6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 12 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification . . . 13
6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 12 6.3. The IKEV2_MESSAGE_ID_SYNC Notification . . . . . . . . . . 13
6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 13 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification . . . . . . . . 14
7. Implementation Details . . . . . . . . . . . . . . . . . . . . 14 7. Implementation Details . . . . . . . . . . . . . . . . . . . . 15
8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 14 8. IKE SA and IPsec SA Message Sequencing . . . . . . . . . . . . 16
8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 15 8.1. Handling of Pending IKE Messages . . . . . . . . . . . . . 16
8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 15 8.2. Handling of Pending IPsec Messages . . . . . . . . . . . . 16
8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 15 8.3. IKE SA Inconsistencies . . . . . . . . . . . . . . . . . . 16
9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 15 9. Step by Step Details . . . . . . . . . . . . . . . . . . . . . 16
10. Interaction with other drafts . . . . . . . . . . . . . . . . 16 10. Interaction with other drafts . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Draft -04 . . . . . . . . . . . . . . . . . . . . . . . . 19
14.2. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 18 14.2. Draft -03 . . . . . . . . . . . . . . . . . . . . . . . . 19
14.3. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 18 14.3. Draft -02 . . . . . . . . . . . . . . . . . . . . . . . . 20
14.4. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 19 14.4. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.5. Draft -00 . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . . 21
A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 20 Appendix A. IKEv2 Message ID Sync Examples . . . . . . . . . . . 21
A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 20 A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22
A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 20 A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 6, line 30 skipping to change at page 6, line 30
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; additionally, this document provides implementation defined below, starting with Section 5; additionally, this section
advice for other issues, as follows. provides implementation advice for other issues in the following
o Section 3.2 of the Problem Statement mentions that there is a subsections.
large amount of state that needs to be synchronized. However if
state is not synchronized, this is not really an interesting 3.1. Large Amount of State
cluster: failover is equivalent to a reboot of the cluster member,
and so the issue need not be solved with a protocol extension. Section 3.2 of the Problem Statement mentions that a lot of state
o 3.3, 3.4,3.5, and 3.6 are solved by this document. Please see needs to be synchronized for a cluster to be transparent. The actual
Section 4, for more details. volume of that data is very much implementation-dependent, and even
o 3.7 is an implementation problem that needs to be solved while for the same implementation, the amounts of data may vary wildly. An
building IPsec clusters. However, the peers should be required to IPsec gateway used for inter-domain VPN with a dozen other gateways,
accept multiple parallel SAs for 3.7.1. and having SAs that are rekeyed every 8 hours, will need a lot less
o 3.8 can be solved by using the IKEv2 Redirect mechanism [6]. synchronization traffic than a similar gateway used for remote
o 3.9 discusses the avoidance of collisions where the same SPI value access, and supporting 10,000 clients. This is because counter
is used by multiple cluster members. This is outside the synchronization is proportional to the number of SAs and requires
document's scope since the problem needs to be solved internally little data, and the setting up of an SA requires a lot of data.
to the cluster and does not involve the peer. Additionally, remote access IKE and IPsec SA setup tend to happen at
a particular time of day, so the example gateway with the 10,000
clients may see 30-50 IKE SA setups per second at 9:00 AM. This
would require very heavy synchronization traffic over that short
period of time.
If a large volume of traffic is necessary, it may be advisable to use
a dedicated high-speed network interface for synch traffic. When
packet loss can be made extremely low, it may be advisable to use a
stateless transport such as UDP, to minimize network overhead.
If these methods are insufficient, it may be prudent that for some
SAs the entire state is not synchronized. Instead, only an
indication of the SA's existence is synchronized. This, in
combination with a sticky solution (as described in section 3.7 of
the problem statement) ensures that the traffic from a particular
peer does not reach a different member before an actual failover
happens. When that happens, the method described in [6] can be used
to quickly force the peer to set up a new SA.
3.2. Multiple Members Using the Same SA
In a load-sharing cluster of the "duplicate" variety (see section 3.7
of the problem statement) multiple members may need to send traffic
with the same selectors. To actually use the same SA the cluster
would have to synchronize the Replay Counter after every packet, and
that would impose unreasonable requirements on the synch connection.
A far better solution would be to not synchronize the outbound SA,
and create multiple outbound SAs, one for each member. The problem
with this option is that the peer might view these multiple parallel
SAs as redundant, and tear down all but one of them.
Section 2.8 of [3] specifically allows multiple parallel SAs, but the
reason given for this is to have multiple SAs with different QoS
attributes. So while this is not a new requirement of IKEv2
implementations, we re-iterate here that IPsec peers MUST accept the
long-term existence of multiple parallel SAs, even when QoS
mechanisms are not in use.
3.3. Avoiding Collisions in SPI Number Allocation
Section 3.9 of the problem statement describes the problem of two
cluster members allocating the same SPI number for two different SAs.
This would violate section 4.4.2.1 of [4]. There are several schemes
to allow implementations to avoid such collisions, such as
partitioning the SPI space, a request-response over the synch
channel, and locking mechanisms. We believe that these are
sufficiently robust and available so that we don't need to make an
exception to RFC 4301, and we can leave this problem for the
implementations to solve. Cluster members MUST NOT generate multiple
inbound SAs with the same SPI.
3.4. Interaction with Counter Modes
For SAs involving counter mode ciphers such as CTR [7] or GCM [8]
there is yet another complication. The initial vector for such modes
MUST NOT be repeated, and senders use methods such as counters or
LFSRs to ensure this property. For an SA shared between multiple
active members (load sharing cases), implementations MUST ensure that
no initial vector is ever repeated. Similar concerns apply to an SA
failing over from one member to another. See [9] for a discussion of
this problem in another context.
Just as in the SPI collision problem, there are ways to avoid a
collision of initial vectors, and this is left up to implementations.
In the context of load sharing, parallel SAs are a simple solution to
this problem as well.
4. The IKEv2/IPsec SA Counter Synchronization Problem 4. The IKEv2/IPsec SA Counter Synchronization Problem
The IKEv2 protocol [3] states that "An IKE endpoint MUST NOT exceed The IKEv2 protocol [3] states that "An IKE endpoint MUST NOT 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
skipping to change at page 16, line 32 skipping to change at page 17, line 40
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 [7] assumes that a peer (client or initiator) o Session resumption [10] assumes that a peer (client or initiator)
detects the need to re-establish the session. In IKEv2/IPsec SA detects the need to re-establish the session. In IKEv2/IPsec SA
counter synchronization, it is the newly-active member (a gateway counter synchronization, it is the newly-active member (a gateway
or responder) that detects the need to synchronize the SA counter or responder) that detects the need to synchronize the SA counter
after the failover event. Also in a hot-standby cluster, the peer after the failover event. Also in a hot-standby cluster, the peer
establishes the IKEv2/IPsec session with a single IP address that establishes the IKEv2/IPsec session with a single IP address that
represents the whole cluster, so the peer normally does not detect represents the whole cluster, so the peer normally does not detect
the event of failover in the cluster unless the standby member the event of failover in the cluster unless the standby member
takes too long to become active and the IKEv2 SA times out by use takes too long to become active and the IKEv2 SA times out by use
of the IKEv2 liveness check mechanism. To conclude, session of the IKEv2 liveness check mechanism. To conclude, session
resumption and SA counter synchronization after failover are resumption and SA counter synchronization after failover are
mutually exclusive. mutually exclusive.
o The IKEv2 Redirect mechanism for load-balancing [6] can be used
o The IKEv2 Redirect mechanism for load-balancing [11] can be used
either during the initial stages of SA setup (the IKE_SA_INIT and either during the initial stages of SA setup (the IKE_SA_INIT and
IKE_AUTH exchanges) or after session establishment. SA counter IKE_AUTH exchanges) or after session establishment. SA 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 [8] solves a similar problem where the o IKEv2 Failure Detection [6] solves a similar problem where the
peer can rapidly detect that a cluster member has crashed based on peer can rapidly detect that a cluster member has crashed based on
a token. It is unrelated to the current scenario because the goal a token. It is unrelated to the current scenario because the goal
in failover is for the peer not to notice that a failure has in failover is for the peer not to notice that a failure has
occurred. occurred.
11. Security Considerations 11. Security Considerations
Since Message ID synchronization messages need to be sent with Since Message ID synchronization messages need to be sent with
Message ID zero, they are potentially vulnerable to replay attacks. Message ID zero, they are potentially vulnerable to replay attacks.
Because of the semantics of this protocol, these can only be denial- Because of the semantics of this protocol, these can only be denial-
skipping to change at page 18, line 22 skipping to change at page 19, line 31
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, and Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and
Pekka Riikonen. Pekka Riikonen.
14. 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.
14.1. Draft -03 14.1. Draft -04
Extended Sec. 3 for better coverage of other IPsec cluster-related
issues, and how they are resolved within the existing standards.
14.2. Draft -03
Clarified the rules for Message ID sync, so that replay attacks can Clarified the rules for Message ID sync, so that replay attacks can
be avoided without a failover counter. be avoided without a failover counter.
Added wording regarding inconsistent IKE state (basically choosing to Added wording regarding inconsistent IKE state (basically choosing to
ignore the problem) and further rules dealing with pending traffic. ignore the problem) and further rules dealing with pending traffic.
The IPsec replay counter delta value now refers to incoming traffic. The IPsec replay counter delta value now refers to incoming traffic.
The associated notification is only sent from the cluster to the The associated notification is only sent from the cluster to the
peer, and not back. peer, and not back.
14.2. Draft -02 14.3. 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.
14.3. Draft -01 14.4. 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.
14.4. Draft -00 14.5. 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.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, [2] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
October 2010. October 2010.
[3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key [3] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[4] Kent, S. and K. Seo, "Security Architecture for the Internet [4] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
15.2. Informative References 15.2. Informative References
[5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 [5] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3
for IPv4 and IPv6", RFC 5798, March 2010. for IPv4 and IPv6", RFC 5798, March 2010.
[6] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the [6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick
Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, Crash Detection Method for IKE",
November 2009. draft-ietf-ipsecme-failure-detection-05 (work in progress),
February 2011.
[7] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol [7] Housley, R., "Using Advanced Encryption Standard (AES) Counter
Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010. Mode With IPsec Encapsulating Security Payload (ESP)",
RFC 3686, January 2004.
[8] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick [8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
Crash Detection Method for IKE", in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
draft-ietf-ipsecme-failure-detection-03 (work in progress), June 2005.
January 2011.
[9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating
Security Payload (ESP) and Authentication Header (AH) to
Protect Group Traffic", RFC 6054, November 2010.
[10] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol
Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[11] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the
Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,
November 2009.
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
 End of changes. 22 change blocks. 
79 lines changed or deleted 169 lines changed or added

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