draft-ietf-ipsecme-ikev2-resumption-03.txt   draft-ietf-ipsecme-ikev2-resumption-04.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: November 2, 2009 Nokia Siemens Networks Expires: November 16, 2009 Nokia Siemens Networks
L. Dondeti L. Dondeti
V. Narayanan V. Narayanan
QUALCOMM, Inc. QUALCOMM, Inc.
May 1, 2009 May 15, 2009
IKEv2 Session Resumption IKEv2 Session Resumption
draft-ietf-ipsecme-ikev2-resumption-03.txt draft-ietf-ipsecme-ikev2-resumption-04.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. 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 2, 2009. This Internet-Draft will expire on November 16, 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 27 skipping to change at page 3, line 27
4.7. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 4.7. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11
4.7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . 12 4.7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . 12
4.7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12 4.7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12
4.8. Computing the AUTH Payload . . . . . . . . . . . . . . . . 13 4.8. Computing the AUTH Payload . . . . . . . . . . . . . . . . 13
5. Processing Guidelines for IKE SA Establishment . . . . . . . . 13 5. Processing Guidelines for IKE SA Establishment . . . . . . . . 13
6. The State After Resumption . . . . . . . . . . . . . . . . . . 14 6. The State After Resumption . . . . . . . . . . . . . . . . . . 14
7. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 7. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 7.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18
9.4. Key Management for Tickets By Value . . . . . . . . . . . 19 9.4. Key Management for Tickets By Value . . . . . . . . . . . 19
9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 19 9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 19
9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 19 9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 22
A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 22 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 22
A.2. Example Ticket by Reference Format . . . . . . . . . . . . 23 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 23
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 B.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 B.6. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.7. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.8. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.8. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.9. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.9. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.10. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.10. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.11. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 11, line 7 skipping to change at page 11, line 7
derived, per Section 2.17 of [RFC4306]. derived, per Section 2.17 of [RFC4306].
When the responder receives a ticket for an IKE SA that is still When the responder receives a ticket for an IKE SA that is still
active and if the responder accepts it, then the old SA SHOULD be active and if the responder accepts it, then the old SA SHOULD be
silently deleted without sending a DELETE informational exchange. silently deleted without sending a DELETE informational exchange.
Consequently, all the dependent IPsec child SAs are also deleted. Consequently, all the dependent IPsec child SAs are also deleted.
This happens after both peers have been authenticated. This happens after both peers have been authenticated.
4.4. IKE_SESSION_RESUME Details 4.4. IKE_SESSION_RESUME Details
The IKE_SESSION_RESUME exchange behaves like the IKE_SA_INIT exchange Where not specified otherwise, the IKE_SESSION_RESUME exchange
in most respects. Specifically: behaves exactly like the IKE_SA_INIT exchange. Specifically:
o The first message may be rejected in denial of service situations, o The first message may be rejected in denial of service situations,
with the initiator instructed to send a cookie. with the initiator instructed to send a cookie.
o Notifications normally associated with IKE_SA_INIT can be sent. o Notifications normally associated with IKE_SA_INIT can be sent.
In particular, NAT detection payloads. In particular, NAT detection payloads.
o The SPI values and Message ID fields behave similarly to o The SPI values and Message ID fields behave similarly to
IKE_SA_INIT. IKE_SA_INIT.
o NAT may be detected during the IKE_SESSION_RESUME exchange, in
which case the initiator switches to UDP encapsulation to port
4500, as per [RFC4306], Sec. 2.23.
4.5. Requesting a Ticket During Resumption 4.5. Requesting a Ticket During Resumption
When resuming a session, a client will typically request a new ticket When resuming a session, a client will typically request a new ticket
immediately, so it is able to resume the session again in the case of immediately, so it is able to resume the session again in the case of
a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE) a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE)
notifications will be included in the IKE_AUTH exchange that follows notifications will be included in the IKE_AUTH exchange that follows
the IKE_SESSION_RESUME exchange, with similar behavior to a ticket the IKE_SESSION_RESUME exchange, with similar behavior to a ticket
request during a regular IKE exchange, Section 4.1. request during a regular IKE exchange, Section 4.1.
skipping to change at page 11, line 40 skipping to change at page 11, line 43
The client MAY resume the IKE exchange from an IP address different The client MAY resume the IKE exchange from an IP address different
from its original address. The gateway MAY reject the resumed from its original address. The gateway MAY reject the resumed
exchange if its policy depends on the client's address (although this exchange if its policy depends on the client's address (although this
rarely makes sense). rarely makes sense).
The client's NAT traversal status SHOULD be determined anew upon The client's NAT traversal status SHOULD be determined anew upon
session resumption, by using the appropriate notifications. This session resumption, by using the appropriate notifications. This
status is explicitly not part of the session resumption state. status is explicitly not part of the session resumption state.
See also Section 4.4 for related details.
4.7. IKE Notifications 4.7. IKE Notifications
This document defines a number of notifications. The notification This document defines a number of notifications. The notification
numbers are TBA by IANA. numbers are TBA by IANA.
+-------------------+--------+-------------------+ +-------------------+--------+-------------------+
| Notification Name | Number | Data | | Notification Name | Number | Data |
+-------------------+--------+-------------------+ +-------------------+--------+-------------------+
| TICKET_LT_OPAQUE | TBA1 | See Section 4.7.1 | | TICKET_LT_OPAQUE | TBA1 | See Section 4.7.1 |
| TICKET_REQUEST | TBA2 | None | | TICKET_REQUEST | TBA2 | None |
skipping to change at page 15, line 8 skipping to change at page 15, line 8
related to their state before the IKE SA was interrupted. When the related to their state before the IKE SA was interrupted. When the
table mentions that a certain state item is taken "from the ticket", table mentions that a certain state item is taken "from the ticket",
this should be construed as: this should be construed as:
o The client retrieves this item from its local store. o The client retrieves this item from its local store.
o In the case of ticket by value, the gateway encodes this o In the case of ticket by value, the gateway encodes this
information in the ticket. information in the ticket.
o In the case of ticket by reference, the gateway fetches this o In the case of ticket by reference, the gateway fetches this
information from the ticket store. information from the ticket store.
+-----------------------------------+-------------------------------+ +--------------------------------------+----------------------------+
| State Item | After Resumption | | State Item | After Resumption |
+-----------------------------------+-------------------------------+ +--------------------------------------+----------------------------+
| IDi | From the ticket (but must | | IDi | From the ticket (but must |
| | also be exchanged in | | | also be exchanged in |
| | IKE_AUTH) | | | IKE_AUTH) |
| IDr | From the new exchange (but | | IDr | From the new exchange (but |
| | old value included in the | | | old value included in the |
| | ticket) | | | ticket) |
| Authentication method | From the ticket | | Authentication method (PKI, | From the ticket |
| pre-shared secret, EAP, PKI-less EAP | |
| [I-D.eronen-ipsec-ikev2-eap-auth] | |
| etc.) | |
| Certificates (when applicable) | Unspecified, see note 1 | | Certificates (when applicable) | Unspecified, see note 1 |
| Local IP address/port, peer IP | Selected by the client, see | | Local IP address/port, peer IP | Selected by the client, |
| address/port | note 2 | | address/port | see note 2 |
| NAT detection status | From new exchange | | NAT detection status | From new exchange |
| SPIs | From new exchange | | SPIs | From new exchange |
| Which peer is the "original | Determined by the initiator | | Which peer is the "original | Determined by the |
| initiator"? | of IKE_SESSION_RESUME | | initiator"? | initiator of |
| IKE SA sequence numbers (Message | Start from 0 | | | IKE_SESSION_RESUME |
| ID) | | | IKE SA sequence numbers (Message ID) | Start from 0 |
| IKE SA algorithms (SAr) | From the ticket | | IKE SA algorithms (SAr) | From the ticket |
| IKE SA keys (SK_*) | SK_d from the ticket, others | | IKE SA keys (SK_*) | SK_d from the ticket, |
| | are refreshed | | | others are refreshed |
| IKE SA window size | Reset to 1 | | IKE SA window size | Reset to 1 |
| Child SAs (ESP/AH) | Created in new exchange, see | | Child SAs (ESP/AH) | Created in new exchange, |
| | note 5 | | | see note 5 |
| Internal IP address | Not resumed, but see note 3 | | Internal IP address | Not resumed, but see note |
| | 3 |
| Other Configuration Payload | Not resumed | | Other Configuration Payload | Not resumed |
| information | | | information | |
| Peer vendor IDs | Unspecified (needed in the | | Peer vendor IDs | Unspecified (needed in the |
| | ticket only if | | | ticket only if |
| | vendor-specific state is | | | vendor-specific state is |
| | required) | | | required) |
| Peer supports MOBIKE [RFC4555] | From new exchange | | Peer supports MOBIKE [RFC4555] | From new exchange |
| MOBIKE additional addresses | Not resumed, should be resent | | MOBIKE additional addresses | Not resumed, should be |
| | by client if necessary | | | resent by client if |
| Time until re-authentication | From new exchange (but ticket | | | necessary |
| [RFC4478] | lifetime is bounded by this | | Time until re-authentication | From new exchange (but |
| | duration) | | [RFC4478] | ticket lifetime is bounded |
| | by this duration) |
| Peer supports redirects | From new exchange | | Peer supports redirects | From new exchange |
| [I-D.ietf-ipsecme-ikev2-redirect] | | | [I-D.ietf-ipsecme-ikev2-redirect] | |
+-----------------------------------+-------------------------------+ +--------------------------------------+----------------------------+
Note 1: Certificates don't need to be stored if the peer never uses Note 1: Certificates don't need to be stored if the peer never uses
them for anything after the IKE SA is up (but would be them for anything after the IKE SA is up (but would be
needed if exposed to applications via IPsec APIs). needed if exposed to applications via IPsec APIs).
Note 2: If the certificate has an iPAddress SubjectAltName, and the Note 2: If the certificate has an iPAddress SubjectAltName, and the
implementation requires it to match the peer's source IP implementation requires it to match the peer's source IP
address, the same check needs to be performed on session address, the same check needs to be performed on session
resumption and the required information saved locally or in resumption and the required information saved locally or in
the ticket. the ticket.
Note 3: The client can request the address it was using earlier, and Note 3: The client can request the address it was using earlier, and
if possible, the gateway SHOULD honor the request. if possible, the gateway SHOULD honor the request.
skipping to change at page 17, line 10 skipping to change at page 17, line 14
vulnerabilities include access by the gateway to unintended URLs vulnerabilities include access by the gateway to unintended URLs
(similar to cross-site scripting) or SQL injection. (similar to cross-site scripting) or SQL injection.
When the state is passed by value, the ticket MUST encode at least When the state is passed by value, the ticket MUST encode at least
the following state from an IKE SA. The same state MUST be stored in the following state from an IKE SA. The same state MUST be stored in
the ticket store, in the case of ticket by reference. the ticket store, in the case of ticket by reference.
o IDi, IDr. o IDi, IDr.
o SPIi, SPIr. o SPIi, SPIr.
o SAr (the accepted proposal). o SAr (the accepted proposal).
o The authentication method used.
o SK_d. o SK_d.
The ticket by value MUST include a key identity field, so that keys The ticket by value MUST include a key identity field, so that keys
for encryption and authentication can be changed, and when necessary, for encryption and authentication can be changed, and when necessary,
algorithms can be replaced. algorithms can be replaced.
7.2. Ticket Identity and Lifecycle 7.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, the client MUST delete its stored ticket.
skipping to change at page 20, line 46 skipping to change at page 21, line 7
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
[I-D.eronen-ipsec-ikev2-eap-auth]
Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
for EAP-Only Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress),
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-08 (work in IKEv2", draft-ietf-ipsecme-ikev2-redirect-09 (work in
progress), April 2009. progress), May 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 22, line 31 skipping to change at page 23, line 17
octet reserved[3]; // sent as 0, ignored by receiver. octet reserved[3]; // sent as 0, ignored by receiver.
octet key_id[8]; // arbitrary byte string octet key_id[8]; // arbitrary byte string
opaque IV[0..255]; // actual length (possibly 0) depends opaque IV[0..255]; // actual length (possibly 0) depends
// on the encryption algorithm // on the encryption algorithm
[encrypted] struct { [encrypted] struct {
opaque IDi, IDr; // the full payloads opaque IDi, IDr; // the full payloads
octet SPIi[8], SPIr[8]; octet SPIi[8], SPIr[8];
opaque SA; // the full SAr payload opaque SA; // the full SAr payload
octet SK_d[0..255]; // actual length depends on SA value octet SK_d[0..255]; // actual length depends on SA value
enum ... authentication_method;
int32 expiration; // an absolute time value, seconds int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970 // since Jan. 1, 1970
} ikev2_state; } ikev2_state;
} protected_part; } protected_part;
opaque MAC[0..255]; // the length (possibly 0) depends opaque MAC[0..255]; // the length (possibly 0) depends
// on the integrity algorithm // on the integrity algorithm
} ticket; } ticket;
Note that the key defined by "key_id" determines the encryption and Note that the key defined by "key_id" determines the encryption and
authentication algorithms used for this ticket. Those algorithms are authentication algorithms used for this ticket. Those algorithms are
skipping to change at page 23, line 29 skipping to change at page 24, line 23
int32 expiration; // an absolute time value, seconds int32 expiration; // an absolute time value, seconds
// since Jan. 1, 1970 // since Jan. 1, 1970
} 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
B.1. -03 B.1. -04
Closed issue #105, Non-PKI use of EAP, and resumption.
Closed issue #106, Resumption and NAT detection and changing ports.
B.2. -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 24, line 11 skipping to change at page 25, line 9
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.2. -02 B.3. -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.3. -01 B.4. -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.4. -00 B.5. -00
Resubmitted document as a WG item. Resubmitted document as a WG item.
B.5. -01 B.6. -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.6. -00 B.7. -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.7. -04 B.8. -04
Editorial fixes; references cleaned up; updated author's contact Editorial fixes; references cleaned up; updated author's contact
address address
B.8. -03 B.9. -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.9. -02 B.10. -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.10. -01 B.11. -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.11. -00 B.12. -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. 35 change blocks. 
55 lines changed or deleted 81 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/