When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a datagram with the RFC 6347-defined record format the MAC calculation <del> defined in Section 4.1.2 of RFC6347 (and Section 4.1.2.4 of RFC6347 for use with AEAD ciphers) MUST be used. </del>  4. described below. When CIDs are being used, the content to be sent is first wrapped <del> along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </del>  <del> This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send. </del>  <del> The DTLSInnerPlaintext.type value contains the content type of the record.  This is the non-obfuscated (true) content type. </del>  An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for for more details.  (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.) <del> The outer opaque_type field of a DTLSCiphertext record is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.type after decryption.  By encapsulating the true content type inside the encrypted payload the outer content type (special_type) can be used to signal the new record layer format containing the CID. </del>  <del> The DTLSCiphertext.version field describes the protocol being employed.  This document describes an extension to DTLS version 1.2. </del>  <del> The DTLSCiphertext.length field indicates the length (in bytes) of the following DTLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. </del>  <del> The CID value of length indicated with cid_length, as agreed during the exchange. </del>  <del> The AEAD-encrypted form of the serialized DTLSInnerPlaintext structure. Other fields are defined in RFC 6347.  Note that this specification does not make use of the DTLSCompressed structure. </del>  5. <del> This specification changes the MAC calculation defined in Section 4.1.2 of RFC 6347.  At the time of writing ciphers using authenticated encryption with additional data (AEAD) were state-of- the-art.  Hence, this specification updates only the additional data calculation defined in Section 6.2.3.3 of RFC5246, which is re-used by Section 4.1.2.1 of RFC6347. </del>  <del> The additional data calculation is extended as follows: </del>  <del> As described in Section 6.2.3.3 of RFC5246 this 64-bit value is formed by concatenating the epoch and the sequence number in the order they appear on the wire. </del>  <del> This value contains the outer-header content type, i.e. the tls12_cid. </del>  <del> This value contains the version number. This value contains the length information in the outer-header. </del> Value of the negotiated CID. 1 byte field indicating the length of the negotiated CID.  6. dtls-example2 shows an example exchange where a CID is used uni-

As discussed with Hannes, this PR replaces
We currently only describe CID processing with AEAD ciphersuites, which seems to imply that the CID extension effectively influences ciphersuite negotiation. The draft should explain how the two - ciphersuite negotiation and CID ext - interact.
I'm not sure, what the scope of this explanation should be? For the MAC, it seems to be obvious, that the block cipher (URL ) extend the data for the MAC accordingly. URL will get That was already discussed in URL So, I'm not sure, if you are the intended "Thomas", which may write that :-)
The question is whether we should define the CID-enhanced MAC calculation for non-AEAD ciphers. The current draft only supports AEAD ciphers. If that's OK then we could just tell implementers that the ciphersuite selection should be influenced by this. Alternatively, we could define the MAC calculation also for non-AEAD ciphers. What would you prefer, Achim?
The latter, I think...
Though Leshan (LWM2M, also supporting CBC) is one of the major using and contributing projects, I would also prefer to have the MAC defined for the none-AEAD.
Here is the PR: URL

When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a datagram with the RFC 6347-defined record format the MAC calculation  <ins> defined in Section 4.1.2 of RFC6347 MUST be used. </ins> 4. described below. When CIDs are being used, the content to be sent is first wrapped  <ins> along with its content type and optional padding into a DTLSInnerPlaintext: </ins>  <ins> A copy of DTLSPlaintext.fragment </ins>  <ins> A copy of DTLSPlaintext.type </ins> An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for for more details.  (Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this specification.)  <ins> The DTLSInnerPlaintext value is then encrypted and the CID added to produce the final DTLSCiphertext. </ins>  <ins> The outer content type of a DTLSCiphertext record carrying a CID is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins>  <ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. </ins>  <ins> The encrypted form of the serialized DTLSInnerPlaintext structure. </ins>  <ins> All other fields are as defined in RFC 6347. </ins> 5.  <ins> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid. </ins>  <ins> Block Ciphers: </ins>  <ins> Block Ciphers with Encrypt-then-MAC processing: </ins>  <ins> AEAD Ciphers: </ins>  Value of the negotiated CID. 1 byte field indicating the length of the negotiated CID. <ins> All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The length MUST NOT exceed 2^14. </ins> 6. dtls-example2 shows an example exchange where a CID is used uni-


All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The <del> length MUST NOT exceed 2^14. </del>  6.

To address URL
Thanks! This PR fixes the missing size of the introduced length.
I miss the hint for the size of . I would assume it's a 2 bytes value. Is that right? Is this information already in the document and have overseen it? Both introduce a special "length" and use different approaches to do so. One with extra definition, one with a included definition. Is this intended?
Fixed with

All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The  <ins> length MUST NOT exceed 2^14.  This field is of type uint16. </ins> 6.


<del> Value of the negotiated CID. </del>  <del> 1 byte field indicating the length of the negotiated CID. </del>  All other fields are as defined in the cited documents.

Addresses URL
Thanks! This PR clarifies the used cid value.
In my opinion, it's the actual cid on the record header, not the negotiated cid, even if both are intended to be the same. Therefore it is . Or has this changed? Is the MAC now extended by the negotiated CID?
Fixed with

<ins> The DTLSCiphertext.cid value. </ins>  <ins> 1 byte field indicating the length of the DTLSCiphertext.cid. </ins> All other fields are as defined in the cited documents.


To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished <del> record type tls12_cid(25).  Use of this content type has the </del>  following three implications: The CID field is present and contains one or more bytes. produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID <del> is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </del>  The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD) defined in this document. </del>  <del> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType </del>  Registry".

URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris

