draft-ietf-tsvwg-datagram-plpmtud-04.txt		draft-ietf-tsvwg-datagram-plpmtud-05.txt
	Internet Engineering Task Force G. Fairhurst		Internet Engineering Task Force G. Fairhurst
	Internet-Draft T. Jones		Internet-Draft T. Jones
	Updates: 4821 (if approved) University of Aberdeen		Updates: 4821 (if approved) University of Aberdeen
	Intended status: Standards Track M. Tuexen		Intended status: Standards Track M. Tuexen
	Expires: March 9, 2019 I. Ruengeler		Expires: April 5, 2019 I. Ruengeler
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	September 5, 2018		October 02, 2018
	Packetization Layer Path MTU Discovery for Datagram Transports		Packetization Layer Path MTU Discovery for Datagram Transports
	draft-ietf-tsvwg-datagram-plpmtud-04		draft-ietf-tsvwg-datagram-plpmtud-05
	Abstract		Abstract
	This document describes a robust method for Path MTU Discovery		This document describes a robust method for Path MTU Discovery
	(PMTUD) for datagram Packetization Layers (PLs). The document		(PMTUD) for datagram Packetization Layers (PLs). The document
	describes an extension to RFC 1191 and RFC 8201, which specifies		describes an extension to RFC 1191 and RFC 8201, which specifies
	ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a		ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a
	PL, or a datagram application that uses a PL, to discover whether a		PL, or a datagram application that uses a PL, to discover whether a
	network path can support the current size of datagram. This can be		network path can support the current size of datagram. This can be
	used to detect and reduce the message size when a sender encounters a		used to detect and reduce the message size when a sender encounters a
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	progressively larger packets to find whether the maximum packet size		progressively larger packets to find whether the maximum packet size
	can be increased. This allows a sender to determine an appropriate		can be increased. This allows a sender to determine an appropriate
	packet size, providing functionally for datagram transports that is		packet size, providing functionally for datagram transports that is
	equivalent to the Packetization layer PMTUD specification for TCP,		equivalent to the Packetization layer PMTUD specification for TCP,
	specified in RFC 4821.		specified in RFC 4821.
	The document also provides implementation notes for incorporating		The document also provides implementation notes for incorporating
	Datagram PMTUD into IETF datagram transports or applications that use		Datagram PMTUD into IETF datagram transports or applications that use
	datagram transports.		datagram transports.
	When published, this specification updates RFC 4821 when used with		When published, this specification updates RFC 4821.
	datagram transports.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). 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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 9, 2019.		This Internet-Draft will expire on April 5, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	5.4.3. Resilience to inconsistent Path information . . . . . 28		5.4.3. Resilience to inconsistent Path information . . . . . 28
	6. Specification of Protocol-Specific Methods . . . . . . . . . 28		6. Specification of Protocol-Specific Methods . . . . . . . . . 28
	6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28		6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 28
	6.1.1. Application Request . . . . . . . . . . . . . . . . . 29		6.1.1. Application Request . . . . . . . . . . . . . . . . . 29
	6.1.2. Application Response . . . . . . . . . . . . . . . . 29		6.1.2. Application Response . . . . . . . . . . . . . . . . 29
	6.1.3. Sending Application Probe Packets . . . . . . . . . . 29		6.1.3. Sending Application Probe Packets . . . . . . . . . . 29
	6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29		6.1.4. Validating the Path . . . . . . . . . . . . . . . . . 29
	6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29		6.1.5. Handling of PTB Messages . . . . . . . . . . . . . . 29
	6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30		6.2. DPLPMTUD with UDP Options . . . . . . . . . . . . . . . . 30
	6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31		6.2.1. UDP Probe Request Option . . . . . . . . . . . . . . 31
	6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 31		6.2.2. UDP Probe Response Option . . . . . . . . . . . . . . 32
	6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32		6.3. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32
	6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32		6.3.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32
	6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32		6.3.1.1. Sending SCTP Probe Packets . . . . . . . . . . . 32
	6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33		6.3.1.2. Validating the Path with SCTP . . . . . . . . . . 33
	6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33		6.3.1.3. PTB Message Handling by SCTP . . . . . . . . . . 33
	6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33		6.3.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33
	6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33		6.3.2.1. Sending SCTP/UDP Probe Packets . . . . . . . . . 33
	6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 33		6.3.2.2. Validating the Path with SCTP/UDP . . . . . . . . 34
	6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 33		6.3.2.3. Handling of PTB Messages by SCTP/UDP . . . . . . 34
	6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 33		6.3.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34
	6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34		6.3.3.1. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34
	6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34		6.3.3.2. Validating the Path with SCTP/DTLS . . . . . . . 34
	6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34		6.3.3.3. Handling of PTB Messages by SCTP/DTLS . . . . . . 34
	6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34		6.4. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 34
	6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 34		6.4.1. Sending QUIC Probe Packets . . . . . . . . . . . . . 35
	6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35		6.4.2. Validating the Path with QUIC . . . . . . . . . . . . 35
	6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35		6.4.3. Handling of PTB Messages by QUIC . . . . . . . . . . 35
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 36		9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	10.1. Normative References . . . . . . . . . . . . . . . . . . 36		10.1. Normative References . . . . . . . . . . . . . . . . . . 37
	10.2. Informative References . . . . . . . . . . . . . . . . . 38		10.2. Informative References . . . . . . . . . . . . . . . . . 39
	Appendix A. Event-driven state changes . . . . . . . . . . . . . 38		Appendix A. Event-driven state changes . . . . . . . . . . . . . 39
	Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 41		Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	The IETF has specified datagram transport using UDP, SCTP, and DCCP,		The IETF has specified datagram transport using UDP, SCTP, and DCCP,
	as well as protocols layered on top of these transports (e.g., SCTP/		as well as protocols layered on top of these transports (e.g., SCTP/
	UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP		UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP
	network layer. This document describes a robust method for Path MTU		network layer. This document describes a robust method for Path MTU
	Discovery (PMTUD) that may be used with these transport protocols (or		Discovery (PMTUD) that may be used with these transport protocols (or
	the applications that use their transport service) to discover an		the applications that use their transport service) to discover an
	appropriate size of packet to use across an Internet path.		appropriate size of packet to use across an Internet path.
	This specification clarifies the PLPMTUD method for SCTP described in
	section 10.2 of [RFC4821] by specifying the procedure in Section 6.3
	of this document.
	1.1. Classical Path MTU Discovery		1.1. Classical Path MTU Discovery
	Classical Path Maximum Transmission Unit Discovery (PMTUD) can be		Classical Path Maximum Transmission Unit Discovery (PMTUD) can be
	used with any transport that is able to process ICMP Packet Too Big		used with any transport that is able to process ICMP Packet Too Big
	(PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message		(PTB) messages (e.g., [RFC1191] and [RFC8201]). The term PTB message
	is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry		is applied to both IPv4 ICMP Unreachable messages (Type 3) that carry
	the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too		the error Fragmentation Needed (Type 3, Code 4) and ICMPv6 packet too
	big messages (Type 2). When a sender receives a PTB message, it		big messages (Type 2). When a sender receives a PTB message, it
	reduces the effective MTU to the value reported in the PTB message		reduces the effective MTU to the value reported in the PTB message
	(in this document called the PTB_SIZE). A method from time-to-time		(in this document called the PTB_SIZE). A method from time-to-time
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 12 ¶
	not risk application data loss. The method defined in this		not risk application data loss. The method defined in this
	specification could be used with DCCP.		specification could be used with DCCP.
	Section 6 specifies the method for a set of transports, and provides		Section 6 specifies the method for a set of transports, and provides
	information to enable the implementation of PLPMTUD with other		information to enable the implementation of PLPMTUD with other
	datagram transports and applications that use datagram transports.		datagram transports and applications that use datagram transports.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [[RFC8174]] when, and only when, they appear in all
			capitals, as shown here.
	Other terminology is directly copied from [RFC4821], and the		Other terminology is directly copied from [RFC4821], and the
	definitions in [RFC1122].		definitions in [RFC1122].
	Actual PMTU: The Actual PMTU is the PMTU of a network path between a		Actual PMTU: The Actual PMTU is the PMTU of a network path between a
	sender PL and a destination PL, which the DPLPMTUD algorithm seeks		sender PL and a destination PL, which the DPLPMTUD algorithm seeks
	to determine.		to determine.
	Black Holed: Packets are Black holed when the sender is unaware that		Black Holed: Packets are Black holed when the sender is unaware that
	packets are not delivered to the destination endpoint (e.g., when		packets are not delivered to the destination endpoint (e.g., when
	skipping to change at page 24, line 16 ¶		skipping to change at page 24, line 16 ¶
	(PROBE_COUNT = MAX_PROBES)		(PROBE_COUNT = MAX_PROBES)
	+-------------------+ +--------------+		+-------------------+ +--------------+
	| PROBE_START +------>|PROBE_DISABLED|		| PROBE_START +------>|PROBE_DISABLED|
	+-------------------+ +--------------+		+-------------------+ +--------------+
	| ^		| ^
	| Path confirmed |		| Path confirmed |
	v |		v |
	MAX_PMTU acked or +--------------+-+ (PROBE_COUNT |		MAX_PMTU acked or +--------------+-+ (PROBE_COUNT |
	PTB (BASE_PMTU <= +---------| PROBE_SEARCH | | < MAX_PROBES) |		PTB (BASE_PMTU <= +---------| PROBE_SEARCH | | < MAX_PROBES) |
	PTB_SIZE | +--> +--------------+<+ or Probe acked |		PTB_SIZE | +--> +--------------+<+ or Probe acked |
	<PROBED_SIZE) | | | ^ |		<PROBED_SIZE) | | | ^ | |
	or | | | | |		or | | | | | |
	(PROBE_COUNT | | | | |		(PROBE_COUNT | | | | |((PTB_SIZE < |
	=MAX_PROBES) | | | | |		=MAX_PROBES) | | | | | BASE_PMTU) |
	+---------------+ | | | |		+---------------+ | | | | or |
	| | | | |		| | | | |(PLPMTU < BASE_MTU)) |
	| | | | |		| | | | |and (PROBE_COUNT = |
	| PMTU_RAISE_TIMER | | | |		| PMTU_RAISE_TIMER | | | | MAX_PROBES) |
	| | | | |		| | | | | |
	| | | | |		| | | | \ |
	| +-----------+ | | |		| +-----------+ | | \ Suspend DPLPDMTUD:|
	| | | | |		| | | | \ |
	| | | | |		| | | | \---------+ |
	| | (PTB_SIZE < PLPMTU)| | |		| | (PTB_SIZE < PLPMTU)| | | |
	| | or | | BASE_PMTU |		| | or | | BASE_PMTU | |
	| | Black hole detected | | Probe acked |		| | Black hole detected | | Probe acked | |
	v | v | |		v | v | v |
	+----------+----+ +--------------+ +-------------+		+----------+----+ +--------------+ +-------------+
	|SEARCH_COMPLETE|----------->| PROBE_BASE |<-------| PROBE_ERROR |		|SEARCH_COMPLETE|----------->| PROBE_BASE |<-------| PROBE_ERROR |
	+------+--------+ +--------------+ +-------------+		+------+--------+ +--------------+ +-------------+
	/\ | Black hole detected ^ | | BASE_PMTU Probe acked: ^		/\ | Black hole detected ^ | | BASE_PMTU Probe acked: ^
	| | or | | | |		| | or | | | |
	| | (PTB_SIZE < PLPMTU) | | | Probe BASE_PMTU: |		| | (PTB_SIZE < PLPMTU) | | | Probe BASE_PMTU: |
	| | | | | (PROBE_COUNT = MAX_PROBES)|		| | | | | (PROBE_COUNT = MAX_PROBES)|
	| | | | +---------------------------+		| | | | +---------------------------+
	+----+ +--+		+----+ +--+
	Confirmation: PROBE_TIMER expiry:		Confirmation: PROBE_TIMER expiry:
	skipping to change at page 30, line 12 ¶		skipping to change at page 30, line 12 ¶
	probed size. A validated PTB message MAY be used as input to the		probed size. A validated PTB message MAY be used as input to the
	DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU.		DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU.
	6.2. DPLPMTUD with UDP Options		6.2. DPLPMTUD with UDP Options
	UDP Options[I-D.ietf-tsvwg-udp-options] can supply the additional		UDP Options[I-D.ietf-tsvwg-udp-options] can supply the additional
	functionality required to implement DPLPMTUD within the UDP transport		functionality required to implement DPLPMTUD within the UDP transport
	service. Implementing DPLPMTU using UDP Options avoids the need for		service. Implementing DPLPMTU using UDP Options avoids the need for
	each application to implement the DPLPMTUD method.		each application to implement the DPLPMTUD method.
	Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the MSS option,		Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the Maximum
	which allows the local sender to indicate the EMTU_R to the peer.		Segment Size (MSS) option, which allows the local sender to indicate
	The value received in this option can be used to initialise PMTU_MAX.		the EMTU_R to the peer. The value received in this option can be
			used to initialise PMTU_MAX.
	UDP Options enables padding to be added to UDP datagrams that are		UDP Options enables padding to be added to UDP datagrams that are
	used as Probe Packets. Feedback confirming reception of each Probe		used as Probe Packets. Feedback confirming reception of each Probe
	Packet is provided by two new UDP Options:		Packet is provided by two new UDP Options:
	o The Probe Request Option (Section 6.2.1) is set by a sending PL to		o The Probe Request Option (Section 6.2.1) is set by a sending PL to
	solicit a response from a remote endpoint. A four-byte token		solicit a response from a remote endpoint. A four-byte token
	identifies each request.		identifies each request.
	o The Probe Response Option (Section 6.2.2 is generated by the UDP		o The Probe Response Option (Section 6.2.2 is generated by the UDP
	skipping to change at page 30, line 39 ¶		skipping to change at page 30, line 40 ¶
	The token value allows implementations to be distinguish between		The token value allows implementations to be distinguish between
	acknowledgements for initial probe packets and acknowledgements		acknowledgements for initial probe packets and acknowledgements
	confirming receipt of subsequent probe packets (e.g., travelling		confirming receipt of subsequent probe packets (e.g., travelling
	along alternate paths with a larger RTT). Each probe packet needs to		along alternate paths with a larger RTT). Each probe packet needs to
	be uniquely identifiable by the UDP Options sender within the Maximum		be uniquely identifiable by the UDP Options sender within the Maximum
	Segment Lifetime (MSL). The UDP Options sender therefore needs to		Segment Lifetime (MSL). The UDP Options sender therefore needs to
	not recycle token values until they have expired or have been		not recycle token values until they have expired or have been
	acknowledged. A 4 byte value for the token field provides sufficient		acknowledged. A 4 byte value for the token field provides sufficient
	space for multiple unique probes to be made within the MSL.		space for multiple unique probes to be made within the MSL.
	Implementations ought to only send a probe packet with a Probe		The initial value of the four byte token field SHOULD be assigned to
	Request Option when required by their local state machine, i.e., when		a randomised value, as described in section 5.1 of [RFC8085]) to
			enhance protection from off-path attacks.
			Implementations ought to only send a probe packet with a Request
			Probe Option when required by their local state machine, i.e., when
	probing to grow the PLPMTU or to confirm the current PLPMTU. The		probing to grow the PLPMTU or to confirm the current PLPMTU. The
	procedure to handle the loss of a response packet is the		procedure to handle the loss of a response packet is the
	responsibility of the sender of the request.		responsibility of the sender of the request. Implementations are
			allowed to track multiple requests and respond to them with a single
			packet.
	A PL needs to determine that the path can still support the size of		A PL needs to determine that the path can still support the size of
	datagram that the application is currently sending in the DPLPMTUD		datagram that the application is currently sending in the DPLPMTUD
	search_done state (i.e., to detect black-holing of data). One way to		search_done state (i.e., to detect black-holing of data). One way to
	achieve this is to send probe packets of size PLPMTU or to utilise a		achieve this is to send probe packets of size PLPMTU or to utilise a
	higher-layer method that provides explicit feedback indicating any		higher-layer method that provides explicit feedback indicating any
	packet loss. Another possibility is to utilise data packets that		packet loss. Another possibility is to utilise data packets that
	carry a Timestamp Option. Reception of a valid timestamp that was		carry a Timestamp Option. Reception of a valid timestamp that was
	echoed by the remote endpoint can be used to infer connectivity.		echoed by the remote endpoint can be used to infer connectivity.
	This can provide useful feedback even over paths with asymmetric		This can provide useful feedback even over paths with asymmetric
	capacity and/or that carry UDP Option flows that have very asymmetric		capacity and/or that carry UDP Option flows that have very asymmetric
	datagram rates, because an echo of the most recent timestamp still		datagram rates, because an echo of the most recent timestamp still
	indicates reception of at least one packet of the transmitted size.		indicates reception of at least one packet of the transmitted size.
	This is sufficient to confirm there is no black hole.		This is sufficient to confirm there is no black hole.
	In contrast, when sending a probe to increase the PLPMTU, a timestamp		In contrast, when sending a probe to increase the PLPMTU, a timestamp
	may be unable to unambiguously identify that a specific probe packet		might be unable to unambiguously identify that a specific probe
	has been received. Timestamp mechanisms cannot be used to confirm		packet has been received. Timestamp mechanisms cannot be used to
	the reception of individual probe messages and cannot be used to		confirm the reception of individual probe messages and cannot be used
	stimulate a response from the remote peer.		to stimulate a response from the remote peer.
	6.2.1. UDP Probe Request Option		6.2.1. UDP Probe Request Option
	The Probe Request Option allows a sending endpoint to solicit a		The Probe Request Option allows a sending endpoint to solicit a
	response from a destination endpoint.		response from a destination endpoint.
	The Probe Request Option carries a four byte token set by the sender.		The Probe Request Option carries a four byte token set by the sender.
	This token can be set to a value that is likely to be known only to		This token can be set to a value that is likely to be known only to
	the sender (and is sent along the end-to-end path). The sender can		the sender (and is sent along the end-to-end path). The initial
	then check the value returned in the UDP Probe Response Option. The		value of the token SHOULD be assigned to a randomised value, as
	value of the Token field, uniquely identifies a probe within the		described in section 5.1 of [RFC8085]) to enhance protection from
	maximum segment lifetime and can also provide additional protection		off-path attacks.
	from off-path insertion of data[RFC8085].
	+---------+--------+-----------------+		The sender needs to then check the value returned in the UDP Probe
	| Kind=9 | Len=6 | Token |		Response Option. The value of the Token field, uniquely identifies a
	+---------+--------+-----------------+		probe within the maximum segment lifetime.
			+----------+--------+-----------------+
			| Kind=9* | Len=6 | Token |
			+----------+--------+-----------------+
	1 byte 1 byte 4 bytes		1 byte 1 byte 4 bytes
			* To be confirmed by IANA.
	Figure 5: UDP Probe REQ Option Format		Figure 5: UDP Probe REQ Option Format
	6.2.2. UDP Probe Response Option		6.2.2. UDP Probe Response Option
	The Probe Response Option is generated in response to reception of a		The Probe Response Option is generated in response to reception of a
	previously received Probe Request Option.		previously received Probe Request Option. This response is generated
			by the UDP Option processing.
	The Probe Response Option carries a four byte token field. The Token		The Probe Response Option carries a four byte token field. The Token
	field associates the response with the Token value carried in the		field associates the response with the Token value carried in the
	most recently-received Echo Request. The rate of generation of UDP		most recently-received Echo Request. The rate of generation of UDP
	packets carrying a Probe Response Option MAY be rate-limited.		packets carrying a Probe Response Option is expected to be less than
			once per RTT and SHOULD be rate-limited (see Section 9).
	+---------+--------+-----------------+		+----------+--------+-----------------+
	| Kind=10 | Len=6 | Token |		| Kind=10* | Len=6 | Token |
	+---------+--------+-----------------+		+----------+--------+-----------------+
	1 byte 1 byte 4 bytes		1 byte 1 byte 4 bytes
			* To be confirmed by IANA.
	Figure 6: UDP Probe RES Option Format		Figure 6: UDP Probe RES Option Format
	6.3. DPLPMTUD for SCTP		6.3. DPLPMTUD for SCTP
	Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing		Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
	method for SCTP. It recommends the use of the PAD chunk, defined in		method for SCTP. It recommends the use of the PAD chunk, defined in
	[RFC4820] to be attached to a minimum length HEARTBEAT chunk to build		[RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
	a probe packet. This enables probing without affecting the transfer		a probe packet. This enables probing without affecting the transfer
	of user messages and without interfering with congestion control.		of user messages and without interfering with congestion control.
	This is preferred to using DATA chunks (with padding as required) as		This is preferred to using DATA chunks (with padding as required) as
	skipping to change at page 36, line 9 ¶		skipping to change at page 36, line 28 ¶
	XXX If new UDP Options are specified in this document, a request to		XXX If new UDP Options are specified in this document, a request to
	IANA will be included here. XXX		IANA will be included here. XXX
	If there are no requirements for IANA, the section will be removed		If there are no requirements for IANA, the section will be removed
	during conversion into an RFC by the RFC Editor.		during conversion into an RFC by the RFC Editor.
	9. Security Considerations		9. Security Considerations
	The security considerations for the use of UDP and SCTP are provided		The security considerations for the use of UDP and SCTP are provided
	in the references RFCs. Security guidance for applications using UDP		in the references RFCs. Security guidance for applications using UDP
	is provided in the UDP Usage Guidelines [RFC8085].		is provided in the UDP Usage Guidelines [RFC8085], specifically the
			generation of probe packets is regarded as a "Low Data-Volume
			Application", described in section 3.1.3 of this document. This
			recommends that sender limits generation of probe packets to an
			average rate lower than one probe per 3 seconds.
			A PL sender needs to ensure that the method used to confirm reception
			of probe packets offers protection from off-path attackers injecting
			packets into the path. This protection if provided in IETF-defined
			protocols (e.g., TCP, SCTP) using a randomly-initialised sequence
			number. A description of one way to do this when using UDP is
			provided in section 5.1 of [RFC8085]).
	There are cases where PTB messages are not delivered due to policy,		There are cases where PTB messages are not delivered due to policy,
	configuration or equipment design (see Section 1.1), this method		configuration or equipment design (see Section 1.1), this method
	therefore does not rely upon PTB messages being received, but is able		therefore does not rely upon PTB messages being received, but is able
	to utilise these when they are received by the sender. PTB messages		to utilise these when they are received by the sender. PTB messages
	could potentially be used to cause a node to inappropriately reduce		could potentially be used to cause a node to inappropriately reduce
	the PLPMTU. A node supporting DPLPMTUD MUST therefore appropriately		the PLPMTU. A node supporting DPLPMTUD MUST therefore appropriately
	validate the payload of PTB messages to ensure these are received in		validate the payload of PTB messages to ensure these are received in
	response to transmitted traffic (i.e., a reported error condition		response to transmitted traffic (i.e., a reported error condition
	that corresponds to a datagram actually sent by the path layer).		that corresponds to a datagram actually sent by the path layer).
	Parallel forwarding paths may need to be considered. Section 5.2.5.1		An on-path attacker, able to create a PTB message could forge PTB
			messages that include a valid quoted IP packet. Such an attack could
			be used to drive down the PLPMTU. There are two ways this method can
			be mitigated against such attacks: First, by ensuring that a PL
			sender never reduces the PLPMTU below the base size, solely in
			response to receiving a PTB message. This is achieved by first
			entering the PROBE_BASE state when such a message is received.
			Second, the design does not require processing of PTB messages, a PL
			sender could therefore suspend processing of PTB messages (e.g., in a
			robustness mode after detecting that subsequent probes actually
			confirm that a size larger than the PTB_SIZE is supported by a path).
			Parallel forwarding paths SHOULD be considered. Section 5.2.5.1
	identifies the need for robustness in the method when the path		identifies the need for robustness in the method when the path
	information may be inconsistent.		information may be inconsistent.
	A node performing DPLPMTUD could experience conflicting information		A node performing DPLPMTUD could experience conflicting information
	about the size of supported probe packets. This could occur when		about the size of supported probe packets. This could occur when
	there are multiple paths are concurrently in use and these exhibit a		there are multiple paths are concurrently in use and these exhibit a
	different PMTU. If not considered, this could result in data being		different PMTU. If not considered, this could result in data being
	black holed when the PLPMTU is larger than the smallest PMTU across		black holed when the PLPMTU is larger than the smallest PMTU across
	the current paths.		the current paths.
	An on-path attacker could forge PTB messages to drive down the PLPMTU
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-14 (work		and Secure Transport", draft-ietf-quic-transport-14 (work
	in progress), August 2018.		in progress), August 2018.
	[I-D.ietf-tsvwg-udp-options]		[I-D.ietf-tsvwg-udp-options]
	skipping to change at page 38, line 5 ¶		skipping to change at page 38, line 42 ¶
	[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream		[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
	Control Transmission Protocol (SCTP) Packets for End-Host		Control Transmission Protocol (SCTP) Packets for End-Host
	to End-Host Communication", RFC 6951,		to End-Host Communication", RFC 6951,
	DOI 10.17487/RFC6951, May 2013,		DOI 10.17487/RFC6951, May 2013,
	<https://www.rfc-editor.org/info/rfc6951>.		<https://www.rfc-editor.org/info/rfc6951>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.		March 2017, <https://www.rfc-editor.org/info/rfc8085>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
	[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,		[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
	"Datagram Transport Layer Security (DTLS) Encapsulation of		"Datagram Transport Layer Security (DTLS) Encapsulation of
	SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
	2017, <https://www.rfc-editor.org/info/rfc8261>.		2017, <https://www.rfc-editor.org/info/rfc8261>.
	skipping to change at page 43, line 19 ¶		skipping to change at page 44, line 19 ¶
	o Clarified supsending DPLPMTUD.		o Clarified supsending DPLPMTUD.
	o Verified normative text in requirements section.		o Verified normative text in requirements section.
	o Removed duplicate text.		o Removed duplicate text.
	o Changed all text to refer to /packet probe/probe packet/		o Changed all text to refer to /packet probe/probe packet/
	/validation/verification/ added term /Probe Confirmation/ and		/validation/verification/ added term /Probe Confirmation/ and
	clarified BlackHole detection.		clarified BlackHole detection.
			Working Group draft -05:
			o Updated security considerations.
			o Feedback after speaking with Joe Touch helped improve UDP-Options
			description.
	Authors' Addresses		Authors' Addresses
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	School of Engineering		School of Engineering
	Fraser Noble Building		Fraser Noble Building
	Aberdeen AB24 3U		Aberdeen AB24 3UE
	UK		UK
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
	Tom Jones		Tom Jones
	University of Aberdeen		University of Aberdeen
	School of Engineering		School of Engineering
	Fraser Noble Building		Fraser Noble Building
	Aberdeen AB24 3U		Aberdeen AB24 3UE
	UK		UK
	Email: tom@erg.abdn.ac.uk		Email: tom@erg.abdn.ac.uk
	Michael Tuexen		Michael Tuexen
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Stein fart 48565		Stein fart 48565
	DE		DE
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
	Irene Ruengeler		Irene Ruengeler
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Stein fart 48565		Stein fart 48565
	DE		DE
	Email: i.ruengeler@fh-muenster.de		Email: i.ruengeler@fh-muenster.de
End of changes. 34 change blocks.
	73 lines changed or deleted		117 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/