rfc9853v1.txt		rfc9853.txt
	skipping to change at line 14 ¶		skipping to change at line 14 ¶
	Updates: 9146, 9147 A. Kraus		Updates: 9146, 9147 A. Kraus
	Category: Standards Track		Category: Standards Track
	ISSN: 2070-1721 T. Fossati		ISSN: 2070-1721 T. Fossati
	Linaro		Linaro
	February 2026		February 2026
	Return Routability Check for DTLS 1.2 and 1.3		Return Routability Check for DTLS 1.2 and 1.3
	Abstract		Abstract
	This document specifies a Return Routability Check (RRC) for use in		This document specifies a Return Routability Check (RRC) subprotocol
	the context of the Connection ID (CID) construct for the Datagram		for use in the context of the Connection ID (CID) construct for the
	Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.		Datagram Transport Layer Security (DTLS) protocol versions 1.2 and
			1.3.
	Implementations offering the CID functionality described in RFCs 9146		Implementations offering the CID functionality described in RFCs 9146
	and 9147 are encouraged to also provide the RRC functionality		and 9147 are encouraged to also provide the RRC functionality
	described in this document. For this reason, this document updates		described in this document. For this reason, this document updates
	RFCs 9146 and 9147.		RFCs 9146 and 9147.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	skipping to change at line 335 ¶		skipping to change at line 336 ¶
	return_routability_check message contains the previously sent		return_routability_check message contains the previously sent
	cookie. The actions taken by the initiator differ based on the		cookie. The actions taken by the initiator differ based on the
	received message:		received message:
	* When a return_routability_check message of type path_response		* When a return_routability_check message of type path_response
	is received, the initiator MUST continue using the previously		is received, the initiator MUST continue using the previously
	valid address, i.e., no switch to the new path takes place and		valid address, i.e., no switch to the new path takes place and
	the peer address binding is not updated.		the peer address binding is not updated.
	* When a return_routability_check message of type path_drop is		* When a return_routability_check message of type path_drop is
	received, the initiator MUST perform a return routability		received, the initiator MUST perform a basic return
	check on the observed new address, as described in		routability check on the observed new address, as described in
	Section 5.1.		Section 5.1.
	5. If T expires, the peer address binding is not updated. In this		5. If T expires, the peer address binding is not updated. In this
	case, the initiator MUST perform a return routability check on		case, the initiator MUST perform a basic return routability check
	the observed new address, as described in Section 5.1.		on the observed new address, as described in Section 5.1.
	5.3. Path Challenge Requirements		5.3. Path Challenge Requirements
	* The initiator MAY send multiple return_routability_check messages		* The initiator MAY send multiple return_routability_check messages
	of type path_challenge to cater for packet loss on the probed		of type path_challenge to account for packet loss on the probed
	path.		path.
	- Each path_challenge SHOULD go into different transport packets.		- Each path_challenge SHOULD go into different transport packets.
	(Note that the DTLS implementation may not have control over		(Note that the DTLS implementation may not have control over
	the packetization done by the transport layer.)		the packetization done by the transport layer.)
	- The transmission of subsequent path_challenge messages SHOULD		- The transmission of subsequent path_challenge messages SHOULD
	be paced to decrease the chance of loss.		be paced to decrease the chance of loss.
	- Each path_challenge message MUST contain random data.		- Each path_challenge message MUST contain random data.
	- In general, the number of "backup" path_challenge messages		- In general, the number of "backup" path_challenge messages
	depends on the application, since some are more sensitive than		depends on the application, since some are more sensitive than
	others to latency caused by changes in the path. In the		others to latency caused by changes in the path. In the
	absence of application-specific requirements, the initiator can		absence of application-specific requirements, the initiator can
	send a path_challenge message once per round-trip time (RTT),		send a path_challenge message once per round-trip time (RTT),
	up to the anti-amplification limit.		up to the anti-amplification limit.
	* The initiator MAY use padding using the record padding mechanism		* The initiator MAY use the record padding mechanism available in
	available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the		DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending
	sending direction) up to the anti-amplification limit to probe if		direction) to add padding up to the anti-amplification limit to
	the Path MTU (PMTU) for the new path is still acceptable.		probe if the Path MTU (PMTU) for the new path is still acceptable.
	5.4. Path Response/Drop Requirements		5.4. Path Response/Drop Requirements
	* The responder MUST NOT delay sending an elicited path_response or		* The responder MUST NOT delay sending an elicited path_response or
	path_drop messages.		path_drop messages.
	* The responder MUST send exactly one path_response or path_drop		* The responder MUST send exactly one path_response or path_drop
	message for each valid path_challenge it received.		message for each valid path_challenge it received.
	* The responder MUST send the path_response or the path_drop to the		* The responder MUST send the path_response or the path_drop to the
	address from which the corresponding path_challenge was received.		address from which the corresponding path_challenge was received.
	This ensures that the path is functional in both directions.		This ensures that the path is functional in both directions.
	* The initiator MUST silently discard any invalid path_response or		* The initiator MUST silently discard any invalid path_response or
	path_drop it receives.		path_drop it receives.
	Note that RRC does not cater for PMTU discovery on the reverse path.		Note that RRC does not account for PMTU discovery on the reverse
	If the responder wants to do PMTU discovery using RRC, it should		path. If the responder wants to do PMTU discovery using RRC, it
	initiate a new path validation procedure.		should initiate a new path validation procedure.
	5.5. Timer Choice		5.5. Timer Choice
	When setting T, implementations are cautioned that the new path could		When setting T, implementations are cautioned that the new path could
	have a longer RTT than the original.		have a longer RTT than the original.
	In settings where there is external information about the RTT of the		In settings where there is external information about the RTT of the
	active path (i.e., the old path), implementations SHOULD use T =		active path (i.e., the old path), implementations SHOULD use T =
	3xRTT.		3xRTT.
	skipping to change at line 556 ¶		skipping to change at line 557 ¶
	Section 4.5.1 of [RFC9147] and Section 4.1.2.6 of [RFC6347]), an		Section 4.5.1 of [RFC9147] and Section 4.1.2.6 of [RFC6347]), an
	attacker could replay a previously sent path_response message		attacker could replay a previously sent path_response message
	containing the reused cookie to mislead the challenger into switching		containing the reused cookie to mislead the challenger into switching
	to a path of the attacker's choosing. To prevent this, RRC cookies		to a path of the attacker's choosing. To prevent this, RRC cookies
	must be _freshly_ generated using a reliable source of entropy		must be _freshly_ generated using a reliable source of entropy
	[RFC4086]. See Appendix C.1 of [RFC8446] for guidance.		[RFC4086]. See Appendix C.1 of [RFC8446] for guidance.
	8.1. Attacker Model		8.1. Attacker Model
	Two classes of attackers are considered, off-path and on-path, with		Two classes of attackers are considered, off-path and on-path, with
	increasing capabilities (see Figure 4) partly following terminology		increasing capabilities (see Figure 4). The following descriptions
	introduced in QUIC (Section 21.1 of [RFC9000]):		of these attackers are based on those introduced in QUIC
			(Section 21.1 of [RFC9000]):
	* An off-path attacker is not on the original path between the DTLS		* An off-path attacker is not on the original path between the DTLS
	peers, but it is able to observe packets on the original path and		peers, but it is able to observe packets on the original path and
	has a faster forwarding path compared to the DTLS peers, which		has a faster forwarding path compared to the DTLS peers, which
	allows it to make copies of the observed packets, race its copies		allows it to make copies of the observed packets, race its copies
	to either peer, and consistently win the race.		to either peer, and consistently win the race.
	* An on-path attacker is on the original path between the DTLS peers		* An on-path attacker is on the original path between the DTLS peers
	and is therefore capable, compared to the off-path attacker, to		and is therefore capable, compared to the off-path attacker, to
	also drop and delay records at will.		also drop and delay records at will.
	skipping to change at line 662 ¶		skipping to change at line 664 ¶
	a new source address. In order to determine that this path change		a new source address. In order to determine that this path change
	was not triggered by an off-path attacker, the receiver will send an		was not triggered by an off-path attacker, the receiver will send an
	RRC message of type path_challenge (1) on the old path.		RRC message of type path_challenge (1) on the old path.
	new old		new old
	path .----------. path		path .----------. path
	| |		| |
	.-----+ Receiver +-----.		.-----+ Receiver +-----.
	| | | |		| | | |
	| '----------' |		| '----------' |
			| 1
	| |		| |
	| |		| |
	| |		.----+------. v
	.----+------. |
	/ Attacker? / |		/ Attacker? / |
	'------+----' |		'------+----' |
	| |		| |
	| |		| |
	| |		| |
	| .----------. |		| .----------. |
	| | | |		| | | |
	'-----+ Sender +-----'		'-----+ Sender +-----'
	| |		| |
	'----------'		'----------'
	skipping to change at line 746 ¶		skipping to change at line 748 ¶
	| '-----+ Sender +-----' |		| '-----+ Sender +-----' |
	'-------+ +-------'		'-------+ +-------'
	'----------'		'----------'
	Figure 7: Old Path Is Not Preferred		Figure 7: Old Path Is Not Preferred
	Case 3: The old path is alive and preferred.		Case 3: The old path is alive and preferred.
	This is most likely the result of an off-path attacker trying to		This is most likely the result of an off-path attacker trying to
	place itself on-path. As shown in Figure 8, the receiver sends a		place itself on-path. As shown in Figure 8, the receiver sends a
	path_challenge on the old path, and the sender replies with a		path_challenge (1) on the old path, and the sender replies with a
	path_response (2) on the old path. This results in the connection		path_response (2) on the old path. This results in the connection
	not being migrated to the new path, thus thwarting the attack.		not being migrated to the new path, thus thwarting the attack.
	new old		new old
	path .----------. path		path .----------. path
	| +-------.		| +-------.
	.-----+ Receiver +-----. |		.-----+ Receiver +-----. |
	| | |<--. | |		| | |<--. | |
	| '----------' | | |		| '----------' | | |
	| | | 1 path-		| | | 1 path-
End of changes. 10 change blocks.
	20 lines changed or deleted		22 lines changed or added
This html diff was produced by rfcdiff 1.48.