To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished  <ins> record type tls12_cid(TBD2).  Use of this content type has the </ins> following three implications: The CID field is present and contains one or more bytes. produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID  <ins> is always set to tls12_cid(TBD2).  The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated. IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for  <ins> connection_id(TBD1) defined in this document. </ins>  <ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType </ins> Registry".


multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple.  With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD1) defined in this document. </del>  IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType <del> Registry". </del>

... IANA consideration section based on issue raised by Sean (see URL) ... Security consideration section based on issue raised by Thomas (see URL)
This PR aims to replace PR & PR
A couple of tweaks are needed for the IANA Considerations Section: Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only. The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended. Add a note to say that connectionid is DTLS1.2 only. Add instructions for IANA to assign "Y" to DTLS-okay column for tls12cid content type.
That results in "DTLS only" for TLS extensions and "DTLS-OK" for TLS parameters. I'm not sure, if that just represents more the "current" usage than the "logic" behind it. I would be afraid, that this will hold up other ideas, which doesn't match that "only for extensions / ok for parameters" pattern.
I am not sure what "DTLS-OK" for TLS parameters means
For TLS parameters there's a column "DTLS-OK", And for TLS extensions a column "DTLS only". Does this explain my comment?
We added text to the draft-ietf-tls-dtls-connection-id-06 about the IANA consideration section. I believe this issue is closed.

multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. <ins> An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for  <ins> connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS. Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType  <ins> Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>


6.  dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'. contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 7. </del>  The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. <del> In addition, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to </del>  communicate per-connection information to on-path observers.  There <del> is no straightforward way to address this with CIDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this extension unsuitable for mobility scenarios where correlation must be considered. Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a client/server pair do a rehandshake to change CID, that does not provide much privacy benefit. The CID-enhanced record layer introduces record padding; a privacy feature not available with the original DTLS 1.2 RFC.  Padding allows to inflate the size of the ciphertext making traffic analysis more difficult.  More details about the padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. </del>  <del> 8. </del>  IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

The part of PR didn't made to the draft, or did I miss it? In the meantime, I would even go further: Applying and may validates the record cryptographically, and so the receive windows may be updated and the application data may be forwarded. But, if the epoch/sequencenumber is not newer than the newest successfully validate epoch/sequencenumber before, the address update event itself may be wrong! Assuming, that a address-change is located somewhere on the message's route, it seems to be not possible to distinguish, if the message was delayed after the "address change" (and so that address is deprecated) or before that (and so the address would be the new one). If that could not be decided, I would go for updating the address only for newer records. Using that approach, updating the address only for newer records (based on epoch/sequence_number) with validated , would also mitigate the first two attacks of issue , though retransmitting an record with changed address will not update the address, because these records are NOT newer.
I have updated the text of URL and was wondering whether it captures your issue. I am not sure what steps I have to take to meet your requirements.
As long as doesn't get mandatory (MUST), everything for me will be OK. So, yes, PR addresses it in the right way.
It looks like closes this issue?
Thanks!
The changes look good to me.This split makes sense to me. Thanks for making the change!

6. <ins> When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following conditions are met: The received datagram has been cryptographically verified using the DTLS record layer processing procedures. The received datagram is "newer" (in terms of both epoch and sequence number) than the newest datagram received.  Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted.  This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service.  An attacker might be able to succeed in changing a peer address if they are able to rewrite source addresses and if replayed packets are able to arrive before any original. There is a strategy for ensuring that the new peer address is able to receive and process DTLS records.  No such test is defined in this specification. The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms.  When delivered such an event, an application layer-specific address validation mechanism can be triggered, for example one that is based on successful exchange of minimal amount of ping-pong traffic with the peer.  Alternatively, an DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc. 7. </ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'. contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well.  <ins> 8. </ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973.  <ins> An on-path adversary observing the DTLS protocol exchanges between the DTLS client and the DTLS server is able to link the observed payloads to all subsequent payloads carrying the same ID pair (for bi-directional communication).  Without multi-homing or mobility, the use of the CID exposes the same information as the 5-tuple. With multi-homing, a passive attacker is able to correlate the communication interaction over the two paths and the sequence number makes it possible to correlate packets across CID changes.  The lack of a CID update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered. Deployments that use DTLS in multi-homing environments and are concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number encryption is available. The specification introduces record padding for the CID-enhanced record layer, which is a privacy feature not available with the original DTLS 1.2 specification.  Padding allows to inflate the size of the ciphertext making traffic analysis more difficult.  More details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. Finally, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to </ins> communicate per-connection information to on-path observers.  There  <ins> is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspects SHOULD refuse to use CIDs. </ins>  <ins> 9. An on-path adversary can create reflection attacks against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged between two DTLS peers is able to replay datagrams with modified IP address/port numbers. The topic of peer address updates is discussed in peer-address- update. 10. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for


different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received <del> datagram unless the following conditions are met: </del>  The received datagram has been cryptographically verified using the DTLS record layer processing procedures. to receive and process DTLS records.  No such test is defined in this specification. <del> The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. </del>  Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc.  7. dtls-example2 shows an example exchange where a CID is used uni-

