< draft-tschofenig-ipsecme-ikev2-resumption-00.txt   draft-tschofenig-ipsecme-ikev2-resumption-01.txt >
Network Working Group Y. Sheffer Network Working Group Y. Sheffer
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 3, 2009 Nokia Siemens Networks Expires: May 5, 2009 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
September 30, 2008 November 1, 2008
IKEv2 Session Resumption IKEv2 Session Resumption
draft-tschofenig-ipsecme-ikev2-resumption-00.txt draft-tschofenig-ipsecme-ikev2-resumption-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2009. This Internet-Draft will expire on May 5, 2009.
Abstract Abstract
The Internet Key Exchange version 2 (IKEv2) protocol has a certain The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved. of round-trips required and the cryptographic operations involved.
In remote access situations, the Extensible Authentication Protocol In remote access situations, the Extensible Authentication Protocol
(EAP) is used for authentication, which adds several more round trips (EAP) is used for authentication, which adds several more round trips
and consequently latency. and consequently latency.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
In order to avoid the need to re-run the key exchange protocol from In order to avoid the need to re-run the key exchange protocol from
scratch it would be useful to provide an efficient way to resume an scratch it would be useful to provide an efficient way to resume an
IKE/IPsec session. This document proposes an extension to IKEv2 that IKE/IPsec session. This document proposes an extension to IKEv2 that
allows a client to re-establish an IKE SA with a gateway in a highly allows a client to re-establish an IKE SA with a gateway in a highly
efficient manner, utilizing a previously established IKE SA. efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
The proposed approach uses a ticket to store state information that The proposed approach uses a ticket to store state information that
is later made available to the IKEv2 responder for re-authentication. is later made available to the IKEv2 responder for re-authentication.
Restoring state information by utilizing a ticket, although the Restoring state information by utilizing a ticket is one possible
format is not specified in this document, is one possible way. way. This document does not specify the format of the ticket but
recommendations are provided.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7
4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 8
4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 9 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 9
skipping to change at page 3, line 36 skipping to change at page 3, line 36
7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 14
7.4. Ticket Protection Key Management . . . . . . . . . . . . . 14 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 14
7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 14 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 14
7.6. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 14
7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 15 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 15
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 15 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 17
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) protocol has a certain The Internet Key Exchange version 2 (IKEv2) protocol has a certain
computational and communication overhead with respect to the number computational and communication overhead with respect to the number
of round-trips required and the cryptographic operations involved. of round-trips required and the cryptographic operations involved.
In particular the Extensible Authentication Protocol (EAP) is used In particular the Extensible Authentication Protocol (EAP) is used
for authentication in remote access cases, which increases latency. for authentication in remote access cases, which increases latency.
To re-establish security associations (SA) upon a failure recovery To re-establish security associations (SA) upon a failure recovery
skipping to change at page 4, line 29 skipping to change at page 4, line 29
In many failure cases it would be useful to provide an efficient way In many failure cases it would be useful to provide an efficient way
to resume an interrupted IKE/IPsec session. This document proposes to resume an interrupted IKE/IPsec session. This document proposes
an extension to IKEv2 that allows a client to re-establish an IKE SA an extension to IKEv2 that allows a client to re-establish an IKE SA
with a gateway in a highly efficient manner, utilizing a previously with a gateway in a highly efficient manner, utilizing a previously
established IKE SA. established IKE SA.
A client can reconnect to a gateway from which it was disconnected. A client can reconnect to a gateway from which it was disconnected.
One way to ensure that the IKEv2 responder is able to recreate the One way to ensure that the IKEv2 responder is able to recreate the
state information is by maintaining IKEv2 state in a "ticket", an state information is by maintaining IKEv2 state in a "ticket", an
opaque data structure. This ticket is created by the server and opaque data structure. This ticket is created by the server and
forwarded to the client by value or by reference. The IKEv2 protocol forwarded to the client. The IKEv2 protocol is extended to allow a
is extended to allow a client to request and present a ticket (by client to request and present a ticket.
value or by reference).
This approach is similar to the one taken by TLS session resumption This approach is similar to the one taken by TLS session resumption
[RFC4507] with the required adaptations for IKEv2, e.g., to [RFC4507] with the required adaptations for IKEv2, e.g., to
accommodate the two-phase protocol structure. We have borrowed accommodate the two-phase protocol structure. We have borrowed
heavily from that specification. heavily from that specification.
The proposed solution should additionally meet the following goals: The proposed solution should additionally meet the following goals:
o Using only symmetric cryptography to minimize CPU consumption. o Using only symmetric cryptography to minimize CPU consumption.
o Allowing a gateway to push state to clients. o Allowing a gateway to push state to clients.
skipping to change at page 5, line 10 skipping to change at page 5, line 9
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 [RFC2119].
This document uses terminology defined in [RFC4301], [RFC4306], and This document uses terminology defined in [RFC4301], [RFC4306], and
[RFC4555]. In addition, this document uses the following terms: [RFC4555]. In addition, this document uses the following terms:
IKEv2 ticket: An IKEv2 ticket is a data structure that contains all Ticket: An IKEv2 ticket is a data structure that contains all the
the necessary information that allows any gateway within the same necessary information that allows an IKEv2 responder to re-
secure domain as the gateway that created the ticket to verify the establish an IKEv2 security association.
validity of the ticket and extract IKEv2 policy and session keys
to re-establish an IKEv2 session.
Ticket reference: A pointer to a ticket. When resolving the
reference an IKEv2 responder obtains the ticket.
In subsequent sections we use the term ticket and thereby refer to In this document we use the term ticket and thereby refer to an
both the ticket by value and by reference, unless indicated opaque data structure that may be either an IKEv2 ticket described
otherwise. above or a reference pointing to such a ticket.
3. Usage Scenario 3. Usage Scenario
This specification envisions two usage scenarios for efficient IKEv2 This specification envisions two usage scenarios for efficient IKEv2
and IPsec SA session re-establishment. and IPsec SA session re-establishment.
The first is similar to the use case specified in Section 1.1.3 of The first is similar to the use case specified in Section 1.1.3 of
the IKEv2 specification [RFC4306], where the IPsec tunnel mode is the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
used to establish a secure channel between a remote access client and used to establish a secure channel between a remote access client and
a gateway; the traffic flow may be between the client and entities a gateway; the traffic flow may be between the client and entities
skipping to change at page 12, line 40 skipping to change at page 12, line 40
where SPIi, SPIr are the SPI values created in the new IKE exchange. where SPIi, SPIr are the SPI values created in the new IKE exchange.
See [RFC4306] for the notation. "prf" is determined from the SA value See [RFC4306] for the notation. "prf" is determined from the SA value
in the ticket. in the ticket.
5. Ticket Recommendations 5. Ticket Recommendations
5.1. Ticket Content 5.1. Ticket Content
The ticket MUST encode at least the following state from an IKE SA. A ticket per value MUST encode at least the following state from an
These values MUST be encrypted and authenticated. IKE SA. These values MUST be encrypted and authenticated.
o IDi, IDr. o IDi, IDr.
o SPIi, SPIr. o SPIi, SPIr.
o SAr (the accepted proposal). o SAr (the accepted proposal).
o SK_d. o SK_d.
In addition, the ticket MUST encode a protected ticket expiration In addition, the ticket MUST encode a protected ticket expiration
value. value.
The ticket MUST include a key identity field, so that encryption and The ticket MUST include a key identity field, so that encryption and
skipping to change at page 15, line 7 skipping to change at page 15, line 7
requirements outlined in Section 5.1 are met. In particular, if requirements outlined in Section 5.1 are met. In particular, if
confidential information, such as a secret key, is transferred to the confidential information, such as a secret key, is transferred to the
client, it MUST be done using secure communication to prevent client, it MUST be done using secure communication to prevent
attackers from obtaining or modifying the key. Also, the ticket MUST attackers from obtaining or modifying the key. Also, the ticket MUST
have its integrity and confidentiality protected with strong have its integrity and confidentiality protected with strong
cryptographic techniques to prevent a breach in the security of the cryptographic techniques to prevent a breach in the security of the
system. system.
7.7. Identity Privacy, Anonymity, and Unlinkability 7.7. Identity Privacy, Anonymity, and Unlinkability
This document mandates that the content of the ticket MUST be Since opaque state information is passed around between the IKEv2
encrypted in order to avoid leakage of information, such as the initiator and the IKEv2 responder it is important that leakage of
identities of an IKEv2 initiator and a responder. Thus, it prevents information, such as the identities of an IKEv2 initiator and a
the disclosure of potentially sensitive information carried within responder, MUST be avoided (e.g., with the help of encryption. Thus,
the ticket. it prevents the disclosure of potentially sensitive information.
When an IKEv2 initiator presents the ticket as part of the When an IKEv2 initiator presents a ticket as part of the
IKE_SESSION_RESUME exchange, confidentiality is not provided for the IKE_SESSION_RESUME exchange, confidentiality is not provided for the
exchange. Although the ticket itself is encrypted there might still exchange. There is thereby the possibility for an on-path adversary
be a possibility for an on-path adversary to observe multiple to observe multiple exchange handshakes where the same state
exchange handshakes where the same ticket is used and therefore to information is used and therefore to conclude that they belong to the
conclude that they belong to the same communication end points. same communication end points.
Administrators that use the ticket mechanism described in this
document should be aware that unlinkability may not be provided by This document therefore envisions that the ticket is presented to the
this mechanism. Note, however, that IKEv2 does not provide active IKEv2 responder only once; multiple usage of the ticket is not
user identity confidentiality for the IKEv2 initiator either. provided.
7.8. Replay Protection in the IKE_SESSION_RESUME Exchange 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange
A major design goal of this protocol extension has been the two- A major design goal of this protocol extension has been the two-
message exchange for session resumption. There is a tradeoff between message exchange for session resumption. There is a tradeoff between
this abbreviated exchange and replay protection. It is RECOMMENDED this abbreviated exchange and replay protection. It is RECOMMENDED
that a gateway should cache tickets, and reject replayed ones. that an IKEv2 responder should cache tickets, and reject replayed
However, some gateways may not do that in order to reduce state size. ones. However, some gateways may not do that in order to reduce
An adversary may attempt to replay a ticket. To mitigate these risks state size. An adversary may attempt to replay a ticket. To
a client may be required by the gateway to show that it knows the mitigate these risks a client may be required by the gateway to show
ticket's secret, before any state is committed on the gateway side. that it knows the ticket's secret, before any state is committed on
Note that this is a stronger guarantee than the regular IKE cookie the gateway side. Note that this is a stronger guarantee than the
mechanism, which only shows IP return routability of the client. regular IKE cookie mechanism, which only shows IP return routability
This is enabled by including the cookie in the protected portion of of the client. This is enabled by including the cookie in the
the message. protected portion of the message.
For performance reasons, the cookie mechanism is optional, and For performance reasons, the cookie mechanism is optional, and
invoked by the gateway only when it suspects that it is the subject invoked by the gateway only when it suspects that it is the subject
of a denial-of-service attack. of a denial-of-service attack.
In any case, a ticket replayed by an adversary only causes partial In any case, a ticket replayed by an adversary only causes partial
IKE state to be created on the gateway. The IKE exchange cannot be IKE state to be created on the gateway. The IKE exchange cannot be
completed and an IKE SA cannot be created unless the client knows the completed and an IKE SA cannot be created unless the client knows the
ticket's secret values. ticket's secret values.
8. Acknowledgements 8. Acknowledgements
We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
Xiaoming Fu, Stjepan Gros, Yoav Nir and Tero Kivinen for their many Xiaoming Fu, Stjepan Gros, Yoav Nir and Tero Kivinen for their many
helpful comments. We would to particularly thank Florian Tegeler and helpful comments. We would to particularly thank Florian Tegeler and
Stjepan Gros for their help with their implementation efforts and Stjepan Gros for their help with their implementation efforts and
Florian Tegeler for his formal verification using the CASPER tool Florian Tegeler for his formal verification using the CASPER tool
set. set.
We would furthermore like to thank the authors of
[I-D.xu-ike-sa-sync] for their input on using a reference to a
ticket.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
9.2. Informative References 9.2. Informative References
[I-D.rescorla-stateless-tokens]
Rescorla, E., "How to Implement Secure (Mostly) Stateless
Tokens", draft-rescorla-stateless-tokens-01 (work in
progress), March 2007.
[I-D.xu-ike-sa-sync]
Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA
Synchronization for session resumption",
draft-xu-ike-sa-sync-01 (work in progress), October 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 4507, May 2006. Server-Side State", RFC 4507, May 2006.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
Appendix A. Change Log Appendix A. Ticket Format
A.1. -00 This document does not specify a mandatory-to-implement or a
mandatory-to-use ticket format. The following format is RECOMMENDED.
struct {
[authenticated] struct {
octet format_version; // 1 for this version of the protocol
octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string
opaque IV[0..255]; // actual length (possibly 0) depends
// on the encryption algorithm
[encrypted] struct {
opaque IDi, IDr; // the full payloads
octet SPIi[8], SPIr[8];
opaque SA; // the full SAr payload
octet SK_d[0..255]; // actual length depends on SA value
int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970
} ikev2_state;
} protected_part;
opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm
} ticket;
Note that the key defined by "key_id" determines the encryption and
authentication algorithms used for this ticket. Those algorithms are
unrelated to the transforms defined by the SA payload.
The reader is referred to a recent draft
[I-D.rescorla-stateless-tokens] that recommends a similar (but not
identical) ticket format, and discusses related security
considerations in depth.
Appendix B. Change Log
B.1. -00
Issued a -00 version for the IPSECME working group. Reflected Issued a -00 version for the IPSECME working group. Reflected
discussions at IETF#72 regarding the strict focus on session discussions at IETF#72 regarding the strict focus on session
resumption. Consequently, text about failover was removed. resumption. Consequently, text about failover was removed.
A.2. -04 B.2. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
A.3. -03 B.3. -03
Removed counter mechanism. Added an optional anti-DoS mechanism, Removed counter mechanism. Added an optional anti-DoS mechanism,
based on IKEv2 cookies (removed previous discussion of cookies). based on IKEv2 cookies (removed previous discussion of cookies).
Clarified that gateways may support reallocation of same IP address, Clarified that gateways may support reallocation of same IP address,
if provided by network. Proposed a solution outline to the problem if provided by network. Proposed a solution outline to the problem
of key exchange for the keys that protect tickets. Added fields to of key exchange for the keys that protect tickets. Added fields to
the ticket to enable interoperability. Removed incorrect MOBIKE the ticket to enable interoperability. Removed incorrect MOBIKE
notification. notification.
A.4. -02 B.4. -02
Clarifications on generation of SPI values, on the ticket's lifetime Clarifications on generation of SPI values, on the ticket's lifetime
and on the integrity protection of the anti-replay counter. and on the integrity protection of the anti-replay counter.
Eliminated redundant SPIs from the notification payloads. Eliminated redundant SPIs from the notification payloads.
A.5. -01 B.5. -01
Editorial review. Removed 24-hour limitation on ticket lifetime, Editorial review. Removed 24-hour limitation on ticket lifetime,
lifetime is up to local policy. lifetime is up to local policy.
A.6. -00 B.6. -00
Initial version. This draft is a selective merge of Initial version. This draft is a selective merge of
draft-sheffer-ike-session-resumption-00 and draft-sheffer-ike-session-resumption-00 and
draft-dondeti-ipsec-failover-sol-00. draft-dondeti-ipsec-failover-sol-00.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim St. 5 Hasolelim St.
 End of changes. 23 change blocks. 
61 lines changed or deleted 106 lines changed or added

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