# Internet AD comments for draft-ietf-tls-dtls-rrc-18
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6

* A brief explanation of what is meant by "nested rebinding" would be good.

### S6.{2,3,...}

* I think if I were implementing this I would try to probe both the old
  and the new paths at the same time.

  Can you say something about the considerations such an implementation
  would need to be aware of?

Hi Hannes, Achim, and Thomas, 

Thank you for the effort put into this specification. 

Thanks to Joe Clarke for the OPSDIR review and Thomas for positively addressing the comment. Much appreciated. 

I’m balloting Yes as this is a specification I would be happily sponsoring myself.

There are some few points that I think need some further considerations:

# Should we tag this document as updating RFC9146?

CURRENT:
   A client offering the
   “connection_id” extension SHOULD also offer the rrc extension, unless
   the application using DTLS has its own address validation mechanism.
 
Although this does not change anything in 9146, this new requirement is worth to be LOUDLY visible for 9146 implementer. 

# Deviation or compliance with the QUIC procedure?

## First, having a statement early in the document to say that this procedure is inspired from the RFC9000 connection migration procedure would be fair.

## I’m not sure if we have full adherence with the approach in RFC9000#Section 8.2 or there are deviations. At least, I see that we don’t have here an equivalent to disable_active_migration. Would it be possible please to have a statement whether we deviate or not from 9000 (and of so list those with the motivation for such deviations?). 

# Path and address control assumptions 

## Path assumptions

For example, Section 5 has the following:

CURRENT:
   For instance, NAT rebinding is improbable if
   packets were recently received on the old path; similarly, rebinding
   is rare on IPv6 paths.   

This puts assumptions on the path that may not be always valid. Also, I would not treat IPv6 as special here because NAT64 may be on-path.

Think about multi-homed address-rewriting devices (multi-homed CPEs with eventually CGNs/NAT64 in all or subset of the network attachment) that use some kind of packet scheduling rather than flow-based to distribute packet among available network attachments. Under such conditions, a client can be seen with distinct addresses. Such scenarios may be possible with UDP. Things are different for TCP, where such mechanisms may be problematic in the presence of firewall (e.g., an on-path stateful device may reject a segment if it didn’t observed a SYN). 

## Impossibility to adhere with a MUST

Section 6.2 has the following:

CURRENT: 
       *  If the path through which the message was received is no
          longer preferred, a return_routability_check message of type
          path_drop MUST be returned.  In either case, the peer echoes
          the cookie value in the response.

This text (and similar) makes an assumption on address control/path awareness of endpoints, which I think does not stand in many cases. 

The external address and forwarding path may not be under the control of the endpoint. It does not even know that the external address changes. Endpoints may use the same local address but distinct external addressed/forwarding paths

## Path control 

Section 6.4 has the following:

CURRENT:
   *  The responder MUST send the path_response or the path_drop on the
      path where the corresponding path_challenge has been received, so
      that validation succeeds only if the path is functional in both
      directions.

Endpoints does not have control on the path. Rather than reasoning on what is beyond their control, may be reason about interface by which a message was received or something this is under the control of an endpoint.

# Broken MUST?

Section 6.4 has the following

CURRENT:
   *  The responder MUST send exactly one path_response or path_drop
      message for each received path_challenge.

This should be applicable only for a valid received challenge message. Please reword.

# Lack of guards against frequent migration and connection oscillation

There might be cases where frequent address changes may be observed. Triggering the validation procedure too frequently may lead to instability. Should there be a guard to control the spacing of migration?

# Detailed comments

## The procedure check in the document is about forwarding, not routing.

## Terminology

### I suggest we grab the definition of “Address” from 9000 and use it through the document.

NEW:
  Address: When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network path.

### Incomplete list

CURRENT:
   The terms "peer" and "endpoint" are defined in Section 1.1 of
   [RFC8446].

The main text also used “client”. Consider adding it to that list.

## Section 3