Here's an alternative suggestion - WDYT, NAME NAME Instead of write: It's a bit long, though.
I don't want to speak for NAME :-), but I think he's arguing for a wider scope than just "When a record with a CID is received"
FMPOV that describes the increment introducing CID in the scope of MAC validation and alert generation.
Let me try to point to the difference of the current text and my proposal above: If the address hasn't changed since the last "validation", should a peer chose the option of to ? If the address has changed, then a peer may choose that option but must not send badrecordmac alert? In my opinion, this option to "alert" should not be chosen for CID. Therefore, I would point to that option in RFC 6347 and recommend not to use it with CID.
Imagine the following: server S has an active session with client A using CID=1 S crashes and restarts a new session using CID=1 is successfully established between S and client B A sends a record with CID=1 MAC verification fails for the record If at this point S decides not* to follow the recommendation in and instead replIes to B (since A's address has not been validated) with a fatal MAC failure alert, a perfectly valid session would be killed.
Why should Server S send any record to B, when receiving and record from A with a different address?
It can't send it to A because per A is not a validated peer (crypto fails on the received record). If S decided to send anything back, it could only send to B, which is the validated peer for CID=1.
Wouldn't it be a general rule, not to sent any response to different addresses?
Please see , last paragraph. PR strengthens the SHOULD to a MUST.
I still think, that generally no answer should be send to a different address. That will no be only true for alerts, it is generally true. Reading The termination of the connection state is independent from introducing CID. (Therefore "a perfectly valid session would be killed." is the specified consequence of sending alert rather than something new and unknown introduced by CID.) If a specification got somehow more complex, and so introduce misunderstandings, I would prefer to have general rules instead of introducing context sensitive rules.
What are you suggesting exactly?
For me this look like, there is no additional risk. Using the option to choose to generate an alert is specified including the consequences. Assuming spoofing for "None-CID" traffic, introducing CID doesn't add new risks. So, nothing need to be added. Maybe, if wanted, an additional hint, that with CID it may be easier to sent records with invalid MAC and so choosing to generate an alert should be well reconsidered though it would be mostly the wrong approach.
But there is a risk that is worth pointing out and fixing. Even if it's only incremental value.
As long as it is clear, that the general risk was always there and CID makes it more probable to terminate the connection state accidentally.
I added a . In my opinion, this describes the higher risk and the resulting MUST NOT for alerts at the right place without limiting the processing in other scopes.
Looks good to me

different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received  <ins> datagram unless the following three conditions are met: </ins> The received datagram has been cryptographically verified using the DTLS record layer processing procedures. to receive and process DTLS records.  No such test is defined in this specification.  <ins> The conditions above are necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks.  Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. </ins> Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc. <ins> DTLS implementations MUST silently discard records with bad MACs or that are otherwise invalid. </ins> 7. dtls-example2 shows an example exchange where a CID is used uni-


The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer).  The length MUST NOT exceed 2^14.  Note "+" denotes concatenation. 5.1. The following MAC algorithm applies to block ciphers that do not use the with Encrypt-then-MAC processing described in RFC7366.  5.2. The following MAC algorithm applies to block ciphers that use the

I added a placeholder seqnum in order to put the tls12cid in the right place. Note that I also did not add an ivlength. This is implicit in the ciphersuite selection and so you'd have to be making some quite strong assumptions to have the ivlength be necessary, it seems, and that's already the way things were without the CID, so presumably if those obtained you could still mount an attack.
NAME WDYT?
In my opinion, there is no reason to use a fixed head with "0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x19".
Well, I think I've explained the rationale for it in the text. Do you believe that the claimed properties are incorrect or merely that they're not necessary?
I understand your explanation to put 0xff 8 times in the front of the marker copy of tlscid. Though that results in a fixed header of 9 bytes, I'm curious, why that should improve the MAC. So back to my question before, why should there be the marker copy of the tlscid in front at all? It was said, that all versions use such marker (maybe that's also a misunderstanding). But at least, for 1.2, such markers wasn't the case. So, the discussion starts with: Why should the , a copy of something, which is already in the MAC, be additionally at the begin? Anyway, if the explanation gets too complex, and others don't feel curious as well, there is also no reason not to agree on that MAC definition of this PR; it could be obviously calculated.
Let me add: I'm not too happy with this proposal. But I will be even more unhappy, if this turns into a endless discussion. I would prefer some signs from others (NAME NAME if they are OK with it. Not to start in some weeks again with discussing the MAC over and over ...
The idea here is to provide domain separation between the MAC inputs when CID is in use and when it is not, for the reason Ben indicated, namely ensuring that an active attacker cannot create confusion about the inputs to the MAC. When CID is not in use, the first bytes are the 8-byte epoch/seq and the content type. Thus, if we want to ensure that the input is different when in use, then we must have 8 placeholder bytes and a different content type (or some other fixed-position distinguisher).
Isn't there is already a separator? In my opinion, the record-type does already provide that! All MAC starts with 8 bytes (epoch +seqn) followed by the record-type. Though that record-type of cid-records already differ from the other, non-cid, record-types, I simply don't see the benefit. An non-cid application-record use 0x17 at the 9th byte, with cid an application-record use 0x19.
Yes, that would be true if we weren't also moving the sequence number to make the DTLS header input into the MAC as-is rather than broken apart as it currently is. Once you've done that, then the type byte would be somewhere later in the packet -- in the version number if I am counting correctly.
I start to understand: In difference to RFC6347, now the header goes as on the wire into the MAC. For that, a artificial dummy header (fixed 9 byte) is put again in front of that, in order to ensure, that this differs from other records. Also as consequence, the cid-length is now between the dummy-header and the on-wire header.
LGTM
Good catch on the . Still looks good.
Duh. One more piece of evidence that it's hard to edit yourself. Updated.
NAME this LGTM. Let's run this past the list!
I am OK with the changes. It is time to wrap this work up.

The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer).  The length MUST NOT exceed 2^14. <ins> 8 bytes of 0xff </ins> Note "+" denotes concatenation. 5.1. The following MAC algorithm applies to block ciphers that do not use the with Encrypt-then-MAC processing described in RFC7366. <ins> The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the connection ID.  The former always consists of a sequence number followed by some other content type than tls12_cid; the latter always consists of the seq_num_placeholder followed by tls12_cid.  Although 2^64-1 is potentially a valid sequence number, tls12_cid will never be a valid content type when the connection ID is not in use.  In addition, the epoch and sequence_number are now fed into the MAC in the same order as they appear on the wire. </ins> 5.2. The following MAC algorithm applies to block ciphers that use the


extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to <del> always recieve CIDs of a fixed length.  If, however, an </del>  implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus, 5.1. The following MAC algorithm applies to block ciphers that do not use <del> the with Encrypt-then-MAC processing described in RFC7366. </del>  The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered.  Deployments that use DTLS in multi-homing environments and are concerned about <del> this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number </del>  encryption is available. The specification introduces record padding for the CID-enhanced

Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >

extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to  <ins> always receive CIDs of a fixed length.  If, however, an </ins> implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus, 5.1. The following MAC algorithm applies to block ciphers that do not use  <ins> the Encrypt-then-MAC processing described in RFC7366. </ins> The rationale behind this construction is to separate the MAC input for DTLS without the connection ID from the MAC input with the update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered.  Deployments that use DTLS in multi-homing environments and are concerned about  <ins> these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number </ins> encryption is available. The specification introduces record padding for the CID-enhanced


10. <del> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del>  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. <del> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </del>

10.  <ins> This document requests three actions by IANA. 10.1. IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described in the table below. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13.  <ins> 10.3. IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType" registry.  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>


extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does <del> not wish the client to include a CID (or again, alternately, to use a zero-length CID). </del>  Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for themselves begin other handshakes.  When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh. <del> If DTLS peers have not negotiated the use of CIDs then the RFC 6347-defined record format and content type MUST be used. </del>  <del> If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages then the peers need to take the following steps. </del>  <del> The DTLS peers determine whether incoming and outgoing messages need to use the new record format, i.e., the record format containing the CID.  The new record format with the the tls12_cid content type is only used once encryption is enabled.  Plaintext payloads never use the new record type and the CID content type. </del>  For sending, if a zero-length CID has been negotiated then the RFC 6347-defined record format and content type MUST be used (see

Clarify that successfully negotiating two zero-len CIDs is the same as failing the negotiation in terms of what happens on the wire afterwards.
For me, this PR makes it clearer and better understandable.
Tom Petch's review: URL
My feeling: remove "(or again, alternately, to use a zero-length CID)" and add: The text following that seems to introduce first the idea of a "zero-length CID", and later use that to negate the use of tlscid record. It may be more straight forward, if the "zero-length CID" is scoped to the ClientHello and the ServerHello extensions, and later the use of a tlscid record is then only caused for a non-empty CID.
What's here is good, but see inline on whether we should do a little more. Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >

extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value indicates that the server will send with the client's CID but does  <ins> not wish the client to include a CID. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for themselves begin other handshakes.  When a DTLS session is resumed or renegotiated, the "connection_id" extension is negotiated afresh.  <ins> If DTLS peers have not negotiated the use of CIDs, which includes the case where both sent a zero-length cid in their connection_id extensions, then the RFC 6347-defined record format and content type MUST be used. </ins>  <ins> If DTLS peers have negotiated the use of a non-zero-length CID in at least one direction using the ClientHello and the ServerHello messages, then the peers need to take the following steps. </ins>  <ins> The DTLS peers determine whether incoming or outgoing (or both) messages need to use the new record format, i.e., the record format containing the CID.  The new record format with the the tls12_cid content type is only used once encryption is enabled.  Plaintext payloads never use the new record type and the CID content type. </ins> For sending, if a zero-length CID has been negotiated then the RFC 6347-defined record format and content type MUST be used (see


Corresponds to the fragment of a given length. <del> The content type describing the payload. </del>  An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for

Russ Housley's secdir review: URL Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-dtls-connection-id-10 Reviewer: Russ Housley Review Date: 2021-03-15 IETF LC End Date: 2021-03-28 IESG Telechat date: Unknown Summary: Ready Major Concerns: None. Minor Concerns: None. Nits: Section 4: For increased clarity, I suggest: OLD: realtype The content type describing the payload. NEW: realtype The content type describing the cleartext payload.

Corresponds to the fragment of a given length.  <ins> The content type describing the cleartext payload. </ins> An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for


before cryptographically validating the enclosed record(s) but instead perform a return routability check. <del> The newly introduced "return_routability_check" message contains a cookie.  The cookie is a 8-byte field containing arbitrary data. </del>  The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. 5.  The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: <del> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </del>  The message is sent to the observed new address and a timer T (see <del> timer-choice) is started; </del>  The peer endpoint, after successfully verifying the received "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type <del> path_response; </del>  When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it <del> updates the peer address binding; </del>  If T expires, or the address confirmation fails, the peer address binding is not updated. for the initiator and responder roles, broken down per protocol phase. <del> 5.1. </del>  The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. <del> 5.2. </del>  <del> The responder MUST NOT delay sending an elicited path_response message. </del>  <del> The responder MUST send exactly one path_response messages for each received path_request. </del>  <del> The responder MUST send the path_response on the network path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions. The initiator MUST NOT enforce this behaviour </del>  The initiator MUST silently discard any invalid path_response it receives. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. <del> 5.3. </del>  When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value. <del> 6. </del>  The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC However, the server wants to test the reachability of the client at his new IP address. <del> 7. </del>  Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 8. </del>  IANA is requested to allocate an entry to the TLS "ContentType" <del> registry, for the "return_routability_check(TBD2)" defined in this document.  The "return_routability_check" content type is only </del>  applicable to DTLS 1.2 and 1.3. IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <del> 9. </del>  Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 10. </del>  We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this

Address
Martin Duke's ballot comment on draft-ietf-dtls-connection-id referenced the procedures of URL (which operates in essentially the same security model as DTLS) including the use of a path challenge for both old and new paths. We may want to have some similar discussion in this document.
The idea of that probe was to check, if the old address is also still valid. That would prevent an attack, where both peers are using CID and an eye-spotting attacker with high SLA prepares to get on path in order to drop then the traffic. With that, I would prefer, to have this as choice, to check this either always, or only, if the peer doesn't respond on the new path.
Copy from RFC 9000: Off-Path Packet Forwarding An off-path attacker that can observe packets might forward copies of genuine packets to endpoints. If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding. 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. This style of attack relies on the attacker using a path that has approximately the same characteristics as the direct path between endpoints. The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack. A non-probing packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path. Eliciting packets on this path increases the likelihood that the attack is unsuccessful. Therefore, mitigation of this attack relies on triggering the exchange of packets. In response to an apparent migration, endpoints MUST validate the previously active path using a PATHCHALLENGE frame. This induces the sending of new packets on that path. If the path is no longer viable, the validation attempt will time out and fail; if the path is viable but no longer desired, the validation will succeed but only results in probing packets being sent on the path. An endpoint that receives a PATHCHALLENGE on an active path SHOULD send a non-probing packet in response. If the non-probing packet arrives before any copy made by an attacker, this results in the connection being migrated back to the original path. Any subsequent migration to another path restarts this entire process. This defense is imperfect, but this is not considered a serious problem. If the path via the attack is reliably faster than the original path despite multiple attempts to use that original path, it is not possible to distinguish between an attack and an improvement in routing. 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; similarly, rebinding is rare on IPv6 paths. Endpoints can also look for duplicated packets. Conversely, a change in connection ID is more likely to indicate an intentional migration rather than an attack.
There are no available "non-probing" packets in DTLS. Should we mint a new "no-op" record type for this?
Addressed by

before cryptographically validating the enclosed record(s) but instead perform a return routability check.  <ins> The cookie is a 8-byte field containing arbitrary data. </ins> The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. 5. <ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints.  If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding.  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. This style of attack relies on the attacker using a path that has approximately the same characteristics as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack. 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.  Eliciting packets on this path increases the likelihood that the attack is unsuccessful. fig-off-path demonstrates the case where a receiver receives a packet with a new source IP address and/or new port number.  The receiver needs to determine whether this path change is caused by an attacker and will send a RRC message of type path_challenge (RRC-1) on the old path. Three cases need to be considered: Case 1: The old path is dead, which leads to a timeout of RRC-1. As shown in fig-old-path-dead, a RRC message of type path_challenge (RRC-2) needs to be sent on the new path.  In this situation the switch to the new path is considered legitimate.  The sender will reply with RRC-3 containing a path_response on the new path. Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender replies with a RRC-2 path_delete message on the old path.  This triggers the receiver to send RRC-3 with a path-challenge along the new path.  The sender will reply with RRC-4 containing a path_response along the new path. Case 3: The old path is alive and preferred. This is most likely the result of an attacker.  The sender replies with RRC-2 containing a path_response along the old path.  The interaction is shown in fig-old-path-preferred.  This results in the connection being migrated back to the old path. Note that this defense is imperfect, but this is not considered a serious problem.  If the path via the attack 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. 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; similarly, rebinding is rare on IPv6 paths.  Endpoints can also look for duplicated packets.  Conversely, a change in connection ID is more likely to indicate an intentional migration rather than an attack.  Note, however, changes in connection IDs are only supported in DTLS 1.3 but not in DTLS 1.2. 6. Note: This algorithm does not take the off-path scenario into account. </ins> The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows:  <ins> The receiver creates a "return_routability_check" message of type path_challenge and places the unpredictable cookie into the message. </ins> The message is sent to the observed new address and a timer T (see  <ins> timer-choice) is started. </ins> The peer endpoint, after successfully verifying the received "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type  <ins> path_response. </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it  <ins> updates the peer address binding. </ins> If T expires, or the address confirmation fails, the peer address binding is not updated. for the initiator and responder roles, broken down per protocol phase.  <ins> 7. Note: This algorithm also takes the off-path scenario into account. The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: The receiver creates a "return_routability_check" message of type path_challenge and places the unpredictable cookie into the message. The message is sent to the previously valid address, which corresponds to the old path.  Additionally, a timer T, see timer- choice, is started. The peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on the preference of the path through which the message was received: If the path through which the message was received is preferred, a "return_routability_check" message of type path_response MUST be returned. If the path through which the message was received is not preferred, a "return_routability_check" message of type path_delete MUST be returned.  In either case, the peer endpoint echoes the cookie value in the response. The initiator receives and verifies that the "return_routability_check" message contains the previously sent cookie.  The actions taken by the initiator differ based on the received message: When a "return_routability_check" message of type path_response was received, the initiator MUST continue using the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated. When a "return_routability_check" message of type path_delete was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. If T expires, or the address confirmation fails, 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 regular. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. 7.1. </ins> The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable.  <ins> 7.2. </ins>  <ins> The responder MUST NOT delay sending an elicited path_response or path_delete messages. </ins>  <ins> The responder MUST send exactly one path_response or path_delete message for each received path_challenge. </ins>  <ins> The responder MUST send the path_response or the path_delete on the path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour. </ins> The initiator MUST silently discard any invalid path_response it receives. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure.  <ins> 7.3. </ins> When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value.  <ins> 8. </ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC However, the server wants to test the reachability of the client at his new IP address.  <ins> 9. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  <ins> 10. </ins> IANA is requested to allocate an entry to the TLS "ContentType"  <ins> registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only </ins> applicable to DTLS 1.2 and 1.3. IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext.  <ins> 11. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues  <ins> 12. </ins> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this


Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender <del> replies with a "path_delete" message (2) on the old path.  This </del>  triggers the receiver to send a "path_challenge" (3) on the new path. The sender will reply with a "path_response" (4) on the new path, thus providing confirmation for the path migration. If the path through which the message was received is not preferred, a "return_routability_check" message of type <del> "path_delete" MUST be returned.  In either case, the peer </del>  endpoint echoes the cookie value in the response. The initiator receives and verifies that the the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated. <del> When a "return_routability_check" message of type "path_delete" </del>  was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. 7.2. The responder MUST NOT delay sending an elicited "path_response" <del> or "path_delete" messages. </del>  <del> The responder MUST send exactly one "path_response" or "path_delete" message for each received "path_challenge". </del>  <del> The responder MUST send the "path_response" or the "path_delete" on the path where the corresponding "path_challenge" has been </del>  received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour.

Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop

Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender  <ins> replies with a "path_drop" message (2) on the old path.  This </ins> triggers the receiver to send a "path_challenge" (3) on the new path. The sender will reply with a "path_response" (4) on the new path, thus providing confirmation for the path migration. If the path through which the message was received is not preferred, a "return_routability_check" message of type  <ins> "path_drop" MUST be returned.  In either case, the peer </ins> endpoint echoes the cookie value in the response. The initiator receives and verifies that the the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated.  <ins> When a "return_routability_check" message of type "path_drop" </ins> was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. 7.2. The responder MUST NOT delay sending an elicited "path_response"  <ins> or "path_drop" messages. </ins>  <ins> The responder MUST send exactly one "path_response" or "path_drop" message for each received "path_challenge". </ins>  <ins> The responder MUST send the "path_response" or the "path_drop" on the path where the corresponding "path_challenge" has been </ins> received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour.


4. <del> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP address and port number with the source specified in the UDP datagram before cryptographically validating the enclosed record(s) but instead perform a return routability check. </del>  <del> The cookie is a 8-byte field containing arbitrary data. </del>  The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context.  5.  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 changes in connection IDs are supported in DTLS 1.3 but not in DTLS 1.2. <del> 6. </del>  Note: This algorithm does not take the off-path scenario into account. for the initiator and responder roles, broken down per protocol phase. <del> 7. </del>  Note: This algorithm also takes the off-path scenario into account. for the initiator and responder roles, broken down per protocol phase. <del> 7.1. </del>  The initiator MAY send multiple "return_routability_check" messages of type "path_challenge" to cater for packet loss on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. <del> 7.2. </del>  The responder MUST NOT delay sending an elicited "path_response" or "path_drop" messages. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. <del> 7.3. </del>  When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original.

Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.

4.  <ins> This document defines the "return_routability_check" content type (fig-rrc-msg) to carry Return Routability Check protocol messages. </ins>  <ins> The protocol consists of three message types: "path_challenge", "path_response" and "path_drop" that are used for path validation and selection as described in path-validation. Each message carries a Cookie, a 8-byte field containing arbitrary data. </ins> The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <ins> Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able to parse and ignore unknown values. </ins> 5. <ins> RRC offers an in-protocol mechanism to perform peer address validation, thus complementing the "peer address update" procedure described in RFC9146.  Specifically, when both CID 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 the one previously associated with that CID value, the receiver SHOULD perform a return routability check as described in path-validation. 6. </ins> 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 changes in connection IDs are supported in DTLS 1.3 but not in DTLS 1.2.  <ins> 7. 7.1. </ins> Note: This algorithm does not take the off-path scenario into account. for the initiator and responder roles, broken down per protocol phase.  <ins> 7.2. </ins> Note: This algorithm also takes the off-path scenario into account. for the initiator and responder roles, broken down per protocol phase.  <ins> 7.3. </ins> The initiator MAY send multiple "return_routability_check" messages of type "path_challenge" to cater for packet loss on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable.  <ins> 7.4. </ins> The responder MUST NOT delay sending an elicited "path_response" or "path_drop" messages. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure.  <ins> 7.5. </ins> When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original.


6.  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 After this point, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.2. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.3.

Section 5 title "Off-path packet forwarding" should be "Attack model" instead? Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics. There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."

6. <ins> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. 6.1. </ins> 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 After this point, any pending send operation is resumed to the bound peer address.  <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.2. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address.  <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.3.


7. <del> 7.1. </del>  <del> Note: This algorithm does not take the off-path scenario into account. </del>  <del> The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del>  The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the value in a "return_routability_check" message of type "path_response". <del> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it updates the peer address binding. If T expires, or the address confirmation fails, the peer address binding is not updated. </del>  <del> After this point, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.2. <del> Note: This algorithm also takes the off-path scenario into account. The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the message. corresponds to the old path.  Additionally, a timer T, see timer- choice, is started. <del> The peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on the preference of the path through which the message was received: </del>  If the path through which the message was received is preferred, a "return_routability_check" message of type was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. <del> If T expires, or the address confirmation fails, 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 regular. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del>  7.3.

factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."

7.  <ins> The receiver that observes the peer's address or port update MUST stop sending any buffered application data, or limit the data sent to the unvalidated address to the anti-amplification limit. </ins>  <ins> It then initiates the return routability check that proceeds as described either in enhanced or regular, depending on whether the off-path attacker scenario described in off-path is to be taken into account or not. </ins>  <ins> (The decision on what strategy to choose depends mainly on the threat model, but may also be influenced by other considerations.  Examples of impacting factors include: the need to minimise implementation complexity, privacy concerns, the need to reduce the time it takes to switch path.  The choice may be offered as a configuration option to the user.) After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. 7.1. </ins> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the value in a "return_routability_check" message of type "path_response".  <ins> When the initiator receives the "return_routability_check" message and verifies that it contains the sent cookie, it updates the peer address binding. </ins>  <ins> If T expires the peer address binding is not updated. </ins> 7.2.  The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the message. corresponds to the old path.  Additionally, a timer T, see timer- choice, is started.  <ins> If the path is still functional, the peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on whether the path through which the message was received is the preferred one or not anymore: </ins> If the path through which the message was received is preferred, a "return_routability_check" message of type was received, the initiator MUST perform a return routability check on the observed new address, as described in regular.  <ins> 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 regular. </ins> 7.3.


functional in both directions.  The initiator MUST NOT enforce this behaviour. <del> The initiator MUST silently discard any invalid "path_response" it receives. </del>  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

Signed-off-by: Thomas Fossati
We say: "The initiator MUST silently discard any invalid pathresponse it receives." we should say instead: "The initiator MUST silently discard any invalid pathresponse or pathdrop it receives."_

functional in both directions.  The initiator MUST NOT enforce this behaviour.  <ins> The initiator MUST silently discard any invalid "path_response" or "path_drop" it receives. </ins> 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


6. <del> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. </del>  6.1.  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

fix/improve the "attacker model" section Signed-off-by: Thomas Fossati
CC NAME
At the top of the "Attacker model" section we say: "RRC is not designed to counter on-path attackers." What we should say instead is "RRC is not designed to counter man-in-the-middle attackers." We do take care of on-path attackers, via the challenge/response exchange, and we should say that.
I don't think the CR exchange solves the problem, because the attacker can just change the IP addresses.

6.  <ins> RRC is not designed to counter man-in-the-middle attackers.  These can never be distinguished from a genuine network device.  Instead, the types of attacker RRC is designed to withstand are: On-path attackers that try to trigger a connection migration (on- path); Off-path attackers that try to put themselves on-path (off-path) - provided that the enhanced path validation algorithm is used, see enhanced. </ins> 6.1. <ins> An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination.  If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped. The subsequent path validation (path-validation) will fail because the entity at the (spoofed) source address does not have the cryptographic keys needed to decode the "path_challenge" message that is sent to it, and therefore to produce the corresponding "path_response".  Since the path validation fails, the address binding is not altered, thus thwarting the attack. 6.2. </ins> 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


3.  When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP After this point, any pending send operation is resumed to the bound peer address. <del> 4. </del>  <del> The example shown in fig-rrc-example illustrates a client and a server exchanging application payloads protected by DTLS with an unilaterally used CIDs.  At some point in the communication interaction the IP address used by the client 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 his new IP address, to avoid being abused (e.g., as an amplifier) by an attacker impersonating the client. </del>  <del> 5. </del>  Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 6. </del>  <del> IANA is requested to allocate an entry to the existing TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </del>  <del> 7. </del>  Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 8. </del>  We would like to thank Achim Kraus, Hanno Becker and Manuel Pegourie- Gonnard for their input to this document.

Updated draft based on feedback from the working group. The following changes have been made: Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section
added a few inline suggestions

3. <ins> This specification uses the tls_flags extension defined in I-D.-ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). 4. </ins> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP After this point, any pending send operation is resumed to the bound peer address.  <ins> 5. </ins>  <ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC extension. </ins>  <ins> Once a connection has been established the client and the server exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for records sent to the server. At some point in the communication interaction the IP address used by the client 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 his new IP address. 6. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  <ins> 7. </ins>  <ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </ins>  <ins> IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y Reference: [[This document]] 8. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues  <ins> 9. </ins> We would like to thank Achim Kraus, Hanno Becker and Manuel Pegourie- Gonnard for their input to this document.


CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as <del> described in path-validation. </del>  6.

Signed-off-by: Thomas Fossati
cc NAME
Works for me.
When discussing that in RFC9146, my consideration was, that a "similar mechanism" maybe used also on the next layer. With that, I would consider
Just to mention, for me the idea of UDP is: Do, what could be done, but be also open, to delegate functions to the next layer, if it could be done there maybe more efficient. Therefore RRC with DTLS is great as one option, but other options in upper layers should not be discredited.

CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as  <ins> described in path-validation, unless an application layer specific address validation mechanism can be triggered instead. </ins> 6.


Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able <del> to parse and ignore unknown values. </del>  5.

Signed-off-by: Thomas Fossati
cc NAME
Works for me.
What are the considerations about that select? For me it looks like all "cases" are the same? Do I oversee something?
Maybe the idea of that select is a "future extension". If so, "ignore unknown values" includes, to skip what ever follows, or? Then maybe
Yep, exactly: RRC is not closed (see URL) so the select anticipates extensions that might need a value different from Cookie.
Thanks. WDYT about the extended formulation:
I think the current text is already saying what you propose :-) In the context of the paragraph, there is no "rest of the RRC message" that isn't the "unknown value", so the addition seems redundant to me. NAME WDYT?
Assuming: If is unknown, what is then to be ignored? Maybe:
This is exactly what I wanted the current text to say. Apparently I failed :-) I'll do the suggested tweak.

Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able  <ins> to parse and ignore messages with an unknown "msg_type". </ins> 5.


