rfc9853.original.xml   rfc9853.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2. <!-- [rfced] Because this document updates RFC 9147, please
2) --> review the errata reported for RFC 9147
<?rfc rfcedstyle="yes"?> (https://www.rfc-editor.org/errata/rfc9147)
<?rfc tocindent="yes"?> and let us know if you confirm our opinion that none of them
<?rfc strict="yes"?> are relevant to the content of this document.
<?rfc comments="yes"?> -->
<?rfc inline="yes"?>
<?rfc docmapping="yes"?> <!-- [rfced] Please note that the title of the document has been updated as
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft follows.
-ietf-tls-dtls-rrc-20" category="std" consensus="true" submissionType="IETF" upd
ates="9146, 9147" tocInclude="true" sortRefs="true" symRefs="true" version="3"> Original:
<!-- xml2rfc v2v3 conversion 3.28.1 --> Return Routability Check for DTLS 1.2 and DTLS 1.3
Current:
Return Routability Check for DTLS 1.2 and 1.3
-->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-tls-dtls-rrc-20" number="9853" category="std" consensus="true" submissionT
ype="IETF" updates="9146, 9147" obsoletes="" xml:lang="en" tocInclude="true" sor
tRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="DTLS Return Routability Check">Return Routability Check for D <title abbrev="DTLS Return Routability Check">Return Routability Check for D
TLS 1.2 and DTLS 1.3</title> TLS 1.2 and 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-rrc-20"/> <seriesInfo name="RFC" value="9853"/>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role ="editor"> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role ="editor">
<organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization> <organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization>
<address> <address>
<email>Hannes.Tschofenig@gmx.net</email> <email>Hannes.Tschofenig@gmx.net</email>
</address> </address>
</author> </author>
<author initials="A." surname="Kraus" fullname="Achim Kraus"> <author initials="A." surname="Kraus" fullname="Achim Kraus">
<organization/> <organization/>
<address> <address>
<email>achimkraus@gmx.net</email> <email>achimkraus@gmx.net</email>
</address> </address>
</author> </author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati"> <author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>Linaro</organization> <organization>Linaro</organization>
<address> <address>
<email>thomas.fossati@linaro.org</email> <email>thomas.fossati@linaro.org</email>
</address> </address>
</author> </author>
<date year="2025" month="July" day="14"/> <date year="2026" month="February"/>
<area>Security</area> <area>SEC</area>
<workgroup>TLS</workgroup> <workgroup>tls</workgroup>
<keyword>DTLS, RRC, CID</keyword> <keyword>DTLS</keyword>
<abstract> <keyword>RRC</keyword>
<?line 47?> <keyword>CID</keyword>
<t>This document specifies a return routability check for use in context of the <!-- [rfced] Is this sentence in the abstract correct as is, or should it
include the word "subprotocol" (which is used in a similar sentence in
the Introduction)?
Original:
This document specifies a return routability check for use in context
of the Connection ID (CID) construct for the Datagram Transport Layer
Security (DTLS) protocol versions 1.2 and 1.3.
Current:
This document specifies a Return Routability Check (RRC) for use in
the context of the Connection ID (CID) construct for the Datagram
Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.
Perhaps:
This document specifies a Return Routability Check (RRC) subprotocol for use
in
the context of the Connection ID (CID) construct for the Datagram
Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.
-->
<abstract>
<t>This document specifies a Return Routability Check (RRC) for use in the conte
xt of the
Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS)
protocol versions 1.2 and 1.3.</t> protocol versions 1.2 and 1.3.</t>
<t>Implementations offering the CID functionality described in RFC 9146 an <t>Implementations offering the CID functionality described in RFCs 9146 a
d RFC 9147 are encouraged to also provide the return routability check functiona nd 9147 are encouraged to also provide the RRC functionality described in this d
lity described in this document. ocument.
For this reason, this document updates RFC 9146 and RFC 9147.</t> For this reason, this document updates RFCs 9146 and 9147.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Transport Layer Security Working Group mailing list (tls@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/tl
s/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/tlswg/dtls-rrc"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 56?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>A Connection ID (CID) is an identifier carried in the record layer head er of a DTLS datagram <t>A Connection ID (CID) is an identifier carried in the record layer head er of a DTLS datagram
that gives the receiver additional information for selecting the appropriate that gives the receiver additional information for selecting the appropriate
security context. The CID mechanism has been specified in <xref target="RFC9146 "/> for security context. The CID mechanism has been specified in <xref target="RFC9146 "/> for
DTLS 1.2 and in <xref target="RFC9147"/> for DTLS 1.3.</t> DTLS 1.2 and in <xref target="RFC9147"/> for DTLS 1.3.</t>
<t><xref section="6" sectionFormat="of" target="RFC9146"/> describes how t he use of CID increases the attack <t><xref section="6" sectionFormat="of" target="RFC9146"/> describes how t he use of CID increases the attack
surface of DTLS 1.2 and 1.3 by providing both on-path and off-path attackers an opportunity for surface of DTLS 1.2 and 1.3 by providing both on-path and off-path attackers an opportunity for
(D)DoS. It also describes the steps a DTLS principal must take when a DoS or DDoS. It also describes the steps a DTLS principal must take when a
record with a CID is received that has a source address different record with a CID is received that has a source address different
from the one currently associated with the DTLS connection. However, the from the one currently associated with the DTLS connection. However, the
actual mechanism for ensuring that the new peer address is willing to receive actual mechanism for ensuring that the new peer address is willing to receive
and process DTLS records is left open. To address the gap, this document define s a Return and process DTLS records is left open. To address the gap, this document define s a Return
Routability Check (RRC) sub-protocol for DTLS 1.2 and 1.3 inspired by the path v alidation procedure defined in <xref section="8.2" sectionFormat="of" target="RF C9000"/>. Routability Check (RRC) subprotocol for DTLS 1.2 and 1.3, inspired by the path v alidation procedure defined in <xref section="8.2" sectionFormat="of" target="RF C9000"/>.
As such, this document updates <xref target="RFC9146"/> and <xref target="RFC914 7"/>.</t> As such, this document updates <xref target="RFC9146"/> and <xref target="RFC914 7"/>.</t>
<t>The return routability check is performed by the receiving endpoint bef ore the <t>The return routability check is performed by the receiving endpoint bef ore the
CID-address binding is updated in that endpoint's session state. CID-address binding is updated in that endpoint's session state.
This is done in order to give the receiving endpoint confidence This is done in order to give the receiving endpoint confidence
that the sending peer is in fact reachable at the source address indicated in th e received datagram. that the sending peer is in fact reachable at the source address indicated in th e received datagram.
For an illustration of the handshake and address validation phases, see <xref ta rget="overview"/>.</t> For an illustration of the handshake and address validation phases, see <xref ta rget="overview"/>.</t>
<t><xref target="regular"/> of this document explains the fundamental mech anism that aims to reduce the DDoS attack surface. <t><xref target="regular"/> of this document explains the fundamental mech anism that aims to reduce the DDoS attack surface.
Additionally, in <xref target="enhanced"/>, a more advanced address validation m echanism is discussed. Additionally, <xref target="enhanced"/> discusses a more advanced address valida tion mechanism.
This mechanism is designed to counteract off-path attackers trying to place them selves on-path by racing packets that trigger address rebinding at the receiver. This mechanism is designed to counteract off-path attackers trying to place them selves on-path by racing packets that trigger address rebinding at the receiver.
To gain a detailed understanding of the attacker model, please refer to <xref ta rget="attacker"/>.</t> To gain a detailed understanding of the attacker model, please refer to <xref ta rget="attacker"/>.</t>
<t>Apart from of its use in the context of CID-address binding updates, <t>Apart from of its use in the context of CID-address binding updates,
the path validation capability offered by RRC can be used at any time by either endpoint. For the path validation capability offered by RRC can be used at any time by either endpoint. For
instance, an endpoint might use RRC to check that a peer is still reachable at instance, an endpoint might use RRC to check that a peer is still reachable at
its last known address after a period of quiescence.</t> its last known address after a period of quiescence.</t>
</section> </section>
<section anchor="conventions-and-terminology"> <section anchor="conventions-and-terminology">
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
<t>This document assumes familiarity with the CID format and protocol defined fo r <t>This document assumes familiarity with the CID format and protocol defined fo r
DTLS 1.2 <xref target="RFC9146"/> and for DTLS 1.3 <xref target="RFC9147"/>. Th e presentation language DTLS 1.2 <xref target="RFC9146"/> and for DTLS 1.3 <xref target="RFC9147"/>. Th e presentation language
used in this document is described in <xref section="4" sectionFormat="of" targe t="RFC8446"/>.</t> used in this document is described in <xref section="4" sectionFormat="of" targe t="RFC8446"/>.</t>
<t>In this document, the term "anti-amplification limit" means three times the amount of data received from an unvalidated address. <t>In this document, the term "anti-amplification limit" means three times the amount of data received from an unvalidated address.
This includes all DTLS records originating from that source address, excluding t hose that have been discarded. This includes all DTLS records originating from that source address, excluding t hose that have been discarded.
This follows the pattern of <xref target="RFC9000"/>, applying a similar concept to DTLS.</t> This follows the pattern of <xref target="RFC9000"/>, applying a similar concept to DTLS.</t>
<t>The term "address" is defined in <xref section="1.2" sectionFormat="of" target="RFC9000"/>.</t> <t>The term "address" is defined in <xref section="1.2" sectionFormat="of" target="RFC9000"/>.</t>
<t>The terms "client", "server", "peer" and "endpoint" are defined in <xre f section="1.1" sectionFormat="of" target="RFC8446"/>.</t> <t>The terms "client", "server", "peer", and "endpoint" are defined in <xr ef section="1.1" sectionFormat="of" target="RFC8446"/>.</t>
</section> </section>
<section anchor="rrc-extension"> <section anchor="rrc-extension">
<name>RRC Extension</name> <name>RRC Extension</name>
<t>The use of RRC is negotiated via the <tt>rrc</tt> extension. <t>The use of RRC is negotiated via the <tt>rrc</tt> extension.
The <tt>rrc</tt> extension is only defined for DTLS 1.2 and DTLS 1.3. The <tt>rrc</tt> extension is only defined for DTLS 1.2 and 1.3.
On connecting, a client wishing to use RRC includes the <tt>rrc</tt> extension i n its ClientHello. On connecting, a client wishing to use RRC includes the <tt>rrc</tt> extension i n its ClientHello.
If the server is capable of meeting this requirement, it responds with a If the server is capable of meeting this requirement, it responds with an
<tt>rrc</tt> extension in its ServerHello. The <tt>extension_type</tt> value fo r this <tt>rrc</tt> extension in its ServerHello. The <tt>extension_type</tt> value fo r this
extension is TBD1 and the <tt>extension_data</tt> field of this extension is emp ty. extension is 61, and the <tt>extension_data</tt> field of this extension is empt y.
A client offering the <tt>rrc</tt> extension <bcp14>MUST</bcp14> also offer the <tt>connection_id</tt> extension <xref target="RFC9146"/>. A client offering the <tt>rrc</tt> extension <bcp14>MUST</bcp14> also offer the <tt>connection_id</tt> extension <xref target="RFC9146"/>.
If the client includes the <tt>rrc</tt> extension in its ClientHello but omits t he <tt>connection_id</tt> extension, the server <bcp14>MUST NOT</bcp14> include the <tt>rrc</tt> extension in its ServerHello. If the client includes the <tt>rrc</tt> extension in its ClientHello but omits t he <tt>connection_id</tt> extension, the server <bcp14>MUST NOT</bcp14> include the <tt>rrc</tt> extension in its ServerHello.
A client offering the <tt>connection_id</tt> extension <bcp14>SHOULD</bcp14> als o offer the <tt>rrc</tt> extension, unless the application using DTLS has its ow n address validation mechanism. A client offering the <tt>connection_id</tt> extension <bcp14>SHOULD</bcp14> als o offer the <tt>rrc</tt> extension, unless the application using DTLS has its ow n address validation mechanism.
The client and server <bcp14>MUST NOT</bcp14> use RRC unless both sides have suc cessfully exchanged <tt>rrc</tt> extensions.</t> The client and server <bcp14>MUST NOT</bcp14> use RRC unless both sides have suc cessfully exchanged <tt>rrc</tt> extensions.</t>
<section anchor="rrc-and-cid-interplay"> <section anchor="rrc-and-cid-interplay">
<name>RRC and CID Interplay</name> <name>RRC and CID Interplay</name>
<t>RRC offers an in-protocol mechanism to perform peer address validatio n that <t>RRC offers an in-protocol mechanism to perform peer address validatio n that
complements the "peer address update" procedure described in <xref section="6" s ectionFormat="of" target="RFC9146"/>. Specifically, when both CID <xref target= "RFC9146"/> and RRC have been complements the "peer address update" procedure described in <xref section="6" s ectionFormat="of" target="RFC9146"/>. Specifically, when both CID <xref target= "RFC9146"/> and RRC have been
successfully negotiated for the session, if a record with CID is received that successfully negotiated for the session, if a record with CID is received that
has the source address of the enclosing UDP datagram different from what is has the source address of the enclosing UDP datagram different from what is
currently associated with that CID value, the receiver <bcp14>SHOULD</bcp14> per form a return currently associated with that CID value, the receiver <bcp14>SHOULD</bcp14> per form a return
routability check as described in <xref target="path-validation"/>, unless an ap plication-specific routability check as described in <xref target="path-validation"/>, unless an ap plication-specific
address validation mechanism can be triggered instead (e.g., CoAP Echo <xref tar get="RFC9175"/>).</t> address validation mechanism can be triggered instead (e.g., Constrained Applica tion Protocol (CoAP) Echo <xref target="RFC9175"/>).</t>
</section> </section>
</section> </section>
<section anchor="return-routability-check-message-types"> <section anchor="return-routability-check-message-types">
<name>Return Routability Check Message Types</name> <name>Return Routability Check Message Types</name>
<t>This document defines the <tt>return_routability_check</tt> content typ e <t>This document defines the <tt>return_routability_check</tt> content typ e
(<xref target="fig-rrc-msg"/>) to carry Return Routability Check messages.</t> (<xref target="fig-rrc-msg"/>) to carry Return Routability Check messages.</t>
<t>The RRC sub-protocol consists of three message types: <tt>path_challeng <t>The RRC subprotocol consists of three message types: <tt>path_challenge
e</tt>, <tt>path_response</tt> </tt>, <tt>path_response</tt>,
and <tt>path_drop</tt> that are used for path validation and selection as descri and <tt>path_drop</tt>. These message types are used for path validation and sel
bed in ection as described in
<xref target="path-validation"/>.</t> <xref target="path-validation"/>.</t>
<t>Each message carries a Cookie, an 8-byte field containing 64 bits of en tropy (e.g., obtained from the CSPRNG used by the TLS implementation, see <xref section="C.1" sectionFormat="of" target="RFC8446"/>).</t> <t>Each message carries a Cookie, an 8-byte field containing 64 bits of en tropy (e.g., obtained from the cryptographically secure pseudorandom number gene rator (CSPRNG) used by the TLS implementation; see <xref section="C.1" sectionFo rmat="of" target="RFC8446"/>).</t>
<t>The <tt>return_routability_check</tt> message <bcp14>MUST</bcp14> be au thenticated and encrypted <t>The <tt>return_routability_check</tt> message <bcp14>MUST</bcp14> be au thenticated and encrypted
using the currently active security context.</t> using the currently active security context.</t>
<figure anchor="fig-rrc-msg"> <figure anchor="fig-rrc-msg">
<name>Return Routability Check Message and Content Type</name> <name>Return Routability Check Message and Content Type</name>
<sourcecode type="tls-msg"><![CDATA[ <sourcecode type="tls-msg"><![CDATA[
enum { enum {
invalid(0), invalid(0),
change_cipher_spec(20), change_cipher_spec(20),
alert(21), alert(21),
handshake(22), handshake(22),
skipping to change at line 178 skipping to change at line 201
struct { struct {
rrc_msg_type msg_type; rrc_msg_type msg_type;
select (return_routability_check.msg_type) { select (return_routability_check.msg_type) {
case path_challenge: Cookie; case path_challenge: Cookie;
case path_response: Cookie; case path_response: Cookie;
case path_drop: Cookie; case path_drop: Cookie;
}; };
} return_routability_check; } return_routability_check;
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>Future extensions to the RRC sub-protocol may <t>Future extensions to the RRC subprotocol may
define new message types. define new message types.
Implementations <bcp14>MUST</bcp14> be able to parse and understand the three RR C message types defined in this document. Implementations <bcp14>MUST</bcp14> be able to parse and understand the three RR C message types defined in this document.
In addition, implementations <bcp14>MUST</bcp14> be able to parse and gracefully ignore messages with an unknown <tt>msg_type</tt>.</t> In addition, implementations <bcp14>MUST</bcp14> be able to parse and gracefully ignore messages with an unknown <tt>msg_type</tt>.</t>
</section> </section>
<section anchor="path-validation"> <section anchor="path-validation">
<name>Path Validation Procedure</name> <name>Path Validation Procedure</name>
<t>A receiver that observes the peer's address change <bcp14>MUST</bcp14> stop sending <t>A receiver that observes the peer's address change <bcp14>MUST</bcp14> stop sending
any buffered application data, or limit the data sent to the unvalidated any buffered application data or limit the data sent to the unvalidated
address to the anti-amplification limit. address to the anti-amplification limit.
It then initiates the return routability check.</t> It then initiates the return routability check.</t>
<t>This document describes two kinds of checks: basic (<xref target="regul ar"/>) and enhanced (<xref target="enhanced"/>). <t>This document describes two kinds of checks: basic (<xref target="regul ar"/>) and enhanced (<xref target="enhanced"/>).
The choice of one or the other depends on whether the off-path attacker scenario described in <xref target="off-path"/> is to be considered. The choice of one or the other depends on whether the off-path attacker scenario described in <xref target="off-path"/> is to be considered.
(The decision on what strategy to choose depends mainly on the threat model, but (The decision on what strategy to choose depends mainly on the threat model but
may also be influenced by other considerations. Examples of impacting factors may also be influenced by other considerations. Examples of impacting factors
include: the need to minimise implementation complexity, privacy concerns, and t he include the need to minimise implementation complexity, privacy concerns, and th e
need to reduce the time it takes to switch path. The choice may be offered as need to reduce the time it takes to switch path. The choice may be offered as
a configuration option to the user of the TLS implementation.)</t> a configuration option to the user of the TLS implementation.)</t>
<t>After the path validation procedure is completed, any pending send oper ation is <t>After the path validation procedure is complete, any pending send opera tion is
resumed to the bound peer address.</t> resumed to the bound peer address.</t>
<t><xref target="path-challenge-reqs"/> and <xref target="path-response-re qs"/> list the requirements for <t>Sections <xref target="path-challenge-reqs" format="counter"/> and <xre f target="path-response-reqs" format="counter"/> list the requirements for
the initiator and responder roles, broken down per protocol phase.</t> the initiator and responder roles, broken down per protocol phase.</t>
<t>Please note that the presented algorithms are not designed to handle ne sted rebindings, i.e. rebindings that may occur while a path is being validated following a previous rebinding. <t>Please note that the presented algorithms are not designed to handle ne sted rebindings, i.e. rebindings that may occur while a path is being validated following a previous rebinding.
If this happens (which should rarely occur), the <tt>path_response</tt> message is dropped, the address validation times out, and the address will not be update d. This should rarely occur, but if it happens, the <tt>path_response</tt> message is dropped, the address validation times out, and the address will not be update d.
A new path validation will start when new data is received.</t> A new path validation will start when new data is received.</t>
<t>Also note that in the event of a NAT rebind, the initiator and responde r will have different views of the path: the initiator will see a new path, whil e the responder will still see the old one.</t> <t>Also, note that in the event of a NAT rebind, the initiator and respond er will have different views of the path: The initiator will see a new path, whi le the responder will still see the old one.</t>
<section anchor="regular"> <section anchor="regular">
<name>Basic</name> <name>Basic</name>
<t>The basic return routability check comprises the following steps:</t> <t>The basic return routability check comprises the following steps:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The receiver (i.e., the initiator) creates a <tt>return_routabili ty_check</tt> message of <t>The receiver (i.e., the initiator) creates a <tt>return_routabili ty_check</tt> message of
type <tt>path_challenge</tt> and places the unpredictable cookie into the messag e.</t> type <tt>path_challenge</tt> and places the unpredictable cookie into the messag e.</t>
</li> </li>
<li> <li>
<t>The message is sent to the observed new address and a timer T (se e <t>The message is sent to the observed new address and a timer T (se e
<xref target="timer-choice"/>) is started.</t> <xref target="timer-choice"/>) is started.</t>
skipping to change at line 227 skipping to change at line 250
<tt>return_routability_check</tt> message of <tt>return_routability_check</tt> message of
type <tt>path_challenge</tt> and responds by echoing the cookie value in a type <tt>path_challenge</tt> and responds by echoing the cookie value in a
<tt>return_routability_check</tt> message of type <tt>path_response</tt>.</t> <tt>return_routability_check</tt> message of type <tt>path_response</tt>.</t>
</li> </li>
<li> <li>
<t>When the initiator receives the <tt>return_routability_check</tt> <t>When the initiator receives the <tt>return_routability_check</tt>
message of type <tt>path_response</tt> and verifies that it contains the sent c ookie, it updates the peer message of type <tt>path_response</tt> and verifies that it contains the sent c ookie, it updates the peer
address binding.</t> address binding.</t>
</li> </li>
<li> <li>
<t>If T expires the peer address binding is not updated.</t> <t>If T expires, the peer address binding is not updated.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="enhanced"> <section anchor="enhanced">
<name>Enhanced</name> <name>Enhanced</name>
<t>The enhanced return routability check comprises the following steps:< /t> <t>The enhanced return routability check comprises the following steps:< /t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The receiver (i.e., the initiator) creates a <tt>return_routabili ty_check</tt> message of <t>The receiver (i.e., the initiator) creates a <tt>return_routabili ty_check</tt> message of
type <tt>path_challenge</tt> and places the unpredictable cookie into the messag e.</t> type <tt>path_challenge</tt> and places the unpredictable cookie into the messag e.</t>
</li> </li>
<li> <li>
<t>The message is sent to the previously valid address, which corres ponds to the <t>The message is sent to the previously valid address, which corres ponds to the
old path. Additionally, a timer T is started, see <xref target="timer-choice"/>. </t> old path. Additionally, a timer T is started (see <xref target="timer-choice"/>) .</t>
</li> </li>
<li> <li>
<t>If the path is still functional, the peer (i.e., the responder) c ryptographically verifies the received <t>If the path is still functional, the peer (i.e., the responder) c ryptographically verifies the received
<tt>return_routability_check</tt> message of <tt>return_routability_check</tt> message of
type <tt>path_challenge</tt>. type <tt>path_challenge</tt>.
The action to be taken depends on whether the path through which the message was received remains the preferred one. The action to be taken depends on whether the path through which the message was received remains the preferred one.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the path through which the message was received is preferr ed, <t>If the path through which the message was received is preferr ed,
skipping to change at line 268 skipping to change at line 291
<t> <t>
In either case, the peer echoes the cookie value in the response.</t> In either case, the peer echoes the cookie value in the response.</t>
</li> </li>
<li> <li>
<t>The initiator receives and verifies that the <tt>return_routabili ty_check</tt> <t>The initiator receives and verifies that the <tt>return_routabili ty_check</tt>
message contains the previously sent cookie. The actions taken by the message contains the previously sent cookie. The actions taken by the
initiator differ based on the received message: initiator differ based on the received message:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>When a <tt>return_routability_check</tt> message of type <tt> path_response</tt> was received, <t>When a <tt>return_routability_check</tt> message of type <tt> path_response</tt> is received,
the initiator <bcp14>MUST</bcp14> continue using the previously valid address, i .e., no switch the initiator <bcp14>MUST</bcp14> continue using the previously valid address, i .e., no switch
to the new path takes place and the peer address binding is not updated.</t> to the new path takes place and the peer address binding is not updated.</t>
</li> </li>
<li> <li>
<t>When a <tt>return_routability_check</tt> message of type <tt> <!-- [rfced] Should "return routability check" here be updated to "basic
path_drop</tt> was received, return routability check" in these instances in Section 5.2?
Original:
* When a return_routability_check message of type path_drop was
received, the initiator MUST perform a return routability
check on the observed new address, as described in
Section 5.1.
...
5. If T expires the peer address binding is not updated. In this
case, the initiator MUST perform a return routability check on
the observed new address, as described in Section 5.1.
Perhaps:
* When a return_routability_check message of type path_drop was
received, the initiator MUST perform a basic return routability
check on the observed new address, as described in
Section 5.1.
...
5. If T expires the peer address binding is not updated. In this
case, the initiator MUST perform a basic return routability check on
the observed new address, as described in Section 5.1.
-->
<t>When a <tt>return_routability_check</tt> message of type <tt>
path_drop</tt> is received,
the initiator <bcp14>MUST</bcp14> perform a return routability check on the obse rved new the initiator <bcp14>MUST</bcp14> perform a return routability check on the obse rved new
address, as described in <xref target="regular"/>.</t> address, as described in <xref target="regular"/>.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>If T expires the peer address binding is not updated. In this cas e, the <t>If T expires, the peer address binding is not updated. In this ca se, the
initiator <bcp14>MUST</bcp14> perform a return routability check on the observed new initiator <bcp14>MUST</bcp14> perform a return routability check on the observed new
address, as described in <xref target="regular"/>.</t> address, as described in <xref target="regular"/>.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="path-challenge-reqs"> <section anchor="path-challenge-reqs">
<name> Path Challenge Requirements</name> <name>Path Challenge Requirements</name>
<ul spacing="normal"> <ul spacing="normal">
<!-- [rfced] For clarity, may we update "cater for"?
Original:
* The initiator MAY send multiple return_routability_check messages
of type path_challenge to cater for packet loss on the probed
path.
...
Note that RRC does not cater for PMTU discovery on the reverse path.
Perhaps:
* The initiator MAY send multiple return_routability_check messages
of type path_challenge to account for packet loss on the probed
path.
...
Note that RRC does not account for PMTU discovery on the reverse path.
-->
<li> <li>
<t>The initiator <bcp14>MAY</bcp14> send multiple <tt>return_routabi lity_check</tt> messages of type <t>The initiator <bcp14>MAY</bcp14> send multiple <tt>return_routabi lity_check</tt> messages of type
<tt>path_challenge</tt> to cater for packet loss on the probed path. <tt>path_challenge</tt> to cater for packet loss on the probed path.
</t> </t>
<!-- [rfced] We see the following phrasing with the message types defined in
this document (i.e., path_challenge, path_response, and
path_drop). Please review and let us know if any updates are needed for
consistency.
return_routability_check message of type path_response
return_routability_check message of type path_challenge
return_routability_check message of type path_drop
path_challenge message
path_response message
path_drop message
path_challenge
path_response
path_drop
Some examples:
3. The peer (i.e., the responder) cryptographically verifies the
received return_routability_check message of type path_challenge
and responds by echoing the cookie value in a
return_routability_check message of type path_response.
...
Each path_challenge message MUST contain random data.
...
* The responder MUST send the path_response or the path_drop to the
address from which the corresponding path_challenge was received.
...
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Each <tt>path_challenge</tt> <bcp14>SHOULD</bcp14> go into di fferent transport packets. (Note that <t>Each <tt>path_challenge</tt> <bcp14>SHOULD</bcp14> go into di fferent transport packets. (Note that
the DTLS implementation may not have control over the packetization done by the DTLS implementation may not have control over the packetization done by
the transport layer.)</t> the transport layer.)</t>
</li> </li>
<li> <li>
<t>The transmission of subsequent <tt>path_challenge</tt> messag es <bcp14>SHOULD</bcp14> be paced to <t>The transmission of subsequent <tt>path_challenge</tt> messag es <bcp14>SHOULD</bcp14> be paced to
decrease the chance of loss.</t> decrease the chance of loss.</t>
</li> </li>
<li> <li>
<t>Each <tt>path_challenge</tt> message <bcp14>MUST</bcp14> cont ain random data.</t> <t>Each <tt>path_challenge</tt> message <bcp14>MUST</bcp14> cont ain random data.</t>
</li> </li>
<li> <li>
<t>In general, the number of "backup" <tt>path_challenge</tt> me ssages depends on the application, since some are more sensitive to latency caus ed by changes in the path than others. <t>In general, the number of "backup" <tt>path_challenge</tt> me ssages depends on the application, since some are more sensitive than others to latency caused by changes in the path.
In the absence of application-specific requirements, the initiator can send a <t t>path_challenge</tt> message once per round-trip time (RTT), up to the anti-amp lification limit.</t> In the absence of application-specific requirements, the initiator can send a <t t>path_challenge</tt> message once per round-trip time (RTT), up to the anti-amp lification limit.</t>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<!-- [rfced] Please review "use padding using...up to". Would updating as follow
s
improve readability of this sentence?
Original:
* The initiator MAY use padding using the record padding mechanism
available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the
sending direction) up to the anti-amplification limit to probe if
the path MTU (PMTU) for the new path is still acceptable.
Perhaps:
* The initiator MAY use the record padding mechanism
available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the
sending direction) to add padding up to the anti-amplification limit to pr
obe if
the Path MTU (PMTU) for the new path is still acceptable.
-->
<t>The initiator <bcp14>MAY</bcp14> use padding using the record pad ding mechanism available in <t>The initiator <bcp14>MAY</bcp14> use padding using the record pad ding mechanism available in
DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending direction) up DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending direction) up
to the anti-amplification limit to probe if the path MTU (PMTU) for the new to the anti-amplification limit to probe if the Path MTU (PMTU) for the new
path is still acceptable.</t> path is still acceptable.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="path-response-reqs"> <section anchor="path-response-reqs">
<name>Path Response/Drop Requirements</name> <name>Path Response/Drop Requirements</name>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The responder <bcp14>MUST NOT</bcp14> delay sending an elicited < tt>path_response</tt> or <t>The responder <bcp14>MUST NOT</bcp14> delay sending an elicited < tt>path_response</tt> or
<tt>path_drop</tt> messages.</t> <tt>path_drop</tt> messages.</t>
skipping to change at line 348 skipping to change at line 463
<tt>path_drop</tt> it receives.</t> <tt>path_drop</tt> it receives.</t>
</li> </li>
</ul> </ul>
<t>Note that RRC does not cater for PMTU discovery on the reverse path. If the <t>Note that RRC does not cater for PMTU discovery on the reverse path. If the
responder wants to do PMTU discovery using RRC, it should initiate a new path responder wants to do PMTU discovery using RRC, it should initiate a new path
validation procedure.</t> validation procedure.</t>
</section> </section>
<section anchor="timer-choice"> <section anchor="timer-choice">
<name>Timer Choice</name> <name>Timer Choice</name>
<t>When setting T, implementations are cautioned that the new path could have a <t>When setting T, implementations are cautioned that the new path could have a
longer RTT than the original.</t> longer RTT than the original.</t>
<!-- [rfced] FYI - We updated "1s" to "1 second" for clarity.
Original:
If an implementation has no way to obtain information regarding the
RTT of the active path, T SHOULD be set to 1s.
Perhaps:
If an implementation has no way to obtain information regarding the
RTT of the active path, T SHOULD be set to 1 second.
-->
<t>In settings where there is external information about the RTT of the active <t>In settings where there is external information about the RTT of the active
path (i.e., the old path), implementations <bcp14>SHOULD</bcp14> use T = 3xRTT.< /t> path (i.e., the old path), implementations <bcp14>SHOULD</bcp14> use T = 3xRTT.< /t>
<t>If an implementation has no way to obtain information regarding the R TT of the <t>If an implementation has no way to obtain information regarding the R TT of the
active path, T <bcp14>SHOULD</bcp14> be set to 1s.</t> active path, T <bcp14>SHOULD</bcp14> be set to 1 second.</t>
<t>Profiles for specific deployment environments -- for example, constra ined <t>Profiles for specific deployment environments -- for example, constra ined
networks <xref target="I-D.ietf-uta-tls13-iot-profile"/> -- <bcp14>MAY</bcp14> s pecify a different, more networks <xref target="I-D.ietf-uta-tls13-iot-profile"/> -- <bcp14>MAY</bcp14> s pecify a different, more
suitable value for T.</t> suitable value for T.</t>
</section> </section>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Example</name> <name>Example</name>
<t><xref target="fig-handshake"/> shows an example of a DTLS 1.3 handshake in which a client and a server successfully negotiate support for both the CID and RRC extensions.</t> <t><xref target="fig-handshake"/> shows an example of a DTLS 1.3 handshake in which a client and a server successfully negotiate support for both the CID and RRC extensions.</t>
<figure anchor="fig-handshake"> <figure anchor="fig-handshake">
<name>Message Flow for Full DTLS Handshake</name> <name>Message Flow for Full DTLS Handshake</name>
skipping to change at line 394 skipping to change at line 521
v {Finished} --------> v {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the + Indicates noteworthy extensions sent in the
previously noted message. previously noted message.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret. derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys [] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N. derived from [sender]_application_traffic_secret_N.]]></artwork
]]></artwork> >
</figure> </figure>
<t>Once a connection has been established, the client and the server <t>Once a connection has been established, the client and the server
exchange application payloads protected by DTLS with a unilaterally used exchange application payloads protected by DTLS with a unilaterally used
CID. In this case, the client is requested to use CID 100 for records CID. In this case, the client is requested to use CID 100 for records
sent to the server.</t> sent to the server.</t>
<t>At some point in the communication interaction, the address used by <t>At some point in the communication interaction, the address used by
the client changes and, thanks to the CID usage, the security context to the client changes, and thanks to the CID usage, the security context to
interpret the record is successfully located by the server. However, the interpret the record is successfully located by the server. However, the
server wants to test the reachability of the client at its new address.</t> server wants to test the reachability of the client at its new address.</t>
<t><xref target="fig-rrc-example"/> shows the server initiating a "basic" RRC exchange <t><xref target="fig-rrc-example"/> shows the server initiating a basic RR C exchange
(see <xref target="regular"/>) that establishes reachability of the client at th e new (see <xref target="regular"/>) that establishes reachability of the client at th e new
address.</t> address.</t>
<figure anchor="fig-rrc-example"> <figure anchor="fig-rrc-example">
<name>"Basic" Return Routability Example</name> <name>Basic Return Routability Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
Client Server Client Server
------ ------ ------ ------
Application Data ========> Application Data ========>
<CID=100> <CID=100>
Src-IP=A Src-IP=A
Dst-IP=Z Dst-IP=Z
<======== Application Data <======== Application Data
Src-IP=Z Src-IP=Z
skipping to change at line 451 skipping to change at line 578
Return Routability Check --------> Return Routability Check -------->
path_response(cookie) path_response(cookie)
Src-IP=B Src-IP=B
Dst-IP=Z Dst-IP=Z
<<< IP Address B <<< IP Address B
Verified >> Verified >>
<======== Application Data <======== Application Data
Src-IP=Z Src-IP=Z
Dst-IP=B Dst-IP=B]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="operational-considerations"> <section anchor="operational-considerations">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<section anchor="logging-anomalous-events"> <section anchor="logging-anomalous-events">
<name>Logging Anomalous Events</name> <name>Logging Anomalous Events</name>
<t>Logging of RRC operations at both ends of the protocol can be general ly useful for the users of an implementation. <t>Logging of RRC operations at both ends of the protocol can be general ly useful for the users of an implementation.
In particular, for security information and event management (SIEM) and troubles hooting purposes, it is strongly advised that implementations collect statistics about any unsuccessful RRC operations, as they could represent security-relevan t events when they coincide with attempts by an attacker to interfere with the e nd-to-end path. In particular, for Security Information and Event Management (SIEM) and troubles hooting purposes, it is strongly advised that implementations collect statistics about any unsuccessful RRC operations, as they could represent security-relevan t events when they coincide with attempts by an attacker to interfere with the e nd-to-end path.
It is also advisable to log instances where multiple responses to a single <tt>p ath_challenge</tt> are received, as this could suggest an off-path attack attemp t.</t> It is also advisable to log instances where multiple responses to a single <tt>p ath_challenge</tt> are received, as this could suggest an off-path attack attemp t.</t>
<t>In some cases, the presence of frequent path probes could indicate a problem with the stability of the path. <t>In some cases, the presence of frequent path probes could indicate a problem with the stability of the path.
This information can be used to identify any issues with the underlying connecti vity service.</t> This information can be used to identify any issues with the underlying connecti vity service.</t>
</section> </section>
<section anchor="middlebox-interference"> <section anchor="middlebox-interference">
<name>Middlebox Interference</name> <name>Middlebox Interference</name>
<t>Since the DTLS 1.3 encrypted packet's record type is opaque to on-pat h observers, RRC messages are immune to middlebox interference when using DTLS 1 .3. <t>Since the DTLS 1.3 encrypted packet's record type is opaque to on-pat h observers, RRC messages are immune to middlebox interference when using DTLS 1 .3.
In contrast, DTLS 1.2 RRC messages that are not wrapped in the <tt>tls12_cid</tt > record (e.g., in the server-to-client direction if the server negotiated a zer o-length CID) have the <tt>return_routability_check</tt> content type in plain t ext, making them susceptible to interference (e.g., dropping of <tt>path_challen ge</tt> messages), which would hinder the RRC functionality altogether. In contrast, DTLS 1.2 RRC messages that are not wrapped in the <tt>tls12_cid</tt > record (e.g., in the server-to-client direction if the server negotiated a zer o-length CID) have the <tt>return_routability_check</tt> content type in plain t ext, making them susceptible to interference (e.g., dropping of <tt>path_challen ge</tt> messages), which would hinder the RRC functionality altogether.
Therefore, when using RRC in DTLS 1.2 and middlebox interference is a concern, i t is recommended to enable CID in both directions.</t> Therefore, when RRC in DTLS 1.2 is used and middlebox interference is a concern, it is recommended to enable CID in both directions.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Note that the return routability checks do not protect against flooding of <t>Note that the return routability checks do not protect against flooding of
third-parties if the attacker is on-path, as the attacker can redirect the third parties if the attacker is on-path, as the attacker can redirect the
return routability checks to the real peer (even if those datagrams are return routability checks to the real peer (even if those datagrams are
cryptographically authenticated). On-path adversaries can, in general, pose a cryptographically authenticated). On-path adversaries can, in general, pose a
harm to connectivity.</t> harm to connectivity.</t>
<t>If the RRC challenger reuses a cookie that was previously used in the s ame connection and does not implement anti-replay protection (see <xref section= "4.5.1" sectionFormat="of" target="RFC9147"/> and <xref section="4.1.2.6" sectio nFormat="of" target="RFC6347"/>), an attacker could replay a previously sent <tt >path_response</tt> message containing the reused cookie to mislead the challeng er into switching to a path of the attacker's choosing. <t>If the RRC challenger reuses a cookie that was previously used in the s ame connection and does not implement anti-replay protection (see <xref section= "4.5.1" sectionFormat="of" target="RFC9147"/> and <xref section="4.1.2.6" sectio nFormat="of" target="RFC6347"/>), an attacker could replay a previously sent <tt >path_response</tt> message containing the reused cookie to mislead the challeng er into switching to a path of the attacker's choosing.
To prevent this, RRC cookies must be <em>freshly</em> generated using a reliable source of entropy <xref target="RFC4086"/>. To prevent this, RRC cookies must be <em>freshly</em> generated using a reliable source of entropy <xref target="RFC4086"/>.
See <xref section="C.1" sectionFormat="of" target="RFC8446"/> for guidance.</t> See <xref section="C.1" sectionFormat="of" target="RFC8446"/> for guidance.</t>
<section anchor="attacker"> <section anchor="attacker">
<name>Attacker Model</name> <name>Attacker Model</name>
<!-- [rfced] How may we clarify this sentence, especially "increasing
capabilities" and the text starting with "partly following
terminology..."?
Original:
Two classes of attackers are considered, off-path and on-path, with
increasing capabilities (see Figure 4) partly following terminology
introduced in QUIC (Section 21.1 of [RFC9000]):
Perhaps:
This model includes two classes of attackers, off-path and on-path, with
various capabilities (see Figure 4). The following
descriptions of these attackers are based on those
introduced in QUIC (Section 21.1 of [RFC9000]):
-->
<t>Two classes of attackers are considered, off-path and on-path, with i ncreasing <t>Two classes of attackers are considered, off-path and on-path, with i ncreasing
capabilities (see <xref target="fig-attacker-capabilities"/>) partly following t erminology capabilities (see <xref target="fig-attacker-capabilities"/>) partly following t erminology
introduced in QUIC (<xref section="21.1" sectionFormat="of" target="RFC9000"/>): </t> introduced in QUIC (<xref section="21.1" sectionFormat="of" target="RFC9000"/>): </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An off-path attacker is not on the original path between the DTLS peers, but <t>An off-path attacker is not on the original path between the DTLS peers, but
is able to observe packets on the original path and has a faster forwarding path it is able to observe packets on the original path and has a faster forwarding p ath
compared to the DTLS peers, which allows it to make copies of the observed compared to the DTLS peers, which allows it to make copies of the observed
packets, race its copies to either peer and consistently win the race.</t> packets, race its copies to either peer, and consistently win the race.</t>
</li> </li>
<li> <li>
<t>An on-path attacker is on the original path between the DTLS peer s and is <t>An on-path attacker is on the original path between the DTLS peer s and is
therefore capable, compared to the off-path attacker, to also drop and delay therefore capable, compared to the off-path attacker, to also drop and delay
records at will.</t> records at will.</t>
</li> </li>
</ul> </ul>
<t>Note that, in general, attackers cannot craft DTLS records in a way t hat would <t>Note that, in general, attackers cannot craft DTLS records in a way t hat would
successfully pass verification, due to the cryptographic protections applied by successfully pass verification, due to the cryptographic protections applied by
the DTLS record layer.</t> the DTLS record layer.</t>
<figure anchor="fig-attacker-capabilities"> <figure anchor="fig-attacker-capabilities">
<name>Attacker capabilities</name> <name>Attacker Capabilities</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="448" viewBox="0 0 448 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="272" width="448" viewBox="0 0 448 272" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 40,32 L 40,80" fill="none" stroke="black"/> <path d="M 40,32 L 40,80" fill="none" stroke="black"/>
<path d="M 40,112 L 40,160" fill="none" stroke="black"/> <path d="M 40,112 L 40,160" fill="none" stroke="black"/>
<path d="M 80,32 L 80,256" fill="none" stroke="black"/> <path d="M 80,32 L 80,256" fill="none" stroke="black"/>
<path d="M 376,32 L 376,256" fill="none" stroke="black"/> <path d="M 376,32 L 376,256" fill="none" stroke="black"/>
<path d="M 416,32 L 416,128" fill="none" stroke="black"/> <path d="M 416,32 L 416,128" fill="none" stroke="black"/>
<path d="M 416,160 L 416,256" fill="none" stroke="black"/> <path d="M 416,160 L 416,256" fill="none" stroke="black"/>
<path d="M 40,32 L 64,32" fill="none" stroke="black"/> <path d="M 40,32 L 64,32" fill="none" stroke="black"/>
<path d="M 80,32 L 376,32" fill="none" stroke="black"/> <path d="M 80,32 L 376,32" fill="none" stroke="black"/>
skipping to change at line 531 skipping to change at line 674
<path d="M 80,192 L 376,192" fill="none" stroke="black"/> <path d="M 80,192 L 376,192" fill="none" stroke="black"/>
<path d="M 80,224 L 376,224" fill="none" stroke="black"/> <path d="M 80,224 L 376,224" fill="none" stroke="black"/>
<path d="M 80,256 L 376,256" fill="none" stroke="black"/> <path d="M 80,256 L 376,256" fill="none" stroke="black"/>
<path d="M 392,256 L 416,256" fill="none" stroke="black"/> <path d="M 392,256 L 416,256" fill="none" stroke="black"/>
<polygon class="arrowhead" points="400,256 388,250.4 388,261.6" fill="black" transform="rotate(180,392,256)"/> <polygon class="arrowhead" points="400,256 388,250.4 388,261.6" fill="black" transform="rotate(180,392,256)"/>
<polygon class="arrowhead" points="400,32 388,26.4 388,37.6" fil l="black" transform="rotate(180,392,32)"/> <polygon class="arrowhead" points="400,32 388,26.4 388,37.6" fil l="black" transform="rotate(180,392,32)"/>
<polygon class="arrowhead" points="72,160 60,154.4 60,165.6" fil l="black" transform="rotate(0,64,160)"/> <polygon class="arrowhead" points="72,160 60,154.4 60,165.6" fil l="black" transform="rotate(0,64,160)"/>
<polygon class="arrowhead" points="72,32 60,26.4 60,37.6" fill=" black" transform="rotate(0,64,32)"/> <polygon class="arrowhead" points="72,32 60,26.4 60,37.6" fill=" black" transform="rotate(0,64,32)"/>
<g class="text"> <g class="text">
<text x="120" y="52">Inspect</text> <text x="120" y="52">Inspect</text>
<text x="204" y="52">un-encrypted</text> <text x="204" y="52">unencrypted</text>
<text x="292" y="52">portions</text> <text x="292" y="52">portions</text>
<text x="116" y="84">Inject</text> <text x="116" y="84">Inject</text>
<text x="36" y="100">off-path</text> <text x="36" y="100">off-path</text>
<text x="120" y="116">Reorder</text> <text x="120" y="116">Reorder</text>
<text x="116" y="148">Modify</text> <text x="116" y="148">Modify</text>
<text x="212" y="148">un-authenticated</text> <text x="212" y="148">unauthenticated</text>
<text x="316" y="148">portions</text> <text x="316" y="148">portions</text>
<text x="416" y="148">on-path</text> <text x="416" y="148">on-path</text>
<text x="112" y="180">Delay</text> <text x="112" y="180">Delay</text>
<text x="108" y="212">Drop</text> <text x="108" y="212">Drop</text>
<text x="132" y="244">Manipulate</text> <text x="132" y="244">Manipulate</text>
<text x="192" y="244">the</text> <text x="192" y="244">the</text>
<text x="264" y="244">packetization</text> <text x="264" y="244">packetization</text>
<text x="344" y="244">layer</text> <text x="344" y="244">layer</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.--> .------------------------------------. <--. .--> .------------------------------------. <--.
| | Inspect un-encrypted portions | | | | Inspect unencrypted portions | |
| +------------------------------------+ | | +------------------------------------+ |
| | Inject | | | | Inject | |
off-path +------------------------------------+ | off-path +------------------------------------+ |
| | Reorder | | | | Reorder | |
| +------------------------------------+ | | +------------------------------------+ |
| | Modify un-authenticated portions | on-path | | Modify unauthenticated portions | on-path
'--> +------------------------------------+ | '--> +------------------------------------+ |
| Delay | | | Delay | |
+------------------------------------+ | +------------------------------------+ |
| Drop | | | Drop | |
+------------------------------------+ | +------------------------------------+ |
| Manipulate the packetization layer | | | Manipulate the packetization layer | |
'------------------------------------' <--' '------------------------------------' <--'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
skipping to change at line 582 skipping to change at line 725
spoofing the source address of the victim (<xref target="sec-amplification"/>).< /t> spoofing the source address of the victim (<xref target="sec-amplification"/>).< /t>
</li> </li>
<li> <li>
<t>Off-path attackers that try to put themselves on-path (<xref targ et="off-path"/>), <t>Off-path attackers that try to put themselves on-path (<xref targ et="off-path"/>),
provided that the enhanced path validation algorithm is used (<xref target="enha nced"/>).</t> provided that the enhanced path validation algorithm is used (<xref target="enha nced"/>).</t>
</li> </li>
</ul> </ul>
<section anchor="sec-amplification"> <section anchor="sec-amplification">
<name>Amplification</name> <name>Amplification</name>
<t>Both on-path and off-path attackers can send a packet (either by mo difying it <t>Both on-path and off-path attackers can send a packet (either by mo difying it
on the fly, or by copying, injecting, and racing it, respectively) with the on the fly or by copying, injecting, and racing it, respectively) with the
source address modified to that of a victim host. If the traffic generated by source address modified to that of a victim host. If the traffic generated by
the server in response is larger compared to the received packet (e.g., a CoAP the server in response is larger compared to the received packet (e.g., a CoAP
server returning an MTU's worth of data from a 20-bytes GET request <xref target ="I-D.irtf-t2trg-amplification-attacks"/>) the server returning an MTU's worth of data from a 20-byte GET request <xref target= "I-D.irtf-t2trg-amplification-attacks"/>), the
attacker can use the server as a traffic amplifier toward the victim.</t> attacker can use the server as a traffic amplifier toward the victim.</t>
<section anchor="mitigation-strategy"> <section anchor="mitigation-strategy">
<name>Mitigation Strategy</name> <name>Mitigation Strategy</name>
<t>When receiving a packet with a known CID that has a source addres s different from the one currently associated with the DTLS connection, an <t>When receiving a packet with a known CID that has a source addres s different from the one currently associated with the DTLS connection, an
RRC-capable endpoint will not send a (potentially large) response but instead a RRC-capable endpoint will not send a (potentially large) response but instead a
small <tt>path_challenge</tt> message to the victim host. Since the host is not able small <tt>path_challenge</tt> message to the victim host. Since the host is not able
to decrypt it and generate a valid <tt>path_response</tt>, the address validatio n to decrypt it and generate a valid <tt>path_response</tt>, the address validatio n
fails, which in turn keeps the original address binding unaltered.</t> fails, which in turn keeps the original address binding unaltered.</t>
<t>Note that in case of an off-path attacker, the original packet st ill reaches <t>Note that in the case of an off-path attacker, the original packe t still reaches
the intended destination; therefore, an implementation could use a different the intended destination; therefore, an implementation could use a different
strategy to mitigate the attack.</t> strategy to mitigate the attack.</t>
</section> </section>
</section> </section>
<section anchor="off-path"> <section anchor="off-path">
<name>Off-Path Packet Forwarding</name> <name>Off-Path Packet Forwarding</name>
<t>An off-path attacker that can observe packets might forward copies of <t>An off-path attacker that can observe packets might forward copies of
genuine packets to endpoints over a different path. If the copied packet arrives before genuine packets to endpoints over a different path. If the copied packet arrives before
the genuine packet, this will appear as a path change, like in a genuine NAT reb inding occurrence. Any genuine the genuine packet, this will appear as a path change, like in a genuine NAT reb inding occurrence. Any genuine
packet will be discarded as a duplicate. If the attacker is able to packet will be discarded as a duplicate. If the attacker is able to
continue forwarding packets, it might be able to cause migration to a continue forwarding packets, it might be able to cause migration to a
path via the attacker. This places the attacker on-path, giving it path via the attacker. This places the attacker on-path, giving it
the ability to observe or drop all subsequent packets.</t> the ability to observe or drop all subsequent packets.</t>
<t>This style of attack relies on the attacker using a path that has <t>This style of attack relies on the attacker using a path that has
the same or better characteristics (e.g., due to a more favourable service level agreements) as the direct path between the same or better characteristics (e.g., due to a more favourable service level agreements) as the direct path between
endpoints. The attack is more effective if relatively few packets are endpoints. The attack is more effective if relatively few packets are
sent or if packet loss coincides with the attempted attack.</t> sent or if packet loss coincides with the attempted attack.</t>
<t>A data packet received on the original path that increases the <t>A data packet received on the original path that increases the
maximum received packet number will cause the endpoint to move back maximum received packet number will cause the endpoint to move back
to that path. Therefore, eliciting packets on this path increases the to that path. Therefore, eliciting packets on this path increases the
likelihood that the attack is unsuccessful. Note however that, unlike QUIC, likelihood that the attack is unsuccessful. However, note that, unlike QUIC,
DTLS has no "non-probing" packets so this would require application specific DTLS has no "non-probing" packets so this would require application-specific
mechanisms.</t> mechanisms.</t>
<section anchor="mitigation-strategy-1"> <section anchor="mitigation-strategy-1">
<name>Mitigation Strategy</name> <name>Mitigation Strategy</name>
<!-- [rfced] Please review the use of "(1)" in the sentences below. Figure 5
does not include a "1". Should "1" be removed from these sentences or
added to Figure 5? Or does "(1)" in these sentences refer to Figure 6?
Let us know how to clarify. Also, should "timeout of (1)" be updated to
"timeout of the path_challenge message (1)"?
Original:
Figure 5 illustrates the case where a receiver receives a packet with
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
RRC message of type path_challenge (1) on the old path.
<Figure 5>
Case 1: The old path is dead (e.g., due to a NAT rebinding), which
leads to a timeout of (1).
As shown in Figure 6, a path_challenge (2) needs to be sent on the
new path. If the sender replies with a path_response on the new path
(3), the switch to the new path is considered legitimate.
<Figure 6>
-->
<t><xref target="fig-off-path"/> illustrates the case where a receiv er receives a <t><xref target="fig-off-path"/> illustrates the case where a receiv er receives a
packet with a new source address. In order packet with a new source address. In order
to determine that this path change was not triggered to determine that this path change was not triggered
by an off-path attacker, the receiver will send an RRC message of type by an off-path attacker, the receiver will send an RRC message of type
<tt>path_challenge</tt> (1) on the old path.</t> <tt>path_challenge</tt> (1) on the old path.</t>
<figure anchor="fig-off-path"> <figure anchor="fig-off-path">
<name>Off-Path Packet Forwarding Scenario</name> <name>Off-Path Packet Forwarding Scenario</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="368" width="256" viewBox="0 0 256 368" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="368" width="256" viewBox="0 0 256 368" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 64,80 L 64,176" fill="none" stroke="black"/> <path d="M 64,80 L 64,176" fill="none" stroke="black"/>
skipping to change at line 690 skipping to change at line 858
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Three cases need to be considered:</t> <t>Three cases need to be considered:</t>
<t>Case 1: The old path is dead (e.g., due to a NAT rebinding), whic h leads to a <t>Case 1: The old path is dead (e.g., due to a NAT rebinding), whic h leads to a
timeout of (1).</t> timeout of (1).</t>
<t>As shown in <xref target="fig-old-path-dead"/>, a <tt>path_challe nge</tt> (2) needs to be sent on <t>As shown in <xref target="fig-old-path-dead"/>, a <tt>path_challe nge</tt> (2) needs to be sent on
the new path. If the sender replies with a <tt>path_response</tt> on the new pa th the new path. If the sender replies with a <tt>path_response</tt> on the new pa th
(3), the switch to the new path is considered legitimate.</t> (3), the switch to the new path is considered legitimate.</t>
<figure anchor="fig-old-path-dead"> <figure anchor="fig-old-path-dead">
<name>Old path is dead</name> <name>Old Path Is Dead</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="368" width="384" viewBox="0 0 384 368" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="368" width="384" viewBox="0 0 384 368" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 80,64 L 80,112" fill="none" stroke="black"/> <path d="M 80,64 L 80,112" fill="none" stroke="black"/>
<path d="M 80,144 L 80,320" fill="none" stroke="black"/> <path d="M 80,144 L 80,320" fill="none" stroke="black"/>
<path d="M 96,80 L 96,176" fill="none" stroke="black"/> <path d="M 96,80 L 96,176" fill="none" stroke="black"/>
<path d="M 96,208 L 96,304" fill="none" stroke="black"/> <path d="M 96,208 L 96,304" fill="none" stroke="black"/>
<path d="M 112,96 L 112,224" fill="none" stroke="black"/> <path d="M 112,96 L 112,224" fill="none" stroke="black"/>
<path d="M 112,256 L 112,288" fill="none" stroke="black"/> <path d="M 112,256 L 112,288" fill="none" stroke="black"/>
<path d="M 144,48 L 144,112" fill="none" stroke="black"/> <path d="M 144,48 L 144,112" fill="none" stroke="black"/>
<path d="M 144,272 L 144,336" fill="none" stroke="black"/> <path d="M 144,272 L 144,336" fill="none" stroke="black"/>
skipping to change at line 787 skipping to change at line 955
| | | challenge . | | | challenge .
| | | .----------. . | | | .----------. .
| | '-->| | . | | '-->| | .
| '-----+ Sender +.....' | '-----+ Sender +.....'
'-------+ | '-------+ |
'----------' '----------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Case 2: The old path is alive but not preferred.</t> <t>Case 2: The old path is alive but not preferred.</t>
<!-- [rfced] Would it be helpful to update "path_challenge" here to
"path_challenge (1)"?
Original:
The receiver sends a path_challenge on the old
path and the sender replies with a path_response (2) on the old path.
The interaction is shown in Figure 8.
Perhaps:
As shown in Figure 8, the receiver sends a
path_challenge (1) on the old path, and the sender replies with a
path_response (2) on the old path.
-->
<t>This case is shown in <xref target="fig-old-path-not-preferred"/> whereby the sender <t>This case is shown in <xref target="fig-old-path-not-preferred"/> whereby the sender
replies with a <tt>path_drop</tt> message (2) on the old path. This triggers replies with a <tt>path_drop</tt> message (2) on the old path. This triggers
the receiver to send a <tt>path_challenge</tt> (3) on the new path. The sender the receiver to send a <tt>path_challenge</tt> (3) on the new path. The sender
will reply with a <tt>path_response</tt> (4) on the new path, thus providing will reply with a <tt>path_response</tt> (4) on the new path, thus providing
confirmation for the path migration.</t> confirmation for the path migration.</t>
<figure anchor="fig-old-path-not-preferred"> <figure anchor="fig-old-path-not-preferred">
<name>Old path is not preferred</name> <name>Old Path Is Not Preferred</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="352" width="424" viewBox="0 0 424 352" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="352" width="424" viewBox="0 0 424 352" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 104,64 L 104,112" fill="none" stroke="black"/> <path d="M 104,64 L 104,112" fill="none" stroke="black"/>
<path d="M 104,144 L 104,320" fill="none" stroke="black"/> <path d="M 104,144 L 104,320" fill="none" stroke="black"/>
<path d="M 120,80 L 120,176" fill="none" stroke="black"/> <path d="M 120,80 L 120,176" fill="none" stroke="black"/>
<path d="M 120,216 L 120,304" fill="none" stroke="black"/> <path d="M 120,216 L 120,304" fill="none" stroke="black"/>
<path d="M 136,96 L 136,224" fill="none" stroke="black"/> <path d="M 136,96 L 136,224" fill="none" stroke="black"/>
<path d="M 136,256 L 136,288" fill="none" stroke="black"/> <path d="M 136,256 L 136,288" fill="none" stroke="black"/>
<path d="M 168,48 L 168,112" fill="none" stroke="black"/> <path d="M 168,48 L 168,112" fill="none" stroke="black"/>
<path d="M 168,272 L 168,336" fill="none" stroke="black"/> <path d="M 168,272 L 168,336" fill="none" stroke="black"/>
skipping to change at line 900 skipping to change at line 1083
| | | .----------. | | | | | | .----------. | | |
| | '-->| |<--' | | | | '-->| |<--' | |
| '-----+ Sender +-----' | | '-----+ Sender +-----' |
'-------+ +-------' '-------+ +-------'
'----------' '----------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Case 3: The old path is alive and preferred.</t> <t>Case 3: The old path is alive and preferred.</t>
<t>This is most likely the result of an off-path attacker trying to place itself <t>This is most likely the result of an off-path attacker trying to place itself
on path. The receiver sends a <tt>path_challenge</tt> on the old path and the s on-path. As shown in
ender <xref target="fig-old-path-preferred"/>, the receiver sends a <tt>path_challenge
replies with a <tt>path_response</tt> (2) on the old path. The interaction is sh </tt> on the old path, and the sender
own in replies with a <tt>path_response</tt> (2) on the old path. This results in the c
<xref target="fig-old-path-preferred"/>. This results in the connection not bein onnection not being migrated
g migrated
to the new path, thus thwarting the attack.</t> to the new path, thus thwarting the attack.</t>
<figure anchor="fig-old-path-preferred"> <figure anchor="fig-old-path-preferred">
<name>Old path is preferred</name> <name>Old Path Is Preferred</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="384" width="352" viewBox="0 0 352 384" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org /2000/svg" version="1.1" height="384" width="352" viewBox="0 0 352 384" class="d iagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lin ecap="round">
<path d="M 64,80 L 64,176" fill="none" stroke="black"/> <path d="M 64,80 L 64,176" fill="none" stroke="black"/>
<path d="M 64,224 L 64,320" fill="none" stroke="black"/> <path d="M 64,224 L 64,320" fill="none" stroke="black"/>
<path d="M 112,48 L 112,112" fill="none" stroke="black"/> <path d="M 112,48 L 112,112" fill="none" stroke="black"/>
<path d="M 112,288 L 112,352" fill="none" stroke="black"/> <path d="M 112,288 L 112,352" fill="none" stroke="black"/>
<path d="M 200,48 L 200,112" fill="none" stroke="black"/> <path d="M 200,48 L 200,112" fill="none" stroke="black"/>
<path d="M 200,288 L 200,352" fill="none" stroke="black"/> <path d="M 200,288 L 200,352" fill="none" stroke="black"/>
<path d="M 232,96 L 232,240" fill="none" stroke="black"/> <path d="M 232,96 L 232,240" fill="none" stroke="black"/>
<path d="M 232,272 L 232,304" fill="none" stroke="black"/> <path d="M 232,272 L 232,304" fill="none" stroke="black"/>
skipping to change at line 999 skipping to change at line 1182
</figure> </figure>
<t>Note that this defense is imperfect, but this is not considered a serious <t>Note that this defense is imperfect, but this is not considered a serious
problem. If the path via the attacker is reliably faster than the problem. If the path via the attacker is reliably faster than the
old path despite multiple attempts to use that old path, it old path despite multiple attempts to use that old path, it
is not possible to distinguish between an attack and an improvement is not possible to distinguish between an attack and an improvement
in routing.</t> in routing.</t>
<t>An endpoint could also use heuristics to improve detection of thi s <t>An endpoint could also use heuristics to improve detection of thi s
style of attack. For instance, NAT rebinding is improbable if style of attack. For instance, NAT rebinding is improbable if
packets were recently received on the old path. packets were recently received on the old path.
Endpoints can also look for duplicated Endpoints can also look for duplicated
packets. Conversely, a change in connection ID is more likely to packets. Conversely, a change in CID is more likely to
indicate an intentional migration rather than an attack. Note that indicate an intentional migration rather than an attack. Note that
changes in connection IDs are supported in DTLS 1.3 but not in changes in CIDs are supported in DTLS 1.3 but not in
DTLS 1.2.</t> DTLS 1.2.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>When using DTLS 1.3, peers <bcp14>SHOULD</bcp14> avoid using the same C ID on multiple network <t>When using DTLS 1.3, peers <bcp14>SHOULD</bcp14> avoid using the same C ID on multiple network
paths, in particular when initiating connection migration or when probing a new paths, in particular when initiating connection migration or when probing a new
network path, as described in <xref target="path-validation"/>, as an adversary can otherwise network path, as described in <xref target="path-validation"/>, as an adversary can otherwise
correlate the communication interaction across those different paths. DTLS 1.3 correlate the communication interaction across those different paths. DTLS 1.3
provides mechanisms to ensure that a new CID can always be used. In provides mechanisms to ensure that a new CID can always be used. In
general, an endpoint should proactively send a RequestConnectionId message to as k for new general, an endpoint should proactively send a RequestConnectionId message to as k for new
CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold). CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).
Also, in case a peer might have exhausted available CIDs, a migrating endpoint Also, in case a peer might have exhausted available CIDs, a migrating endpoint
could include NewConnectionId in packets sent on the new path to make sure that could include NewConnectionId in packets sent on the new path to make sure that
the subsequent path validation can use fresh CIDs.</t> the subsequent path validation can use fresh CIDs.</t>
<t>Note that DTLS 1.2 does not offer the ability to request new CIDs durin g the session lifetime since CIDs have the same life-span <t>Note that DTLS 1.2 does not offer the ability to request new CIDs durin g the session lifetime since CIDs have the same lifespan
of the connection. Therefore, deployments that use DTLS in multihoming of the connection. Therefore, deployments that use DTLS in multihoming
environments <bcp14>SHOULD</bcp14> refuse to use CIDs with DTLS 1.2 environments <bcp14>SHOULD</bcp14> refuse to use CIDs with DTLS 1.2
and switch to DTLS 1.3 if the correlation privacy threat is a concern.</t> and switch to DTLS 1.3 if the correlation privacy threat is a concern.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with th is RFC number and remove this note.</cref></t>
<section anchor="new-tls-contenttype"> <section anchor="new-tls-contenttype">
<name>New TLS ContentType</name> <name>New TLS ContentType</name>
<t>IANA is requested to allocate an entry in the TLS <tt>ContentType</tt <t>IANA has allocated an entry in the "TLS ContentType" registry within
> registry within the "Transport Layer Security (TLS) Parameters" registry group the "Transport Layer Security (TLS) Parameters" registry group <xref target="IAN
<xref target="IANA.tls-parameters"/> for the <tt>return_routability_check(TBD2) A.tls-parameters"/> for the <tt>return_routability_check</tt> (27) message defin
</tt> message defined in this document. ed in this document.
IANA is requested to set the <tt>DTLS_OK</tt> column to <tt>Y</tt> and to add th IANA set the DTLS_OK column to "Y" and added the following note to the registry:
e following note prior to the table:</t> </t>
<ul empty="true"> <blockquote><t>Note: The return_routability_check content type is only applicabl
<li> e
<t>NOTE: The return_routability_check content type is only to DTLS 1.2 and 1.3.</t></blockquote>
applicable to DTLS 1.2 and 1.3.</t>
</li>
</ul>
</section> </section>
<section anchor="new-tls-extensiontype"> <section anchor="new-tls-extensiontype">
<name>New TLS ExtensionType</name> <name>New TLS ExtensionType</name>
<t>IANA is requested to allocate the extension code point (TBD1) for the <t>IANA has allocated the extension code point (61) for <tt>rrc</tt>
<tt>rrc</tt> in the "TLS ExtensionType Values" registry as described in
extension to the <tt>TLS ExtensionType Values</tt> registry as described in
<xref target="tbl-ext"/>.</t> <xref target="tbl-ext"/>.</t>
<table align="left" anchor="tbl-ext"> <table align="left" anchor="tbl-ext">
<name>rrc entry in the TLS ExtensionType Values registry</name> <name>New Entry in the TLS ExtensionType Values Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Extension Name</th> <th align="left">Extension Name</th>
<th align="left">TLS 1.3</th> <th align="left">TLS 1.3</th>
<th align="left">DTLS-Only</th> <th align="left">DTLS-Only</th>
<th align="left">Recommended</th> <th align="left">Recommended</th>
<th align="left">Reference</th> <th align="left">Reference</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD1</td> <td align="left">61</td>
<td align="left">rrc</td> <td align="left">rrc</td>
<td align="left">CH, SH</td> <td align="left">CH, SH</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">N</td> <td align="left">N</td>
<td align="left">RFCthis</td> <td align="left">RFC 9853</td>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="new-tls-rrc-message-type-registry"> <section anchor="new-tls-rrc-message-type-registry">
<name>New "TLS RRC Message Type" Registry</name> <name>New "TLS RRC Message Type" Registry</name>
<t>IANA is requested to create a new registry "TLS RRC Message Types" wi <t>IANA has created the "TLS RRC Message Types" registry within the "Tra
thin the Transport Layer Security (TLS) Parameters registry group <xref target=" nsport Layer Security (TLS) Parameters" registry group <xref target="IANA.tls-pa
IANA.tls-parameters"/>. rameters"/>.
This registry will be administered under the "Expert Review" policy (<xref secti This registration procedure is "Expert Review" (<xref section="4.5" sectionForma
on="4.5" sectionFormat="of" target="RFC8126"/>).</t> t="of" target="RFC8126"/>).</t>
<t>Follow the procedures in <xref section="16" sectionFormat="of" target <t>To submit registration requests, follow the procedures in <xref secti
="I-D.ietf-tls-rfc8447bis"/> to submit registration requests.</t> on="16" sectionFormat="of" target="RFC9847"/>.</t>
<t>Each entry in the registry must include the following fields:</t> <t>Each entry in the registry must include the following fields:</t>
<dl newline="true"> <dl newline="true">
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>
<t>A (decimal) number in the range 0 to 253</t> <t>A (decimal) number in the range 0 to 253.</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>A brief description of the RRC message</t> <t>A brief description of the RRC message.</t>
</dd> </dd>
<dt>DTLS-Only:</dt> <dt>DTLS-Only:</dt>
<dd> <dd>
<t>Whether the message applies only to DTLS. <t>Indication of whether the message only applies to DTLS.
Since RRC is only available in DTLS, this column will be set to <tt>Y</tt> for a Since RRC is only available in DTLS, this column is set to "Y" for all the initi
ll the current entries in this registry. al entries in this registry.
Future work may define new RRC Message Types that also apply to TLS.</t> Future work may define new RRC message types that also apply to TLS.</t>
</dd> </dd>
<dt>Recommended:</dt> <dt>Recommended:</dt>
<dd> <dd>
<t>Whether the message is recommended for implementations to support <t>Indication of whether the message is recommended for implementati
. ons to support.
The semantics for this field is defined in <xref section="5" sectionFormat="of" The semantics for this field is defined in <xref section="5" sectionFormat="of"
target="RFC8447"/> and updated in <xref section="3" sectionFormat="of" target="I target="RFC8447"/> and updated in <xref section="3" sectionFormat="of" target="R
-D.ietf-tls-rfc8447bis"/></t> FC9847"/>.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>A reference to a publicly available specification for the value</ t> <t>A reference to a publicly available specification for the value.< /t>
</dd> </dd>
<dt>Comment:</dt> <dt>Comment:</dt>
<dd> <dd>
<t>Any relevant notes or comments that relate to this entry</t> <t>Any relevant notes or comments that relate to this entry.</t>
</dd> </dd>
</dl> </dl>
<t>The initial state of this sub-registry is as follows:</t> <t><xref target="tbl-rrc-mt"/> shows the initial contents of this regist ry:</t>
<table align="left" anchor="tbl-rrc-mt"> <table align="left" anchor="tbl-rrc-mt">
<name>Initial Entries in TLS RRC Message Type registry</name> <name>Initial Entries in TLS RRC Message Type Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">DTLS-Only</th> <th align="left">DTLS-Only</th>
<th align="left">Recommended</th> <th align="left">Recommended</th>
<th align="left">Reference</th> <th align="left">Reference</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">path_challenge</td> <td align="left">path_challenge</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">RFCthis</td> <td align="left">RFC 9853</td>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">path_response</td> <td align="left">path_response</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">RFCthis</td> <td align="left">RFC 9853</td>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">path_drop</td> <td align="left">path_drop</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">RFCthis</td> <td align="left">RFC 9853</td>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">3-253</td> <td align="left">3-253</td>
<td align="left">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">254-255</td> <td align="left">254-255</td>
<td align="left">Reserved for Private Use</td> <td align="left">Reserved for Private Use</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left"> </td> <td align="left"/>
<td align="left">RFCthis</td> <td align="left">RFC 9853</td>
<td align="left"> </td> <td align="left"/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>IANA is requested to add the following note for additional informatio <t>IANA added the following note to provide additional information regar
n regarding the use of RRC message codepoints in experiments:</t> ding the use of RRC message codepoints in experiments:</t>
<dl>
<dt>Note:</dt> <blockquote><t>Note: As specified in <xref target="RFC8126"/>, assignments
<dd> made in the Private Use space are not generally useful for broad
<t>As specified in <xref target="RFC8126"/>, assignments made in the interoperability. Those making use of the Private Use range are responsible
Private Use space are not generally useful for broad interoperability. for ensuring that no conflicts occur within the intended scope of use. For
Those making use of the Private Use range are responsible for ensuring that no c widespread experiments, provisional registrations (<xref section="4.13"
onflicts occur within the intended scope of use. sectionFormat="of" target="RFC8126"/>) are available.</t></blockquote>
For widespread experiments, provisional registrations (<xref section="4.13" sect
ionFormat="of" target="RFC8126"/>) are available.</t>
</dd>
</dl>
<section anchor="designated-expert-instructions"> <section anchor="designated-expert-instructions">
<name>Designated Expert Instructions</name> <name>Designated Expert Instructions</name>
<t>To enable a broadly informed review of registration decisions, it i <t>To enable a broadly informed review of registration decisions, it i
s recommended that multiple Designated Experts be appointed who are able to repr s recommended that multiple designated experts be appointed to represent the per
esent the perspectives of both the transport and security areas.</t> spectives of both the transport and security areas.</t>
<t>In cases where a registration decision could be perceived as creati <t>In cases where a registration decision could be perceived as creati
ng a conflict of interest for a particular Expert, that Expert <bcp14>SHOULD</bc ng a conflict of interest for a particular expert, that expert <bcp14>SHOULD</bc
p14> defer to the judgment of the other Experts.</t> p14> defer to the judgment of the other experts.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>We would like to thank
Colin Perkins,
Deb Cooley,
Eric Rescorla,
Éric Vyncke,
Erik Kline,
Hanno Becker,
<contact fullname="Hanno Böck"/>,
Joe Clarke,
<contact fullname="Manuel Pégourié-Gonnard"/>,
Marco Tiloca,
Martin Thomson,
Mike Bishop,
Mike Ounsworth,
Mohamed Boucadair,
Mohit Sahni,
Rich Salz,
Russ Housley,
Sean Turner, and
Yaron Sheffer
for their input to this document.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-uta-tls13-iot-profile" to="IOT-PROFILE"/>
<displayreference target="I-D.irtf-t2trg-amplification-attacks" to="AMP-ATTACKS"
/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9146"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 146.xml"/>
<title>Connection Identifier for DTLS 1.2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="E. Rescorla" initials="E." role="editor" surname=" 147.xml"/>
Rescorla"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="H. Tschofenig" initials="H." role="editor" surname 119.xml"/>
="Tschofenig"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="T. Fossati" initials="T." surname="Fossati"/> 174.xml"/>
<author fullname="A. Kraus" initials="A." surname="Kraus"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="March" year="2022"/> 446.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>This document specifies the Connection ID (CID) construct for t 347.xml"/>
he Datagram Transport Layer Security (DTLS) protocol version 1.2.</t>
<t>A CID is an identifier carried in the record layer header that
gives the recipient additional information for selecting the appropriate securit
y association. In "classical" DTLS, selecting a security association of an incom
ing DTLS record is accomplished with the help of the 5-tuple. If the source IP a
ddress and/or source port changes during the lifetime of an ongoing DTLS session
, then the receiver will be unable to locate the correct security context.</t>
<t>The new ciphertext record format with the CID also provides con
tent type encryption and record layer padding.</t>
<t>This document updates RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9146"/>
<seriesInfo name="DOI" value="10.17487/RFC9146"/>
</reference>
<reference anchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="January" year="2012"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privacy
for datagram protocols. The protocol allows client/server applications to commu
nicate in a way that is designed to prevent eavesdropping, tampering, or message
forgery. The DTLS protocol is based on the Transport Layer Security (TLS) proto
col and provides equivalent security guarantees. Datagram semantics of the under
lying transport are preserved by the DTLS protocol. This document updates DTLS 1
.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="IANA.tls-parameters" target="https://www.iana.org/ass ignments/tls-parameters"> <reference anchor="IANA.tls-parameters" target="https://www.iana.org/ass ignments/tls-parameters">
<front> <front>
<title>Transport Layer Security (TLS) Parameters</title> <title>Transport Layer Security (TLS) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="RFC8126"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 126.xml"/>
<title>Guidelines for Writing an IANA Considerations Section in RFCs <!-- [I-D.ietf-tls-rfc8447bis]
</title> companion doc RFC 9847
<author fullname="M. Cotton" initials="M." surname="Cotton"/> draft-ietf-tls-rfc8447bis-15
<author fullname="B. Leiba" initials="B." surname="Leiba"/> AUTH48 as of 12/16/25
<author fullname="T. Narten" initials="T." surname="Narten"/> -->
<date month="June" year="2017"/> <reference anchor="RFC9847" target="https://www.rfc-editor.org/info/rfc9847">
<abstract> <front>
<t>Many protocols make use of points of extensibility that use con <title>IANA Registry Updates for TLS and DTLS</title>
stants to identify various protocol parameters. To ensure that the values in the <author initials="J." surname="Salowey" fullname="Joseph A. Salowey">
se fields do not have conflicting uses and to promote interoperability, their al <organization>Venafi</organization>
locations are often coordinated by a central record keeper. For IETF protocols, </author>
that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <author initials="S." surname="Turner" fullname="Sean Turner">
<t>To make assignments in a given registry prudently, guidance des <organization>sn3rd</organization>
cribing the conditions under which new values should be assigned, as well as whe </author>
n and how modifications to existing values can be made, is needed. This document <date month='December' year='2025'/>
defines a framework for the documentation of these guidelines by specification </front>
authors, in order to assure that the provided guidance for the IANA Consideratio <seriesInfo name="RFC" value="9847"/>
ns is clear and addresses the various issues that are likely in the operation of <seriesInfo name="DOI" value="10.17487/RFC9847"/>
a registry.</t> </reference>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="I-D.ietf-tls-rfc8447bis">
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<author fullname="Joseph A. Salowey" initials="J. A." surname="Salow
ey">
<organization>Venafi</organization>
</author>
<author fullname="Sean Turner" initials="S." surname="Turner">
<organization>sn3rd</organization>
</author>
<date day="16" month="June" year="2025"/>
<abstract>
<t> This document updates the changes to TLS and DTLS IANA regis
tries
made in RFC 8447. It adds a new value "D" for discouraged to the
Recommended column of the selected TLS registries and adds a
"Comment" column to all active registries that do not already have a
"Comment" column. Finally, it updates the registration request
instructions.
This document updates RFC 8447.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 447.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8447bis-14"
/>
</reference>
<reference anchor="RFC8447">
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="August" year="2018"/>
<abstract>
<t>This document describes a number of changes to TLS and DTLS IAN
A registries that range from adding notes to the registry all the way to changin
g the registration policy. These changes were mostly motivated by WG review of t
he TLS- and DTLS-related registries undertaken as part of the TLS 1.3 developmen
t process.</t>
<t>This document updates the following RFCs: 3749, 5077, 4680, 524
6, 5705, 5878, 6520, and 7301.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8447"/>
<seriesInfo name="DOI" value="10.17487/RFC8447"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC9000"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 000.xml"/>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="J. Iyengar" initials="J." role="editor" surname="I 175.xml"/>
yengar"/> <!-- [I-D.ietf-uta-tls13-iot-profile]
<author fullname="M. Thomson" initials="M." role="editor" surname="T draft-ietf-uta-tls13-iot-profile-15
homson"/> IESG State: I-D Exists as of 12/16/25
<date month="May" year="2021"/> -->
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<t>This document defines the core of the QUIC transport protocol. ietf-uta-tls13-iot-profile.xml"/>
QUIC provides applications with flow-controlled streams for structured communica <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
tion, low-latency connection establishment, and network path migration. QUIC inc 086.xml"/>
ludes security measures that ensure confidentiality, integrity, and availability <!-- [I-D.irtf-t2trg-amplification-attacks]
in a range of deployment circumstances. Accompanying documents describe the int draft-irtf-t2trg-amplification-attacks-05
egration of TLS for key negotiation, loss detection, and an exemplary congestion IESG State: Expired as of 12/22/25
control algorithm.</t> Long Way for author name
</abstract> -->
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9175">
<front>
<title>Constrained Application Protocol (CoAP): Echo, Request-Tag, a
nd Token Processing</title>
<author fullname="C. Amsüss" initials="C." surname="Amsüss"/>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<date month="February" year="2022"/>
<abstract>
<t>This document specifies enhancements to the Constrained Applica
tion Protocol (CoAP) that mitigate security issues in particular use cases. The
Echo option enables a CoAP server to verify the freshness of a request or to for
ce a client to demonstrate reachability at its claimed network address. The Requ
est-Tag option allows the CoAP server to match block-wise message fragments belo
nging to the same request. This document updates RFC 7252 with respect to the fo
llowing: processing requirements for client Tokens, forbidding non-secure reuse
of Tokens to ensure response-to-request binding when CoAP is used with a securit
y protocol, and amplification mitigation (where the use of the Echo option is no
w recommended).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9175"/>
<seriesInfo name="DOI" value="10.17487/RFC9175"/>
</reference>
<reference anchor="I-D.ietf-uta-tls13-iot-profile">
<front>
<title>TLS/DTLS 1.3 Profiles for the Internet of Things</title>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofen
ig">
<organization>University of Applied Sciences Bonn-Rhein-Sieg</orga
nization>
</author>
<author fullname="Thomas Fossati" initials="T." surname="Fossati">
<organization>Linaro</organization>
</author>
<author fullname="Michael Richardson" initials="M." surname="Richard
son">
<organization>Sandelman Software Works</organization>
</author>
<date day="5" month="May" year="2025"/>
<abstract>
<t> RFC 7925 offers guidance to developers on using TLS/DTLS 1.2
for
Internet of Things (IoT) devices with resource constraints. This
document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles
for IoT devices. Additionally, it updates RFC 7925 with respect to
the X.509 certificate profile and ciphersuite requirements.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/thomas-fossati/draft-tls13-iot.
</t> <reference anchor="I-D.irtf-t2trg-amplification-attacks" target="https://datatra
</abstract> cker.ietf.org/doc/html/draft-irtf-t2trg-amplification-attacks-05">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-prof <title>
ile-14"/> Amplification Attacks Using the Constrained Application Protocol (CoAP)
</reference> </title>
<reference anchor="RFC4086"> <author fullname="John Preuß Mattsson" initials="J." surname="Preuß Mattsson">
<front> <organization>Ericsson AB</organization>
<title>Randomness Requirements for Security</title> </author>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3 <author fullname="Göran Selander" initials="G." surname="Selander">
rd"/> <organization>Ericsson AB</organization>
<author fullname="J. Schiller" initials="J." surname="Schiller"/> </author>
<author fullname="S. Crocker" initials="S." surname="Crocker"/> <author fullname="Christian Amsüss" initials="C." surname="Amsüss">
<date month="June" year="2005"/> <organization>Energy Harvesting Solutions</organization>
<abstract> </author>
<t>Security systems are built on strong cryptographic algorithms t <date day="18" month="June" year="2025"/>
hat foil pattern analysis attempts. However, the security of these systems is de </front>
pendent on generating secret quantities for passwords, cryptographic keys, and s <seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-amplification-attacks-
imilar quantities. The use of pseudo-random processes to generate secret quantit 05"/>
ies can result in pseudo-security. A sophisticated attacker may find it easier t </reference>
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="I-D.irtf-t2trg-amplification-attacks">
<front>
<title>Amplification Attacks Using the Constrained Application Proto
col (CoAP)</title>
<author fullname="John Preuß Mattsson" initials="J. P." surname="Mat
tsson">
<organization>Ericsson AB</organization>
</author>
<author fullname="Göran Selander" initials="G." surname="Selander">
<organization>Ericsson AB</organization>
</author>
<author fullname="Christian Amsüss" initials="C." surname="Amsüss">
<organization>Energy Harvesting Solutions</organization>
</author>
<date day="18" month="June" year="2025"/>
<abstract>
<t> Protecting Internet of Things (IoT) devices against attacks
is not
enough. IoT deployments need to make sure that they are not used for
Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are
typically done with compromised devices or with amplification attacks
using a spoofed source address. This document gives examples of
different theoretical amplification attacks using the Constrained
Application Protocol (CoAP). The goal with this document is to raise
awareness and to motivate generic and protocol-specific
recommendations on the usage of CoAP. Some of the discussed attacks
can be mitigated by not using NoSec or by using the Echo option.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-amplificatio
n-attacks-05"/>
</reference>
</references> </references>
</references> </references>
<?line 816?>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>We would like to thank
<contact fullname="Colin Perkins"/>,
<contact fullname="Deb Cooley"/>,
<contact fullname="Eric Rescorla"/>,
<contact fullname="Éric Vyncke"/>,
<contact fullname="Erik Kline"/>,
<contact fullname="Hanno Becker"/>,
<contact fullname="Hanno Böck"/>,
<contact fullname="Joe Clarke"/>,
<contact fullname="Manuel Pégourié-Gonnard"/>,
<contact fullname="Marco Tiloca"/>,
<contact fullname="Martin Thomson"/>,
<contact fullname="Mike Bishop"/>,
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Mohamed Boucadair"/>,
<contact fullname="Mohit Sahni"/>,
<contact fullname="Rich Salz"/>,
<contact fullname="Russ Housley"/>,
<contact fullname="Sean Turner"/>, and
<contact fullname="Yaron Sheffer"/>
for their input to this document.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+V963IbR5bm/3yKWjpiRdoALFJy203fhpKoFrd1G5HqXq/D
LRWAJFCjQhWmskAKTar/71vM33mBfYDpF9vznXMyK6tQoCi7d3YjFhG2iEJW
Xs/9lsPh0FwcJveMqbM6t4fJK1uvqiJ5Va7qdJzlWb1OHs7t5F1yXlbJo7On
p8n+6CBJi6n/cs+k43FlqRN+sO19My0nRbqgEaZVel4PM1ufD+vcDaf4X1VN
hgd3zSSt7ays1oeJq6dmUhbOFm7lDpO6WlnjVuNF5lxWFvV6SR2dHJ89Nqvl
lF6iJr/fv/+7Af7/tTHZsuJ3XH1w9+7v7x6YtLLpYXJqJ6uKZmQuy+rdrCpX
y8OE5mze2TU9mcoKBsmrVw8HycOTR8a4mhb6Js3LgoZbW2eW2aFJkup8Yqeu
Xuf6NEnqchL9mRVTW9T+gSururLnLnxfL1pf6yqbhMaTcrGgd8OvWZFnRRiG
9nCRLpdZMZMnJl3V87LCnIbUlN56MkrO3GRentsim9HjJJFNf5IWhXXd38qK
OnpdZBe2cjip8jw5Wi7zzE6T00lmiwm98qAsiuGruc2K4Wlm5T1/4k+GD16d
8pOqxGbYaVaXFT+wizTL/bijZtx/mi3ejwpbN1M+GiV/rNKVi2Z7NJlni+ip
dpbi8Ts83ezlbJQ8Lp1L6yzq52xeLlLX+oGWnBbZX+lrWRwmT7Mircp4jJpf
GZ3LK/+Uc4MRvWUMnQttEjb79Pjp48Nk59Xjh/U8czvGDIdD2hQ6ynRSG3NG
D3FWKxxl4pZ2kp1ntJVpUgl2VBF2TAJ2rZyltRAIFLV9X+Mw6rk1D2n/7QTT
TU4eJbsEl3toQmOtJjW/R62SR2mdzqp0kZxVaeGWBHLJ03RtqwDzyS6Ae88s
q5IgtMwTPnPqJ+AzofLImJPFMreYN++Qo1mc24oAjkehwZPzVcGzSXn2U+sm
VTYmgKGZ034wGnJ3+uXrhHAvIVAqV1U6o3Z1maS5KxOayEU2tdzv9m3ZPlgd
b/LIPOaNoEeE6a4sBu3fEyUT/VMcyQEusuk0t8Z8lpwUdVVOVzy0MUdJ3xlQ
72mRZMB0nG6VTNKqyvzcsKYJ0ZQk51OY23RK/9CRpkImp3pepp6ndTIjDHT+
LQt0TNIp4RKvnDqkU17wefB5O5tjMnomRA+qcllltDzj/GErDI0SQgE5toWd
zAnw3SKZE0aMrS0CYPKUr67+C20HtubDB4xiWrQ+bvC1NAj0n3bv6upUt+d3
WGPUkz8yl8zLS54voJzaYE5ZMcFp6dLTuk6JT7hVdZ5OuE1rCjRSMl4r2GDx
47KeJ2UxXKb0L1oQqOoX7ongGydULoENqwLbgnXtPtp7VJ7SzpzUAojNFDEL
V9ul86dE21pMsiWdwYJ4SVKn72xyOaetS40e72WG8WQ1zp8eATlOFRudEvlf
VbQcOs/KOoLIDAhFQGPOq3LBQxJ3Sejc8DBfJ6lzxEHoNLVzxm5MZhKAkCb/
pLy0BCYDJhFEdFaYYzhiHA84pyIuzQW9FPYyWVqBLZ4Lzfgyy3NuVPrJG2wl
7fIELXhgWSo3z+05EaalxRTOytARep+lyy7STe15VjDdE6nAbEoVu8Rs9xLi
7MNAmDYEDZw80fhlVtGeEAhgND7nCyILU8ELnvB0RaRGBlWQ9WD5DXVFAAW4
vHv37ocPI3PkaNTJfBudaKEDJhGD/wgk/gaqRR0ubQWkbSYsu4uttsV0WWY0
1thSEytE/uTR0G/mmMQHtKNeZDZKUugU/at3aPKWJSGCV2oxEpbDCymYidCB
0UHTqYK0bJsAQdQ5CNjEmgAkJHHx6Awo6JNoDsEXyCpB1zgHnkrDNlxj0pNm
srbBBU/qhEaDZub5CqyST0a4HOFKMXVz4Bc223caH/AchGJA87N0FiXB/kVm
L/ksrq4qO1vlaUVHxd3FB2rfL/OUoIdHIXYyTZm5xdjCa0+zhRMsILovO/aI
6ITSkkSpEsFNoMv5eiBAZgvqiKDvw4cBgfoCZ5pOL/hR30qagTHPzE1Wztmp
HmH7R+uyWSE8k/gnkXTIF310rq7WisW0Wpn+gtgEuIqnkASH9DYfLV6qnRKG
KpvNIppQWQ9/es6eI9EECZpoK2mNU1uTsEQTo/2k4SEl4w09Sz8t2oqpzQc0
JRB56uhcQPLqyrfg4ztapiStMDWkDjKamApC6CsShvpwRNF1YPpowiRderxk
KUaQkQgO/VIQ9mGcKZaZFoSj2cLiZ0s011YBRyBVVobgp8Z5DgC+AX0W2Wxe
82TRJ86IsV/AKSCQqwneW+hjsMY8JYbyrigvi7D1pBbhIEA7shLsLPnXFYmN
EyDoCGIJiSEXEDcglwFNzmy1yIoyL2droUikyCSXTKt3nr0+PdsZyL/J8xf8
96vjf3598ur4Ef4+fXL09Gn4w2iL0ycvXj991PzVvPnwxbNnx88fycv0NGk9
MjvPjn7aGfCsdl68PDt58fzo6c6GmMayIG3UGOdLi10SCcURONMS7R48fPkf
/7Z/X2nuwf7+7wmz5cs3+1/fpy9gwjJaWRDPlK90cGtD4pBNK/RCGAoQyAjZ
iW4QL3Zz7DadLnbz85+xM78cJt+NJ8v9+z/oAyy49dDvWesh79nmk42XZRN7
HvUME3az9byz0+35Hv3U+u73PXr43Y9QH5Ph/jc//mC6iglJGvSHI/q+ICxJ
WXAMIgeL+ix2JioQCHf27LUlIm5wy1g+bLNOkUjp4J3XMQgVitmKdAPD+LgB
M0IIG+houPp9L2x+cx8jQ3vpvMxAkRCkLZKdlDBnmJJ6QzLvREfOFlm9Q0Q3
ZQZREW8BHVB5dAGSiyHAwRp+xpSK6MCqUFrTkHnPh4tJvppC8CEQbIlQJVFb
0ihZeFf5jza4zUoHxLPwvshupbNemiRGznI7eEZK/N3zjPMyz8tL5+UiWi2z
1aurH4O8M4CakDOPIImUVk3cErR1Ypc1EBKTVKlGN0vmsiO73yNR7YtE9WMk
UoXXifxM8oy2H7TCEae2Ff4CRdwREuFp6A5ThC0D7KvIFk73Mya0x+9rkm1Z
Mztr9An8QnMt7KysRXq+yFLekrdVNXlLe6pvjfitzkO8ypQkAu9+a9fIvCiC
KF7MwPFlrYQ6bq5M2POEAAg988BqwQge8ttPLJ3hyJycqxCGPcOkmIflvMKF
tar0saZBvKGyAuMZxDNS+kmEUoXEbBnslDuWwQQT34Y2b2BVewsGurJqV8ic
aW3R2YNH+7wbdftNIMjbhFTJfBoksNaLdrGs1yQ8+b1qWRW6c2U6zKoZN5M2
jfbzJpvGrWPaEzZQh/nE/U/GK5raIqvdzWMO4kPyXMMPdtNY8fZv24ytC1XO
0d2Y9kgDIku5V8mA857UrRxGYCiGXorZxLJHn3wqmKKTxKl3V+zBXIdkhdxl
2G8mVqRfQYk8X5GoDJpGvcIA1JmxA2ILZmMM8J0Tlg3ylKQaPObFirWlaNTE
SH4vvbrVVm+jNYGCmknpbVuyPTut1iJK7rQ0yV6uAxOHaUAuSU7FjjIRlYDt
A7wVWMrVVZsxYj2BkpvWDkWky1v1VMkjDD9n42FjcugzOBgcbI9qpmI5iZF5
yVDw+tHLoJU1BglhSJfgNYT3NxkkqAXGZ0oxaJutFEj9eXiLp9lUktMNtg75
fdgcGriWQhYdfQTLQzVcTcyN2pUK+arg8CCutuk02bWj2WhA0vTRy+R4Mi89
p9z/+qsPH/aEz2zzgjyj4UhUSc6IVrquQOXtHYKX3MWbaOFveOFvRaeh5qC3
Zvfq6jybsQNk4WY0PisSaVWtt09iIZNwynIBUy0LCszDmav15CHV6Bs8pDtM
3mKraToEsZZw8u1AnwgXcfYtG4Hk2bQql29VqalUZwJ8drUtIRC5IknndE3P
6dLsj0kpCnMT+ymsRQ/L8l0mytY3w/G6tspasHGkgAKEf3efdEBZoYWxdrn2
x1qO0cbLaSzKnr589fwPMnO1xoAMZi1Lt7csHJH+QLrl++ShyB+NeLmn233D
yfqlMIUk2IN7BgqbGEawQ4SE1XpJ34wQZGZWDarR5oFwds24xvztb39L4Cgj
GDG2WC2SK3ZaZCKD7t7dG/B3obFvJtmS1Jw3wJPdA/9bmtuq3j3Y16/B4rJ7
cOBbNDjGLH334J5vTDpVPbYpvX9/b5AkX37OxvPffXVwN/n8S25Cs9s/oJGn
uwdfRU3ELRdEKRay9I1t+7hLYgZNCT08P/6zb03dfrVnPkAJBvYAAb81ZkVC
JMGCQMy3Jt6bNoyHLWoB+u5+/BSgvus3w49HmPmGdp2lo2/hEmS/iwwR/5Y0
jfCToEKyu22RI998T/vi44OdpD3vw7C2zUZ+FYfJDY2wqEN5GDf68C3WtmVy
3wLezNVh8llEmwiAslnx/Q5swDvogz3G3+98lFYyW1eah2Pb+WDM41UNFttI
ASB7dR8xW5AYIISVDdgtSjbacFcFzIPQDMEgrZzMoDFViU7IdBGjtXqMdZGO
h+mkCE6ZQYd43DQuMdmJFQ5P2wfjoCffKqtDkxRD0FsPE2+ZCb0Ehf1TQ2Ff
Bsnk6rMuNYWXKjBhJtblmMU1VQtJ0rnjgkQgZEIm7epy6a2+Bpaw8UqNZbH4
CHJAtLUSlZn7ZK3YMSOTo4sU4sCZ9adtujftKncG0S5j4ce7wfpN66NNlhuc
N5dl8i6DCkRUmxsToxunLpsku5GFeE/JsJhs8VNjvt1TiXdeZuKAgjFdRbGS
zYJTC+4AXRFyHj/iH7sW2QRWu7TKyq6M41uSOJg5NYUxu55iy0dmFxOYknjD
Ij8PAwMBrOV2thYjYwmbgJ/JgpgdgVZZBKim9mp4JXXGEPqIysA2t3OS2Hjd
xAdlRX5wgWOSZo/f45wsbyNBeSqeRvgAysoZVXIO1aEktukFHd4ig9G2hRWJ
CNzv6fQGcKVdpJO1GB2qwg28Hml8L5HlnY2xmTjceJccoQqJCtg51Vv1kLC8
sQ323dSZVNwas5V3MCxFAyi997HyAvGmEDDaIzxiK+zNPiYo5rw2AvUBm4+X
6jYBIsFBpoOTIE1osFrICtHpuFzBnBZpHuzBYHwORH9I6r0Ljif+zdN6/1Oe
OW+fD5YAx1Y5PFRsYn/L1BsHaEiEadDWj6vyHQxJIDo018a6x14WmtBLMdkX
ZW0b/6Ea7bDN+awkAWW+cCwTUrOWrwKiRQ7wcGgcPAo0cDayo+iB9I0zLCck
8hCwZ7CQy85ncFNjTxszm1i6xIpFs7nIylXksVDtP4P6CSnOJbvUIYGNm5cr
Eh8rmmuuQ+2J3tIRewMvAIkhvrnE8TL96lEp2VBIBCpAcmgFpypvCnwM4sKD
us/+1w5McVPiSlUtiiPaMGGNlDv4SIDBzWmoc8ReiPmAduP50ZluhEx4GwDw
eKyANnofHGlBS8QEDztdyCQtTsavYaBnJRDY6l0cHmjOpBEmocKKkv+AyfHV
Z54ai0AtRHqrNxWYVmU+SqABAfbUHxqzP0rOYhV0F0DW2YW9BJEGNWsXt5Df
ScGHfAOprqsqiTUcTjanTI8AcZpNaub8E5aw4NwQbNcOR36SEXzFnFN59ZS3
N7iD4AhlMKuSs2SXNhSTurriJ0Ohf+Bn7GMiAAKg6DBMXqJ9CCeEfSD1oySh
ZDkXiwUCgSQ8KfbaYqh/wEYFsyQ8a5iyV3lkn8TWCF/NrceLBwt4ywv/M/Cn
Dbi6mo9p5Bjcj7BtCF5OtFXAwtprpM67zmtdGdtkfSyBF8AwTMeByRMnqnUG
PzVR8aZxtyUbt8u6oSfAp2Mvxlx9FqQYwakg4Pz/jFaeRQDIQXIbD4vwhUlZ
BQCVVzA/UCwRNNq+/gYXG4zzVoM2TvpTDUJEcAM38WyD5qT/LyPqCL9gF9OJ
l5RgNktZQuiXd3lRJGuWq9lc9zI6luQyjSyTFQIrFUOWHAMAQY1ZQoLozXif
btkl4mt8T6ys3xL6+hHbq27SA6FWsvvcc9pBY0UKR3OHo3tgW4GxZtBZWIhG
88yPH0xKBJJN7Y2cm6TP37AjRZnkZTFjae437o2Y/Db3JdqYDuPn8DgWK7we
B951UeYroo/VWtayyGZeLI4ClKD6+i5xsIovzXI2AYekdFoY6eMarAFjR4RP
YDSKJV0+08zaNdSjh19sEvvbc5AWT4hIUMQeRhG+OUU1sUwaNur5+YiMBgGJ
V95CfD/eoQANc7/fhAcxQDHktHkpgwPWlhUrmzTWy+1EVsha4bU37rJUxVEl
YVHwJGbJI82tuN9vWrPA923W2/Vj9PBRPZZYhIsY/aDHzxFsEb+e+yc+0CGA
fhtw/lMmTxLIf/wbG6keemaSvIq1UTVTddRaYz7voN2zo59EcV6s8jojtfoW
R+r8mdJ8N4QJdqFAjRdHBcLdiJo459dL+u5YaTVA6fOEHREb3agza1aK5NFo
THUIstdYuhZtFHP4XMN2OzYRKLs4SSaWQCdSyZPyIjBWdKfpCRLMOV6H/pph
Oaqc+YXsJf+iyTHYGLeiE/3XFea6saqwgbq8MQ/LmjuPNLUSlS0ElMVIdIn9
u2mzWr4PpYGkchdT4p/QaOVdgtuZLWzlBaBitRiLRWZnTGtfLXdumHAkjXTc
2ySHZZinKxeWTRIchYnsoYw9KnR6OQFEAQNU6h1BYgV1ni8ov0XIOLiKG0k0
EWy6zuom9HkhWxaYrvYNJySDdrp9x2ARYzNMBdvQsK6ypVjAdl+dne0NCOk/
bkbtQ6kVuwCmEigZ6LV6kf0Pjb80vUiznMXtrKCzCuFbu5oA4H046uJWD7Qt
8ErgTj58eEobwuxtj6Zvko8tgE3mQEp4usNhPDt7ney+pP/vBY+4EKi2UJ1O
EMaEaYhWxCTplfK1Lx8Rse8lS22LmqdKjUwTwhymltAtrAwRoAQDGUScLgvl
3KeYxzSe2t7eGTLsexIE2IS7yZNp1T3d0SAc4Q88FJ67AVscEuTNR9vH7rOB
6U63vL9ly74FmZjm0MikjSKFHdqYTMxp2XzLcONWVSRcRafaKEkAOw6lCODk
ekCdV5Pl4kLV4Dg2yqp39OPH1OwWrLGNkAv30BSyJCh2w1EAkjwQ6Pa6EcyQ
UmW9kVqkeBMZx1IOPCE+UnZ7EOzkvEOaiporvSQdWd1MnzVagP6MddOHYhW/
+qylkBrDkpKzNdvyzzbdVyCZRBjxxWevtOS0Cc+IeVZqVC4n4iTkkiUICWzM
JQZTR3KgFJLhIEZzuPuqbkpTOiYmz52gRx9DzsqV4cEj/dgrVHubS1BuBqJ3
lnyf3HtPvWE25xw41GbCCJQhufQyZY+KRAy05kRSDgGRJ5nNvIx66MUEehax
UFoy+toHAL2syvMMLhTO1vJsgrhXXq4lKaG4yKqyEHI0HAo2i99loMl9HMNg
ClsjVxX5KD+eDB+NOGuWRCJkzu7fG2ZlDUcpBvvwAR2xJMUDrhGm7wWWAfND
41aZ2FOaGL8z9jSqz4fgJiRWwCkB528IE6ABEEDNwTg61yifDYyiyeHICiUO
aRw+lvoAsv6wJ3rMqVo8L8Z67D3YjA+casWMwUOtzm4J4Utu/5E4PGP+aNdJ
8pc4BNAcv6dpXydfIJb+Da2msjIKHsHDkcJv/aZxgDS/VtVEvlzQl1YU3/cc
/mi2Tkc+Q/388LGGWxckQYy0IFrXp3fyRdKsGSvCTnxCL90179+9S738irX4
7mg/aS9v3cHVsQ+tCQHC7gM2w5/2rYe+emirWgQUC8HBuvoDTpUEiyr1J/4J
n7g/zOgTOohf/RPsEesPOJqjVf3Ro/nOw1Pc3WNiKm5up1iPkR7+0p6fQd80
RM/IHrrjXuLPBgD/fBRFECBD+Zf21H7oa2I6C/sClh7JLWM+bIkg1vN1HDri
JNbXq8HtT2SfwNvTxnjcaXv1IRoo6BxwjRJQI9eJmTShSA8EEH+PcgOSnyFc
2eqXN4EkviGKfk67+cZBu6o3Bv/5l3/Q4GHoOJirPfib56NWfE9DtzWixwfu
PM7LS6bGj1c+keGJb4sgnhdQXNII75vcYsIZ4jQMJcK5Iz4gegLjpI8KbsWa
LNN1XqbTePmkrfHwmm67KjKocxWbxaHOIYGyxygS4sAlYF780RqfD8YCGnUu
dj+kZ5jYeSAzhO+1FrVSkr5CXtpiQbOYeHumpOaF2PAQVCyqponm4rXOVFy1
afEuRMlgSivsvA8wb4cBQkEPaVOxLpe5NkvNSwk41GBHXUknaVh5cZBKCfB8
p5yq5hPnWqdXc+B45KUceTkBQWIqFgRJoRncC7Piut9hj++O8nTZELMrnpQo
UEdSXgMguY/MzKuHzcwaEeGTJYQO19igpB//yCsez7tkLm75vX483fyO4ADs
038/pa09efn9kX595Gp8/R+3YCPf+a79g+40fi171indZg69H13DUZcMdj/f
BS4mDONjstF332FywFb+3K49VKdPaf+UFcFbtu/O/x8IEA+6APFpp/EdLeZ1
oV6OaXLy8tMP80jJ3APsxG3gsZFJttYJ+qQJdGJ8xbuy96ug8jeBtB7BA78J
W2Nik00xqR2Q3F7CP+6kT142p/XpS/yTh5IIgm8c8f9xwvNgI8DZq7QiAt3Z
eaAsavMgVVm+8wGa8wsf6pfmiHGOQinZKvO0nM3A846KcpHmiFY7hueXfvS/
aOpiCBl0YGWs/VqNZVWHhaZ2SFKL2tBF+iGmH+yjiG/ktzaMHmzORqp9NgGD
HWgpGRUxWgYZGCXZQb1IC5JG2GSxe3py/EyCZ+uqXI1zSzy+ZIa+XFXLkosz
ZLVYZauymCGdYXqROW9P6tpraDUcIY8CFpmjWTm1BMFytyoagaazP+yUoqWu
1ShVWY1LDIsZVja3FynsLLzZYq/WV9QPL4JkXUMz5+gkpBj54N26FIkOxpMm
I9rCNl8OYTYVx9EJr5aDa3mlPvY7L2eJrxjgTWDBs+URnWUu5OLSTvWFw1SN
p1dXzEGnWLFbzWYQ1uCpaAce+xWpFQ58cCJlM+oQvymOjPNK3UP8Npveffe+
kgfHWJa0pkWzB67uiF+yE5r13IBQXGABuylVktZilXVu5YPfJdSHcEZyk70m
cYERIDlmEzVvPuPaTOPyvSQHsllrYo05ZbdPcLbBDBVSbNSbdsd5OZldwMj0
Xaa0eDb9aXEMdYBWbhCnBIhdNIOkbyXO2U8iiyYh4BXlV3KW8IkU8qpSV0fp
L63OQ04VrMuXFWJWQ/WUtyGd5q2fveY3ZUUkVwMgVQIOJnLvQlHJO0orTJO/
2qocAsQkhXBPTLo3xza08tUwPBdUSaCRDIhCvFMr6YLg0sERkykatPZIJ89B
tUr2tvr59nx81qVYnTM2n7MhlravXRIszetyxoFJHLtfcUmdQXwkkofdTube
cpDAZh+g7okZNh8l+aYCyeLu0upVm74J4gih4FqXHXRjZ/pd8shtYIBQ5TdJ
UXOFsP08L0utskLqZFZNh0zM4b/slF3JQtEXTyub34CYCKzDlNU/sW0eqpSS
0pVrnBrIqYzGGQiaQcpYYjbD1VrJb3ukfr7wtbqmwLSUk/1oPgzSwSkMTpKk
Zp5WCyl701AEseZ7OAiAA/V95aycHYf78CbD6RTZfpraEoQZ6cLGVguARHDz
BD4lzkpiL/D+6WmgtSqqoQjF6KtQqUCro0nYftOAwG4UCqP97h7a7A1aHCew
MoyVbkQNbQtTjxIi5ah4lX4XQLBcjoxX9eT7/eJoBgnK0YIFGnLfKeBzx0m2
CQeqnpU8LSYERO6FUMpQTuK/iOC/Ib7i5vn6jR5oY7pCEEqeMfJoenKUuikJ
uPfvfsM5/Ke9iZghD5MFl9kqm6aF5w5Hfh+fIfElufosFBgy5uySoChPnZOQ
kag2XBWn3gwiXsplZRSBmE1poTpkSIWiQli2ggJkSN/vMG4AKwawNF9HAbZ1
VLUn00KDApv//PrkITKSPOQcNDUwpMbG3iHc1EcbfF+QHtBbtt1xcqxjW19a
DY6WunaWWR3ygxKmekqylQ2GClG9vWF7pLTdOTE3cYleqreMnZRcxZSW3SS9
xIOqY0hKlojnfwHb46RcZjYIvD4iid3CPJkByldZtj9pU5BjCQCUkKli6jOf
xRV86QP+uHCXblyxuW+fsGdSDJHLvHpm40t0DDZWvXFIg1D8EnxQyA5iC0wS
CsSAcGV5Hnuh2/SxgV8ineyWRjndTqE+RMWxc5MJIWhLu9TAMkUuC+t0Pn5m
KgIRU4qYlEeUz4mVtrFoRoNqRJIkKqepu5BCsSMY+UfDW3xGMA5wXF9yLf87
KTjGluTDYSTSlZVMJWlaNi99cZuRvui8hJH+BQPd9NGRwpH+ypFeWYl7/fhI
v3VNRAkhcNPmtZPQow289tjA793BUX3qYDrjRxwhc5sNDN9/7UhAnP+UkZ6l
RbZcwc3QE5knVV27I925zUh3AOh3WvaHXt5B/Il9/0NNu54g9a6KE6+PGqGu
eQ1+Ga2FFKfkTe05R6GpMFm3Uj5kfMfM5cXNBVW1ZqBkonLuB8sxrYgu1UU5
cJEklvLcyyf9dUlIyauzBfgeKfDt4DApukCTunkiS4kf6VY83I3TbTmrX2sO
RxEuIU9mo5yF9/BzHU7XkypMggdJHq2VX322uQRjHtyiUG0UJ6jxqrvK28Zr
pPMSLnMYcG2UW50jJaXkn4kdrrkUVcZ0TKpSIflKyj1mxEEgOkq+Qr7eC6q3
6RwIj5N5BpZqgoKeD8n8dQhrStSjGIl5yhOCvydYOrhubFrNWMxtc8gQyx7W
zFpiyrVZvIdKNBQNvXt29pqkUnYBh8ps6nQ9uMu1Qlzyh+Mz7+4LcTMVqs0f
1NWsfTqKek7cTda09KSVxsDqPFjk8evWXthYBOEngmSBDJgs6mwmcHGq+dsa
iNWUYg2nrY5NqQMA7fIWFYSTX19BGAACMjH09cVCUcuQu6rQuLssIU5lrNLx
Me41J4t6Wb6qTmrcAvXutoa56pm3wamx3+CBl2IxJcNUi/k+xEQupaDABqDs
C+zblqtrztMsD6InpEKovO8sKj23JL+N8qL0sJbE/Eh9R432VKrObZrg1L0a
S5N8wFEZUOs0R7sWswLR6ZqLApbFt41cOeiJWxM1EXAZBXeZuDrAQoDORnqc
UirQUI6MfSkTetxI7VefBTppTK92wesGTnQ1BKmBqhpAI8MbOqoVSnaEWrNl
ADEn4e7RCjRk0tduQyeBJKAoEIi6FEvmjWv3rRWcGW61+CdjjcQtsm95kOSZ
RKWl4eUm7YptKhNBH1IUSEtY+1YmYCd1PrZN5UUZYroSp4YNc4/VClWqTMiZ
aelJqtNkvoxsVDuEI9SjbCkoDRIJ6Usa+mFGEksb5U2GCQQFdiaUhjiHxLKL
jSdS9pBnxOoIsrabvAGf2aAVN/i6i0aBZm3eNqH4fliv7PtgeqZhJhhdwLAs
KlTiZBAxQTqI2P69gVDUEC2jfJ5e4NoANhqINTjJLfEwkmMqK9Hce97EpTat
WHkzAeQ04UqmjjLL6N0S+Ek4Z3aO9aTCH5NzjnoVuIVpi00wNHNqFeeSeF9C
ZMpW8ztXFVbUOxIepS8Ghtercyp1iYrim0X6PlusFhucUvMmGDAFXtRFIVQc
lKBElTlU1PfcXLAsspJKHHtcErrUCBoJxW7NBCiUZ/OyjKSnZkNjh80oYVo5
l2gT1WFXBeMgTBwDE8oQFmWyU5Rc1Y9QcbYTJuJKRWs1jHH4fitKKBSBCxkM
7kbOK2aauP6KL0PucwVB08VbE6q9ximBps2qEQTT5swcgMT6nfAuMfQEm6/f
Vo14ukyF14X6dEa8UFv4SZiQFmMAcy5a9Yt8PtQGA97d3wvw5nObu4o6PljR
xofeCA14WrE6P0qSoD92FDD9M/w0UjXrlV+HqGUj037rutvNdafBnViT6muw
8fkHNeAFfBHWvdHgy2CF/JH+3mygE/+imfn/gUl+SoP2OfY0uOEs7nil+ZSj
Db2Sfec2kBD3oG/9LdaGGwT4mAJ8g0hzqvWXdrgeAkp9sSM0lCxqlV0ixfch
kH//kNlEyNpmHbopGBl4U0t2CN4qWNrFq2uQfQFXNqEkIR+4gK8+zjmUvMp8
yqscYgS5OWATcQ/2eMK+UJQwosLEqRmNSiaBn+xEyEJxsc3clyKJXze797QU
jpZY6mbostfZbxStcUa0dcFXTkQUJDrbXiKCT0xIPCnZBMIOOdGff4gAyZtz
RlGz6x7yMuJPC+6uteEXXQjdbHad9JAabsaHhm/3tNnGZ5TsSyvTaErX2xtf
N66Znkn0veCb0VquiaBc9xuaLpo9+lJX6jsEAEef/04NFGTlBV75DV23EH37
TDuNDpq9294o2o2bGvWQr26jO224ue5ptEnGGGji1XkgiGGmJ/joBnIWI/ot
aFqH+ICAMXE62CRO1MmFKOHiMNYaCV5kZ4Em2055Cs4e0pfkUgWiauuImJhe
YtLKRWQi1ZUuNMdPRRuR/5vqhOXWjFgiRl0CJZK7TudSdOhlvt5G3nbvb/QA
8rZyzcVRhuvDxRdq+UCWRufqlY/wuSV5uzWB6yVx199tkrh+Iqf9XncabpC5
L6RZT8MeQnftGwZ0vR+jeIPE+75hP5lrEPl669Cdj2/Y7FqgQpHM1UP3aKtY
6AJlOwq0LpLDGhKIJg/4kYkN9tfyXySa9VDBO5+yiPaTe5vULyKKPf1u0EF5
DOzrnUUH0vpn0SWK8EX0NNwm33Ua9hDHL3p3qvvCsOsC6SdKn0YuW0Qw0M17
2+imXGvSoZlsG3A1G4xyf3OXW+X1NmvfxtVLWe1sfm44jyVUqwzEz3FUZw/p
65DQKFFmOyGOyF4fET5TI6NmpsSswHRYQcQG1KYkqw7FEaJoGSlsyLUDmFyS
5toRGpXi1vNLRCj5ewq9ReSWiufHVc+PKZ+bkuItCOim6vNdl3T2KqLXPU06
HzTZ76D71oZ9UuH2xt7Z3qOgtoglb8WXDRR3CSTRRh7kS1ZoA4xHzVpE8U5L
rd3Qam+5J/1NArU82NqkzXZuVm/7mnRgpU0Ib0kCN2Clj/h9nOz9SpLXIndx
gKFc22PV/ZYtUAuI8JdjfuRnJZiRcsf52Qg7Mxr32y5i1zU+S3Qkx3StfSiQ
rwdgAh2b0hlldRQAHYKuNQ9PHI3aHAZx40l56ZyPJZ3CSlzMVplrInNC/Jwk
l7OzhGQ8NgubTEIaOXINLo3ozkMYFDkIB6PP7cpboBGyKj2w7W7SXE+YOdMx
f/O1cElzLVzbmyA7Tnso1VTOjbdqXloN62Y/3YYxOBjnjoOrBD4XnmxelnJL
cHA6TE0oPsQXw1XEd7hMoRoYsyKm2lKthe3enrchm9CHeksOY6GZDI3vgf6Z
+3MNG64GXrlUpSmi0xpN4us0pd/GBWTuBY2F+JAPy5WC51ojuhs5++fNAOuB
xmP5S3EuymwaFblhZwPcqKi45CFPiymwK8VxVFWTDiERw1GWYrSYZjdKbafm
arEC+yINSYi4/fi9JqncaaKBsGtxrWGnLzNnDZdTCZEnW1NNk3RSlXzVD4fj
trxpqEgVLmjXsIfodkl1yKEEi4ahMxPGjgnEXaZr5yP4YWIqTBOBFmGTliqh
AVKNLvC6nSbONzcnn0xjT3DqBJqxfw8ZWmDzl4tDmOKUKIt1njjECyTcgkma
1NxOdhECWrJbEDnKIEwIPCUM2htxseRB8NLqTYziZeNwd/t+nq44FbgpeYQR
+PZOOevollTjsyLkdqfn9rK1JoYi9VmIea5tP/PhjWGrxRkW+9m6t1ZK5AFH
0vK8Ws7nEMceApabu6Ai556Pf9BTpa1bhSum/NWxeXZuuc6U1M7iZiEfgDEI
LYZ0BIXx2bbxHcSRJ6mpbaKROViBlD9TBJyXC+jerconirzUCTOCkJetYq5f
Kl9G05gnAxnJ/JwEW6QojlAQrYMfB/QzhTk5en60QV5+/ktdDseoAwWf2fQX
Dimmc+YC8dF1I8bw691kcoSyeiKKgOa1l5nx+tvofWRyzIjZVGK90FY7229s
x4XtUnQCviS307w/I+a2xNVnmNEIF8MsQzONkL4xqUOuWGmMODfcetG3ZKf5
529xFm9e/BE5Ivlqwa7qtz9JMd+ar4fuRJpxCXM6pLLyhmYuSHNozA8otXV8
qNpS/6w7mShyZR+9qW5BlRW6d0ePWucZioPc5kTZpxouYJuUU18FAPu3vxft
czV5G12Vp2t7uzEgrvOgcSJI2LwoqR7nQ+qKKyxeywvJddNN8hyYeZ14LLjm
BQ9f4BaIBBGmTb4Kf/XJLdcEygvOa7imblkWTa6TYevTPGj91GkXf43foG75
gkB6xrVbYhH54ZMBoTv++il+/Lzd6urqv54eP31MENwI1dcsLOumbLuDBuNt
4F7fzoeN30k+BLjYQWu4UuPbvZD7KU23QIkPf2QaG86zty9C3Qjjb43wt8V3
TcCLqIuEq6RT3MzhOIJJ0uyE4hy/J3WgpvWh0tMOgTRhzzpOPLg/+ircfbV/
oHdfPWYsFu7sa4+5zp2dkuUSKlVhotX55Jv7978eZyBMoB2r8YLrrfFkfbkt
3lfnrwRrHWVYFieZxLcsNnSF7wdDAOvV4YVDNcsPhs/70BwmR8kuLlRZpPme
D5sIiQGQk+9iVgdf3TPmESMi3xciL46rzJ4rfi4bfaB1b5AxAf/w0p+jMtme
ukrYvN4wGm5bldA3jdXln+IKjNxIY5uUuPpj1VJjILQgQIjbYT4oAYC8eZkv
axmBxchfusTCKuqQRtcqbUCsioWc3IqrYzGiXBIbUZhtC+7kzWGW3fRfhgRW
DuTSHWcXyLeauHD1qF76tu0C2gZC74ekKy2P225472aYxIKURsqhV4FkSmLU
akzo0TodH3rS9iBwUTVjlMpyXwWUPM1FBuvDBcCJ7IsXlLygr/EuDPlSwl+U
Eb4dpLbhWlXcjRUwImO5We//PYzZRQTKQlobJtHmEdfJNh6hdH3DBXi95e/O
t+YLGMNdpfBts2eLHbRYQ4sZtLgBbGhRX8EG9Ov6Ooj7mobkgl/V170hURF6
9rpInUbeyxvx28m2b515fXWfevuKD0trM3PlSci3BA2vnezddYdpNsySL23b
yi9PFLaOG1rRx7fa3LJfVuqX8ZgwhesTbqitGF3f3GQ1kjoh5o8MtQaJWWWM
MYeiCDFqOY+FHt0bZgX1GvsvWLZIm7L78fYxmwjp170FFcak1k5F4+b6AyKL
gl5B4dbUZ11At3vhLZLGzxDKpiwu9Ai1W5afgizwfVVEYhB+J7cgNaJCiBF2
E5oBxlmhcP1jvpQHprUKTuVoiwbi53Sy7TGTdW0Gv3+vw+F5roHGadDwIys1
D2kGKjScFHIDoqhOZyEjOpXdyn0pCb75AfIFhmkxe3+7metNseYLobzFZmN4
tkkQPwJ0ILx9Xsq0VfRvakGwlNLc0sDJJqGmZFNHWy4tVfErRbSjlE6QYKEm
GLBn+mpJHPM4asgjYsxSodiG/LnyTWoAIijkjBix4UkWNpCV6yarYgwLblCU
/mU1nS301gi2FjLX1W1h5fZogvSB3Eo72M2sxk9y6KWEgRbviEPlBF4vbUXw
6wYk9YxxM2Ru1wNzXGUTUBzSqfN0YP7+P/H9T+ti8s7yj++SP9K79PcTJB8m
DywHKJLScqUP/v6/Ju8+EAqa/1aSKk/rw4v087O0WNk8efn3f5+VtNt///fh
H8qiIDrAjZ+l1YTEiwxqF3+rQZDm5cKVBX3H7B9kbl4u9cuLVeE4B4S+l/MU
wPagXE3SaZpV/IgA6zSdF9nAvEJo1mma/5X+XDmXPEFaNZZ6aklfP8PNFhWn
y5if0goBo3OEBVdGuXoGYZHzi8quZmyg9HCArfn5LyRR2KlaEH455JtPj4n6
ldVhspS71OQ3ZeKKhhLULiKGXB4vhkF6fbRhltjSq3gdGyagwcg0CpqrwCt3
MTUTAI0emf8NFPF8Ov2RAAA=
<!-- [rfced] Font styling
a) The terms enclosed in <tt> in this document are listed below. Please review
to ensure the usage of <tt> is correct and consistent. Let us know if any
updates are needed. Note that <tt> produces fixed-width font in the HTML and
PDF outputs but no changes in the TXT output.
<tt>connection_id</tt>
<tt>extension_data</tt>
<tt>extension_type</tt>
<tt>msg_type</tt>
<tt>path_challenge</tt>
<tt>path_drop</tt>
<tt>path_response</tt>
<tt>return_routability_check</tt>
<tt>rrc</tt>
<tt>tls12_cid</tt>
b) The following sentence includes <em>, which produces underscores in the TXT
output and italics in the HTML and PDF outputs. Please review to ensure that
this is a correct use of <em>.
Original:
To prevent this, RRC cookies
must be _freshly_ generated using a reliable source of entropy
[RFC4086].
-->
<!-- [rfced] Please review the "type" attribute of the sourcecode element in
Section 4, as "tls-msg" is not part of the current list of preferred values
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types).
Perhaps "tls-presentation" would be acceptable? This was used for similar
sourcecode in RFCs 9420 and 9458.
If the current list of preferred values for "type" does not contain an
applicable type, then feel free to suggest a new one. Also, it is acceptable
to leave the "type" attribute not set.
-->
<!-- [rfced] Terminology
a) We see both "Cookie" and "cookie" used in this document. Should these be
uniform? If so, please let us know which form is preferred.
b) We see the following forms used in the document? Please review and let us
know if any updates are needed for correctness and consistency.
Return Routability Check message
RRC message
return_routability_check message
c) Is "CID-address binding" correct, or should this be updated to "CID address
binding" (no hyphen)?
d) We see that "return routability check" and its acronym "RRC" are used
throughout the document. Would you like to expand the first instance and then
use the acronym in the remainder of the document? Or do you prefer the current
arrangement?
-->
<!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Constrained Application Protocol (CoAP)
cryptographically secure pseudorandom number generator (CSPRNG)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 104 change blocks. 
829 lines changed or deleted 545 lines changed or added

This html diff was produced by rfcdiff 1.48.