draft-ietf-ipsecme-ipsecha-protocol-04.txt   draft-ietf-ipsecme-ipsecha-protocol-05.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: September 3, 2011 Y. Nir Expires: September 30, 2011 Y. Nir
Check Point Check Point
Y. Sheffer Y. Sheffer
Independent Independent
D. Zhang D. Zhang
Huawei Huawei
March 2, 2011 March 29, 2011
Protocol Support for High Availability of IKEv2/IPsec Protocol Support for High Availability of IKEv2/IPsec
draft-ietf-ipsecme-ipsecha-protocol-04 draft-ietf-ipsecme-ipsecha-protocol-05
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
document attempts to resolve these issues with the least possible document resolves these issues with the least possible change to the
change to the protocol. protocol.
This document proposes an extension to the IKEv2 protocol to solve This document defines an extension to the IKEv2 protocol to solve the
the main issues of "IPsec Cluster Problem Statement" in the commonly 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 solved are the synchronization of
of IKEv2 Message ID counters, and of IPsec Replay Counters. 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 3, 2011. This Internet-Draft will expire on September 30, 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 4, line 10 skipping to change at page 4, line 10
A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22 A.1. Normal Failover - Example 1 . . . . . . . . . . . . . . . 22
A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22 A.2. Normal Failover - Example 2 . . . . . . . . . . . . . . . 22
A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22 A.3. Simultaneous Failover . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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) clusters. However
there are many issues with the IKEv2/IPsec HA cluster. The problem there are many issues with the IKEv2/IPsec HA cluster. Section 4
statement draft Section 4 enumerates the issues around the IKEv2/ below enumerates the issues around the IKEv2/IPsec HA cluster
IPsec HA cluster solution. solution.
In the case of a hot-standby cluster implementation of IKEv2/IPsec In the case of a hot-standby cluster implementation of IKEv2/IPsec
based VPNs, the IKEv2/IPsec session is first established between the based VPNs, the IKEv2/IPsec session is first established between the
peer and the active member of the cluster. Later, the active member peer and the active member of the cluster. Later, the active member
continuously syncs/updates the IKE/IPsec SA state to the standby continuously syncs/updates the IKE/IPsec SA state to the standby
member of the cluster. This primary SA state sync-up takes place member of the cluster. This primary SA state sync-up takes place
upon each SA bring-up and/or rekey. Performing the SA state upon each SA bring-up and/or rekey. Performing the SA state
synchronization/update for every single IKE and IPsec message is very synchronization/update for every single IKE and IPsec message is very
costly, so normally it is done periodically. As a result, when the costly, so normally it is done periodically. As a result, when the
failover event happens, this is first detected by the standby member failover event happens, this is first detected by the standby member
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 [1]. 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 informational 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 [2] with further Some of the terms listed below are reused from [4] 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 [5] is one method of referred to as "standby" members. VRRP [5] is one method of
building such a cluster. The goal of the Hot Standby Cluster is building such a cluster. The goal of the Hot Standby Cluster is
to create the illusion of a single virtual gateway to the peer(s). 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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 and document. This term refers to both IKEv2 Message ID counters and
IPsec replay counters. According to the IPsec standards, the IKEv2 IPsec replay counters. According to the IPsec standards, the IKEv2
Message ID counter is mandatory, and used to ensure reliable delivery Message ID counter is mandatory, and used to ensure reliable delivery
as well as to protect against message replay in IKEv2; the IPsec SA 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 counters are optional, and are used to provide the IPsec anti-
replay feature. replay feature.
3. Issues Resolved from IPsec Cluster Problem Statement 3. Issues Resolved from IPsec Cluster Problem Statement
The IPsec Cluster Problem Statement [2] enumerates the problems The IPsec Cluster Problem Statement [4] 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
skipping to change at page 7, line 32 skipping to change at page 7, line 32
of the problem statement) multiple members may need to send traffic of the problem statement) multiple members may need to send traffic
with the same selectors. To actually use the same SA the cluster with the same selectors. To actually use the same SA the cluster
would have to synchronize the Replay Counter after every packet, and would have to synchronize the Replay Counter after every packet, and
that would impose unreasonable requirements on the synch connection. that would impose unreasonable requirements on the synch connection.
A far better solution would be to not synchronize the outbound SA, A far better solution would be to not synchronize the outbound SA,
and create multiple outbound SAs, one for each member. The problem and create multiple outbound SAs, one for each member. The problem
with this option is that the peer might view these multiple parallel with this option is that the peer might view these multiple parallel
SAs as redundant, and tear down all but one of them. SAs as redundant, and tear down all but one of them.
Section 2.8 of [3] specifically allows multiple parallel SAs, but the Section 2.8 of [2] specifically allows multiple parallel SAs, but the
reason given for this is to have multiple SAs with different QoS reason given for this is to have multiple SAs with different QoS
attributes. So while this is not a new requirement of IKEv2 attributes. So while this is not a new requirement of IKEv2
implementations, we re-iterate here that IPsec peers MUST accept the implementations, we re-iterate here that IPsec peers MUST accept the
long-term existence of multiple parallel SAs, even when QoS long-term existence of multiple parallel SAs, even when QoS
mechanisms are not in use. mechanisms are not in use.
3.3. Avoiding Collisions in SPI Number Allocation 3.3. Avoiding Collisions in SPI Number Allocation
Section 3.9 of the problem statement describes the problem of two Section 3.9 of the problem statement describes the problem of two
cluster members allocating the same SPI number for two different SAs. 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 This would violate section 4.4.2.1 of [3]. There are several schemes
to allow implementations to avoid such collisions, such as to allow implementations to avoid such collisions, such as
partitioning the SPI space, a request-response over the synch partitioning the SPI space, a request-response over the synch
channel, and locking mechanisms. We believe that these are channel, and locking mechanisms. We believe that these are
sufficiently robust and available so that we don't need to make an 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 exception to RFC 4301, and we can leave this problem for the
implementations to solve. Cluster members MUST NOT generate multiple implementations to solve. Cluster members MUST NOT generate multiple
inbound SAs with the same SPI. inbound SAs with the same SPI.
3.4. Interaction with Counter Modes 3.4. Interaction with Counter Modes
skipping to change at page 8, line 23 skipping to change at page 8, line 23
failing over from one member to another. See [9] for a discussion of failing over from one member to another. See [9] for a discussion of
this problem in another context. this problem in another context.
Just as in the SPI collision problem, there are ways to avoid a Just as in the SPI collision problem, there are ways to avoid a
collision of initial vectors, and this is left up to implementations. collision of initial vectors, and this is left up to implementations.
In the context of load sharing, parallel SAs are a simple solution to In the context of load sharing, parallel SAs are a simple solution to
this problem as well. 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 [2] 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
outstanding at a given point of time, but mandates that the sender's outstanding at a given point of time, but mandates that the sender's
window should not move until the oldest message it has sent is window should not move until the oldest message it has sent is
acknowledged. Loss of even a single message leads to repeated acknowledged. Loss of even a single message leads to repeated
retransmissions followed by an IKEv2 SA teardown if the retransmissions followed by an IKEv2 SA teardown if the
skipping to change at page 13, line 15 skipping to change at page 13, line 15
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 [3]. The 'SPI Size' field MUST be set to 0 to indicate that the of [2]. The 'SPI Size' field MUST be set to 0 to indicate that the
SPI is not present in this message. The 'Protocol ID' MUST be set to SPI is not present in this message. The 'Protocol ID' MUST be set to
0, since the notification is not specific to a particular security 0, since the notification is not specific to a particular security
association. The 'Payload Length' field is set to the length in association. The 'Payload Length' field is set to the length in
octets of the entire payload, including the generic payload header. octets of the entire payload, including the generic payload 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. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification 6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification
skipping to change at page 13, line 40 skipping to change at page 13, line 40
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 [3] . The 'SPI Size' field MUST be set to 0 to indicate that the of [2] . The 'SPI Size' field MUST be set to 0 to indicate that the
SPI is not present in this message. The 'Protocol ID' MUST be set to SPI is not present in this message. The 'Protocol ID' MUST be set to
0, since the notification is not specific to a particular security 0, since the notification is not specific to a particular security
association. The 'Payload Length' field is set to the length in association. The 'Payload Length' field is set to the length in
octets of the entire payload, including the generic payload header. octets of the entire payload, including the generic payload 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. The IKEV2_MESSAGE_ID_SYNC Notification 6.3. The IKEV2_MESSAGE_ID_SYNC Notification
skipping to change at page 14, line 42 skipping to change at page 14, line 42
6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification 6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification
This notification payload type (value TBD by IANA) is defined to This notification payload type (value TBD by IANA) is defined to
synchronize the IPsec SA Replay Counters between the newly-active synchronize the IPsec SA Replay Counters between the newly-active
(formerly standby) cluster member and the peer. Since there may be (formerly standby) cluster member and the peer. Since there may be
numerous IPsec SAs established under a single IKE SA, we do not numerous IPsec SAs established under a single IKE SA, we do not
directly synchronize the value of each one. Instead, a delta value directly synchronize the value of each one. Instead, a delta value
is sent and all Replay Counters for Child SAs of this IKE SA are is sent and all Replay Counters for Child SAs of this IKE SA are
incremented by the same value. Note that this solution requires that incremented by the same value. Note that this solution requires that
all these Child SAs either use or do not use Extended Sequence all these Child SAs either use or do not use Extended Sequence
Numbers [4]. This notification is only sent by the cluster. Numbers [3]. 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 |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming IPsec SA delta value | | Incoming IPsec SA delta value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 48 skipping to change at page 20, line 48
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] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
October 2010.
[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 [3] 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
[4] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
October 2010.
[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] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick [6] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick
Crash Detection Method for IKE", Crash Detection Method for IKE",
draft-ietf-ipsecme-failure-detection-05 (work in progress), draft-ietf-ipsecme-failure-detection-07 (work in progress),
February 2011. March 2011.
[7] Housley, R., "Using Advanced Encryption Standard (AES) Counter [7] Housley, R., "Using Advanced Encryption Standard (AES) Counter
Mode With IPsec Encapsulating Security Payload (ESP)", Mode With IPsec Encapsulating Security Payload (ESP)",
RFC 3686, January 2004. RFC 3686, January 2004.
[8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) [8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM)
in IPsec Encapsulating Security Payload (ESP)", RFC 4106, in IPsec Encapsulating Security Payload (ESP)", RFC 4106,
June 2005. June 2005.
[9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating [9] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating
 End of changes. 20 change blocks. 
29 lines changed or deleted 29 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/