described in RFC9146.  Specifically, when both CID 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 <del> datagram different from the one previously associated with that CID </del>  value, the receiver SHOULD perform a return routability check as described in path-validation, unless an application layer specific address validation mechanism can be triggered instead.

Signed-off-by: Thomas Fossati
cc NAME
works for me
For me the is misleading. My understanding was, that RFC9146 recommend to not update the association before passing the address check. So, for me "currently" may be the better choice.

described in RFC9146.  Specifically, when both CID 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  <ins> datagram different from the one currently associated with that CID </ins> value, the receiver SHOULD perform a return routability check as described in path-validation, unless an application layer specific address validation mechanism can be triggered instead.


5. RRC offers an in-protocol mechanism to perform peer address <del> validation, thus complementing the "peer address update" procedure </del>  described in RFC9146.  Specifically, when both CID 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 6. <del> RRC is designed to withstand the following attacks: </del>  <del> On-path attackers that try to trigger a connection migration (on- path); </del>  <del> Off-path attackers that try to put themselves on-path (off-path) - provided that the enhanced path validation algorithm is used, see enhanced. </del>  <del> It is not possible for RRC to counter a man-in-the-middle attacker that is indistinguishable from a genuine network device.  Such an attacker could, for example, drop, reorder or delay records at will. Man-in-the-middle attackers cannot craft DTLS records that would successfully pass verification due to the cryptographic protections applied by the DTLS record layer. </del>  6.1. <del> An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination.  If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped. The subsequent path validation (path-validation) will fail because the entity at the (spoofed) source address does not have the cryptographic keys needed to decode the "path_challenge" message that is sent to it, and therefore to produce the corresponding "path_response".  Since the path validation fails, the address binding is not altered, thus thwarting the attack. </del>  6.2.

