Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-16
Yes
No Objection
No Record
Summary: Has enough positions to pass.
Erik Kline Yes
# Internet AD comments for {draft-ietf-quic-applicability-16}
CC @ekline
## Nits
### S2
* s/a application/an application/
### S3.2
* s/and to unacceptable/and unacceptable/, I think
### S4
* s/they are assigned Section 6/they are assigned; see Section 6/, perhaps
Martin Duke Yes
11.2 “ QUIC requires that endpoints generate fresh connection IDs for use on new network paths.” This is ambiguously phrased and ignores NAT rebinding. I suggest “If QUIC endpoints do not issue fresh connection IDs, then clients cannot reduce the linkability of address migration by using them.” 11.3. Note that “retry service” has been renamed to “retry offload” and now has its own draft separate from QUIC-LB: draft-duke-quic-retry-offload (soon to be -ietf-) 14. This entire section appears to be a duplicate of section 5 of the version negotiation draft. I suggest the authors verify that the latter has all the relevant information, and then replace this section with a reference to the VN draft.
Paul Wouters Yes
Thanks for writing this document, I believe it is important for application developers to understand if or when they should adopt QUIC versus HTTP over TCP with TLS. (Although after reading the document, I feel for application developers who think they need to support or use QUIC instead of using it via HTTP/3)
Some comments:
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.
This sentence is a bit tricky to read and could use a rewrite. But I'm also not sure of the meaning. I understand that with TCP you can send RST packets to kill it, and with UDP you cannot. But with UDP you can also send equivalent to RST packets. For instance I have observed responses to UDP based IKEv2 packets causing IKEv2 communication to completely fail (where the MITM replies before the real target). Does QUIC really prevent all of this, because that is what the sentence seems to suggest by pointing out specific flaws in the "fallback option" to QUIC.
Further, downgrades to older TLS versions
I would probably use "Additionally" instead of "Further" here. Or we can compromise on "furthermore" :)
I am not sure if ALPN leakage would qualify as "significantly weaker cryptographic protection". I don't see much multiplexing usin ALPN, so the port number is still kind of a dead giveaway for the application being used anyway.
Section 3.5 of
[RFC8085] further discusses keep-alive intervals for UDP: it requires
a minimum value of 15 seconds, but recommends larger values, or
omitting keep-alive entirely.
The paragraph is warning about NAT mappings and idleness. It then feels contradicting to see some context apparently recommends not doing keep-alives entirely. Why is this part being brought up here? When would an application with QUIC not use keep-alives? When no NAT is detected? (Does QUIC have an indication of that to begin with, like IKEv2 does?). But when reading the next paragraph it became clear keep-alives might not be needed if one can depend on the QUIC connection ID. Maybe a better lead into the next paragraph would be better?
Section 7 talks about acknowledgment strategy, but it is not actually giving any examples of what the application can do. Since it is kind of a transport layer property and not an application layer property, it is unclear how an application [developer] can replace the "TCP like ack every other packet" functionality. Are there QUIC options to consider that do this? If so, why not mention those here?
The assumption that an application can be
identified in the network based on the port number is less true today
due to encapsulation, mechanisms for dynamic port assignments, and
NATs.
NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per RFC 6335 suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?
In the limit where connection migration in a server pool is rare
In the limit? Is that supposed to be "In the case" ?
Robert Wilton Yes
Hi,
Thanks for this document. I think that these sorts of documents are incredibly helpful and important for end users who are considering how to use IETF technology.
I found the document to be well written, and only had a few minor comments/questions:
1.
If a QUIC receiver has opened the maximum allowed concurrent streams,
and the sender indicates that more streams are needed, it does not
automatically lead to an increase of the maximum number of streams by
the receiver. Therefore, an application can use the maximum number
of allowed, currently open, and currently used streams when
determining how to map data to streams.
I was wondering whether "can use" is right here, or whether this should be "must use", given that the client cannot necessarily control how many streams are available.
7. Acknowledgment Efficiency
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP Section 13.2 of [QUIC]).
Nit: This doesn't quite scan/read easily.
9. Connection Migration
QUIC supports connection migration by the client. If an IP address
changes, a QUIC endpoint can still associate packets with an existing
For clarity, perhaps: If an IP address changes => If the client IP address changes?
Thanks,
Rob
Zaheduzzaman Sarker Yes
Alvaro Retana No Objection
Lars Eggert No Objection
The datatracker state does not indicate whether the consensus boilerplate should be included in this document. Thanks to Maria Ines Robles for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/869_aZXxcQCMeZGDSfN-E1JyjrU). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 14, paragraph 1, nit: - QUIC version 1 does not specify a version negotation mechanism in the + QUIC version 1 does not specify a version negotiation mechanism in the + + Document references draft-ietf-quic-datagram, but that has been published as RFC9221. Document references draft-ietf-quic-manageability-15, but -16 is the latest available revision. Reference [RFC5077] to RFC5077, which was obsoleted by RFC8446 (this may be on purpose). Paragraph 1938, nit: > ols needs to be avoided. In general, a application that implements fallback > ^ Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". Paragraph 2371, nit: > lishment is qualitatively different than one that does not from the point of > ^^^^ Did you mean "different from"? "Different than" is often considered colloquial style. Paragraph 5804, nit: > opened and closed they are consumed and the cumulative total is incremented > ^^^^ Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). Paragraph 5822, nit: > increased using the MAX_STREAMS frame but there is no mechanism to reduce lim > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Paragraph 6727, nit: > e an error code space that is independent from QUIC or other applications (s > ^^^^^^^^^^^^^^^^ The usual collocation for "independent" is "of", not "from". Did you mean "independent of"? Paragraph 10802, nit: > nd using QUIC. Further, migration to an new address exposes a linkage between > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university".
Roman Danyliw No Objection
Thank you to Chris Lonvick for the SECDIR review. Section 2. Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided. Consider if fallback needs to be the default behavior of applications. For example: Specifically, support for fallback to insecure protocols or to weaker versions of the secure protocol needs to be evaluated on a per-application basis. Section 2. Typo. s/a application/an application/ Section 3.2. Typo. s/mobilty/mobility/ Section 14. Typo. s/negotation/negotiation/
Éric Vyncke No Objection
Thank you for the work put into this document. Such a document is important for developers / operators wanting to use the new transport. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status. I hope that this helps to improve the document, Regards, -éric Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? ## Section 2 "permits traversal of network middleboxes (including NAT)" could perhaps be refined as TCP also traverse NAT, perhaps something such as "using a new IP protocol would have issue with network middleboxes (Internet ossification)" ? ## Section 4.4 (and some others) Sometimes the text is a little unclear on which part of the "application using QUIC" is discussed: the transport layer or the application layer in the "application" ? Unsure whether it is only me having this confusion though and I have no real suggestion on how to clarify things. ## Section 5 For the last paragraph, should a reference to a TAPS API/parameter be given ? (if it exists of course)
Andrew Alston No Record
Francesca Palombini No Record
John Scudder No Record
Murray Kucherawy No Record
Warren Kumari No Record