Original text:
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.

Reviewer comments:
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

Revised text:
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.