Signed-off-by: Thomas Fossati
cc NAME
From my side LGTM.
For me, "man-in-the-middle" is a synonym for "on-path". If that text addresses the general "on-path" attacks in order to clarify, that RRC is no mitigation for these general "on-path-attacks", I think we should try to find an other text. As idea, we may also refer to ideas to mitigate them, but explicitly exclude that from this draft. e.g.: "reorder": don't use the record sequence number window, just drop all packets with no higher number (that drops then reordered packets). "delay records": maybe the first idea for an extension: execute a fresh RRC exchange and the next ip-packet must have a record sequence number higher as the one of the RRC message.
Right, we need to align the terminology. I propose we use the with its three levels: Inspect Inject Reorder injected ——— Off-path ——— Reorder original Modify un-authenticated portions ——— Limited on-path ——— Delay Drop Manipulating the packetization layer ——— On-path ——— and work from there.
I miss, that I'm not sure, if we should "repeat" that. Do you know, if it's possible to just refer to that?
If it works for us as-is we can just reference the relevant sections. We need to check that everything applies -- in particular whether we want to make the distinction between "on-path" and "limited on-path".
In difference to the on-path attack, where the original packet (with the original source address) simply may get dropped, and so never reaches the destination, the off-path attack is not able to drop that original packet. Though also this attack is based on a response to that "malicious source address", a implementation may use the "internal processing delay" and check, if the same packet with the original address arrives. If so, and if that address matches the previously associated address, then the implementation may chose to use the previously associated address.
For me this looks more like the off-path case. On-path attacker may just replace the original package and only forward the spoofed one.
See also my comment on . We need to rework this section starting from establishing shared terminology.

