Re: Martin Duke's Yes on draft-ietf-quic-transport-33: (with COMMENT)

[Lucas Pardue <[e-mail]>]

Hi Martin,

Thanks for the comments. I've captured each comment as a new issue on the
QUIC WG base-drafts Github repository and tagged you in each one. The
document editors will follow up on each issue and may create Pull Requests
if needs be. See in-line response for more details. We'll be tracking all
IESG comments on the Transport document under
https://github.com/quicwg/base-drafts/milestone/23

On Tue, Dec 22, 2020 at 12:09 AM Martin Duke via Datatracker <
[e-mail]> wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-quic-transport-33: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-transport/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm proud of the IETF for producing this document. I have a few minor
> comments
> and a bunch of nits.:
>
> COMMENTS:
>
> 17.2.1 I believe it is correct that there will be no negative consequences
> from
> not having Retry-like integrity protection on VN packets. But I ask the
> editors
> to take one more careful look at it, as the VN format is one of those
> things we
> really cannot fix later.
>

https://github.com/quicwg/base-drafts/issues/4450


> 21.13 "This means that client-controlled fields, such as the initial
> Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be
> used
> by themselves to make routing decisions." There was a lot of discussion in
> the
> QUIC-LB design team about whether this was an attack to be worried about or
> not, and we came down in favor of "not".
>
> More importantly, I don't see how this is practical advice. If we're to use
> Retry SCIDs to route subsequent packets, then load balancers have to use
> the
> DCID of Initials. Without validating the token, which most LBs will not do,
> they have no way of distinguishing between attacker-generated DCIDs with a
> bogus token and those that originally came from the server. One option is
> to
> simply remove this recommendation.
>
> Alternatively, you could leave this section unaltered and delete the bit in
> 8.1.2 about using Retry to reroute packets. In practice, keeping 21.13
> would
> require a revision of QUIC-LB to just use 4-tuple routing for long header
> packets or make it less robust for new versions.
>

https://github.com/quicwg/base-drafts/issues/4453


> 22 I am unclear about the status of these registries (except the version
> registry) for new versions. QUICv2 might have entirely new frame, TP, and
> error
> registries, right? Is it worthwhile to point that out? Or that it's heavily
> discouraged, or forbidden?
>

https://github.com/quicwg/base-drafts/issues/4451


> NITS:
>
> 3.1 An endpoint shouldn't "generate STREAM_DATA_BLOCKED frames" if it is
> suffering from connection flow control limits.
>

https://github.com/quicwg/base-drafts/issues/4452


> 8.1.2 I am not sure what you mean by the phrase "that can be unprotected"
>


https://github.com/quicwg/base-drafts/issues/4454


>
> 13.3 I believe MAX_STREAM_DATA retransmissions should cease in state
> RESET_RECVD.
>

https://github.com/quicwg/base-drafts/issues/4455


> 13.3 "it is not forbidden to retransmit copies of frames from lost
> packets" Is
> this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be
> copied.
>

https://github.com/quicwg/base-drafts/issues/4456


> 14 "Thus, modern IPv4 and all IPv6 network paths will be able to support
> QUIC."
> Generally true, but should be qualified for the presence of arbitrary
> numbers
> of tunnels.
>
>
https://github.com/quicwg/base-drafts/issues/4457


> 16 The CID length field is another exception to varint encoding.
>
>
https://github.com/quicwg/base-drafts/issues/4458

17.2.2 Please include a reference for HelloRetryRequest for those unfamiliar
> with TLS.
>

 https://github.com/quicwg/base-drafts/issues/4459


> 17.2.5.3 "A client MUST use the same cryptographic handshake message it
> included in this packet. A server MAY treat a packet that contains a
> different
> cryptographic handshake message as a connection error or discard it." If
> the
> client hello is large, the Retry Token itself might affect what part of it
> fits
> in the packet. The language here doesn't contradict that, but a naive
> server
> implementation of the server check might not catch that corner case (e.g.
> including a hash of the CHLO in the Retry token)
>
> [BTW the very next paragraph redundantly repeats part of this requirement].
>
>
> https://github.com/quicwg/base-drafts/issues/4460

Cheers,
Lucas
On behalf of QUIC WG Chairs