CURRENT:
   The client and
   server MUST NOT use RRC unless both sides have successfully exchanged
   rrc extensions.  A client offering the “rrc” extension MUST also offer
   the connection_id extension [RFC9146].  

Consider reorder to follow the validation logic. I would place the second sentence first.

## Section 5

### I would move this section to be a subsection of the Security Considerations.

### Faster routing?!

CURRENT:
   *  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, 

I really don’t parse what is meant by faster routing. Please reword/clarify

### Attack types

CURRENT:
              .--> .------------------------------------. <--.
              |    | Inspect un-encrypted portions      |    |
              |    +------------------------------------+    |
              |    | Inject                             |    |
          off-path +------------------------------------+    |
              |    | Reorder                            |    |
              |    +------------------------------------+    |
              |    | Modify un-authenticated portions   | on-path
              '--> +------------------------------------+    |
                   | Delay                              |    |
                   +------------------------------------+    |
                   | Drop                               |    |
                   +------------------------------------+    |
                   | Manipulate the packetization layer |    |
                   '------------------------------------' <--'

                      Figure 2: Attacker capabilities

I would add “store” as an additional line for on-path. That can be used for replay attacks.

## Section 6

### Broken MUST

CURRENT:
   The receiver that observes the peer's address or port number change MUST
   stop sending any buffered application data, or limit the data sent to
   the unvalidated address to the anti-amplification limit.   

This absolute requirement is only valid assuming the extension is successfully validated. Please update accordingly.

Also, s/ The receiver/A receiver

### Hidden Operational Consideration

CURRENT (6):
  (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, and the need to
   reduce the time it takes to switch path.  The choice may be offered
   as a configuration option to the user of the TLS implementation.)


CURRENT (6.3):
      -  In general, the number of "backup" path_challenge messages
         depends on the application, since some are more sensitive to
         latency caused by changes in the path than others.  In the
         absence of application-specific requirements, the initiator can
         send a path_challenge message once per round-trip time (RTT),
         up to the anti-amplification limit.

Consider moving this text to be discussed under Operational Consideration section.

### Nested rebinding

CURRENT:
   Please note that the presented algorithms are not designed to handle
   nested rebindings.   

Can we be explicit about the case we are referring to? Is this the case of double NAT, for example? Else? 

## Random Data

CURRENT:
   Each path_challenge message MUST contain random data. 

Does that random data to be unique per challenge message? 

## Section 10

Maybe mention that detection of frequent paths probes is a signal of path instability and that such event can be used to diagnose underlying connectivity service.

## Section 11

### Indicate the registry group

OLD:
   IANA is requested to allocate an entry in the TLS ContentType
   Registry 
NEW:
   IANA is requested to allocate an entry in the TLS ContentType
   Registry under the “Transport Layer Security (TLS) Parameters” registry group

### Use the name used by IANA

OLD: 
   IANA is requested to create a new registry "RRC Message Types" within
   the TLS Parameters  

NEW:
   IANA is requested to create a new registry "RRC Message Types" within
   the Transport Layer Security (TLS) Parameters

## Misc.

### Section 1: 

* s/return routability check (RRC)/Return Routability Check (RRC)

* s/and/or port/and/or port number

* s/address (and port)/address (and port number)


### Section 5

(1)

OLD: We define two classes of attackers

NEW: Two classes of attackers are considered

(2)

OLD: a RRC message

NEW: an RRC message

### Section 7

OLD: 
   In the example DTLS 1.3 handshake shown in Figure 7, a client and a
   server successfully negotiate support for both CID and the RRC
   extension.

NEW:
   In the example of DTLS 1.3 handshake shown in Figure 7, a client and a
   server successfully negotiate support for both CID and the RRC
   extensions.

### Section 10

Per the guidance in draft-opsarea-rfc5706bis, it is recommended to put this section right before the security cons section.

### Global

* s/rrc extension/“rrc” extension (idem for other extensions

* s/Return Routability Check sub-protocol/RRC sub-protocol

Hope this helps.   

Cheers,
Med