<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!--generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.2.2)[rfced] Because this document updates RFC 9147, please review the errata reported for RFC 9147 (https://www.rfc-editor.org/errata/rfc9147) and let us know if you confirm our opinion that none of them are relevant to the content of this document. --> <!-- [rfced] Please note that the title of the document has been updated as follows. Original: Return Routability Check for DTLS 1.2 and DTLS 1.3 Current: Return Routability Check for DTLS 1.2 and 1.3 --><?rfc rfcedstyle="yes"?> <?rfc tocindent="yes"?> <?rfc strict="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc docmapping="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-tls-dtls-rrc-20" number="9853" category="std" consensus="true" submissionType="IETF" updates="9146, 9147" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.28.1 --><front> <title abbrev="DTLS Return Routability Check">Return Routability Check for DTLS 1.2 andDTLS1.3</title> <seriesInfoname="Internet-Draft" value="draft-ietf-tls-dtls-rrc-20"/>name="RFC" value="9853"/> <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role="editor"> <organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sieg</organization> <address> <email>Hannes.Tschofenig@gmx.net</email> </address> </author> <author initials="A." surname="Kraus" fullname="Achim Kraus"> <organization/> <address> <email>achimkraus@gmx.net</email> </address> </author> <author initials="T." surname="Fossati" fullname="Thomas Fossati"> <organization>Linaro</organization> <address> <email>thomas.fossati@linaro.org</email> </address> </author> <dateyear="2025" month="July" day="14"/> <area>Security</area> <workgroup>TLS</workgroup> <keyword>DTLS, RRC, CID</keyword> <abstract> <?line 47?> <t>Thisyear="2026" month="February"/> <area>SEC</area> <workgroup>tls</workgroup> <keyword>DTLS</keyword> <keyword>RRC</keyword> <keyword>CID</keyword> <!-- [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 context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3.</t> <t>Implementations offering the CID functionality described inRFCRFCs 9146 andRFC9147 are encouraged to also provide thereturn routability checkRRC functionality described in this document. For this reason, this document updatesRFCRFCs 9146 andRFC9147.</t> </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/tls/"/>.</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> <middle><?line 56?><section anchor="introduction"> <name>Introduction</name> <t>A Connection ID (CID) is an identifier carried in the record layer header of a DTLS datagram that gives the receiver additional information for selecting the appropriate 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> <t><xref section="6" sectionFormat="of" target="RFC9146"/> describes how the 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(D)DoS.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 from the one currently associated with the DTLS connection. However, the 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 defines a Return Routability Check (RRC)sub-protocolsubprotocol for DTLS 1.2 and1.31.3, inspired by the path validation procedure defined in <xref section="8.2" sectionFormat="of" target="RFC9000"/>. As such, this document updates <xref target="RFC9146"/> and <xref target="RFC9147"/>.</t> <t>The return routability check is performed by the receiving endpoint before the CID-address binding is updated in that endpoint's session state. 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 the received datagram. For an illustration of the handshake and address validation phases, see <xref target="overview"/>.</t> <t><xref target="regular"/> of this document explains the fundamental mechanism that aims to reduce the DDoS attack surface. Additionally,in<xreftarget="enhanced"/>,target="enhanced"/> discusses a more advanced address validationmechanism is discussed.mechanism. This mechanism is designed to counteract off-path attackers trying to place themselves 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 target="attacker"/>.</t> <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 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> </section> <section anchor="conventions-and-terminology"> <name>Conventions and Terminology</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document assumes familiarity with the CID format and protocol defined for DTLS 1.2 <xref target="RFC9146"/> and for DTLS 1.3 <xref target="RFC9147"/>. The presentation language used in this document is described in <xref section="4" sectionFormat="of" target="RFC8446"/>.</t> <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 those that have been discarded. 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 terms "client", "server","peer""peer", and "endpoint" are defined in <xref section="1.1" sectionFormat="of" target="RFC8446"/>.</t> </section> <section anchor="rrc-extension"> <name>RRC Extension</name> <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 andDTLS1.3. On connecting, a client wishing to use RRC includes the <tt>rrc</tt> extension in its ClientHello. If the server is capable of meeting this requirement, it responds withaan <tt>rrc</tt> extension in its ServerHello. The <tt>extension_type</tt> value for this extension isTBD161, and the <tt>extension_data</tt> field of this extension is empty. 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 the <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> also offer the <tt>rrc</tt> extension, unless the application using DTLS has its own address validation mechanism. The client and server <bcp14>MUST NOT</bcp14> use RRC unless both sides have successfully exchanged <tt>rrc</tt> extensions.</t> <section anchor="rrc-and-cid-interplay"> <name>RRC and CID Interplay</name> <t>RRC offers an in-protocol mechanism to perform peer address validation that complements the "peer address update" procedure described in <xref section="6" sectionFormat="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 has the source address of the enclosing UDP datagram different from what is currently associated with that CID value, the receiver <bcp14>SHOULD</bcp14> perform a return routability check as described in <xref target="path-validation"/>, unless an application-specific address validation mechanism can be triggered instead (e.g.,CoAPConstrained Application Protocol (CoAP) Echo <xref target="RFC9175"/>).</t> </section> </section> <section anchor="return-routability-check-message-types"> <name>Return Routability Check Message Types</name> <t>This document defines the <tt>return_routability_check</tt> content type (<xref target="fig-rrc-msg"/>) to carry Return Routability Check messages.</t> <t>The RRCsub-protocolsubprotocol consists of three message types: <tt>path_challenge</tt>,<tt>path_response</tt><tt>path_response</tt>, and<tt>path_drop</tt> that<tt>path_drop</tt>. These message types are used for path validation and selection as described in <xref target="path-validation"/>.</t> <t>Each message carries a Cookie, an 8-byte field containing 64 bits of entropy (e.g., obtained from theCSPRNGcryptographically secure pseudorandom number generator (CSPRNG) used by the TLSimplementation,implementation; see <xref section="C.1" sectionFormat="of" target="RFC8446"/>).</t> <t>The <tt>return_routability_check</tt> message <bcp14>MUST</bcp14> be authenticated and encrypted using the currently active security context.</t> <figure anchor="fig-rrc-msg"> <name>Return Routability Check Message and Content Type</name> <sourcecode type="tls-msg"><![CDATA[ enum { invalid(0), change_cipher_spec(20), alert(21), handshake(22), application_data(23), heartbeat(24), /* RFC 6520 */ tls12_cid(25), /* RFC 9146, DTLS 1.2 only */ return_routability_check(TBD2), /* NEW */ (255) } ContentType; uint64 Cookie; enum { path_challenge(0), path_response(1), path_drop(2), (255) } rrc_msg_type; struct { rrc_msg_type msg_type; select (return_routability_check.msg_type) { case path_challenge: Cookie; case path_response: Cookie; case path_drop: Cookie; }; } return_routability_check; ]]></sourcecode> </figure> <t>Future extensions to the RRCsub-protocolsubprotocol may define new message types. Implementations <bcp14>MUST</bcp14> be able to parse and understand the three RRC 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> </section> <section anchor="path-validation"> <name>Path Validation Procedure</name> <t>A receiver that observes the peer's address change <bcp14>MUST</bcp14> stop sending any buffered applicationdata,data or limit the data sent to the unvalidated address to the anti-amplification limit. It then initiates the return routability check.</t> <t>This document describes two kinds of checks: basic (<xref target="regular"/>) 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 decision on what strategy to choose depends mainly on the threatmodel,model but may also be influenced by other considerations. Examples of impacting factorsinclude:include the need to minimise implementation complexity, privacy concerns, and the 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> <t>After the path validation procedure iscompleted,complete, any pending send operation is resumed to the bound peer address.</t><t><xref target="path-challenge-reqs"/><t>Sections <xref target="path-challenge-reqs" format="counter"/> and <xreftarget="path-response-reqs"/>target="path-response-reqs" format="counter"/> list the requirements for the initiator and responder roles, broken down per protocol phase.</t> <t>Please note that the presented algorithms are not designed to handle nested rebindings, i.e. rebindings that may occur while a path is being validated following a previous rebinding.If this happens (whichThis should rarelyoccur),occur, but if it happens, the <tt>path_response</tt> message is dropped, the address validation times out, and the address will not be updated. A new path validation will start when new data is received.</t><t>Also<t>Also, note that in the event of a NAT rebind, the initiator and responder will have different views of the path:theThe initiator will see a new path, while the responder will still see the old one.</t> <section anchor="regular"> <name>Basic</name> <t>The basic return routability check comprises the following steps:</t> <ol spacing="normal" type="1"><li> <t>The receiver (i.e., the initiator) creates a <tt>return_routability_check</tt> message of type <tt>path_challenge</tt> and places the unpredictable cookie into the message.</t> </li> <li> <t>The message is sent to the observed new address and a timer T (see <xref target="timer-choice"/>) is started.</t> </li> <li> <t>The peer (i.e., the responder) cryptographically verifies the received <tt>return_routability_check</tt> message of 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> </li> <li> <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 cookie, it updates the peer address binding.</t> </li> <li> <t>If Texpiresexpires, the peer address binding is not updated.</t> </li> </ol> </section> <section anchor="enhanced"> <name>Enhanced</name> <t>The enhanced return routability check comprises the following steps:</t> <ol spacing="normal" type="1"><li> <t>The receiver (i.e., the initiator) creates a <tt>return_routability_check</tt> message of type <tt>path_challenge</tt> and places the unpredictable cookie into the message.</t> </li> <li> <t>The message is sent to the previously valid address, which corresponds to the old path. Additionally, a timer T isstarted, seestarted (see <xreftarget="timer-choice"/>.</t>target="timer-choice"/>).</t> </li> <li> <t>If the path is still functional, the peer (i.e., the responder) cryptographically verifies the received <tt>return_routability_check</tt> message of 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. </t> <ul spacing="normal"> <li> <t>If the path through which the message was received is preferred, a <tt>return_routability_check</tt> message of type <tt>path_response</tt> <bcp14>MUST</bcp14> be returned. (Note that, from the responder's perspective, the preferred path and the old path coincide in the event of a NAT rebind.)</t> </li> <li> <t>If the path through which the message was received is no longer preferred, a <tt>return_routability_check</tt> message of type <tt>path_drop</tt> <bcp14>MUST</bcp14> be returned. (Note that the responder must have initiated a voluntary path migration in order to know that this path is no longer the preferred one.)</t> </li> </ul> <t> In either case, the peer echoes the cookie value in the response.</t> </li> <li> <t>The initiator receives and verifies that the <tt>return_routability_check</tt> message contains the previously sent cookie. The actions taken by the initiator differ based on the received message: </t> <ul spacing="normal"> <li> <t>When a <tt>return_routability_check</tt> message of type <tt>path_response</tt>wasis received, 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> </li> <li> <!-- [rfced] Should "return routability check" here be updated to "basic 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>wasis received, the initiator <bcp14>MUST</bcp14> perform a return routability check on the observed new address, as described in <xref target="regular"/>.</t> </li> </ul> </li> <li> <t>If Texpiresexpires, the peer address binding is not updated. In this case, the initiator <bcp14>MUST</bcp14> perform a return routability check on the observed new address, as described in <xref target="regular"/>.</t> </li> </ol> </section> <section anchor="path-challenge-reqs"><name> Path<name>Path Challenge Requirements</name> <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> <t>The initiator <bcp14>MAY</bcp14> send multiple <tt>return_routability_check</tt> messages of type <tt>path_challenge</tt> to cater for packet loss on the probed path. </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"> <li> <t>Each <tt>path_challenge</tt> <bcp14>SHOULD</bcp14> go into different transport packets. (Note that the DTLS implementation may not have control over the packetization done by the transport layer.)</t> </li> <li> <t>The transmission of subsequent <tt>path_challenge</tt> messages <bcp14>SHOULD</bcp14> be paced to decrease the chance of loss.</t> </li> <li> <t>Each <tt>path_challenge</tt> message <bcp14>MUST</bcp14> contain random data.</t> </li> <li> <t>In general, the number of "backup" <tt>path_challenge</tt> messages depends on the application, since some are more sensitive than others to latency caused by changes in thepath than others.path. In the absence of application-specific requirements, the initiator can send a <tt>path_challenge</tt> message once per round-trip time (RTT), up to the anti-amplification limit.</t> </li> </ul> </li> <li> <!-- [rfced] Please review "use padding using...up to". Would updating as follows 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 probe if the Path MTU (PMTU) for the new path is still acceptable. --> <t>The initiator <bcp14>MAY</bcp14> 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 thepathPath MTU (PMTU) for the new path is still acceptable.</t> </li> </ul> </section> <section anchor="path-response-reqs"> <name>Path Response/Drop Requirements</name> <ul spacing="normal"> <li> <t>The responder <bcp14>MUST NOT</bcp14> delay sending an elicited <tt>path_response</tt> or <tt>path_drop</tt> messages.</t> </li> <li> <t>The responder <bcp14>MUST</bcp14> send exactly one <tt>path_response</tt> or <tt>path_drop</tt> message for each valid <tt>path_challenge</tt> it received.</t> </li> <li> <t>The responder <bcp14>MUST</bcp14> send the <tt>path_response</tt> or the <tt>path_drop</tt> to the address from which the corresponding <tt>path_challenge</tt> was received. This ensures that the path is functional in both directions.</t> </li> <li> <t>The initiator <bcp14>MUST</bcp14> silently discard any invalid <tt>path_response</tt> or <tt>path_drop</tt> it receives.</t> </li> </ul> <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 validation procedure.</t> </section> <section anchor="timer-choice"> <name>Timer Choice</name> <t>When setting T, implementations are cautioned that the new path could have a 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 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 RTT of the active path, T <bcp14>SHOULD</bcp14> be set to1s.</t>1 second.</t> <t>Profiles for specific deployment environments -- for example, constrained networks <xref target="I-D.ietf-uta-tls13-iot-profile"/> -- <bcp14>MAY</bcp14> specify a different, more suitable value for T.</t> </section> </section> <section anchor="overview"> <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> <figure anchor="fig-handshake"> <name>Message Flow for Full DTLS Handshake</name> <artwork><![CDATA[ Client Server Key ^ ClientHello Exch | + key_share | + signature_algorithms | + rrc v + connection_id=empty --------> ServerHello ^ Key + key_share | Exch + connection_id=100 | + rrc v {EncryptedExtensions} ^ Server {CertificateRequest} v Params {Certificate} ^ {CertificateVerify} | Auth <-------- {Finished} v ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data] <-------> [Application Data] + Indicates noteworthy extensions sent in the previously noted message. {} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret. [] Indicates messages protected using keys derived from[sender]_application_traffic_secret_N. ]]></artwork>[sender]_application_traffic_secret_N.]]></artwork> </figure> <t>Once a connection has been established, the client and the server exchange application payloads protected by DTLS with a unilaterally used CID. In this case, the client is requested to use CID 100 for records sent to the server.</t> <t>At some point in the communication interaction, the address used by the clientchanges and,changes, and thanks to the CID usage, the security context to 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> <t><xref target="fig-rrc-example"/> shows the server initiating a"basic"basic RRC exchange (see <xref target="regular"/>) that establishes reachability of the client at the new address.</t> <figure anchor="fig-rrc-example"><name>"Basic"<name>Basic Return Routability Example</name> <artwork><![CDATA[ Client Server ------ ------ Application Data ========> <CID=100> Src-IP=A Dst-IP=Z <======== Application Data Src-IP=Z Dst-IP=A <<------------->> << Some >> << Time >> << Later >> <<------------->> Application Data ========> <CID=100> Src-IP=B Dst-IP=Z <<< Unverified IP Address B >> <-------- Return Routability Check path_challenge(cookie) Src-IP=Z Dst-IP=B Return Routability Check --------> path_response(cookie) Src-IP=B Dst-IP=Z <<< IP Address B Verified >> <======== Application Data Src-IP=ZDst-IP=B ]]></artwork>Dst-IP=B]]></artwork> </figure> </section> <section anchor="operational-considerations"> <name>Operational Considerations</name> <section anchor="logging-anomalous-events"> <name>Logging Anomalous Events</name> <t>Logging of RRC operations at both ends of the protocol can be generally useful for the users of an implementation. In particular, forsecurity informationSecurity Information andevent managementEvent Management (SIEM) and troubleshooting purposes, it is strongly advised that implementations collect statistics about any unsuccessful RRC operations, as they could represent security-relevant events when they coincide with attempts by an attacker to interfere with the end-to-end path. It is also advisable to log instances where multiple responses to a single <tt>path_challenge</tt> are received, as this could suggest an off-path attack attempt.</t> <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 connectivity service.</t> </section> <section anchor="middlebox-interference"> <name>Middlebox Interference</name> <t>Since the DTLS 1.3 encrypted packet's record type is opaque to on-path 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 zero-length CID) have the <tt>return_routability_check</tt> content type in plain text, making them susceptible to interference (e.g., dropping of <tt>path_challenge</tt> messages), which would hinder the RRC functionality altogether. Therefore, whenusingRRC 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 anchor="security-considerations"> <name>Security Considerations</name> <t>Note that the return routability checks do not protect against flooding ofthird-partiesthird 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 cryptographically authenticated). On-path adversaries can, in general, pose a harm to connectivity.</t> <t>If the RRC challenger reuses a cookie that was previously used in the same 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" sectionFormat="of" target="RFC6347"/>), an attacker could replay a previously sent <tt>path_response</tt> message containing the reused cookie to mislead the challenger 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"/>. See <xref section="C.1" sectionFormat="of" target="RFC8446"/> for guidance.</t> <section anchor="attacker"> <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 increasing capabilities (see <xref target="fig-attacker-capabilities"/>) partly following terminology introduced in QUIC (<xref section="21.1" sectionFormat="of" target="RFC9000"/>):</t> <ul spacing="normal"> <li> <t>An off-path attacker is not on the original path between the DTLS peers, but it is able to observe packets on the original path and has a faster forwarding path compared to the DTLS peers, which allows it to make copies of the observed packets, race its copies to eitherpeerpeer, and consistently win the race.</t> </li> <li> <t>An on-path attacker is on the original path between the DTLS peers and is therefore capable, compared to the off-path attacker, to also drop and delay records at will.</t> </li> </ul> <t>Note that, in general, attackers cannot craft DTLS records in a way that would successfully pass verification, due to the cryptographic protections applied by the DTLS record layer.</t> <figure anchor="fig-attacker-capabilities"> <name>Attackercapabilities</name>Capabilities</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width="448" viewBox="0 0 448 272" class="diagram" 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,112 L 40,160" 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 416,32 L 416,128" 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 80,32 L 376,32" fill="none" stroke="black"/> <path d="M 392,32 L 416,32" fill="none" stroke="black"/> <path d="M 80,64 L 376,64" fill="none" stroke="black"/> <path d="M 80,96 L 376,96" fill="none" stroke="black"/> <path d="M 80,128 L 376,128" fill="none" stroke="black"/> <path d="M 40,160 L 64,160" fill="none" stroke="black"/> <path d="M 80,160 L 376,160" 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,256 L 376,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,32 388,26.4 388,37.6" fill="black" transform="rotate(180,392,32)"/> <polygon class="arrowhead" points="72,160 60,154.4 60,165.6" fill="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)"/> <g class="text"> <text x="120" y="52">Inspect</text> <text x="204"y="52">un-encrypted</text>y="52">unencrypted</text> <text x="292" y="52">portions</text> <text x="116" y="84">Inject</text> <text x="36" y="100">off-path</text> <text x="120" y="116">Reorder</text> <text x="116" y="148">Modify</text> <text x="212"y="148">un-authenticated</text>y="148">unauthenticated</text> <text x="316" y="148">portions</text> <text x="416" y="148">on-path</text> <text x="112" y="180">Delay</text> <text x="108" y="212">Drop</text> <text x="132" y="244">Manipulate</text> <text x="192" y="244">the</text> <text x="264" y="244">packetization</text> <text x="344" y="244">layer</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--> .------------------------------------. <--. | | Inspectun-encryptedunencrypted portions | | | +------------------------------------+ | | | Inject | | off-path +------------------------------------+ | | | Reorder | | | +------------------------------------+ | | | Modifyun-authenticatedunauthenticated portions | on-path '--> +------------------------------------+ | | Delay | | +------------------------------------+ | | Drop | | +------------------------------------+ | | Manipulate the packetization layer | | '------------------------------------' <--' ]]></artwork> </artset> </figure> <t>RRC is designed to defend against the following attacks:</t> <ul spacing="normal"> <li> <t>On-path and off-path attackers that try to create an amplification attack by spoofing the source address of the victim (<xref target="sec-amplification"/>).</t> </li> <li> <t>Off-path attackers that try to put themselves on-path (<xref target="off-path"/>), provided that the enhanced path validation algorithm is used (<xref target="enhanced"/>).</t> </li> </ul> <section anchor="sec-amplification"> <name>Amplification</name> <t>Both on-path and off-path attackers can send a packet (either by modifying it on thefly,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 the server in response is larger compared to the received packet (e.g., a CoAP server returning an MTU's worth of data from a20-bytes20-byte GET request <xreftarget="I-D.irtf-t2trg-amplification-attacks"/>)target="I-D.irtf-t2trg-amplification-attacks"/>), the attacker can use the server as a traffic amplifier toward the victim.</t> <section anchor="mitigation-strategy"> <name>Mitigation Strategy</name> <t>When receiving a packet with a known CID that has a source address different from the one currently associated with the DTLS connection, an 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 to decrypt it and generate a valid <tt>path_response</tt>, the address validation fails, which in turn keeps the original address binding unaltered.</t> <t>Note that in the case of an off-path attacker, the original packet still reaches the intended destination; therefore, an implementation could use a different strategy to mitigate the attack.</t> </section> </section> <section anchor="off-path"> <name>Off-Path Packet Forwarding</name> <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 the genuine packet, this will appear as a path change, like in a genuine NAT rebinding occurrence. Any genuine 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 path via the attacker. This places the attacker on-path, giving it the ability to observe or drop all subsequent packets.</t> <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 endpoints. The attack is more effective if relatively few packets are sent or if packet loss coincides with the attempted attack.</t> <t>A data packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path. Therefore, eliciting packets on this path increases the likelihood that the attack is unsuccessful.Note howeverHowever, note that, unlike QUIC, DTLS has no "non-probing" packets so this would requireapplication specificapplication-specific mechanisms.</t> <section anchor="mitigation-strategy-1"> <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 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 <tt>path_challenge</tt> (1) on the old path.</t> <figure anchor="fig-off-path"> <name>Off-Path Packet Forwarding Scenario</name> <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="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 64,80 L 64,176" fill="none" stroke="black"/> <path d="M 64,208 L 64,304" fill="none" stroke="black"/> <path d="M 112,48 L 112,112" fill="none" stroke="black"/> <path d="M 112,272 L 112,336" fill="none" stroke="black"/> <path d="M 200,48 L 200,112" fill="none" stroke="black"/> <path d="M 200,272 L 200,336" fill="none" stroke="black"/> <path d="M 248,80 L 248,304" fill="none" stroke="black"/> <path d="M 112,48 L 200,48" fill="none" stroke="black"/> <path d="M 64,80 L 112,80" fill="none" stroke="black"/> <path d="M 200,80 L 248,80" fill="none" stroke="black"/> <path d="M 112,112 L 200,112" fill="none" stroke="black"/> <path d="M 24,176 L 120,176" fill="none" stroke="black"/> <path d="M 8,208 L 104,208" fill="none" stroke="black"/> <path d="M 112,272 L 200,272" fill="none" stroke="black"/> <path d="M 64,304 L 112,304" fill="none" stroke="black"/> <path d="M 200,304 L 248,304" fill="none" stroke="black"/> <path d="M 112,336 L 200,336" fill="none" stroke="black"/> <path d="M 8,208 L 24,176" fill="none" stroke="black"/> <path d="M 104,208 L 120,176" fill="none" stroke="black"/> <g class="text"> <text x="72" y="36">new</text> <text x="240" y="36">old</text> <text x="76" y="52">path</text> <text x="236" y="52">path</text> <text x="156" y="84">Receiver</text> <text x="64" y="196">Attacker?</text> <text x="156" y="308">Sender</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ new old path .----------. path | | .-----+ Receiver +-----. | | | | | '----------' | | | | | | | .----+------. | / Attacker? / | '------+----' | | | | | | | | .----------. | | | | | '-----+ Sender +-----' | | '----------' ]]></artwork> </artset> </figure> <t>Three cases need to be considered:</t> <t>Case 1: The old path is dead (e.g., due to a NAT rebinding), which leads to a timeout of (1).</t> <t>As shown in <xref target="fig-old-path-dead"/>, a <tt>path_challenge</tt> (2) needs to be sent on the new path. If the sender replies with a <tt>path_response</tt> on the new path (3), the switch to the new path is considered legitimate.</t> <figure anchor="fig-old-path-dead"> <name>Oldpath is dead</name>Path Is Dead</name> <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="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <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 96,80 L 96,176" 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,256 L 112,288" 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 232,48 L 232,112" fill="none" stroke="black"/> <path d="M 232,272 L 232,336" fill="none" stroke="black"/> <path d="M 296,64 L 296,112" fill="none" stroke="black"/> <path d="M 296,144 L 296,176" fill="none" stroke="black"/> <path d="M 144,48 L 232,48" fill="none" stroke="black"/> <path d="M 80,64 L 136,64" fill="none" stroke="black"/> <path d="M 232,64 L 296,64" fill="none" stroke="black"/> <path d="M 96,80 L 144,80" fill="none" stroke="black"/> <path d="M 112,96 L 144,96" fill="none" stroke="black"/> <path d="M 144,112 L 232,112" fill="none" stroke="black"/> <path d="M 56,176 L 72,176" fill="none" stroke="black"/> <path d="M 88,176 L 104,176" fill="none" stroke="black"/> <path d="M 120,176 L 288,176" fill="none" stroke="black"/> <path d="M 304,176 L 320,176" fill="none" stroke="black"/> <path d="M 40,208 L 72,208" fill="none" stroke="black"/> <path d="M 88,208 L 104,208" fill="none" stroke="black"/> <path d="M 120,208 L 304,208" fill="none" stroke="black"/> <path d="M 144,272 L 232,272" fill="none" stroke="black"/> <path d="M 112,288 L 136,288" fill="none" stroke="black"/> <path d="M 96,304 L 144,304" fill="none" stroke="black"/> <path d="M 80,320 L 144,320" fill="none" stroke="black"/> <path d="M 144,336 L 232,336" fill="none" stroke="black"/> <path d="M 40,208 L 56,176" fill="none" stroke="black"/> <path d="M 304,208 L 320,176" fill="none" stroke="black"/> <polygon class="arrowhead" points="304,176 292,170.4 292,181.6" fill="black" transform="rotate(90,296,176)"/> <polygon class="arrowhead" points="144,288 132,282.4 132,293.6" fill="black" transform="rotate(0,136,288)"/> <polygon class="arrowhead" points="144,64 132,58.4 132,69.6" fill="black" transform="rotate(0,136,64)"/> <g class="text"> <text x="88" y="36">new</text> <text x="288" y="36">old</text> <text x="92" y="52">path</text> <text x="284" y="52">path</text> <text x="188" y="84">Receiver</text> <text x="260" y="84">......</text> <text x="280" y="100">.</text> <text x="280" y="116">.</text> <text x="24" y="132">path-</text> <text x="80" y="132">3</text> <text x="280" y="132">.</text> <text x="296" y="132">1</text> <text x="328" y="132">path-</text> <text x="36" y="148">response</text> <text x="280" y="148">.</text> <text x="344" y="148">challenge</text> <text x="280" y="164">.</text> <text x="184" y="196">NAT</text> <text x="296" y="196">X</text> <text x="352" y="196">timeout</text> <text x="280" y="228">.</text> <text x="112" y="244">2</text> <text x="144" y="244">path-</text> <text x="280" y="244">.</text> <text x="160" y="260">challenge</text> <text x="280" y="260">.</text> <text x="280" y="276">.</text> <text x="280" y="292">.</text> <text x="188" y="308">Sender</text> <text x="260" y="308">.....'</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ new old path .----------. path .------>| +-------. | .-----+ Receiver +...... | | | .---+ | . | | | | '----------' . | path- 3 | | . 1 path- response | | | . | challenge | | | . | .--|-+-|----------------------v--. / | | NAT X / timeout '----|-+-|-----------------------' | | | . | | 2 path- . | | | challenge . | | | .----------. . | | '-->| | . | '-----+ Sender +.....' '-------+ | '----------' ]]></artwork> </artset> </figure> <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 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 will reply with a <tt>path_response</tt> (4) on the new path, thus providing confirmation for the path migration.</t> <figure anchor="fig-old-path-not-preferred"> <name>Oldpath is not preferred</name>Path Is Not Preferred</name> <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="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <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 120,80 L 120,176" 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,256 L 136,288" 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 256,48 L 256,112" fill="none" stroke="black"/> <path d="M 256,272 L 256,336" fill="none" stroke="black"/> <path d="M 288,96 L 288,112" fill="none" stroke="black"/> <path d="M 288,144 L 288,288" fill="none" stroke="black"/> <path d="M 304,80 L 304,176" fill="none" stroke="black"/> <path d="M 304,208 L 304,304" fill="none" stroke="black"/> <path d="M 320,64 L 320,224" fill="none" stroke="black"/> <path d="M 320,256 L 320,320" fill="none" stroke="black"/> <path d="M 168,48 L 256,48" fill="none" stroke="black"/> <path d="M 104,64 L 160,64" fill="none" stroke="black"/> <path d="M 264,64 L 320,64" fill="none" stroke="black"/> <path d="M 120,80 L 168,80" fill="none" stroke="black"/> <path d="M 256,80 L 304,80" fill="none" stroke="black"/> <path d="M 136,96 L 168,96" fill="none" stroke="black"/> <path d="M 256,96 L 288,96" fill="none" stroke="black"/> <path d="M 168,112 L 256,112" fill="none" stroke="black"/> <path d="M 24,176 L 96,176" fill="none" stroke="black"/> <path d="M 112,176 L 128,176" fill="none" stroke="black"/> <path d="M 144,176 L 176,176" fill="none" stroke="black"/> <path d="M 264,176 L 280,176" fill="none" stroke="black"/> <path d="M 296,176 L 312,176" fill="none" stroke="black"/> <path d="M 328,176 L 416,176" fill="none" stroke="black"/> <path d="M 8,208 L 96,208" fill="none" stroke="black"/> <path d="M 112,208 L 128,208" fill="none" stroke="black"/> <path d="M 144,208 L 160,208" fill="none" stroke="black"/> <path d="M 248,208 L 280,208" fill="none" stroke="black"/> <path d="M 296,208 L 312,208" fill="none" stroke="black"/> <path d="M 328,208 L 400,208" fill="none" stroke="black"/> <path d="M 168,272 L 256,272" fill="none" stroke="black"/> <path d="M 136,288 L 160,288" fill="none" stroke="black"/> <path d="M 264,288 L 288,288" fill="none" stroke="black"/> <path d="M 120,304 L 168,304" fill="none" stroke="black"/> <path d="M 256,304 L 304,304" fill="none" stroke="black"/> <path d="M 104,320 L 168,320" fill="none" stroke="black"/> <path d="M 256,320 L 320,320" fill="none" stroke="black"/> <path d="M 168,336 L 256,336" fill="none" stroke="black"/> <path d="M 8,208 L 24,176" fill="none" stroke="black"/> <path d="M 160,208 L 176,176" fill="none" stroke="black"/> <path d="M 248,208 L 264,176" fill="none" stroke="black"/> <path d="M 400,208 L 416,176" fill="none" stroke="black"/> <polygon class="arrowhead" points="272,288 260,282.4 260,293.6" fill="black" transform="rotate(180,264,288)"/> <polygon class="arrowhead" points="272,64 260,58.4 260,69.6" fill="black" transform="rotate(180,264,64)"/> <polygon class="arrowhead" points="168,288 156,282.4 156,293.6" fill="black" transform="rotate(0,160,288)"/> <polygon class="arrowhead" points="168,64 156,58.4 156,69.6" fill="black" transform="rotate(0,160,64)"/> <g class="text"> <text x="112" y="36">new</text> <text x="312" y="36">old</text> <text x="116" y="52">path</text> <text x="308" y="52">path</text> <text x="212" y="84">Receiver</text> <text x="48" y="132">path-</text> <text x="104" y="132">4</text> <text x="224" y="132">path-</text> <text x="288" y="132">1</text> <text x="60" y="148">response</text> <text x="240" y="148">challenge</text> <text x="64" y="196">NAT</text> <text x="88" y="196">A</text> <text x="344" y="196">NAT</text> <text x="368" y="196">B</text> <text x="136" y="244">3</text> <text x="168" y="244">path-</text> <text x="320" y="244">2</text> <text x="352" y="244">path-</text> <text x="184" y="260">challenge</text> <text x="348" y="260">drop</text> <text x="212" y="308">Sender</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ new old path .----------. path .------>| |<------. | .-----+ Receiver +-----. | | | .---+ +---. | | | | | '----------' | | | path- 4 | | path- 1 | | response | | | challenge | | | | | | | | | .---------|-+-|----. .--|-+-|-----------. / NAT A | | / / | | NAT B / '-----------|---|--' '----|-+-|---------' | | | | | | | | 3 path- | | 2 path- | | | challenge | | | drop | | | .----------. | | | | | '-->| |<--' | | | '-----+ Sender +-----' | '-------+ +-------' '----------' ]]></artwork> </artset> </figure> <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 itselfon path. Theon-path. As shown in <xref target="fig-old-path-preferred"/>, the receiver sends a <tt>path_challenge</tt> on the oldpathpath, and the sender replies with a <tt>path_response</tt> (2) on the old path.The interaction is shown in <xref target="fig-old-path-preferred"/>.This results in the connection not being migrated to the new path, thus thwarting the attack.</t> <figure anchor="fig-old-path-preferred"> <name>Oldpath is preferred</name>Path Is Preferred</name> <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="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <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 112,48 L 112,112" 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,288 L 200,352" 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 248,80 L 248,176" fill="none" stroke="black"/> <path d="M 248,208 L 248,320" fill="none" stroke="black"/> <path d="M 264,64 L 264,112" fill="none" stroke="black"/> <path d="M 264,144 L 264,336" fill="none" stroke="black"/> <path d="M 112,48 L 200,48" fill="none" stroke="black"/> <path d="M 200,64 L 264,64" fill="none" stroke="black"/> <path d="M 64,80 L 112,80" fill="none" stroke="black"/> <path d="M 200,80 L 248,80" fill="none" stroke="black"/> <path d="M 208,96 L 232,96" fill="none" stroke="black"/> <path d="M 112,112 L 200,112" fill="none" stroke="black"/> <path d="M 32,176 L 120,176" fill="none" stroke="black"/> <path d="M 208,176 L 224,176" fill="none" stroke="black"/> <path d="M 240,176 L 256,176" fill="none" stroke="black"/> <path d="M 272,176 L 312,176" fill="none" stroke="black"/> <path d="M 192,208 L 224,208" fill="none" stroke="black"/> <path d="M 240,208 L 256,208" fill="none" stroke="black"/> <path d="M 272,208 L 296,208" fill="none" stroke="black"/> <path d="M 8,224 L 96,224" fill="none" stroke="black"/> <path d="M 112,288 L 200,288" fill="none" stroke="black"/> <path d="M 200,304 L 232,304" fill="none" stroke="black"/> <path d="M 64,320 L 112,320" fill="none" stroke="black"/> <path d="M 200,320 L 248,320" fill="none" stroke="black"/> <path d="M 208,336 L 264,336" fill="none" stroke="black"/> <path d="M 112,352 L 200,352" fill="none" stroke="black"/> <path d="M 8,224 L 32,176" fill="none" stroke="black"/> <path d="M 96,224 L 120,176" fill="none" stroke="black"/> <path d="M 192,208 L 208,176" fill="none" stroke="black"/> <path d="M 296,208 L 312,176" fill="none" stroke="black"/> <polygon class="arrowhead" points="216,336 204,330.4 204,341.6" fill="black" transform="rotate(180,208,336)"/> <polygon class="arrowhead" points="216,96 204,90.4 204,101.6" fill="black" transform="rotate(180,208,96)"/> <g class="text"> <text x="72" y="36">new</text> <text x="256" y="36">old</text> <text x="76" y="52">path</text> <text x="252" y="52">path</text> <text x="156" y="84">Receiver</text> <text x="264" y="132">1</text> <text x="296" y="132">path-</text> <text x="312" y="148">challenge</text> <text x="68" y="196">off-path</text> <text x="248" y="196">NAT</text> <text x="60" y="212">attacker</text> <text x="176" y="260">path-</text> <text x="232" y="260">2</text> <text x="188" y="276">response</text> <text x="156" y="324">Sender</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ new old path .----------. path | +-------. .-----+ Receiver +-----. | | | |<--. | | | '----------' | | | | | | 1 path- | | | | challenge | | | | .---+------. .--|-+-|-----. / off-path / / |NAT| / / attacker / '----|-+-|---' '------+---' | | | | | | | | path- 2 | | | response | | | | .----------. | | | | | +---' | | '-----+ Sender +-----' | | |<------' '----------' ]]></artwork> </artset> </figure> <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 old path despite multiple attempts to use that old path, it is not possible to distinguish between an attack and an improvement in routing.</t> <t>An endpoint could also use heuristics to improve detection of this style of attack. For instance, NAT rebinding is improbable if packets were recently received on the old path. Endpoints can also look for duplicated packets. Conversely, a change inconnection IDCID is more likely to indicate an intentional migration rather than an attack. Note that changes inconnection IDsCIDs are supported in DTLS 1.3 but not in DTLS 1.2.</t> </section> </section> </section> </section> <section anchor="privacy-considerations"> <name>Privacy Considerations</name> <t>When using DTLS 1.3, peers <bcp14>SHOULD</bcp14> avoid using the same CID on multiple network 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 correlate the communication interaction across those different paths. DTLS 1.3 provides mechanisms to ensure that a new CID can always be used. In general, an endpoint should proactively send a RequestConnectionId message to ask for new 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 could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs.</t> <t>Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the samelife-spanlifespan of the connection. Therefore, deployments that use DTLS in multihoming 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> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t><cref anchor="to-be-removed">RFC Editor: please replace RFCthis with this RFC number and remove this note.</cref></t><section anchor="new-tls-contenttype"> <name>New TLS ContentType</name> <t>IANAis requested to allocatehas allocated an entry in theTLS <tt>ContentType</tt>"TLS ContentType" registry within the "Transport Layer Security (TLS) Parameters" registry group <xref target="IANA.tls-parameters"/> for the<tt>return_routability_check(TBD2)</tt><tt>return_routability_check</tt> (27) message defined in this document. IANAis requested toset the<tt>DTLS_OK</tt>DTLS_OK column to<tt>Y</tt>"Y" andto addadded the following notepriorto thetable:</t> <ul empty="true"> <li> <t>NOTE:registry:</t> <blockquote><t>Note: The return_routability_check content type is only applicable to DTLS 1.2 and1.3.</t> </li> </ul>1.3.</t></blockquote> </section> <section anchor="new-tls-extensiontype"> <name>New TLS ExtensionType</name> <t>IANAis requested to allocatehas allocated the extension code point(TBD1)(61) forthe<tt>rrc</tt>extension toin the<tt>TLS"TLS ExtensionTypeValues</tt>Values" registry as described in <xref target="tbl-ext"/>.</t> <table align="left" anchor="tbl-ext"><name>rrc entry<name>New Entry in the TLS ExtensionType Valuesregistry</name>Registry</name> <thead> <tr> <th align="left">Value</th> <th align="left">Extension Name</th> <th align="left">TLS 1.3</th> <th align="left">DTLS-Only</th> <th align="left">Recommended</th> <th align="left">Reference</th> <th align="left">Comment</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD1</td>align="left">61</td> <td align="left">rrc</td> <td align="left">CH, SH</td> <td align="left">Y</td> <td align="left">N</td> <tdalign="left">RFCthis</td>align="left">RFC 9853</td> <tdalign="left"> </td>align="left"/> </tr> </tbody> </table> </section> <section anchor="new-tls-rrc-message-type-registry"> <name>New "TLS RRC Message Type" Registry</name> <t>IANAis requested to create a new registryhas created the "TLS RRC Message Types" registry within theTransport"Transport Layer Security (TLS)ParametersParameters" registry group <xref target="IANA.tls-parameters"/>. Thisregistry will be administered under theregistration procedure is "Expert Review"policy(<xref section="4.5" sectionFormat="of" target="RFC8126"/>).</t><t>Follow<t>To submit registration requests, follow the procedures in <xref section="16" sectionFormat="of"target="I-D.ietf-tls-rfc8447bis"/> to submit registration requests.</t>target="RFC9847"/>.</t> <t>Each entry in the registry must include the following fields:</t> <dl newline="true"> <dt>Value:</dt> <dd> <t>A (decimal) number in the range 0 to253</t>253.</t> </dd> <dt>Description:</dt> <dd> <t>A brief description of the RRCmessage</t>message.</t> </dd> <dt>DTLS-Only:</dt> <dd><t>Whether<t>Indication of whether the messageappliesonly applies to DTLS. Since RRC is only available in DTLS, this columnwill beis set to<tt>Y</tt>"Y" for all thecurrentinitial entries in this registry. Future work may define new RRCMessage Typesmessage types that also apply to TLS.</t> </dd> <dt>Recommended:</dt> <dd><t>Whether<t>Indication of whether the message is recommended for implementations to support. 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-D.ietf-tls-rfc8447bis"/></t>target="RFC9847"/>.</t> </dd> <dt>Reference:</dt> <dd> <t>A reference to a publicly available specification for thevalue</t>value.</t> </dd> <dt>Comment:</dt> <dd> <t>Any relevant notes or comments that relate to thisentry</t>entry.</t> </dd> </dl><t>The<t><xref target="tbl-rrc-mt"/> shows the initialstatecontents of thissub-registry is as follows:</t>registry:</t> <table align="left" anchor="tbl-rrc-mt"> <name>Initial Entries in TLS RRC Message Typeregistry</name>Registry</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">DTLS-Only</th> <th align="left">Recommended</th> <th align="left">Reference</th> <th align="left">Comment</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">path_challenge</td> <td align="left">Y</td> <td align="left">Y</td> <tdalign="left">RFCthis</td>align="left">RFC 9853</td> <tdalign="left"> </td>align="left"/> </tr> <tr> <td align="left">1</td> <td align="left">path_response</td> <td align="left">Y</td> <td align="left">Y</td> <tdalign="left">RFCthis</td>align="left">RFC 9853</td> <tdalign="left"> </td>align="left"/> </tr> <tr> <td align="left">2</td> <td align="left">path_drop</td> <td align="left">Y</td> <td align="left">Y</td> <tdalign="left">RFCthis</td>align="left">RFC 9853</td> <tdalign="left"> </td>align="left"/> </tr> <tr> <td align="left">3-253</td> <td align="left">Unassigned</td> <tdalign="left"> </td>align="left"/> <tdalign="left"> </td>align="left"/> <tdalign="left"> </td>align="left"/> <tdalign="left"> </td>align="left"/> </tr> <tr> <td align="left">254-255</td> <td align="left">Reserved for Private Use</td> <td align="left">Y</td> <tdalign="left"> </td>align="left"/> <tdalign="left">RFCthis</td>align="left">RFC 9853</td> <tdalign="left"> </td>align="left"/> </tr> </tbody> </table> <t>IANAis requested to addadded the following noteforto provide additional information regarding the use of RRC message codepoints in experiments:</t><dl> <dt>Note:</dt> <dd> <t>As<blockquote><t>Note: As specified in <xref target="RFC8126"/>, assignments made in the Private Use space are not generally useful for broad interoperability. Those making use of the Private Use range are responsible for ensuring that no conflicts occur within the intended scope of use. For widespread experiments, provisional registrations (<xref section="4.13" sectionFormat="of" target="RFC8126"/>) areavailable.</t> </dd> </dl>available.</t></blockquote> <section anchor="designated-expert-instructions"> <name>Designated Expert Instructions</name> <t>To enable a broadly informed review of registration decisions, it is recommended that multipleDesignated Expertsdesignated experts be appointedwho are ableto represent the perspectives of both the transport and security areas.</t> <t>In cases where a registration decision could be perceived as creating a conflict of interest for a particularExpert,expert, thatExpertexpert <bcp14>SHOULD</bcp14> defer to the judgment of the otherExperts.</t>experts.</t> </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> <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"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC9146"> <front> <title>Connection Identifier for DTLS 1.2</title> <author fullname="E. Rescorla" initials="E." role="editor" surname="Rescorla"/> <author fullname="H. Tschofenig" initials="H." role="editor" surname="Tschofenig"/> <author fullname="T. Fossati" initials="T." surname="Fossati"/> <author fullname="A. Kraus" initials="A." surname="Kraus"/> <date month="March" year="2022"/> <abstract> <t>This document specifies the Connection ID (CID) construct for the 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 security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address 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 content 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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, 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 exception 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</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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</title> <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9146.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <reference anchor="IANA.tls-parameters" target="https://www.iana.org/assignments/tls-parameters"> <front> <title>Transport Layer Security (TLS) Parameters</title> <author> <organization>IANA</organization> </author> </front> </reference><reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <!-- [I-D.ietf-tls-rfc8447bis] companion doc RFC 9847 draft-ietf-tls-rfc8447bis-15 AUTH48 aswhen and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third editionofthis document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference>12/16/25 --> <referenceanchor="I-D.ietf-tls-rfc8447bis">anchor="RFC9847" target="https://www.rfc-editor.org/info/rfc9847"> <front> <title>IANA Registry Updates for TLS and DTLS</title> <author initials="J." surname="Salowey" fullname="Joseph A.Salowey" initials="J. A." surname="Salowey">Salowey"> <organization>Venafi</organization> </author> <authorfullname="Sean Turner"initials="S."surname="Turner">surname="Turner" fullname="Sean Turner"> <organization>sn3rd</organization> </author> <dateday="16" month="June" year="2025"/> <abstract> <t> This document updates the changes to TLS and DTLS IANA registries 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> </abstract> </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 IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.</t> <t>This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.</t> </abstract>month='December' year='2025'/> </front> <seriesInfo name="RFC"value="8447"/>value="9847"/> <seriesInfo name="DOI"value="10.17487/RFC8447"/>value="10.17487/RFC9847"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9175.xml"/> <!-- [I-D.ietf-uta-tls13-iot-profile] draft-ietf-uta-tls13-iot-profile-15 IESG State: I-D Exists as ofdeployment circumstances. Accompanying documents describe the integration12/16/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-uta-tls13-iot-profile.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <!-- [I-D.irtf-t2trg-amplification-attacks] draft-irtf-t2trg-amplification-attacks-05 IESG State: Expired as ofTLS12/22/25 Long Way forkey negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference>author name --> <referenceanchor="RFC9175">anchor="I-D.irtf-t2trg-amplification-attacks" target="https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-amplification-attacks-05"> <front><title>Constrained<title> Amplification Attacks Using the Constrained Application Protocol(CoAP): Echo, Request-Tag, and Token Processing</title> <author fullname="C. Amsüss" initials="C." surname="Amsüss"/>(CoAP) </title> <authorfullname="J.fullname="John Preuß Mattsson" initials="J." surname="PreußMattsson"/>Mattsson"> <organization>Ericsson AB</organization> </author> <authorfullname="G.fullname="Göran Selander" initials="G."surname="Selander"/>surname="Selander"> <organization>Ericsson AB</organization> </author> <author fullname="Christian Amsüss" initials="C." surname="Amsüss"> <organization>Energy Harvesting Solutions</organization> </author> <datemonth="February" year="2022"/> <abstract> <t>Thisday="18" month="June" year="2025"/> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-amplification-attacks-05"/> </reference> </references> </references> <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> <!-- [rfced] Font styling a) The terms enclosed in <tt> in this documentspecifies enhancementsare listed below. Please review to ensure theConstrained Application Protocol (CoAP)usage of <tt> is correct and consistent. Let us know if any updates are needed. Note thatmitigate security issues<tt> produces fixed-width font inparticular use cases. The Echo option enables a CoAP server to verifythefreshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allowsHTML and PDF outputs but no changes in theCoAP server to match block-wise message fragments belonging toTXT 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 thesame request. This document updates RFC 7252 with respect toTXT output and italics in thefollowing: processing requirements for client Tokens, forbidding non-secure reuse of TokensHTML and PDF outputs. Please review to ensureresponse-to-request binding when CoAPthat this isused withasecurity protocol, and amplification mitigation (where thecorrect use of <em>. Original: To prevent this, RRC cookies must be _freshly_ generated using a reliable source of entropy [RFC4086]. --> <!-- [rfced] Please review theEcho option is now 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"type" attribute of theInternetsourcecode element in Section 4, as "tls-msg" is not part ofThings</title> <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"> <organization>Universitythe current list ofApplied Sciences Bonn-Rhein-Sieg</organization> </author> <author fullname="Thomas Fossati" initials="T." surname="Fossati"> <organization>Linaro</organization> </author> <author fullname="Michael Richardson" initials="M." surname="Richardson"> <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.2preferred values (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types). Perhaps "tls-presentation" would be acceptable? This was used forInternetsimilar sourcecode in RFCs 9420 and 9458. If the current list ofThings (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profilespreferred values forIoT devices. Additionally,"type" does not contain an applicable type, then feel free to suggest a new one. Also, itupdates RFC 7925 with respectis acceptable to leave theX.509 certificate profile"type" attribute not set. --> <!-- [rfced] Terminology a) We see both "Cookie" andciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for"cookie" used in thisdraft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls13-iot-profile-14"/> </reference> <reference anchor="RFC4086"> <front> <title>Randomness Requirements for Security</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="J. Schiller" initials="J." surname="Schiller"/> <author fullname="S. Crocker" initials="S." surname="Crocker"/> <date month="June" year="2005"/> <abstract> <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security ofdocument. Should thesesystemsbe uniform? If so, please let us know which form isdependent on generating secret quantitiespreferred. b) We see the following forms used in the document? Please review and let us know if any updates are needed forpasswords, cryptographic keys,correctness andsimilar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easierconsistency. Return Routability Check message RRC message return_routability_check message c) Is "CID-address binding" correct, or should this be updated toreproduce the environment"CID address binding" (no hyphen)? d) We see thatproduced the secret quantities"return routability check" andto searchits acronym "RRC" are used throughout theresulting small set of possibilities thandocument. Would you like tolocateexpand the first instance and then use thequantitiesacronym in thewholeremainder of thepotential number space.</t> <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniquesdocument? Or do you prefer the current arrangement? --> <!-- [rfced] FYI - We have added expansions forgenerating such quantities. It recommendstheusefollowing abbreviations per Section 3.6 oftruly random hardware techniques and shows thatRFC 7322 ("RFC Style Guide"). Please review each expansion in theexisting hardware on many systems can be used for this purpose. It provides suggestionsdocument carefully toameliorateensure correctness. Constrained Application Protocol (CoAP) cryptographically secure pseudorandom number generator (CSPRNG) --> <!-- [rfced] Please review theproblem when a hardware solution is not available, and it gives examples"Inclusive Language" portion ofhow large such quantities need to be for some applications. This document specifies an Internet Best Current Practices fortheInternet Community,online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> andrequests discussion and suggestions 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 Protocol (CoAP)</title> <author fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson"> <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 Internetlet us know if any changes are needed. Updates ofThings (IoT) devices against attacksthis nature typically result in more precise language, which isnot enough. IoT deployments need to make surehelpful for readers. Note thatthey areour script did notused 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 withflag any words in particular, but thisdocument is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks canshould still bemitigated by not using NoSec or by using the Echo option. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-t2trg-amplification-attacks-05"/> </reference> </references> </references> <?line 816?> </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=reviewed as a best practice. --> </rfc>