Re: [quicwg/base-drafts] Pad path validation in both directions (#4241)

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

LG, but a few suggestions

> +A PATH_RESPONSE frame MUST be sent on the network path where the PATH_CHALLENGE
+was received.  This requirement MUST NOT be enforced by the endpoint that
+initiates path validation as that would enable an attack on migration; see
+{{off-path-forward}}.

I think this is a SHOULD not a MUST both because it's unenforceable and because future multicast use cases may need to not follow it.

```suggestion
A PATH_RESPONSE frame SHOULD be sent on the network path where the PATH_CHALLENGE
was received.  This ensures the path is functional in both directions.  This requirement
MUST NOT be enforced by the endpoint that initiates path validation as that would enable
an attack on migration; see {{off-path-forward}}.
```

> +least the smallest allowed maximum datagram size of 1200 bytes. This in
+combination with sending on the same path allows the endpoint that initiated
+path validation to verify that the path is able to carry datagrams of this size
+in both directions.

```suggestion
least the smallest allowed maximum datagram size of 1200 bytes. This verifies
that the path is able to carry datagrams of this size in both directions.
```

> +the data that was sent in a previous PATH_CHALLENGE frame.  This PATH_RESPONSE
+frame can be received on any network path.  This validates the path on which
+the PATH_CHALLENGE was sent.

```suggestion
the data that was sent in a previous PATH_CHALLENGE frame.  A PATH_RESPONSE
frame received on any network path validates the path on which the
PATH_CHALLENGE was sent.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4241#pullrequestreview-511366824