< draft-ietf-ipsecme-ikev2-resumption-08.txt		draft-ietf-ipsecme-ikev2-resumption-09.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: March 25, 2010 Nokia Siemens Networks		Expires: April 24, 2010 Nokia Siemens Networks
	September 21, 2009		October 21, 2009
	IKEv2 Session Resumption		IKEv2 Session Resumption
	draft-ietf-ipsecme-ikev2-resumption-08.txt		draft-ietf-ipsecme-ikev2-resumption-09.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 March 25, 2010.		This Internet-Draft will expire on April 24, 2010.
	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 35 ¶		skipping to change at page 3, line 35 ¶
	7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18		7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . . . 18
	7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18		7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		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. Detecting the Need for Resumption . . . . . . . . . . . . 20		9.4. Detecting the Need for Resumption . . . . . . . . . . . . 20
	9.5. Key Management for Tickets By Value . . . . . . . . . . . 20		9.5. Key Management for Tickets By Value . . . . . . . . . . . 20
	9.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 21		9.6. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 21
	9.7. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21		9.7. Tickets and Identity . . . . . . . . . . . . . . . . . . . 21
	9.8. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21		9.8. Ticket Revocation . . . . . . . . . . . . . . . . . . . . 21
	9.9. Identity Privacy, Anonymity, and Unlinkability . . . . . . 21		9.9. Ticket by Value Format . . . . . . . . . . . . . . . . . . 21
			9.10. Identity Privacy, Anonymity, and Unlinkability . . . . . . 22
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 22		11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . . 23		11.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24		Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 24
	A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 24		A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 25
	A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25		A.2. Example Ticket by Reference Format . . . . . . . . . . . . 25
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
	B.1. -08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		B.1. -09 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.2. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		B.2. -08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.3. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		B.3. -07 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.4. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		B.4. -06 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		B.5. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	B.6. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		B.6. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	B.7. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		B.7. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	B.8. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.8. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	B.9. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.9. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.10. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.10. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.11. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.12. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.13. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.13. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.14. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		B.14. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.15. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		B.15. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	B.16. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		B.16. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
			B.17. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	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 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	The second use case focuses on the usage of transport (or tunnel)		The second use case focuses on the usage of transport (or tunnel)
	mode to secure the communicate between two end points (e.g., two		mode to secure the communicate between two end points (e.g., two
	servers). The two endpoints have a client-server relationship with		servers). The two endpoints have a client-server relationship with
	respect to a protocol that runs using the protections afforded by the		respect to a protocol that runs using the protections afforded by the
	IPsec SA.		IPsec SA.
	(a)		(a)
	+-+-+-+-+-+ +-+-+-+-+-+		+-+-+-+-+-+ +-+-+-+-+-+
	! ! IKEv2/IKEv2-EAP ! ! Protected		| | IKEv2/IKEv2-EAP | | Protected
	! Remote !<------------------------>! ! Subnet		| Remote |<------------------------>| | Subnet
	! Access ! ! Access !<--- and/or		| Access | | Access |<--- and/or
	! Client !<------------------------>! Gateway ! Internet		| Client |<------------------------>| Gateway | Internet
	! ! IPsec tunnel ! !		| | IPsec tunnel | |
	+-+-+-+-+-+ +-+-+-+-+-+		+-+-+-+-+-+ +-+-+-+-+-+
	(b)		(b)
	+-+-+-+-+-+ +-+-+-+-+-+		+-+-+-+-+-+ +-+-+-+-+-+
	! ! IKE_SESSION_RESUME ! !		| | IKE_SESSION_RESUME | |
	! Remote !<------------------------>! !		| Remote |<------------------------>| |
	! Access ! ! Access !		| Access | | Access |
	! Client !<------------------------>! Gateway !		| Client |<------------------------>| Gateway |
	! ! IPsec tunnel ! !		| | IPsec tunnel | |
	+-+-+-+-+-+ +-+-+-+-+-+		+-+-+-+-+-+ +-+-+-+-+-+
	Figure 1: Resuming a Session with a Remote Access Gateway		Figure 1: Resuming a Session with a Remote Access Gateway
	In the first use case above, an end host (an entity with a host		In the first use case above, an end host (an entity with a host
	implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA		implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA
	with a gateway in a remote network using IKEv2. The end host in this		with a gateway in a remote network using IKEv2. The end host in this
	scenario is sometimes referred to as a remote access client. At a		scenario is sometimes referred to as a remote access client. At a
	later stage when a client needs to re-establish the IKEv2 session it		later stage when a client needs to re-establish the IKEv2 session it
	may choose to establish IPsec SAs using a full IKEv2 exchange or the		may choose to establish IPsec SAs using a full IKEv2 exchange or the
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	In particular, NAT detection payloads.		In particular, NAT detection payloads.
	o The client's NAT traversal status SHOULD be determined anew in		o The client's NAT traversal status SHOULD be determined anew in
	IKE_SESSION_RESUME. If NAT is detected, the initiator switches to		IKE_SESSION_RESUME. If NAT is detected, the initiator switches to
	UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT		UDP encapsulation on port 4500, as per [RFC4306], Sec. 2.23. NAT
	status is explicitly not part of the session resumption state.		status is explicitly not part of the session resumption state.
	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.
	Although the IKE SA is not fully valid until the completion of the		Although the IKE SA is not fully valid until the completion of the
	IKE_AUTH exchange, the peers must create much of the SA state		IKE_AUTH exchange, the peers must create much of the SA state
	(Section 5) now. Specifically, the SK_xx values are required to		(Section 5) now. Specifically, the shared key values are required to
	protect the IKE_AUTH payloads.		protect the IKE_AUTH payloads. Their generation is described in
			Section 5.1.
	4.3.3. IKE_AUTH Exchange		4.3.3. IKE_AUTH Exchange
	Following the IKE_SESSION_RESUME exchange, the client MUST initiate		Following the IKE_SESSION_RESUME exchange, the client MUST initiate
	an IKE_AUTH exchange, which is largely as specified in [RFC4306].		an IKE_AUTH exchange, which is largely as specified in [RFC4306].
	This section lists the differences and constraints compared to the		This section lists the differences and constraints compared to the
	base document.		base document.
	The value of the AUTH payload is derived in a manner similar to the		The value of the AUTH payload is derived in a manner similar to the
	usage of IKEv2 pre-shared secret authentication:		usage of IKEv2 pre-shared secret authentication:
	AUTH = prf(SK_px, <message octets>)		AUTH = prf(SK_px, <message octets>)
	Each of the initiator and responder uses its own SK_p value, taken		Each of the initiator and responder uses its own value for SK_px,
	from the newly generated IKE SA, Section 5.1.		namely SK_pi for the initiator and SK_pr for the responder. Both are
			taken from the newly generated IKE SA, Section 5.1.
	The exact material to be signed is defined in Section 2.15 of		The exact material to be signed is defined in Section 2.15 of
	[RFC4306].		[RFC4306].
	The IDi value sent in the IKE_AUTH exchange MUST be identical to the		The IDi value sent in the IKE_AUTH exchange MUST be identical to the
	value included in the ticket. A CERT payload MUST NOT be included in		value included in the ticket. A CERT payload MUST NOT be included in
	this exchange, and therefore a new IDr value cannot be negotiated		this exchange, and therefore a new IDr value cannot be negotiated
	(since it would not be authenticated). As a result, the IDr value		(since it would not be authenticated). As a result, the IDr value
	sent (by the gateway, and optionally by the client) in this exchange		sent (by the gateway, and optionally by the client) in this exchange
	MUST also be identical to the value included in the ticket.		MUST also be identical to the value included in the ticket.
	skipping to change at page 15, line 9 ¶		skipping to change at page 15, line 9 ¶
	| | resent by client if |		| | resent by client if |
	| | necessary |		| | necessary |
	| Time until re-authentication | From new exchange (but |		| Time until re-authentication | From new exchange (but |
	| [RFC4478] | ticket lifetime is bounded |		| [RFC4478] | ticket lifetime is bounded |
	| | by this duration) |		| | 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: The authenticated peer identity used for policy lookups may		Note 1: The authenticated peer identity used for policy lookups may
	not be the same as the IDi payload (see Sec. 3.5 of		not be the same as the IDi payload. This is possible when
	[RFC4718]), and if so, MUST be included in the ticket. Note		using certain EAP methods, see Sec. 3.5 of [RFC4718]. If
	that the client may not have access to this value.		these identities are indeed different, then the
			authenticated client identity MUST be included in the
			ticket. Note that the client may not have access to this
			value.
	Note 2: Certificates don't need to be stored if the peer never uses		Note 2: Certificates don't need to be stored if the peer never uses
	them for anything after the IKE SA is up; however if they		them for anything after the IKE SA is up; however if they
	are needed, e.g. if exposed to applications via IPsec APIs,		are needed, e.g. if exposed to applications via IPsec APIs,
	they MUST be stored in the ticket.		they MUST be stored in the ticket.
	Note 3: If the certificate has an iPAddress SubjectAltName, and the		Note 3: 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 4: SPI values of the old SA MAY be stored in the ticket, to		Note 4: SPI values of the old SA MAY be stored in the ticket, to
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 18 ¶
	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 by the client or the gateway, the client MUST		an IKE SA is deleted by the client or the gateway, the client MUST
	delete its stored ticket. Similarly, when credentials associated		delete its stored ticket. Similarly, when credentials associated
	with the IKE SA are invalidated (e.g. when a user logs out), the		with the IKE SA are invalidated (e.g. when a user logs out), the
	ticket MUST be deleted. When the IKE SA is rekeyed the ticket is		ticket MUST be deleted. When the IKE SA is rekeyed the ticket is
	invalidated, and the client SHOULD request a new ticket. When a		invalidated, and the client SHOULD request a new ticket. When a
	client does not follow these rules, it might present an invalid		client does not follow these rules, it might present an invalid
	ticket to the gateway. See Section 9.7 for more about this issue.		ticket to the gateway. See Section 9.8 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.
	In normal operation, the client will request a ticket when		In normal operation, the client will request a ticket when
	establishing the initial IKE SA, and then every time the SA is		establishing the initial IKE SA, and then every time the SA is
	rekeyed or re-established because of re-authentication.		rekeyed or re-established because of re-authentication.
	7. IKE Notifications		7. IKE Notifications
	This document defines a number of notifications. The notification		This document defines a number of notifications. The Notify Message
	numbers are TBA by IANA.		types are TBA by IANA.
	+-------------------+--------+-----------------+		+-------------------+-------+-----------------+
	| Notification Name | Number | Data |		| Notification Name | Value | Data |
	+-------------------+--------+-----------------+		+-------------------+-------+-----------------+
	| TICKET_LT_OPAQUE | TBA1 | See Section 7.1 |		| TICKET_LT_OPAQUE | TBA1 | See Section 7.1 |
	| TICKET_REQUEST | TBA2 | None |		| TICKET_REQUEST | TBA2 | None |
	| TICKET_ACK | TBA3 | None |		| TICKET_ACK | TBA3 | None |
	| TICKET_NACK | TBA4 | None |		| TICKET_NACK | TBA4 | None |
	| TICKET_OPAQUE | TBA5 | See Section 7.2 |		| TICKET_OPAQUE | TBA5 | See Section 7.2 |
	+-------------------+--------+-----------------+		+-------------------+-------+-----------------+
	For all these notifications, the Protocol ID and the SPI Size fields		For all these notifications, the Protocol ID and the SPI Size fields
	MUST both be sent as 0.		MUST both be sent as 0.
	7.1. TICKET_LT_OPAQUE Notify Payload		7.1. TICKET_LT_OPAQUE Notify Payload
	The data for the TICKET_LT_OPAQUE Notify payload consists of the		The data for the TICKET_LT_OPAQUE Notify payload consists of the
	Notify message header, a Lifetime field and the ticket itself. The		Notify message header, a Lifetime field and the ticket itself. The
	four octet Lifetime field contains a relative time value, the number		four octet Lifetime field contains a relative time value, the number
	of seconds until the ticket expires (encoded as an unsigned integer).		of seconds until the ticket expires (encoded as an unsigned integer,
			in network byte order).
	0 1 2 3		0 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 ! SPI Size = 0 ! Notify Message Type !		| Protocol ID | SPI Size = 0 | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Lifetime !		| Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		| |
	~ Ticket ~		~ Ticket ~
	! !		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: TICKET_LT_OPAQUE Notify Payload		Figure 6: TICKET_LT_OPAQUE Notify Payload
	7.2. TICKET_OPAQUE Notify Payload		7.2. TICKET_OPAQUE Notify Payload
	The data for the TICKET_OPAQUE Notify payload consists of the Notify		The data for the TICKET_OPAQUE Notify payload consists of the Notify
	message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE		message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE
	payload, no lifetime value is included in the TICKET_OPAQUE Notify		payload, no lifetime value is included in the TICKET_OPAQUE Notify
	payload.		payload.
	0 1 2 3		0 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 ! SPI Size = 0 ! Notify Message Type !		| Protocol ID | SPI Size = 0 | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! !		| |
	~ Ticket ~		~ Ticket ~
	! !		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: TICKET_OPAQUE Notify Payload		Figure 7: TICKET_OPAQUE Notify Payload
	8. IANA Considerations		8. IANA Considerations
	Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME,		Section 4.3.2 defines a new IKEv2 exchange type, IKE_SESSION_RESUME,
	whose value is to be allocated (has been allocated) from the "IKEv2		whose value is to be allocated (has been allocated) from the "IKEv2
	Exchange Types" registry.		Exchange Types" registry.
	Section 7 defines several new IKEv2 notifications whose values are to		Section 7 defines several new IKEv2 notifications whose Message Type
	be allocated (have been allocated) from the "IKEv2 Notify Message		values are to be allocated (have been allocated) from the "IKEv2
	Types - Status Types" registry.		Notify Message Types - Status Types" registry.
	9. Security Considerations		9. Security Considerations
	This section addresses security issues related to the usage of a		This section addresses security issues related to the usage of a
	ticket.		ticket.
	9.1. Stolen Tickets		9.1. Stolen Tickets
	A man-in-the-middle may try to eavesdrop on an exchange to obtain a		A man-in-the-middle may try to eavesdrop on an exchange to obtain a
	ticket by value and use it to establish a session with the IKEv2		ticket by value and use it to establish a session with the IKEv2
	skipping to change at page 19, line 39 ¶		skipping to change at page 19, line 39 ¶
	key, a stolen ticket cannot be used by an attacker to successfully		key, a stolen ticket cannot be used by an attacker to successfully
	resume a session. An IKEv2 responder MUST use strong encryption and		resume a session. An IKEv2 responder MUST use strong encryption and
	integrity protection of the ticket to prevent an attacker from		integrity protection of the ticket to prevent an attacker from
	obtaining the ticket's contents, e.g., by using a brute force attack.		obtaining the ticket's contents, e.g., by using a brute force attack.
	A ticket by reference does not need to be encrypted. When an		A ticket by reference does not need to be encrypted. When an
	adversary is able to eavesdrop on a resumption attempt, as described		adversary is able to eavesdrop on a resumption attempt, as described
	in the previous paragraph, then the ticket by reference may be		in the previous paragraph, then the ticket by reference may be
	obtained. A ticket by reference cannot be used by an attacker to		obtained. A ticket by reference cannot be used by an attacker to
	successfully resume a session, for the same reasons as for a ticket		successfully resume a session, for the same reasons as for a ticket
	by value. Moreover, the adversary MUST NOT be able to resolve the		by value, namely because the attacker would not be able to prove,
	ticket via the reference, i.e., access control MUST be enforced to		during IKE_AUTH, its knowledge of the secret part of the IKE state
	ensure disclosure only to authorized entities.		embedded in the ticket. Moreover, the adversary MUST NOT be able to
			resolve the ticket via the reference, i.e., access control MUST be
			enforced to ensure disclosure only to authorized entities.
	9.2. Forged Tickets		9.2. Forged Tickets
	A malicious user could forge or alter a ticket by value in order to		A malicious user could forge or alter a ticket by value in order to
	resume a session, to extend its lifetime, to impersonate as another		resume a session, to extend its lifetime, to impersonate as another
	user, or to gain additional privileges. This attack is not possible		user, or to gain additional privileges. This attack is not possible
	if the content of the ticket by value is protected using a strong		if the content of the ticket by value is protected using a strong
	integrity protection algorithm.		integrity protection algorithm.
	In case of a ticket by reference an adversary may attempt to		In case of a ticket by reference an adversary may attempt to
	construct a fake ticket by reference to point to state information		construct a fake ticket by reference to point to state information
	stored by the IKEv2 responder. This attack will fail because the		stored by the IKEv2 responder. This attack will fail because the
	adversary is not in possession of the keying material associated with		adversary is not in possession of the keying material associated with
	the IKEv2 SA. As noted in Section 6.1, it is often useful to		the IKEv2 SA. As noted in Section 6.1, it is often useful to
	integrity-protect the ticket by reference, too.		integrity-protect the ticket by reference, too.
	9.3. Denial of Service Attacks		9.3. Denial of Service Attacks
	An adversary could generate and send a large number of tickets by		An adversary could generate and send a large number of tickets by
	value to a gateway for verification. To minimize the possibility of		value to a gateway for verification. Such an attack could burden the
	such denial of service, ticket verification should be lightweight		gateway's CPU, and/or exhaust its memory with half-open IKE state.
	(e.g., using efficient symmetric key cryptographic algorithms).		To minimize the possibility of such denial of service, ticket
			verification should be lightweight (e.g., using efficient symmetric
			key cryptographic algorithms).
	When an adversary chooses to send a large number of tickets by		When an adversary chooses to send a large number of tickets by
	reference then this may lead to an amplification attack as the IKEv2		reference then this may lead to an amplification attack as the IKEv2
	responder is forced to resolve the reference to a ticket in order to		responder is forced to resolve the reference to a ticket in order to
	determine that the adversary is not in possession of the keying		determine that the adversary is not in possession of the keying
	material corresponding to the stored state or that the reference is		material corresponding to the stored state or that the reference is
	void. To minimize this attack, the protocol to resolve the reference		void. To minimize this attack, the protocol to resolve the reference
	should be as lightweight as possible and should not generate a large		should be as lightweight as possible and should not generate a large
	number of messages.		number of messages.
			Note also that the regular IKEv2 cookie mechanism can be used to
			handle state-overflow DoS situations.
	9.4. Detecting the Need for Resumption		9.4. Detecting the Need for Resumption
	Detecting when an old IKE SA is no longer usable and needs to be		Detecting when an old IKE SA is no longer usable and needs to be
	resumed is out of scope of the current document. However, clients		resumed is out of scope of the current document. However, clients
	are warned against implementing a more liberal policy than that used		are warned against implementing a more liberal policy than that used
	to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular,		to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular,
	untrusted messages MUST NOT be relied upon to make this decision.		untrusted messages MUST NOT be relied upon to make this decision.
	9.5. Key Management for Tickets By Value		9.5. Key Management for Tickets By Value
	skipping to change at page 20, line 43 ¶		skipping to change at page 21, line 4 ¶
	to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular,		to detect failed IKE SAs (Sec. 2.4 of RFC 4306). In particular,
	untrusted messages MUST NOT be relied upon to make this decision.		untrusted messages MUST NOT be relied upon to make this decision.
	9.5. Key Management for Tickets By Value		9.5. Key Management for Tickets By Value
	A full description of the management of the keys used to protect the		A full description of the management of the keys used to protect the
	ticket by value is beyond the scope of this document. A list of		ticket by value is beyond the scope of this document. A list of
	RECOMMENDED practices is given below.		RECOMMENDED practices is given below.
	o The keys should be generated securely following the randomness		o The keys should be generated securely following the randomness
	recommendations in [RFC4086].		recommendations in [RFC4086].
	o The keys and cryptographic protection algorithms should be at		o The keys and cryptographic protection algorithms should be at
	least 128 bits in strength.		least 128 bits in strength.
	o The keys should not be used for any other purpose than generating		o The keys should not be used for any other purpose than generating
	and verifying tickets.		and verifying tickets.
	o The keys should be changed regularly.		o The keys should be changed regularly.
	o The keys should be changed if the ticket format or cryptographic		o The keys should be changed if the ticket format or cryptographic
	protection algorithms change.		protection algorithms change.
	9.6. Ticket Lifetime		9.6. 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.7. Ticket Revocation		9.7. Tickets and Identity
			A ticket is associated with a certain identity, and MUST be managed
			securely on the client side. Section 6.2 requires that a ticket be
			deleted when the credentials associated with the ticket's identity
			are no longer valid, e.g. when a user whose credentials were used to
			create the SA logs out.
			9.8. Ticket Revocation
	A misbehaving client could present a ticket in its possession to the		A misbehaving client could present a ticket in its possession to the
	gateway resulting in session resumption, even though the IKE SA		gateway resulting in session resumption, even though the IKE SA
	associated with this ticket had previously been deleted. This is		associated with this ticket had previously been deleted. This is
	disallowed by Section 6.2. This issue is unique to ticket by value		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		cases, since a ticket by reference will have been deleted from the
	ticket store.		ticket store.
	To avoid this issue for ticket by value, an Invalid Ticket List (ITL)		To avoid this issue for ticket by value, an Invalid Ticket List (ITL)
	may be maintained by the gateway, see		may be maintained by the gateway, see
	[I-D.rescorla-stateless-tokens]. This can be a simple blacklist of		[I-D.rescorla-stateless-tokens]. This can be a simple blacklist of
	revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens]		revoked tickets. Alternatively, [I-D.rescorla-stateless-tokens]
	suggests to use Bloom Filters [Bloom70] to maintain the list in		suggests to use Bloom Filters [Bloom70] to maintain the list in
	constant space. Management of such lists is outside the scope of the		constant space. Management of such lists is outside the scope of the
	current document. Note that a policy that requires tickets to have		current document. Note that a policy that requires tickets to have
	shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.		shorter lifetimes (e.g., 1 hour) significantly mitigates this issue.
	9.8. Ticket by Value Format		9.9. 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.9. Identity Privacy, Anonymity, and Unlinkability		9.10. 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 23, line 13 ¶		skipping to change at page 23, line 27 ¶
	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		[Bloom70] Bloom, B., "Space/time trade-offs in hash coding with
	allowable errors", Comm. ACM 13(7):422-6, July 1970.		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-07 (work in progress),
	April 2009.		October 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-13 (work in		IKEv2", draft-ietf-ipsecme-ikev2-redirect-13 (work in
	progress), August 2009.		progress), August 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-04 (work in progress),		draft-ietf-ipsecme-ikev2bis-05 (work in progress),
	July 2009.		October 2009.
	[I-D.ietf-rohc-ikev2-extensions-hcoipsec]		[I-D.ietf-rohc-ikev2-extensions-hcoipsec]
	Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.		Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
	Bormann, "IKEv2 Extensions to Support Robust Header		Bormann, "IKEv2 Extensions to Support Robust Header
	Compression over IPsec (ROHCoIPsec)",		Compression over IPsec (ROHCoIPsec)",
	draft-ietf-rohc-ikev2-extensions-hcoipsec-09 (work in		draft-ietf-rohc-ikev2-extensions-hcoipsec-09 (work in
	progress), August 2009.		progress), August 2009.
	[I-D.rescorla-stateless-tokens]		[I-D.rescorla-stateless-tokens]
	Rescorla, E., "How to Implement Secure (Mostly) Stateless		Rescorla, E., "How to Implement Secure (Mostly) Stateless
	skipping to change at page 26, line 25 ¶		skipping to change at page 26, 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. -08		B.1. -09
			Implemented IESG and opsdir review comments.
			B.2. -08
	Implemented IETF LC, secdir and gen-art comments.		Implemented IETF LC, secdir and gen-art comments.
	B.2. -07		B.3. -07
	Implemented AD Review comments, most of them editorial.		Implemented AD Review comments, most of them editorial.
	B.3. -06		B.4. -06
	Clients resuming propely closed sessions and how this can be avoided.		Clients resuming propely closed sessions and how this can be avoided.
	B.4. -05		B.5. -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.5. -04		B.6. -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.6. -03		B.7. -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 27, line 38 ¶		skipping to change at page 27, line 40 ¶
	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.7. -02		B.8. -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.8. -01		B.9. -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.9. -00		B.10. -00
	Resubmitted document as a WG item.		Resubmitted document as a WG item.
	B.10. -01		B.11. -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.11. -00		B.12. -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.12. -04		B.13. -04
	Editorial fixes; references cleaned up; updated author's contact		Editorial fixes; references cleaned up; updated author's contact
	address		address
	B.13. -03		B.14. -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.14. -02		B.15. -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.15. -01		B.16. -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.16. -00		B.17. -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. 51 change blocks.
	97 lines changed or deleted		125 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/