< draft-rescorla-dtls-00.txt		draft-rescorla-dtls-01.txt >
	E. Rescorla		E. Rescorla
	RTFM, Inc.		RTFM, Inc.
	N. Modadugu		N. Modadugu
	INTERNET-DRAFT Stanford University		INTERNET-DRAFT Stanford University
	<draft-rescorla-dtls-00.txt> January 2004 (Expires July 2004)		<draft-rescorla-dtls-01.txt> July 2004 (Expires December 2004)
	Datagram Transport Layer Security		Datagram Transport Layer Security
			Copyright Notice
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	Status of this Memo		Status of this Memo
			By submitting this Internet-Draft, I certify that any applicable
			patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	This document is an Internet-Draft and is in full conformance with		Internet-Drafts are working documents of the Internet Engineering
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		Task Force (IETF), its areas, and its working groups. Note that other
	documents of the Internet Engineering Task Force (IETF), its areas,		groups may also distribute working documents as Internet-Drafts.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	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 mate-		time. It is inappropriate to use Internet-Drafts as reference
	rial or to cite them other than as ``work in progress.''		material or to cite them other than a "work in progress."
	To learn the current status of any Internet-Draft, please check the		The list of current Internet-Drafts can be accessed at
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow		http://www.ietf.org/1id-abstracts.html
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
	ftp.isi.edu (US West Coast).
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html
	Abstract		Abstract
	This document specifies Version 1.0 of the Datagram Transport Layer		This document specifies Version 1.0 of the Datagram Transport Layer
	Security (DTLS) protocol. The DTLS protocol provides communications		Security (DTLS) protocol. The DTLS protocol provides communications
	privacy for datagram protocols. The protocol allows client/server		privacy for datagram protocols. The protocol allows client/server
	applications to communicate in a way that is designed to prevent		applications to communicate in a way that is designed to prevent
	eavesdropping, tampering, or message forgery. The DTLS protocol is		eavesdropping, tampering, or message forgery. The DTLS protocol is
	based on the TLS protocol and provides equivalent privacy guarantees.		based on the TLS protocol and provides equivalent privacy guarantees.
	Datagram semantics of the underlying transport are preserved by the		Datagram semantics of the underlying transport are preserved by the
	DTLS protocol.		DTLS protocol.
			Contents
			1 Introduction 3
			2 Usage Model 3
			3 Overview of DTLS 4
			3.1 Loss-insensitive messaging 4
			3.2 Providing Reliability for Handshake 5
			3.2.1 Packet Loss 5
			3.2.2 Reordering 5
			3.3 Message Size 5
			3.4 Replay Detection 6
			4 Differences from TLS 6
			4.1 Record Layer 6
			4.1.1 Transport Layer Mapping 7
			4.1.1.1 PMTU Discovery 7
			4.1.2 Record payload protection 8
			4.1.2.1 MAC 8
			4.1.2.2 Null or standard stream cipher 8
			4.1.2.3 Block Cipher 9
			4.1.2.4 Anti-Replay 9
			4.2 The DTLS Handshake Protocol 9
			4.2.1 Denial of Service Countermeasures 10
			4.2.2 Handshake Message Format 11
			4.2.3 Message Fragmentation and Reassembly 13
			4.2.4 Timeout and Retransmission 13
			4.2.4.1 Timer Values 16
			4.2.5 ChangeCipherSpec 16
			4.2.6 Finished messages 17
			4.2 Record Layer 17
			4.3 Handshake Protocol 18
			5 Security Considerations 18
	1. Introduction		1. Introduction
	TLS [TLS] is the most widely deployed protocol for securing network		TLS [TLS] is the most widely deployed protocol for securing network
	traffic. It is widely used for protecting Web traffic and for e-mail		traffic. It is widely used for protecting Web traffic and for e-mail
	protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of		protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of
	TLS is that it provides a transparent channel. Thus, it is easy to		TLS is that it provides a transparent channel. Thus, it is easy to
	secure an application protocol by inserting TLS between the applica-		secure an application protocol by inserting TLS between the
	tion layer and the network layer. However, TLS must run over a reli-		application layer and the network layer. However, TLS must run over a
	able transport channel--typically TCP [REF]. It therefore cannot be		reliable transport channel--typically TCP [REF]. It therefore cannot
	used to secure unreliable datagram traffic.		be used to secure unreliable datagram traffic.
	However, over the past few years an increasing number of application		However, over the past few years an increasing number of application
	layer protocols have been designed using UDP transport. In particular		layer protocols have been designed using UDP transport. In particular
	such protocols as the Session Initiation Protocol (SIP) [SIP], and		such protocols as the Session Initiation Protocol (SIP) [SIP], and
	electronic gaming protocols are increasingly popular. Currently,		electronic gaming protocols are increasingly popular. Currently,
	designers these applications are faced with a number of unsatisfac-		designers these applications are faced with a number of
	tory choices. First, they can use IPsec. However, for a number of		unsatisfactory choices. First, they can use IPsec. However, for a
	reasons detailed in [WHYIPSEC], this is only suitable for some appli-		number of reasons detailed in [WHYIPSEC], this is only suitable for
	cations. Second, they can design a custom application layer security		some applications. Second, they can design a custom application layer
	protocol. SIP, for instance, uses a variant of S/MIME to secure its		security protocol. SIP, for instance, uses a variant of S/MIME to
	traffic. Unfortunately, application layer security protocols typi-		secure its traffic. Unfortunately, application layer security
	cally require a large amount of effort to design--by contrast to the		protocols typically require a large amount of effort to design--by
	relatively small amount of effort required to run the protocol over		contrast to the relatively small amount of effort required to run the
	TLS.		protocol over TLS.
	In many cases, the most desirable way to secure client/server appli-		In many cases, the most desirable way to secure client/server
	cations would be to use TLS, however the requirement for datagram		applications would be to use TLS, however the requirement for
	semantics automatically prohibits use of TLS. Thus, a datagram-com-		datagram semantics automatically prohibits use of TLS. Thus, a
	patible variant of TLS would be very desirable. This memo describes		datagram-compatible variant of TLS would be very desirable. This memo
	such a protocol: Datagram Transport Layer Security (DTLS). DTLS is		describes such a protocol: Datagram Transport Layer Security (DTLS).
	deliberately designed to be as similar to to TLS as possible, both to		DTLS is deliberately designed to be as similar to to TLS as possible,
	minimize new security invention and to maximize the amount of code		both to minimize new security invention and to maximize the amount of
	and infrastructure reuse.		code and infrastructure reuse.
	2. Usage Model		2. Usage Model
	The DTLS protocol is designed to secure data between communicating		The DTLS protocol is designed to secure data between communicating
	applications. It is designed to run in application space, without		applications. It is designed to run in application space, without
	requiring any kernel modifications. While the design of the DTLS pro-		requiring any kernel modifications. While the design of the DTLS
	tocol does not preclude its use in securing arbitrary datagram traf-		protocol does not preclude its use in securing arbitrary datagram
	fic, it is primarily expected to secure communication based on data-		traffic, it is primarily expected to secure communication based on
	gram sockets.		datagram sockets.
	Datagram transport does not guarantee reliable or in-order delivery		Datagram transport does not guarantee reliable or in-order delivery
	of data. The DTLS protocol preserves this property for payload data.		of data. The DTLS protocol preserves this property for payload data.
	Applications such as media streaming, Internet telephony and online		Applications such as media streaming, Internet telephony and online
	gaming use datagram transport for communication due to the delay-sen-		gaming use datagram transport for communication due to the delay-
	sitive nature of transported data. The behaviour of such applications		sensitive nature of transported data. The behaviour of such
	is unchanged when the DTLS protocol is used to secure communication,		applications is unchanged when the DTLS protocol is used to secure
	since the DTLS protocol does not compensate for lost or re-ordered		communication, since the DTLS protocol does not compensate for lost
	data traffic.		or re-ordered data traffic.
	3. Overview of DTLS		3. Overview of DTLS
	The basic design philosophy of DTLS is to construct "TLS over data-		The basic design philosophy of DTLS is to construct "TLS over
	gram". The reason that TLS cannot be used directly in datagram envi-		datagram". The reason that TLS cannot be used directly in datagram
	ronments is simply that packets may be lost or reordered. TLS has no		environments is simply that packets may be lost or reordered. TLS has
	internal facilities to handle this kind of unreliability and there-		no internal facilities to handle this kind of unreliability and
	fore TLS implementations break when rehosted on datagram transport.		therefore TLS implementations break when rehosted on datagram
	The purpose of DTLS is to make only the minimal changes to TLS		transport. The purpose of DTLS is to make only the minimal changes to
	required to fix this problem. To the greatest extent possible, DTLS		TLS required to fix this problem. To the greatest extent possible,
	is identical to TLS. Whenever we need to invent new mechanisms, we		DTLS is identical to TLS. Whenever we need to invent new mechanisms,
	attempt to do so in such a way that it preserves the style of TLS.		we attempt to do so in such a way that it preserves the style of TLS.
	Unreliability creates problems for TLS at two levels:		Unreliability creates problems for TLS at two levels:
	1. TLS's traffic encryption layer does not allow independent		1. TLS's traffic encryption layer does not allow independent
	decryption of individual records. If record N is not received,		decryption of individual records. If record N is not received,
	then record N+1 cannot be decrypted.		then record N+1 cannot be decrypted.
	2. The TLS handshake layer assumes that handshake messages are		2. The TLS handshake layer assumes that handshake messages are
	delivered reliably and breaks if those messages are lost.		delivered reliably and breaks if those messages are lost.
	skipping to change at page 4, line 11 ¶		skipping to change at page 5, line 11 ¶
	from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1		from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1
	[TLS11] is already adding explicit CBC state to TLS records. DTLS		[TLS11] is already adding explicit CBC state to TLS records. DTLS
	borrows that mechanism and adds explicit sequence numbers.		borrows that mechanism and adds explicit sequence numbers.
	3.2. Providing Reliability for Handshake		3.2. Providing Reliability for Handshake
	The TLS handshake is a lockstep cryptographic handshake. Messages		The TLS handshake is a lockstep cryptographic handshake. Messages
	must be transmitted and received in a defined order and any other		must be transmitted and received in a defined order and any other
	order is an error. Clearly, this is incompatible with reordering and		order is an error. Clearly, this is incompatible with reordering and
	message loss. In addition, TLS handshake messages are potentially		message loss. In addition, TLS handshake messages are potentially
	larger than any given datagram, thus creating the problem of fragmen-		larger than any given datagram, thus creating the problem of
	tation. DTLS must provide fixes for both these problems.		fragmentation. DTLS must provide fixes for both these problems.
	3.2.1. Packet Loss		3.2.1. Packet Loss
	DTLS uses a simple retransmission timer to handle packet loss. The		DTLS uses a simple retransmission timer to handle packet loss. The
	following figure demonstrates the basic concept using the first phase		following figure demonstrates the basic concept using the first phase
	of the DTLS handshake:		of the DTLS handshake:
	Client Server		Client Server
	------ ------		------ ------
	ClientHello ------>		ClientHello ------>
	skipping to change at page 4, line 42 ¶		skipping to change at page 5, line 42 ¶
	Once the client has transmitted the ClientHello message, it expects		Once the client has transmitted the ClientHello message, it expects
	to see a HelloVerifyRequest from the server. However, if the server's		to see a HelloVerifyRequest from the server. However, if the server's
	message is lost the client knows that either the ClientHello or the		message is lost the client knows that either the ClientHello or the
	HelloVerifyRequest has been lost and retransmits. When the server		HelloVerifyRequest has been lost and retransmits. When the server
	receives the retransmission, it knows to retransmit. The server also		receives the retransmission, it knows to retransmit. The server also
	maintains a retransmission timer and retransmits when that timer		maintains a retransmission timer and retransmits when that timer
	expires.		expires.
	3.2.2. Reordering		3.2.2. Reordering
	In DTLS, each handshake message is assigned a specific sequence num-		In DTLS, each handshake message is assigned a specific sequence
	ber within that handshake. When a peer receives a handshake message,		number within that handshake. When a peer receives a handshake
	it can quickly determine whether that message is the next message it		message, it can quickly determine whether that message is the next
	expects. If it is, then it processes it. If not, it queues it up for		message it expects. If it is, then it processes it. If not, it queues
	future handling once all previous messages have been received.		it up for future handling once all previous messages have been
			received.
	3.3. Message Size		3.3. Message Size
	TLS and DTLS handshake messages can be quite large (in theory up to		TLS and DTLS handshake messages can be quite large (in theory up to
	2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams		2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams
	are often limited to <1500 bytes. In order to compensate for this		are often limited to <1500 bytes. In order to compensate for this
	limitation, each DTLS handshake message may be fragmented over sev-		limitation, each DTLS handshake message may be fragmented over
	eral DTLS records. Each DTLS handshake message contains both a frag-		several DTLS records. Each DTLS handshake message contains both a
	ment offset and a fragment length. Thus, a recipient in possession of		fragment offset and a fragment length. Thus, a recipient in
	all bytes of a handshake message can reassemble the original unfrag-		possession of all bytes of a handshake message can reassemble the
	mented message.		original unfragmented message.
			3.4. Replay Detection
	DTLS optionally supports record replay detection. The technique used		DTLS optionally supports record replay detection. The technique used
	is the same as in IPsec, by maintaining a bitmap window of received		is the same as in IPsec, by maintaining a bitmap window of received
	records. Records that are too old to fit in the window and records		records. Records that are too old to fit in the window and records
	that have been previously received are silently discarded. The replay		that have been previously received are silently discarded. The replay
	detection feature is optional, since packet duplication is not always		detection feature is optional, since packet duplication is not always
	malicious, but can also occur due to routing errors. Applications may		malicious, but can also occur due to routing errors. Applications may
	conceivably detect duplicate packets and accordingly modify their		conceivably detect duplicate packets and accordingly modify their
	data transmission strategy.		data transmission strategy.
	4. Differences from TLS		4. Differences from TLS
	skipping to change at page 5, line 48 ¶		skipping to change at page 7, line 4 ¶
	opaque fragment[DTLSPlaintext.length];		opaque fragment[DTLSPlaintext.length];
	} DTLSPlaintext;		} DTLSPlaintext;
	type		type
	Equivalent to the type field in a TLS 1.1 record.		Equivalent to the type field in a TLS 1.1 record.
	version		version
	The version of the protocol being employed. This document		The version of the protocol being employed. This document
	describes DTLS Version 1.0, which uses the version { 254, 255		describes DTLS Version 1.0, which uses the version { 254, 255
	}. The version value of 254.255 is the 1's complement of DTLS		}. The version value of 254.255 is the 1's complement of DTLS
	Version 1.0. The maximal spacing between TLS and DTLS version		Version 1.0. This maximal spacing between TLS and DTLS version
	numbers ensures that records from the two protocols can be		numbers ensures that records from the two protocols can be
	easily distinguished.		easily distinguished.
	epoch		epoch
	A counter value that is incremented on every cipher state		A counter value that is incremented on every cipher state
	change.		change.
	sequence_number		sequence_number
	The sequence number for this record.		The sequence number for this record.
	skipping to change at page 6, line 28 ¶		skipping to change at page 7, line 31 ¶
	DTLS uses an explicit rather than implicit sequence number, carried		DTLS uses an explicit rather than implicit sequence number, carried
	in the sequence_number field of the record. As with TLS, the sequence		in the sequence_number field of the record. As with TLS, the sequence
	number is set to zero after each ChangeCipherSpec message is sent.		number is set to zero after each ChangeCipherSpec message is sent.
	If several handshakes are performed in close succession, there might		If several handshakes are performed in close succession, there might
	be multiple records on the wire with the same sequence number but		be multiple records on the wire with the same sequence number but
	from different cipher states. The epoch field allows recipients to		from different cipher states. The epoch field allows recipients to
	distinguish such packets. The epoch number is initially zero and is		distinguish such packets. The epoch number is initially zero and is
	incremented each time the ChangeCipherSpec messages is sent. In order		incremented each time the ChangeCipherSpec messages is sent. In order
	to ensure that any given sequence/epoch pair is unique, implementa-		to ensure that any given sequence/epoch pair is unique,
	tions MUST NOT allow the same epoch value to be reused within two		implementations MUST NOT allow the same epoch value to be reused
	times the maximum segment lifetime. In practice, TLS implementations		within two times the maximum segment lifetime. In practice, TLS
	rehandshake rarely and we therefore do not expect this to be a prob-		implementations rehandshake rarely and we therefore do not expect
	lem.		this to be a problem.
	4.1.1. Transport Layer Mapping		4.1.1. Transport Layer Mapping
	Each DTLS record MUST fit within a single datagram. In order to avoid		Each DTLS record MUST fit within a single datagram. In order to avoid
	IP fragmentation [MOGUL], DTLS implementations SHOULD determine the		IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
	MTU and send records smaller than the MTU. DTLS implementations		MTU and send records smaller than the MTU. DTLS implementations
	SHOULD provide a way for applications to determine the value of the		SHOULD provide a way for applications to determine the value of the
	MTU (optimally the maximum application datagram size, which is the		MTU (optimally the maximum application datagram size, which is the
	PMTU minus the DTLS per-record overhead). If the application attempts		PMTU minus the DTLS per-record overhead). If the application attempts
	to send a record larger than the MTU, the DTLS implementation MUST		to send a record larger than the MTU, the DTLS implementation MUST
	skipping to change at page 7, line 22 ¶		skipping to change at page 8, line 26 ¶
	ignored, as described in [RFC 1191]. (We are aware that this may		ignored, as described in [RFC 1191]. (We are aware that this may
	cause problems for DTLS endpoints behind certain firewalls.)		cause problems for DTLS endpoints behind certain firewalls.)
	A DTLS implementation may allow the application to occasionally		A DTLS implementation may allow the application to occasionally
	request that PMTU discovery be performed again. This will reset the		request that PMTU discovery be performed again. This will reset the
	PMTU to the outgoing interface's MTU. Such requests SHOULD be rate		PMTU to the outgoing interface's MTU. Such requests SHOULD be rate
	limited, to one per two seconds, for example.		limited, to one per two seconds, for example.
	Because some firewalls and routers screen out ICMP messages, it is		Because some firewalls and routers screen out ICMP messages, it is
	difficult to distinguish packet loss from an overlarge PMTU estimate.		difficult to distinguish packet loss from an overlarge PMTU estimate.
	In order to allow connections under these circumstances, DTLS imple-		In order to allow connections under these circumstances, DTLS
	mentations MAY choose to back off their PMTU estimate during the		implementations MAY choose to back off their PMTU estimate during the
	retransmit backoff described in Section 4.2.4.. For instance, if a		retransmit backoff described in Section 4.2.4.. For instance, if a
	large packet is being sent, after 3 retransmits a sender might choose		large packet is being sent, after 3 retransmits a sender might choose
	to fragment the packet.		to fragment the packet.
	4.1.2. Record payload protection		4.1.2. Record payload protection
	4.1.2.1. MAC		4.1.2.1. MAC
	The DTLS MAC is the same as that of TLS 1.1. However, rather than		The DTLS MAC is the same as that of TLS 1.1. However, rather than
	using TLS's implicit sequence number, the sequence number used to		using TLS's implicit sequence number, the sequence number used to
	skipping to change at page 8, line 38 ¶		skipping to change at page 9, line 43 ¶
	The "right" edge of the window represents the highest, validated		The "right" edge of the window represents the highest, validated
	Sequence Number value received on this session. Records that contain		Sequence Number value received on this session. Records that contain
	Sequence Numbers lower than the "left" edge of the window are		Sequence Numbers lower than the "left" edge of the window are
	rejected. Packets falling within the window are checked against a		rejected. Packets falling within the window are checked against a
	list of received packets within the window. An efficient means for		list of received packets within the window. An efficient means for
	performing this check, based on the use of a bit mask, is described		performing this check, based on the use of a bit mask, is described
	in [RFC 2401].		in [RFC 2401].
	If the received record falls within the window and is new, or if the		If the received record falls within the window and is new, or if the
	packet is to the right of the window, then the receiver proceeds to		packet is to the right of the window, then the receiver proceeds to
	MAC verification. If the MAC validation fails, the receiver MUST dis-		MAC verification. If the MAC validation fails, the receiver MUST
	card the received record as invalid. The receive window is updated		discard the received record as invalid. The receive window is updated
	only if the MAC verification succeeds.		only if the MAC verification succeeds.
	4.2. The DTLS Handshake Protocol		4.2. The DTLS Handshake Protocol
	DTLS uses all of the same handshake messages and flows as TLS, with		DTLS uses all of the same handshake messages and flows as TLS, with
	three principal changes:		three principal changes:
	1. A stateless cookie exchange to prevent denial of service		1. A stateless cookie exchange to prevent denial of service
	attacks.		attacks.
	skipping to change at page 9, line 13 ¶		skipping to change at page 10, line 19 ¶
	reordering and fragmentation.		reordering and fragmentation.
	3. Retransmission timers to handle message loss.		3. Retransmission timers to handle message loss.
	With these exceptions, the DTLS message formats, flows, and logic are		With these exceptions, the DTLS message formats, flows, and logic are
	the same as those of TLS 1.1.		the same as those of TLS 1.1.
	4.2.1. Denial of Service Countermeasures		4.2.1. Denial of Service Countermeasures
	Datagram security protocols are extremely susceptible to a variety of		Datagram security protocols are extremely susceptible to a variety of
	denial of service (DoS) attacks. Two attacks are of particular con-		denial of service (DoS) attacks. Two attacks are of particular
	cern:		concern:
	1. An attacker can consume excessive resources on the server by		1. An attacker can consume excessive resources on the server by
	transmitting a series of handshake initiation requests, causing		transmitting a series of handshake initiation requests, causing
	the server to allocate state and potentially perform expensive		the server to allocate state and potentially perform expensive
	cryptographic operations.		cryptographic operations.
	2. An attacker can use the server as an amplifier by sending con-		2. An attacker can use the server as an amplifier by sending
	nection initiation messages with a forged source of the victim.		connection initiation messages with a forged source of the victim.
	The server then sends its next message (in DTLS, a Certificate		The server then sends its next message (in DTLS, a Certificate
	message, which can be quite large) to the victim machine, thus		message, which can be quite large) to the victim machine, thus
	flooding it.		flooding it.
	In order to prevent both of these attacks, DTLS borrows the stateless		In order to prevent both of these attacks, DTLS borrows the stateless
	cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When		cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When
	the client sends its ClientHello message to the server, the server		the client sends its ClientHello message to the server, the server
	MAY respond with a HelloVerifyRequest message. This message contains		MAY respond with a HelloVerifyRequest message. This message contains
	a stateless cookie generated using the technique of [PHOTURIS]. The		a stateless cookie generated using the technique of [PHOTURIS]. The
	client MUST retransmit the ClientHello with the cookie added. The		client MUST retransmit the ClientHello with the cookie added. The
	skipping to change at page 10, line 23 ¶		skipping to change at page 11, line 28 ¶
	The definition of HelloVerifyRequest is as follows:		The definition of HelloVerifyRequest is as follows:
	struct {		struct {
	Cookie cookie<0..32>;		Cookie cookie<0..32>;
	} HelloVerifyRequest;		} HelloVerifyRequest;
	The HelloVerifyRequest message type is hello_verify_request(3).		The HelloVerifyRequest message type is hello_verify_request(3).
	When responding to a HelloVerifyRequest the client MUST use the same		When responding to a HelloVerifyRequest the client MUST use the same
	parameter values (version, random, session_id, cipher_suites, com-		parameter values (version, random, session_id, cipher_suites,
	pression_method) as in the original ClientHello. The server SHOULD		compression_method) as in the original ClientHello. The server SHOULD
	use those values to generate its cookie and verify that they are cor-		use those values to generate its cookie and verify that they are
	rect.		correct.
	Although DTLS servers are not required to do a cookie exchange, they		Although DTLS servers are not required to do a cookie exchange, they
	SHOULD do so whenever a new handshake is performed in order to avoid		SHOULD do so whenever a new handshake is performed in order to avoid
	being used as amplifiers. If the server is being operated in an envi-		being used as amplifiers. If the server is being operated in an
	ronment where amplification is not a problem, the server MAY choose		environment where amplification is not a problem, the server MAY
	not to perform a cookie exchange. In addition, the server MAY choose		choose not to perform a cookie exchange. In addition, the server MAY
	not do to a cookie exchange when a session is resumed. Clients MUST		choose not do to a cookie exchange when a session is resumed. Clients
	be prepared to do a cookie exchange with every handshake.		MUST be prepared to do a cookie exchange with every handshake.
	4.2.2. Handshake Message Format		4.2.2. Handshake Message Format
	In order to support message loss, reordering, and fragmentation DTLS		In order to support message loss, reordering, and fragmentation DTLS
	modifies the TLS 1.1 handshake header:		modifies the TLS 1.1 handshake header:
	struct {		struct {
	HandshakeType msg_type;		HandshakeType msg_type;
	uint24 length;		uint24 length;
	uint16 message_seq; // New field		uint16 message_seq; // New field
	skipping to change at page 11, line 14 ¶		skipping to change at page 12, line 19 ¶
	case server_key_exchange: ServerKeyExchange;		case server_key_exchange: ServerKeyExchange;
	case certificate_request: CertificateRequest;		case certificate_request: CertificateRequest;
	case server_hello_done:ServerHelloDone;		case server_hello_done:ServerHelloDone;
	case certificate_verify: CertificateVerify;		case certificate_verify: CertificateVerify;
	case client_key_exchange: ClientKeyExchange;		case client_key_exchange: ClientKeyExchange;
	case finished:Finished;		case finished:Finished;
	} body;		} body;
	} Handshake;		} Handshake;
	The first message each side transmits in each handshake always has		The first message each side transmits in each handshake always has
	message_seq = 0. Whenever each new message is generated, the mes-		message_seq = 0. Whenever each new message is generated, the
	sage_seq value is incremented by one. When a message is retransmit-		message_seq value is incremented by one. When a message is
	ted, the same message_seq value is used. For example.		retransmitted, the same message_seq value is used. For example.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello (seq=0) ------>		ClientHello (seq=0) ------>
	X<-- HelloVerifyRequest (seq=0)		X<-- HelloVerifyRequest (seq=0)
	(lost)		(lost)
	[Timer Expires]		[Timer Expires]
	skipping to change at page 12, line 7 ¶		skipping to change at page 13, line 9 ¶
	next_receive_seq counter. This counter is initially set to zero. When		next_receive_seq counter. This counter is initially set to zero. When
	a message is received, if its sequence number matches		a message is received, if its sequence number matches
	next_receive_seq, next_receive_seq is incremented and the message is		next_receive_seq, next_receive_seq is incremented and the message is
	processed. If the sequence number is less than next_receive_seq the		processed. If the sequence number is less than next_receive_seq the
	message MUST be discarded. If the sequence number is greater than		message MUST be discarded. If the sequence number is greater than
	next_receive_seq, the implementation SHOULD queue the message but MAY		next_receive_seq, the implementation SHOULD queue the message but MAY
	discard it. (This is a simple space/bandwidth tradeoff).		discard it. (This is a simple space/bandwidth tradeoff).
	4.2.3. Message Fragmentation and Reassembly		4.2.3. Message Fragmentation and Reassembly
	As noted in Section 4.1.1., each DTLS message MUST fit within a sin-		As noted in Section 4.1.1., each DTLS message MUST fit within a
	gle transport layer datagram. However, handshake messages are poten-		single transport layer datagram. However, handshake messages are
	tially bigger than the maximum record size. Therefore DTLS provides a		potentially bigger than the maximum record size. Therefore DTLS
	mechanism for fragmenting a handshake message over a number of		provides a mechanism for fragmenting a handshake message over a
	records.		number of records.
	When transmitting the handshake message, the sender divides the mes-		When transmitting the handshake message, the sender divides the
	sage into a series of N contiguous data ranges. These range must be		message into a series of N contiguous data ranges. These range must
	no larger than the maximum handshake fragment size and MUST jointly		be no larger than the maximum handshake fragment size and MUST
	contain the entire handshake message. The ranges SHOULD NOT overlap.		jointly contain the entire handshake message. The ranges SHOULD NOT
	The sender then creates N handshake messages, all with the same mes-		overlap. The sender then creates N handshake messages, all with the
	sage_seq value as the original handshake message. Each new message is		same message_seq value as the original handshake message. Each new
	labelled with the fragment_offset (the number of bytes contained in		message is labelled with the fragment_offset (the number of bytes
	previous fragments) and the fragment_length (the length of this frag-		contained in previous fragments) and the fragment_length (the length
	ment). The length field in all messages is the same as the length		of this fragment). The length field in all messages is the same as
	field of the original message. An unfragmented message is a degener-		the length field of the original message. An unfragmented message is
	ate case with fragment_offset=0 and fragment_length=length.		a degenerate case with fragment_offset=0 and fragment_length=length.
	When a DTLS implementation receives a handshake message fragment, it		When a DTLS implementation receives a handshake message fragment, it
	MUST buffer it until it has the entire handshake message. DTLS imple-		MUST buffer it until it has the entire handshake message. DTLS
	mentations MUST be able to handle overlapping fragment ranges. This		implementations MUST be able to handle overlapping fragment ranges.
	allows senders to retransmit handshake messages with smaller fragment		This allows senders to retransmit handshake messages with smaller
	sizes during path MTU discovery.		fragment sizes during path MTU discovery.
	4.2.4. Timeout and Retransmission		4.2.4. Timeout and Retransmission
	DTLS messages are grouped into a series of message flights, according		DTLS messages are grouped into a series of message flights, according
	the diagrams below. Although each flight of messages may consist of a		the diagrams below. Although each flight of messages may consist of a
	number of messages, they should be viewed as monolithic for the pur-		number of messages, they should be viewed as monolithic for the
	pose of timeout and retransmission.		purpose of timeout and retransmission.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello --------> Flight 1		ClientHello --------> Flight 1
	<------- HelloVerifyRequest Flight 2		<------- HelloVerifyRequest Flight 2
	ClientHello --------> Flight 3		ClientHello --------> Flight 3
	skipping to change at page 13, line 43 ¶		skipping to change at page 14, line 43 ¶
	ClientHello --------> Flight 1		ClientHello --------> Flight 1
	ServerHello \		ServerHello \
	[ChangeCipherSpec] Flight 2		[ChangeCipherSpec] Flight 2
	<-------- Finished /		<-------- Finished /
	[ChangeCipherSpec] \Flight 3		[ChangeCipherSpec] \Flight 3
	Finished --------> /		Finished --------> /
	Figure 2: Message flights for abbreviated handshake (no cookie exchange)		Figure 2: Message flights for abbreviated handshake (no cookie exchange)
	DTLS uses a simple timeout and retransmission scheme with the follow-		DTLS uses a simple timeout and retransmission scheme with the
	ing state machine.		following state machine.
	+--------+		+--------+
	| PREPAR |		| PREPAR |
	+---> | -ING |		+---> | -ING |
	| | |		| | |
	| +--------+		| +--------+
	| |		| |
	| |		| |
	| | Buffer next flight		| | Buffer next flight
	| |		| |
	skipping to change at page 15, line 6 ¶		skipping to change at page 16, line 6 ¶
	Figure 3: DTLS timeout and retransmission state machine		Figure 3: DTLS timeout and retransmission state machine
	The state machine has three basic states.		The state machine has three basic states.
	In the PREPARING state the implementation does whatever computations		In the PREPARING state the implementation does whatever computations
	are necessary to prepare the next flight of messages. It then buffers		are necessary to prepare the next flight of messages. It then buffers
	them up for transmission (emptying the buffer first) and enters the		them up for transmission (emptying the buffer first) and enters the
	SENDING state.		SENDING state.
	In the SENDING state, the implementation transmits the buffered		In the SENDING state, the implementation transmits the buffered
	flight of messages. Once the messages have been sent, the implementa-		flight of messages. Once the messages have been sent, the
	tion then enters the FINISH state if this is the last flight in the		implementation then enters the FINISH state if this is the last
	handshake, or, if the implementation expects to receive more mes-		flight in the handshake, or, if the implementation expects to receive
	sages, sets a retransmit timer and then enters the WAITING state.		more messages, sets a retransmit timer and then enters the WAITING
			state.
	There are three ways to exit the WAITING state:		There are three ways to exit the WAITING state:
	1. The retransmit timer expires: the implementation transitions to		1. The retransmit timer expires: the implementation transitions to
	the SENDING state, where it retransmits the flight, resets the		the SENDING state, where it retransmits the flight, resets the
	retransmit timer, and returns to the WAITING state.		retransmit timer, and returns to the WAITING state.
	2. The implementation reads a retransmitted flight from the peer:		2. The implementation reads a retransmitted flight from the peer:
	the implementation transitions to the SENDING state, where it		the implementation transitions to the SENDING state, where it
	retransmits the flight, resets the retransmit timer, and returns		retransmits the flight, resets the retransmit timer, and returns
	to the WAITING state. The rationale here is that the receipt of a		to the WAITING state. The rationale here is that the receipt of a
	duplicate message is the likely result of timer expiry on the peer		duplicate message is the likely result of timer expiry on the peer
	and therefore suggests that part of one's previous flight was		and therefore suggests that part of one's previous flight was
	lost.		lost.
	3. The implementation receives the next flight of messages: if		3. The implementation receives the next flight of messages: if
	this is the final flight of messages the implementation transi-		this is the final flight of messages the implementation
	tions to FINISHED. If the implementation needs to send a new		transitions to FINISHED. If the implementation needs to send a new
	flight, it transitions to the PREPARING state. Partial reads		flight, it transitions to the PREPARING state. Partial reads
	(whether partial messages or only some of the messages in the		(whether partial messages or only some of the messages in the
	flight) do not cause state transitions or timer resets.		flight) do not cause state transitions or timer resets.
	Because DTLS clients send the first message (ClientHello) they start		Because DTLS clients send the first message (ClientHello) they start
	in the PREPARING state. DTLS servers start in the WAITING state, but		in the PREPARING state. DTLS servers start in the WAITING state, but
	with empty buffers and no retransmit timer.		with empty buffers and no retransmit timer.
	4.2.4.1. Timer Values		4.2.4.1. Timer Values
	Timer value choices are a local matter. We recommend that implementa-		Timer value choices are a local matter. We recommend that
	tions use an initial timer value of 500 ms and double the value at		implementations use an initial timer value of 500 ms and double the
	each retransmission, up to 2MSL. Implementations SHOULD start the		value at each retransmission, up to 2MSL. Implementations SHOULD
	timer value at the initial value with each new flight of messages.		start the timer value at the initial value with each new flight of
			messages.
	4.2.5. ChangeCipherSpec		4.2.5. ChangeCipherSpec
	As with TLS, the ChangeCipherSpec message is not technically a hand-		As with TLS, the ChangeCipherSpec message is not technically a
	shake message but MUST be treated as part of the same flight as the		handshake message but MUST be treated as part of the same flight as
	associated Finished message for the purposes of timeout and retrans-		the associated Finished message for the purposes of timeout and
	mission.		retransmission.
	4.2.6. Finished messages		4.2.6. Finished messages
	Finished messages have the same format as in TLS. However, in order		Finished messages have the same format as in TLS. However, in order
	to remove sensitivity to fragmentation, the Finished MAC MUST be com-		to remove sensitivity to fragmentation, the Finished MAC MUST be
	puted as if each handshake message had been sent as a single frag-		computed as if each handshake message had been sent as a single
	ment. Note that in cases where the cookie exchange is used, the ini-		fragment. Note that in cases where the cookie exchange is used, the
	tial ClientHello and HelloVerifyRequest ARE included in the Finished		initial ClientHello and HelloVerifyRequest ARE included in the
	MAC.		Finished MAC.
	A.1Summary of new syntax		A.1Summary of new syntax
	This section includes specifications for the data structures that		This section includes specifications for the data structures that
	have changed between TLS 1.1 and DTLS.		have changed between TLS 1.1 and DTLS.
	4.2. Record Layer		4.2. Record Layer
	struct {		struct {
	ContentType type;		ContentType type;
	ProtocolVersion version;		ProtocolVersion version;
	skipping to change at page 17, line 40 ¶		skipping to change at page 18, line 40 ¶
	case certificate_verify: CertificateVerify;		case certificate_verify: CertificateVerify;
	case client_key_exchange: ClientKeyExchange;		case client_key_exchange: ClientKeyExchange;
	case finished:Finished;		case finished:Finished;
	} body;		} body;
	} Handshake;		} Handshake;
	struct {		struct {
	Cookie cookie<H0..32>;		Cookie cookie<H0..32>;
	} HelloVerifyRequest;		} HelloVerifyRequest;
	5.		5. Security Considerations
	Security Considerations
	This document describes a variant of TLS 1.1 and therefore most of		This document describes a variant of TLS 1.1 and therefore most of
	the security considerations are the same as TLS 1.1.		the security considerations are the same as TLS 1.1.
	The primary additional security consideration raised by DTLS is that		The primary additional security consideration raised by DTLS is that
	of denial of service. DTLS includes a cookie exchange designed to		of denial of service. DTLS includes a cookie exchange designed to
	protect against denial of service. However, implementations which do		protect against denial of service. However, implementations which do
	not use this cookie exchange are still vulnerable to DoS. In particu-		not use this cookie exchange are still vulnerable to DoS. In
	lar, DTLS servers which do not use the cookie exchange may be used as		particular, DTLS servers which do not use the cookie exchange may be
	attack amplifiers even if they themselves are not experiencing DoS.		used as attack amplifiers even if they themselves are not
	Therefore DTLS servers SHOULD use the cookie exchange unless there is		experiencing DoS. Therefore DTLS servers SHOULD use the cookie
	good reason to believe that amplification is not a threat in their		exchange unless there is good reason to believe that amplification is
	environment.		not a threat in their environment.
	References		References
	Normative References		Normative References
	[PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management		[PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
	Protocol", RFC 2521, March 1999.		Protocol", RFC 2521, March 1999.
	[RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery",		[RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery",
	RFC 1191, November 1990.		RFC 1191, November 1990.
	skipping to change at page 19, line 32 ¶		skipping to change at page 20, line 30 ¶
	Nagendra Modadugu <nagendra@cs.stanford.edu>		Nagendra Modadugu <nagendra@cs.stanford.edu>
	Gates Computer Science		Gates Computer Science
	Stanford University		Stanford University
	Stanford, CA 94305		Stanford, CA 94305
	Acknowledgements		Acknowledgements
	The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine		The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine
	Sapuntzakis, and Hovav Shacham for discussions and comments on the		Sapuntzakis, and Hovav Shacham for discussions and comments on the
	design of DTLS. Thanks to the anonymous NDSS reviewers of our origi-		design of DTLS. Thanks to the anonymous NDSS reviewers of our
	nal NDSS paper on DTLS [DTLS] for their comments. Also, thanks to		original NDSS paper on DTLS [DTLS] for their comments. Also, thanks
	Steve Kent for feedback that helped clarify many points. The section		to Steve Kent for feedback that helped clarify many points. The
	on PMTU was cribbed from the DCCP specification [DCCP].		section on PMTU was cribbed from the DCCP specification [DCCP].
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
			Copyright Notice
			Copyright (C) The Internet Society (2003). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
			except as set forth therein, the authors retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 39 change blocks.
	142 lines changed or deleted		182 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/