< draft-ietf-tls-dtls-heartbeat-03.txt		draft-ietf-tls-dtls-heartbeat-04.txt >
	Network Working Group R. Seggelmann		Network Working Group R. Seggelmann
	Internet-Draft M. Tuexen		Internet-Draft M. Tuexen
	Intended status: Standards Track Muenster Univ. of Appl. Sciences		Intended status: Standards Track Muenster Univ. of Appl. Sciences
	Expires: March 30, 2012 M. Williams		Expires: June 4, 2012 M. Williams
	September 27, 2011		December 2, 2011
	Transport Layer Security (TLS) and Datagram Transport Layer Security		Transport Layer Security (TLS) and Datagram Transport Layer Security
	(DTLS) Heartbeat Extension		(DTLS) Heartbeat Extension
	draft-ietf-tls-dtls-heartbeat-03.txt		draft-ietf-tls-dtls-heartbeat-04.txt
	Abstract		Abstract
	This document describes the Heartbeat Extension for the Transport		This document describes the Heartbeat Extension for the Transport
	Layer Security (TLS) and Datagram Transport Layer Security (DTLS)		Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
	protocol.		protocol.
	The Heartbeat Extension provides a new protocol for TLS/DTLS allowing		The Heartbeat Extension provides a new protocol for TLS/DTLS allowing
	the usage of keep-alive functionality without performing a		the usage of keep-alive functionality without performing a
	renegotiation and a basis for path maximum transmission unit (PMTU)		renegotiation and a basis for path maximum transmission unit (PMTU)
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 30, 2012.		This Internet-Draft will expire on June 4, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3		2. Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
	3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4		3. Heartbeat Protocol . . . . . . . . . . . . . . . . . . . . . . 4
	4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5		4. Heartbeat Request and Response Messages . . . . . . . . . . . . 5
	5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	This document describes the Heartbeat Extension for the Transport		This document describes the Heartbeat Extension for the Transport
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 51 ¶
	The support of Heartbeats is indicated with Hello Extensions. A peer		The support of Heartbeats is indicated with Hello Extensions. A peer
	can not only indicate that its implementation supports Heartbeats, it		can not only indicate that its implementation supports Heartbeats, it
	can also choose whether it is willing to receive HeartbeatRequest		can also choose whether it is willing to receive HeartbeatRequest
	messages and respond with HeartbeatResponse messages or only to send		messages and respond with HeartbeatResponse messages or only to send
	HeartbeatRequest messages. The former is indicated by using		HeartbeatRequest messages. The former is indicated by using
	peer_allowed_to_send as the HeartbeatMode, the latter is indicated by		peer_allowed_to_send as the HeartbeatMode, the latter is indicated by
	using peer_not_allowed_to_send as the Heartbeat mode. This decision		using peer_not_allowed_to_send as the Heartbeat mode. This decision
	can be changed with every renegotiation. HeartbeatRequest messages		can be changed with every renegotiation. HeartbeatRequest messages
	MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If		MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If
	an endpoint has indicated peer_not_allowed_to_send and receives a		an endpoint that has indicated peer_not_allowed_to_send receives a
	HeartbeatRequest message SHOULD drop the message silently and MAY		HeartbeatRequest message, the endpoint SHOULD drop the message
	send an unexpected_message Alert message.		silently and MAY send an unexpected_message Alert message.
	The format of the Heartbeat Hello Extension is defined by:		The format of the Heartbeat Hello Extension is defined by:
	enum {		enum {
	peer_allowed_to_send(1),		peer_allowed_to_send(1),
	peer_not_allowed_to_send(2),		peer_not_allowed_to_send(2),
	(255)		(255)
	} HeartbeatMode;		} HeartbeatMode;
	struct {		struct {
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	and HeartbeatResponse.		and HeartbeatResponse.
	enum {		enum {
	heartbeat_request(1),		heartbeat_request(1),
	heartbeat_response(2),		heartbeat_response(2),
	(255)		(255)
	} HeartbeatMessageType;		} HeartbeatMessageType;
	A HeartbeatRequest message can arrive almost at any time during the		A HeartbeatRequest message can arrive almost at any time during the
	lifetime of a connection. Whenever a HeartbeatRequest message is		lifetime of a connection. Whenever a HeartbeatRequest message is
	received, it has to be answered with a corresponding		received, it SHOULD be answered with a corresponding
	HeartbeatResponse message.		HeartbeatResponse message.
	However, a HeartbeatRequest message SHOULD NOT be sent during		However, a HeartbeatRequest message SHOULD NOT be sent during
	handshakes. If a handshake is initiated while a HeartbeatRequest is		handshakes. If a handshake is initiated while a HeartbeatRequest is
	still in flight, the sending peer MUST stop the DTLS retransmission		still in flight, the sending peer MUST stop the DTLS retransmission
	timer for it. The receiving peer SHOULD discard it silently, if it		timer for it. The receiving peer SHOULD discard it silently, if it
	arrives during or after the handshake. In case of DTLS,		arrives during the handshake. In case of DTLS, HeartbeatRequest
	HeartbeatRequest messages from older epochs SHOULD be discarded.		messages from older epochs SHOULD be discarded.
	There MUST NOT be more than one HeartbeatRequest message in flight at		There MUST NOT be more than one HeartbeatRequest message in flight at
	a time. A HeartbeatRequest message is considered to be in flight		a time. A HeartbeatRequest message is considered to be in flight
	until the corresponding HeartbeatResponse message is received, or		until the corresponding HeartbeatResponse message is received, or
	until the retransmit timer expires.		until the retransmit timer expires.
	When using an unreliable transport protocol like DCCP or UDP,		When using an unreliable transport protocol like DCCP or UDP,
	HeartbeatRequest messages MUST be retransmitted using the simple		HeartbeatRequest messages MUST be retransmitted using the simple
	timeout and retransmission scheme DTLS uses for flights as described		timeout and retransmission scheme DTLS uses for flights as described
	in Section 4.2.4 of [I-D.ietf-tls-rfc4347-bis]. In particular, after		in Section 4.2.4 of [I-D.ietf-tls-rfc4347-bis]. In particular, after
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	HeartbeatRequest message is eligible for retransmission. The		HeartbeatRequest message is eligible for retransmission. The
	retransmission scheme in combination with the restriction that only		retransmission scheme in combination with the restriction that only
	one HeartbeatRequest is allowed to be in flight ensures that the		one HeartbeatRequest is allowed to be in flight ensures that the
	congestion control is handled appropriately in case of the transport		congestion control is handled appropriately in case of the transport
	protocol not providing one, like in the case of DTLS over UDP.		protocol not providing one, like in the case of DTLS over UDP.
	When using a reliable transport protocol like SCTP or TCP,		When using a reliable transport protocol like SCTP or TCP,
	HeartbeatRequest messages only need to be sent once. The transport		HeartbeatRequest messages only need to be sent once. The transport
	layer will handle retransmissions. If no corresponding		layer will handle retransmissions. If no corresponding
	HeartbeatResponse message has been received after some amount of		HeartbeatResponse message has been received after some amount of
	time, the DTLS/TLS connection MAY be terminated by the user.		time, the DTLS/TLS connection MAY be terminated by the application
			that initiated the sending of the HeartbeatRequest message.
	4. Heartbeat Request and Response Messages		4. Heartbeat Request and Response Messages
	The Heartbeat protocol messages consist of their type and an		The Heartbeat protocol messages consist of their type and an
	arbitrary payload and padding.		arbitrary payload and padding.
	struct {		struct {
	HeartbeatMessageType type;		HeartbeatMessageType type;
	uint16 payload_length;		uint16 payload_length;
	opaque payload[HeartbeatMessage.payload_length];		opaque payload[HeartbeatMessage.payload_length];
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or		The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or
	max_fragment_length when negotiated as defined in [RFC6066].		max_fragment_length when negotiated as defined in [RFC6066].
	type: The message type, either heartbeat_request or		type: The message type, either heartbeat_request or
	heartbeat_response.		heartbeat_response.
	payload_length: The length of the payload.		payload_length: The length of the payload.
	payload: The payload consists of arbitrary content.		payload: The payload consists of arbitrary content.
	padding: The padding is additional arbitrary content which MUST be		padding: The padding is random content which MUST be ignored by the
	ignored by the receiver. The length of a HeartbeatMessage is		receiver. The length of a HeartbeatMessage is TLSPlaintext.length
	TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS.		for TLS and DTLSPlaintext.length for DTLS. Furthermore the length
	Furthermore the length of the type field is 1 byte and the length		of the type field is 1 byte and the length of the payload_length
	of the payload_length is 2. Therefore, the padding_length is		is 2. Therefore, the padding_length is TLSPlaintext.length -
	TLSPlaintext.length - payload_length - 3 for TLS and		payload_length - 3 for TLS and DTLSPlaintext.length -
	DTLSPlaintext.length - payload_length - 3 for DTLS.		payload_length - 3 for DTLS. The padding_length MUST be at least
			16.
	When a HeartbeatRequest message is received, a corresponding		The sender of a HeartbeatMessage MUST use a random padding of at
	HeartbeatResponse message MUST be sent carrying an exact copy of the		least 16 bytes. The padding of a received HeartbeatMessage message
	payload of the HeartbeatRequest. The padding of the received		MUST be ignored.
	HeartbeatRequest message MUST be ignored. It MUST NOT be included in
	the HeartbeatResponse message, i.e. the padding field of the		If the payload_length of a received HeartbeatMessage is too large,
	HeartbeatResponse message MUST have a length of zero.		the received HeartbeatMessage MUST be discarded silently.
			When a HeartbeatRequest message is received and sending a
			HeartbeatResponse is not prohibited as described elsewhere in this
			document, the receiver MUST send a corresponding HeartbeatResponse
			message carrying an exact copy of the payload of the received
			HeartbeatRequest.
	If a received HeartbeatResponse message does not contain the expected		If a received HeartbeatResponse message does not contain the expected
	payload the message MUST be discarded silently. If it does contain		payload the message MUST be discarded silently. If it does contain
	the expected payload the retransmission timer MUST be stopped.		the expected payload the retransmission timer MUST be stopped.
	If payload_length is either shorter than expected and thus indicates
	padding in a HeartbeatResponse or exceeds the actual message length
	in any message type, an error Alert message using illegal_parameter
	as its AlertDescription MUST be sent in response.
	5. Use Cases		5. Use Cases
			Each endpoint sends HeartbeatRequest messages at a rate and with the
			padding required for the particular use case. The endpoint should
			not expect its peer to send HeartbeatRequests. The directions are
			independent.
	5.1. Path MTU Discovery		5.1. Path MTU Discovery
	DTLS performs path MTU discovery as described in Section 4.1.1.1 of		DTLS performs path MTU discovery as described in Section 4.1.1.1 of
	[I-D.ietf-tls-rfc4347-bis]. A detailed description how to perform		[I-D.ietf-tls-rfc4347-bis]. A detailed description how to perform
	path MTU discovery is given in [RFC4821]. The necessary probe		path MTU discovery is given in [RFC4821]. The necessary probe
	packets are the HeartbeatRequest messages.		packets are the HeartbeatRequest messages.
	This method using HeartbeatRequest messages for DTLS is similar to		This method using HeartbeatRequest messages for DTLS is similar to
	the one for the Stream Control Transmission Protocol (SCTP) using the		the one for the Stream Control Transmission Protocol (SCTP) using the
	padding chunk (PAD-chunk) defined in [RFC4820].		padding chunk (PAD-chunk) defined in [RFC4820].
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 17 ¶
	Sending HeartbeatRequest messages allows the sender to make sure that		Sending HeartbeatRequest messages allows the sender to make sure that
	it can reach the peer and the peer is alive. Even in case of TLS/TCP		it can reach the peer and the peer is alive. Even in case of TLS/TCP
	this allows a check at a much higher rate than the TCP keep-alive		this allows a check at a much higher rate than the TCP keep-alive
	feature would allow.		feature would allow.
	Besides making sure that the peer is still reachable, sending		Besides making sure that the peer is still reachable, sending
	HeartbeatRequest messages refreshes the NAT state of all involved		HeartbeatRequest messages refreshes the NAT state of all involved
	NATs.		NATs.
	HeartbeatRequest messages SHOULD only be sent after an idle period		HeartbeatRequest messages SHOULD only be sent after an idle period
	that is at least multiple round trip times long.		that is at least multiple round trip times long. This idle period
			SHOULD to be configurable up to a period of multiple minutes and down
			to a period of one second. A default value for the idle period
			SHOULD be configurable but it SHOULD also be tunable on a per peer
			basis.
	6. IANA Considerations		6. IANA Considerations
	[NOTE to RFC-Editor:		[NOTE to RFC-Editor:
	"RFCXXXX" is to be replaced by the RFC number you assign this		"RFCXXXX" is to be replaced by the RFC number you assign this
	document.		document.
	]		]
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 15 ¶
	as described in [RFC5226]. The reference should be RFCXXXX.		as described in [RFC5226]. The reference should be RFCXXXX.
	7. Security Considerations		7. Security Considerations
	This document does not add any additional security considerations in		This document does not add any additional security considerations in
	addition to the ones given in [I-D.ietf-tls-rfc4347-bis] and		addition to the ones given in [I-D.ietf-tls-rfc4347-bis] and
	[RFC5246].		[RFC5246].
	8. Acknowledgments		8. Acknowledgments
	The authors wish to thank Pasi Eronen, Adam Langley, Nikos		The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen
	Mavrogiannopoulos, Tom Petch, Eric Rescorla, Peter Saint-Andre, and		Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric
	Juho Vaehae-Herttua for their invaluable comments.		Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their
			invaluable comments.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
End of changes. 14 change blocks.
	35 lines changed or deleted		48 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/