5. RRC offers an in-protocol mechanism to perform peer address  <ins> validation that complements the "peer address update" procedure </ins> described in RFC9146.  Specifically, when both CID 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 6.  <ins> We define two classes of attackers, off-path and on-path, with increasing capabilities (see fig-attacker-capabilities) partly following terminology introduced in QUIC RFC9000: </ins>  <ins> An off-path attacker is not on the original path between the DTLS peers, but is able to observe packets on the original path and has faster routing compared to the DTLS peers, which allows it to make copies of the observed packets, race its copies to either peer and consistently win the race. </ins>  <ins> 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. </ins>  <ins> 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. RRC is designed to defend against the following attacks: On-path and off-path attackers that try to create an amplification attack by spoofing the source address of the victim (sec- amplification). Off-path attackers that try to put themselves on-path (off-path), provided that the enhanced path validation algorithm is used (enhanced). </ins> 6.1.  <ins> Both on-path and off-path attackers can send a packet (either by modifying it on the fly, or by copying, injecting and racing it, respectively) with the source address modified to that of a victim host.  If the traffic generated by the server in response is larger compared to the received packet (e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET request) the attacker can use the server as a traffic amplifier toward the victim. When receiving a packet with a known CID and a spoofed source address, an RRC-capable endpoint will not send a (potentially large) response but instead a small "path_challenge" message to the victim host.  Since the host is not able to decrypt it and generate a valid "path_response", the address validation fails, which in turn keeps the original address binding unaltered. Note that in 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. </ins> 6.2.


12. <del> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this document. </del>

Signed-off-by: Thomas Fossati
Also, remove NAME who's now a co-author.

12.  <ins> We would like to thank Hanno Becker, , , Mohit Sahni and Rich Salz for their input to this document. </ins>


8. <del> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC </del>  extension. Once a connection has been established the client and the server <del> exchange application payloads protected by DTLS with an unilaterally used CIDs.  In our case, the client is requested to use CID 100 for </del>  records sent to the server. At some point in the communication interaction the IP address used by the client 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 <del> his new IP address. </del>  9.

/cc NAME Signed-off-by: Thomas Fossati
This is important and so the example should show it.
The draft splits the probes in and . The example demonstrates the so I think, we should add that to the figure description "Basic Return Routability Example".

8.  <ins> In the example TLS 1.3 handshake shown in fig-handshake, a client and a server successfully negotiate support for CID as well as the RRC </ins> extension. Once a connection has been established the client and the server  <ins> exchange application payloads protected by DTLS with a unilaterally used CID.  In our case, the client is requested to use CID 100 for </ins> records sent to the server. At some point in the communication interaction the IP address used by the client 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  <ins> its new IP address. fig-rrc-example shows the server initiating a "basic" RRC exchange (see regular) that establishes reachability of the client at the new IP address. </ins> 9.