draft-ietf-ipsecme-ikev2-resumption-05.txt   draft-ietf-ipsecme-ikev2-resumption-06.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: December 18, 2009 Nokia Siemens Networks Expires: December 20, 2009 Nokia Siemens Networks
June 16, 2009 June 18, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-05.txt draft-ietf-ipsecme-ikev2-resumption-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 December 18, 2009. This Internet-Draft will expire on December 20, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 8 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 8
4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9 4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9
4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
4.3.1. Prologue . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Prologue . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10 4.3.2. IKE_SESSION_RESUME Exchange . . . . . . . . . . . . . 10
4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 4.3.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12
4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.4. Epilogue . . . . . . . . . . . . . . . . . . . . . . . 13
5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13 5. IKE and IPsec State After Resumption . . . . . . . . . . . . . 13
5.1. Generating Cryptographic Material for the Resumed IKE 5.1. Generating Cryptographic Material for the Resumed IKE
SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 6. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 6.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17 7. IKE Notifications . . . . . . . . . . . . . . . . . . . . . . 17
7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 17 7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 17
7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18 7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 20
9.4. Key Management for Tickets By Value . . . . . . . . . . . 20 9.4. Key Management for Tickets By Value . . . . . . . . . . . 20
9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 20
9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 20 9.6. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 20
9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21 9.7. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21
9.8. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24
A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 23 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 24
A.2. Example Ticket by Reference Format . . . . . . . . . . . . 24 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 24
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
B.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.1. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.3. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.5. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.6. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.7. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.8. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.9. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.10. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.10. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.11. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.11. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.12. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.12. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.13. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 B.13. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.14. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
is restored, all the clients might reconnect almost is restored, all the clients might reconnect almost
simultaneously. This mechanism could be used to reduce the load simultaneously. This mechanism could be used to reduce the load
spike for cryptographic operations and authentication spike for cryptographic operations and authentication
infrastructure. infrastructure.
o Losing connectivity can also be predictable and planned; for o Losing connectivity can also be predictable and planned; for
example, putting a laptop to "stand-by" mode before travelling. example, putting a laptop to "stand-by" mode before travelling.
This mechanism could be used to re-establish the SA when the This mechanism could be used to re-establish the SA when the
laptop is switched back on (again, with less overhead and without laptop is switched back on (again, with less overhead and without
requiring user interaction for authentication). However such requiring user interaction for authentication). However such
user-level "resumption" may often be disallowed by policy. user-level "resumption" may often be disallowed by policy.
Moreover, this document requires the client to destroy the ticket
when the user explicitly "logs out" (Section 6.2.
4. Protocol Sequences 4. Protocol Sequences
This section provides protocol details and contains the normative This section provides protocol details and contains the normative
parts. This document defines two protocol exchanges, namely parts. This document defines two protocol exchanges, namely
requesting a ticket, see Section 4.1, and presenting a ticket, see requesting a ticket, see Section 4.1, and presenting a ticket, see
Section 4.3. Section 4.3.
4.1. Requesting a Ticket 4.1. Requesting a Ticket
skipping to change at page 17, line 8 skipping to change at page 17, line 8
an absolute time value and SHOULD correspond to the value included in an absolute time value and SHOULD correspond to the value included in
the TICKET_LT_OPAQUE payload. the TICKET_LT_OPAQUE payload.
The ticket by value MUST additionally include a key identity field, The ticket by value MUST additionally include a key identity field,
so that keys for ticket encryption and authentication can be changed, so that keys for ticket encryption and authentication can be changed,
and when necessary, algorithms can be replaced. and when necessary, algorithms can be replaced.
6.2. Ticket Identity and Lifecycle 6.2. Ticket Identity and Lifecycle
Each ticket is associated with a single IKE SA. In particular, when Each ticket is associated with a single IKE SA. In particular, when
an IKE SA is deleted, the client MUST delete its stored ticket. an IKE SA is deleted by the client or the gateway, the client MUST
Similarly, when credentials associated with the IKE SA are delete its stored ticket. Similarly, when credentials associated
invalidated (e.g. when a user logs out), the ticket MUST be deleted. with the IKE SA are invalidated (e.g. when a user logs out), the
When the IKE SA is rekeyed the ticket is invalidated, and the client ticket MUST be deleted. When the IKE SA is rekeyed the ticket is
SHOULD request a new ticket. invalidated, and the client SHOULD request a new ticket. When a
client does not follow these rules, it might present an invalid
ticket to the gateway. See Section 9.6 for more about this issue.
The lifetime of the ticket sent by the gateway SHOULD be the minimum The lifetime of the ticket sent by the gateway SHOULD be the minimum
of the IKE SA lifetime (per the gateway's local policy) and its re- of the IKE SA lifetime (per the gateway's local policy) and its re-
authentication time, according to [RFC4478]. Even if neither of authentication time, according to [RFC4478]. Even if neither of
these are enforced by the gateway, a finite lifetime MUST be these are enforced by the gateway, a finite lifetime MUST be
specified for the ticket. specified for the ticket.
The key that is used to protect the ticket MUST have a lifetime that The key that is used to protect the ticket MUST have a lifetime that
is significantly longer than the lifetime of an IKE SA. is significantly longer than the lifetime of an IKE SA.
skipping to change at page 20, line 45 skipping to change at page 20, line 48
9.5. Ticket Lifetime 9.5. Ticket Lifetime
An IKEv2 responder controls the validity period of the state An IKEv2 responder controls the validity period of the state
information by attaching a lifetime to a ticket. The chosen lifetime information by attaching a lifetime to a ticket. The chosen lifetime
is based on the operational and security requirements of the is based on the operational and security requirements of the
environment in which this IKEv2 extension is deployed. The responder environment in which this IKEv2 extension is deployed. The responder
provides information about the ticket lifetime to the IKEv2 provides information about the ticket lifetime to the IKEv2
initiator, allowing it to manage its tickets. initiator, allowing it to manage its tickets.
9.6. Ticket by Value Format 9.6. Ticket Revocation
A misbehaving client could present a ticket in its possession to the
gateway resulting in session resumption, even though the IKE SA
associated with this ticket had previously been deleted. This is
disallowed by Section 6.2. This issue is unique to ticket by value
cases, since a ticket by reference will have been deleted from the
ticket store.
To avoid this issue for ticket by value, an Invalid Ticket List (ITL)
may be maintained by the gateway, see
[I-D.rescorla-stateless-tokens]. This can be a simple blacklist of
revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens]
suggests to use Bloom Filters [Bloom70] to maintain the list in
constant space. Management of such lists is outside the scope of the
current document. Note that a policy that requires tickets to have
shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
9.7. Ticket by Value Format
The ticket's format is not defined by this document, since this is The ticket's format is not defined by this document, since this is
not required for interoperability. However great care must be taken not required for interoperability. However great care must be taken
when defining a ticket format such that the requirements outlined in when defining a ticket format such that the requirements outlined in
Section 6.1 are met. The ticket by value MUST have its integrity and Section 6.1 are met. The ticket by value MUST have its integrity and
confidentiality protected with strong cryptographic techniques to confidentiality protected with strong cryptographic techniques to
prevent a breach in the security of the system. prevent a breach in the security of the system.
9.7. Identity Privacy, Anonymity, and Unlinkability 9.8. Identity Privacy, Anonymity, and Unlinkability
Since opaque state information is passed around between the IKEv2 Since opaque state information is passed around between the IKEv2
initiator and the IKEv2 responder it is important that leakage of initiator and the IKEv2 responder it is important that leakage of
information, such as the identities of an IKEv2 initiator and a information, such as the identities of an IKEv2 initiator and a
responder, MUST be avoided. responder, MUST be avoided.
When an IKEv2 initiator presents a 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. There is thereby the possibility for an on-path adversary exchange. There is thereby the possibility for an on-path adversary
to observe multiple exchange handshakes where the same state to observe multiple exchange handshakes where the same state
skipping to change at page 22, line 10 skipping to change at page 22, line 31
11.1. Normative References 11.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.
11.2. Informative References 11.2. Informative References
[Bloom70] Bloom, B., "Space/time trade-offs in hash coding with
allowable errors", Comm. ACM 13(7):422-6, July 1970.
[I-D.eronen-ipsec-ikev2-eap-auth] [I-D.eronen-ipsec-ikev2-eap-auth]
Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
for EAP-Only Authentication in IKEv2", for EAP-Only Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress), draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress),
April 2009. April 2009.
[I-D.ietf-ipsecme-ikev2-redirect] [I-D.ietf-ipsecme-ikev2-redirect]
Devarapalli, V. and K. Weniger, "Redirect Mechanism for Devarapalli, V. and K. Weniger, "Redirect Mechanism for
IKEv2", draft-ietf-ipsecme-ikev2-redirect-10 (work in IKEv2", draft-ietf-ipsecme-ikev2-redirect-11 (work in
progress), May 2009. progress), June 2009.
[I-D.ietf-ipsecme-ikev2bis] [I-D.ietf-ipsecme-ikev2bis]
Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol: IKEv2", "Internet Key Exchange Protocol: IKEv2",
draft-ietf-ipsecme-ikev2bis-03 (work in progress), draft-ietf-ipsecme-ikev2bis-03 (work in progress),
April 2009. April 2009.
[I-D.ietf-rohc-ikev2-extensions-hcoipsec] [I-D.ietf-rohc-ikev2-extensions-hcoipsec]
Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and
C. Bormann, "IKEv2 Extensions to Support Robust Header C. Bormann, "IKEv2 Extensions to Support Robust Header
skipping to change at page 25, line 25 skipping to change at page 25, line 25
} ikev2_state_ref; } ikev2_state_ref;
} protected_part; } protected_part;
opaque MAC[0..255]; // the length depends opaque MAC[0..255]; // the length depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
Appendix B. Change Log Appendix B. Change Log
Note to RFC Editor: remove this appendix before publication. Note to RFC Editor: remove this appendix before publication.
B.1. -05 B.1. -06
Clients resuming propely closed sessions and how this can be avoided.
B.2. -05
Editorial changes: reordered and merged some sections. Editorial changes: reordered and merged some sections.
Restated the use cases. Restated the use cases.
IDr is not negotiated during resumption, the gateway must use the IDr is not negotiated during resumption, the gateway must use the
stored IDr. stored IDr.
Multiple small clarifications based on Pasi's LC review. Multiple small clarifications based on Pasi's LC review.
IPR: pre5378Trust200902. IPR: pre5378Trust200902.
B.2. -04 B.3. -04
Closed issue #105, Non-PKI use of EAP, and resumption. Closed issue #105, Non-PKI use of EAP, and resumption.
Closed issue #106, Resumption and NAT detection and changing ports. Closed issue #106, Resumption and NAT detection and changing ports.
B.3. -03 B.4. -03
Changed the protocol from one to two round trips, to simplify the Changed the protocol from one to two round trips, to simplify the
security assumptions. Eliminated security considerations associated security assumptions. Eliminated security considerations associated
with the previous version. with the previous version.
Closed issue #69, Clarify behavior of SPI and sequence numbers. Closed issue #69, Clarify behavior of SPI and sequence numbers.
Closed issue #70, Ticket lifetime - explicit or not? (and ticket push Closed issue #70, Ticket lifetime - explicit or not? (and ticket push
from gateway). from gateway).
skipping to change at page 26, line 24 skipping to change at page 26, line 32
Closed issue #95, Minor nits for ikev2-resumption-02. Closed issue #95, Minor nits for ikev2-resumption-02.
Closed issue #97, Clarify what state comes from where. Closed issue #97, Clarify what state comes from where.
Closed issue #98, Replays in 1-RTT protocol. Closed issue #98, Replays in 1-RTT protocol.
Closed issue #100, NAT detection [and] IP address change. Closed issue #100, NAT detection [and] IP address change.
Closed issue #101, Assorted issues by Tero. Closed issue #101, Assorted issues by Tero.
B.4. -02 B.5. -02
Added a new TICKET_OPAQUE payload that does not have a lifetime field Added a new TICKET_OPAQUE payload that does not have a lifetime field
included. included.
Removed the lifetime usage from the IKE_SESSION_RESUME exchange Removed the lifetime usage from the IKE_SESSION_RESUME exchange
(utilizing the TICKET_OPAQUE) when presenting the ticket to the (utilizing the TICKET_OPAQUE) when presenting the ticket to the
gateway. gateway.
Removed IDi payloads from the IKE_SESSION_RESUME exchange. Removed IDi payloads from the IKE_SESSION_RESUME exchange.
Clarified that IPsec child SAs would be deleted once the old IKE SA Clarified that IPsec child SAs would be deleted once the old IKE SA
gets deleted as well. gets deleted as well.
Clarified the behavior of SPI and sequence number usage. Clarified the behavior of SPI and sequence number usage.
B.5. -01 B.6. -01
Addressed issue#75, see Addressed issue#75, see
http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included
changes throughout the document to ensure that the ticket may contain changes throughout the document to ensure that the ticket may contain
a reference or a value. a reference or a value.
B.6. -00 B.7. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.7. -01 B.8. -01
Added reference to [I-D.xu-ike-sa-sync] Added reference to [I-D.xu-ike-sa-sync]
Included recommended ticket format into the appendix Included recommended ticket format into the appendix
Various editorial improvements within the document Various editorial improvements within the document
B.8. -00 B.9. -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.
B.9. -04 B.10. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.10. -03 B.11. -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.
B.11. -02 B.12. -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.
B.12. -01 B.13. -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.
B.13. -00 B.14. -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. 28 change blocks. 
47 lines changed or deleted 78 lines changed or added

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