QUIC: A UDP-Based Multiplexed and Secure Transport
RFC 9000

Received changes through RFC Editor sync (created alias RFC 9000, changed abstract to 'This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.', changed pages to 151, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-05-27, changed IESG state to RFC Published)

[Ballot comment]
Thank you for addressing my Discuss point!

My previous comments and the associated github issues are available at
https://mailarchive.ietf.org/arch/msg/quic/yiSeJb2bgM4Aeef-ut5K1PhVNrw/
with thanks to Lucas for doing the format conversion.

[Ballot comment]
As per my prior discuss comments on email, I'm generally supportive of this protocol and document, but don't support how it defines the spin-bit which is likely to negatively impact network operations and manageability.  Hopefully, as the industry gains experience from its deployment, future versions of this protocol will act to mitigate the manageability issues (including measuring packet loss) that are being raised by network operators.

[Ballot comment]
As per my prior discuss comments on email, I'm generally supportive of this protocol and document, but don't support how it defines the spin-bit which is likely to negatively impact network operations and manageability.  Hopefully, as the industry gains experience from its deployment, then future versions of this protocol will act to mitigate the manageability issues that are being raised by network operators.

[Ballot comment]
Apologies for the late ballot; I was on vacation.

Let me start off by saying that I'm very supportive of the document and protocol.
Unfortunately, I believe that the nature of the spin bit negatively impacts operational practices. I understand that I'm in the rough here, and also believe that the gains from the protocol outweigh this concers, and so I'm abstaining / holding my nose on this part.

This is intentionally non-blocking

[Ballot comment]
This is really great technical and written work.  Kudos to everyone involved, and I'm happy to join the "Yes" pile.

There were some SHOULDs in the document that had me wondering why one might legitimately do something other than what's being recommended, since SHOULD does leave the implementer a choice.  For instance, in Section 10.2.2 there's this:

  An endpoint MAY enter the draining state from the closing state if it
  receives a CONNECTION_CLOSE frame, which indicates that the peer is
  also closing or draining.  In this case, the draining state SHOULD
  end when the closing state would have ended.  In other words, the
  endpoint uses the same end time, but ceases transmission of any
  packets on this connection.

This left me wondering why the endpoint would ever do something other than what's specified as SHOULD here.  There might be a good reason, but the prose doesn't say what that might be (or I managed to miss it).  Or maybe "SHOULD end" should simply be "ends"?

Also, I have the same question as Ben about Section 22.1.4.  I think it's appropriate that a permanent registration refers to a specification that is also likely to be permanent, as we do with Standards Track RFCs.

Lastly, also on 22.1.4: I believe (though my colleagues can correct me if I'm wrong) that the IESG's current preference is to list the IESG, and not a working group, as the contact email address for registrations over which the IETF has change control.

[Ballot comment]
This protocol is nicely done and the document well-written and
well-organized.  It's really exciting to see what we can do with a
nearly clear slate and the accumulated modern knowledge about protocol
design.  Congratulations and thanks to all who contributed!
Special thanks (in advance) to the chairs for helping translate my
comments into github issues.

I have some editorial suggestions that I put up at
https://github.com/quicwg/base-drafts/pull/4597 .

Abstract, Section 1

My understanding is that "exemplary" typically is used to refer to not
just any example of the topic in question, but to one that is the
pinnacle of achievement or the best of its kind.  Do we intend to make
such a claim about the congestion control algorithm in [QUIC-RECOVERY]?

Section 1.3

> x (E) ...:  Indicates that x is repeated zero or more times (and that
>    each instance is length E)

Does "repeated zero or more times" mean that there is zero or more
instances in total, or one or more instances in total?  (I assume the
latter, and would suggest additional wording if the former is what was
intended.)  I am specifically curious about the application to the Ack
Range field of the ACK Frame, since it seems like early on in a
connection it is not always possible to construct a valid Gap field, but
will not duplicate the question there.

Section 2.4

> *  write data, understanding when stream flow control credit
>    (Section 4.1) has successfully been reserved to send the written
>    data;

(side note) I note that "flow control credit has been reserved" is
different than "has been ACKd by the peer".  I guess the expectation is
that if such information is needed, an application-layer ACK should be
used, since QUIC ACKs can be sent before the peer application has
consumed the received data?

Section 3.1

I'm not sure why "Peer Creates Bidirectional Stream" appears on two
transitions in the figure.  The prose suggests that the copy on the
Ready->Send transition is erroneous.

Section 4.1

> QUIC employs a limit-based flow-control scheme where a receiver
> advertises the limit of total bytes it is prepared to receive on a
> given stream or for the entire connection.  [...]

Should I be reading some distinction into "limit-based" (here) vs
"credit-based" (earlier) flow control?

Section 4.2

> When a sender receives credit after being blocked, it might be able
> to send a large amount of data in response, resulting in short-term
> congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
> how a sender can avoid this congestion.

No such section exists in the -33; perhaps §7.7 is intended?

Section 5.1.1

> An endpoint SHOULD ensure that its peer has a sufficient number of
> available and unused connection IDs.  Endpoints advertise the number
> of active connection IDs they are willing to maintain using the
> active_connection_id_limit transport parameter.  An endpoint MUST NOT
> provide more connection IDs than the peer's limit.  [...]

IIUC, the reason that a negotiated limit is needed here is not exactly
for the storage of the connection ID values themselves (though the
requirement to explicitly use RETIRE_CONNECTION_ID makes it not as
simple as it might be), but rather due to the requirement to recognize
the associated stateless reset tokens.  Is that correct?  If so, perhaps
it could be mentioned as a factor, here.

Section 5.2.2

>                                Servers SHOULD respond with a Version
> Negotiation packet, provided that the datagram is sufficiently long.

This SHOULD seems redundant with the first sentence of the section?

> Packets with a supported version, or no version field, are matched to
> a connection using the connection ID or - for packets with zero-
> length connection IDs - the local address and port.  These packets
> are processed using the selected connection; otherwise, the server
> continues below.

(side note) Packets with a short header do not indicate the connection
ID length (or version).  I think we admit the possibility that a server
could advertise a zero-length connection ID to some but not all clients;
does that imply that a lookup by address/port in the local connection
database would be needed to determine whether such a short-header packet
would have a zero-length connection ID or not?

Section 6.2

>                                            A client MUST discard any
> Version Negotiation packet if it has received and successfully
> processed any other packet, including an earlier Version Negotiation
> packet.  [...]

It seems like this requirement might be too strict, in that it could
prevent otherwise successful communication when a limited on-path
attacker injects a Version Negotiation packet.

Section 7.2

> When an Initial packet is sent by a client that has not previously
> received an Initial or Retry packet from the server, the client
> populates the Destination Connection ID field with an unpredictable
> value.  This Destination Connection ID MUST be at least 8 bytes in
> length.  [...]

My usual policy on seeing a random nonce shorter than 128 bits is to ask
for explanation of why the shorter value is safe for the use it is being
put to.  (How bad would it be to bump this to 16?)

>                                                        Once a client
> has received a valid Initial packet from the server, it MUST discard
> any subsequent packet it receives with a different Source Connection
> ID.

This seems over-zealous as written, since it would seem to prevent the
server from ever using a new Source Connection ID on that connection,
even in response to a client migration event.  Is it intended to be
scoped to just Initial (and Handshake?) packets as is done for the
server in the following paragraph?

Section 7.4

>                Application protocols can recommend values for
> transport parameters, such as the initial flow control limits.
> However, application protocols that set constraints on values for
> transport parameters could make it impossible for a client to offer
> multiple application protocols if these constraints conflict.

Should we go a step further and forbid application protocols from making
such requirements?

Section 7.5

> Once the handshake completes, if an endpoint is unable to buffer all
> data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
> CRYPTO frames received in the future, or it MAY close the connection
> with a CRYPTO_BUFFER_EXCEEDED error code.  [...]

How future-proof is this?  NewSessionTicket is "safe" to discard in that
doing so has no negative consequences for the current connection (it may
indicate that previously received tickets have been invalidated, but
that is also fairly benign and can happen for other reasons), but in
general post-handshake CRYPTO frames are not constrained in what TLS
messages they can carry, including any TLS messages defined in the
future.  I am not sure that we can effectively require all future TLS
post-handshake messages to be safe to discard.

Section 8.1.3

> Clients that want to break continuity of identity with a server MAY
> discard tokens provided using the NEW_TOKEN frame.  [...]

This seems more like a SHOULD than a MAY, given the precondition.

>                                                  A server SHOULD
> encode tokens provided with NEW_TOKEN frames and Retry packets
> differently, and validate the latter more strictly.  [...]

Didn't we already have a MUST-level requirement for being able to tell
them apart, in §8.1.1?

Section 8.1.4

> An address validation token MUST be difficult to guess.  Including a
> large enough random value in the token would be sufficient, but this
> depends on the server remembering the value it sends to clients.

(How large is "large enough?")

Section 8.2

> Path validation is used by both peers during connection migration
> (see Section 9) to verify reachability after a change of address.  In
> path validation, endpoints test reachability between a specific local
> address and a specific peer address, where an address is the two-
> tuple of IP address and port.

In light of the toplevel definition of "address" in this document, the
last clause seems unnecessary.

Section 9

> The design of QUIC relies on endpoints retaining a stable address for
> the duration of the handshake.  [...]

Why do we allow PATH_CHALLENGE (and the impossible PATH_RESPONSE) to be
sent in 0-RTT frames, then?  (This might dupe a comment later...)

Section 9.5

> Similarly, an endpoint MUST NOT reuse a connection ID when sending to
> more than one destination address.  Due to network changes outside
> the control of its peer, an endpoint might receive packets from a new
> source address with the same destination connection ID, in which case
> it MAY continue to use the current connection ID with the new remote
> address while still sending from the same local address.

The MAY seems like it may be in conflict with the MUST.

Section 10.2.1

> An endpoint's selected connection ID and the QUIC version are
> sufficient information to identify packets for a closing connection;
> the endpoint MAY discard all other connection state.  [...]

Are the packet protection keys for outgoing traffic (or the literal
CONNECTION_CLOSE packet contents) not considered part of "connection
state"?

Section 10.3

Just to check my understanding: it is "safe" for a server to decide that
it will never use stateless reset and send random values in the
stateless_reset_token fields that it immediately forgets?  (It would
then not be able to ever send stateless reset, of course, but AFAICT
that is the only consequence.  The client still has to track the
relevant state, and the server has to track
per-connection-ID-sequence-number state.)  I don't know if that's worth
mentioning, since the field is otherwise essentially mandatory when
server connection IDs are in use.

>                                                              An
> endpoint that sends a stateless reset in response to a packet that is
> 43 bytes or shorter SHOULD send a stateless reset that is one byte
> shorter than the packet it responds to.

(side note) We haven't gotten to the anti-looping stuff in §10.3.3 yet,
so the "one byte shorter" is a bit out of the blue until we get there.

Section 10.3.2

I'm not sure whether it should be here or earlier, but somewhere we
should motivate this construction as being something that can be
generated statelessly, e.g., by a server restarting after a crash, based
only on attributes (e.g., Connection ID) of a received packet from a
previous connection.  The value is computed in advance and given to the
peer so that the peer will know what to expect if the stateless reset
functionality needs to be used, and then generated at runtime by an
endpoint that has lost state.  The scheme described in the first
paragraph requires state, and thus is hard to justify describing as a
stateless reset...

> A single static key can be used across all connections to the same
> endpoint by generating the proof using a second iteration of a
> preimage-resistant function that takes a static key and the
> connection ID chosen by the endpoint (see Section 5.1) as input.  [...]

The phrase "second iteration" doesn't seem to be explained at all.

> This design relies on the peer always sending a connection ID in its
> packets so that the endpoint can use the connection ID from a packet
> to reset the connection.  An endpoint that uses this design MUST
> either use the same connection ID length for all connections or
> encode the length of the connection ID such that it can be recovered
> without state.  In addition, it cannot provide a zero-length
> connection ID.

(There is a corollary that the length of the connection ID has to be
enough so that multiple connection IDs can be issued to all potential
peers cumulatively over the lifetime of the static key, though perhaps
it's sufficiently obvious so as to go without saying.)

Section 12.4

A forward-reference to §19.21 for how extension frames can be used might
be useful.

Why are PATH_CHALLENGE/PATH_RESPONSE allowed in the 0-RTT packet number
space?  (Hmm, the prose and table may be inconsistent here, too.  I
touch some things in my PR but I think not all of them.)  The server
isn't allowed to send at that level, so it seems that even if a client
did sent PATH_CHALLENGE in 0-RTT, the PATH_RESPONSE would have to come
back in 1-RTT.  (And with no challenge to reply to, the client can't
very well send a PATH_RESPONSE in 0-RTT.)  Also, IIRC, we state
elsewhere that we require a stable path for the duration of the
handshake.  Even preferred-address probing can't occur until the client
has the server's transport parameters, which aren't usable until 1-RTT
keys are available (even if they may technically be available prior to
then).

Section 13.2.3

> ACK frames SHOULD always acknowledge the most recently received
> packets, and the more out-of-order the packets are, the more
> important it is to send an updated ACK frame quickly, [...]

Do we have a strict definition of "out of order" that we adhere to?  I
didn't see one in [QUIC-RECOVERY] on a quick search, but haven't read it
in depth yet.
(TCP RACK used roughly "X is out of order when X has lower sequence
number than Y and X is received after Y is received", which is what I'll
use as a mental model until I read otherwise.)

Section 13.2.5

> When the measured acknowledgement delay is larger than its
> max_ack_delay, an endpoint SHOULD report the measured delay.  This
> information is especially useful during the handshake when delays
> might be large; see Section 13.2.1.

I'm not sure I understand when this delay would not be reported even in
the absence of this guidance.  Is the idea that you should specifically
send an ACK with Largest Acknowledged corresponding to the highly
delayed packet, even if you could send an ACK with a larger Largest
Acknowledged (but lower delay)?

Section 17

(side note) I don't know that it would be of particular benefit to have
it explained in the document, but I do find myself curious why there is
a Fixed Bit.

Section 17.2.5

Should we give some guidance on the (minimum) length of the Retry Token
(possibly in a subsection)?  I am not sure that the "MUST be
non-zero-length" from §17.2.5.2 is the only guidance we want to give...

Section 17.2.5.1

> A server MAY send Retry packets in response to Initial and 0-RTT
> packets.  A server can either discard or buffer 0-RTT packets that it
> receives.  A server can send multiple Retry packets as it receives
> Initial or 0-RTT packets.  A server MUST NOT send more than one Retry
> packet in response to a single UDP datagram.

When the server sends multiple Retry packets in such a scenario, do the
Source Connection ID fields need to be different (or the same) across
all of them?  (Or does it not matter?)

Section 17.2.5.2

> Token field to the token provided in the Retry.  The client MUST NOT
> change the Source Connection ID because the server could include the
> connection ID as part of its token validation logic; see
> Section 8.1.4.

It looks like Section 8.1.4 doesn't actually talk specifically about
connection IDs being bound to the token, just "additional information
about clients".  Perhaps it should?

Section 19.16

> Retiring a connection ID invalidates the stateless reset token
> associated with that connection ID.

Is it the sending or the ACKing of the frame that effectuates the
invalidation?

Section 19.17

As above, please confirm that the 64-bit nonce is wide enough to support
the purpose for which it is being used.

Section 19.19

> Reason Phrase:  A human-readable explanation for why the connection
>    was closed.  This can be zero length if the sender chooses not to
>    give details beyond the Error Code.  This SHOULD be a UTF-8
>    encoded string [RFC3629].

Does "human-readable" engage BCP 18 and the SHOULD-level requirement for
carrying information about language?

Section 20.1

> TRANSPORT_PARAMETER_ERROR (0x8):  An endpoint received transport
>    parameters that were badly formatted, included an invalid value,
>    was absent even though it is mandatory, was present though it is
>    forbidden, or is otherwise in error.

(nit) maybe some singluar/plural mismatch here, though the RFC Editor
would probably have a better suggested fix than I could come up with.

Section 21

Should we reiterate somewhere that 1-RTT data sent by the server prior
to handshake completion is being sent to an unauthenticated client?

Section 21.1

As was noted by others, the terminology used for the taxonomy of
attackers is a bit unusual (i.e., divergent from [SEC-CONS]) and
surprising.  It does seem to be fairly clearly specified, though, so is
probably not worth trying to change at this point.

Section 21.1.1

[Just noting here for visibility that my editorial PR adds some text
here to emphasize that the peer authentication provided by the TLS
handshake is a vital property as well.  Clients that do not check TLS
server certificates against the identity of the endpoint they're
attempting to contact are not guaranteed secure operation.]

Section 21.1.3.1

> *  Split and merge datagrams along packet boundaries

Those packet boundaries are obfuscated by header protection, though,
right?

Section 21.1.3.3

> 3.  A limited on-path attacker can cause an idle connection to be
>    deemed lost if the server is the first to resume activity.

Pedantically, if the client resumes activity after the server does, but
within, say, 2*PTO, I don't think the connection would actually be lost.
But perhaps I am missing something.

Section 21.2

> The Source and Destination Connection ID fields are the primary means
> of protection against off-path attack during the handshake.  These

Presumably we should then give some guidance on how to generate the
Connection IDs so that they can fulfill this role effectively.  Though it
is likely to change significantly as a result of IETF Review,
draft-gont-numeric-ids-sec-considerations may have some useful advice
here.  In particular, it seems like they actually do need to be
unpredictable in order to fulfill this role, and very short Connection
IDs will not be very effective either.

Section 21.3

> Servers SHOULD provide mitigations for this attack by limiting the
> usage and lifetime of address validation tokens; see Section 8.1.3.

I recognize that it is probably an advanced implementation feature to do
so, but implementations can also mitigate by detecting elevated rates
across all connections or some identifiable cateogry of connections, of
sending responses to 0-RTT data that are declared lost, treating that as
indication of an ongoing attack, and racheting down the congestion
window it uses for such data for the duration of the attack.  This in
theory could improve the stability of the Internet as a whole, which
would be the motivation for mentioning it in this document as opposed to
leaving it at the discretion of implementors.

Section 21.5

> For example, cross-site request forgery [CSRF] exploits on the Web
> cause a client to issue requests that include authorization cookies
> [COOKIE], allowing one site access to information and actions that
> are intended to be restricted to a different site.

Server-side request forgery is also a powerful example of this type of
attack.  Though it's not really clear that we need more than one example
here, so "no change" is okay with me.

Section 21.5.2

> Clients however are not obligated to use the NEW_TOKEN frame.
> Request forgery attacks that rely on the Token field can be avoided
> if clients send an empty Token field when the server address has
> changed from when the NEW_TOKEN frame was received.

> Clients could avoid using NEW_TOKEN if the server address changes.
> However, not including a Token field could adversely affect
> performance.  Servers could rely on NEW_TOKEN to enable sending of
> data in excess of the three times limit on sending data; see
> Section 8.1.  In particular, this affects cases where clients use
> 0-RTT to request data from servers.

This seems to be setting us up to specifically recommend trading away
security in favor of performance.  Is that the right tradeoff?
(Also, in the vein of my earlier comment, advanced implementation
strategies involving detecting the presence of an attack might provide
global benefit to the Internet, though the case is a bit weaker here
than it was in the other situation.)

Section 21.10

> An on-the-side attacker can duplicate and send packets with modified

This is the only instance of "on-the-side" (or "on the side") in the
document; I suggest rephrasing to conform to the prevailing terminology.

Section 21.11

This would be a good place (or §10.3) to discuss the procedures for
rotating the static key used by stateless reset, per BCP 107.

Section 21.13

>                    Ideally, routing decisions are made independently
> of client-selected values; a Source Connection ID can be selected to
> route later packets to the same server.

Is the client's address considered to be "client-selected"?  It's not
clear to me that ignoring IP address locality and routing efficiency is
going to be the ideal behavior.

Section 22.1.1

Are there going to be PII concerns with requiring contact information in
the (public) registry?

Section 22.1.2

> Applications to register codepoints in QUIC registries MAY include a
> codepoint as part of the registration.  IANA MUST allocate the
> selected codepoint if the codepoint is unassigned and the
> requirements of the registration policy are met.

Is this intended to preclude the experts from requiring an allocation to
be made from a range with a different-length encoding?

Section 22.1.4

Should we require an expectation that the publicly available
specification is going to be stable and/or continue to be accessible, as
a condition of a permanent registration?

Section 23.1

I think RFC 4086 is typically listed only as an Informative reference.

It is amusing that IPv4 is a normative reference but IPv6 only
informative.  (Given how they are referenced, I don't fault this
categorization.)

Section 23.2

Should [QUIC-INVARIANTS] also be required reading?
[ed. I see it already is, in the editor's copy]

[Ballot discuss]
This is very much a "discuss discuss", and I am not strongly convinced
that there is a problem here, but if there is a problem it is a fairly big
one.

This document defers creation of a downgrade protection mechanism for
version negotiation; after all, if there is only one version in
existence, there is nothing to negotiate.  However, an effective
downgrade protection mechanism requires support from all potentially
affected parties in order to be reliable, so some careful thought is in
order.  If we limit ourselves to a mindset where QUIC versions are
infrequent undertakings brought about by standards action (i.e., we
don't have to worry until a "v2" exists), then deferring seems to be
okay (but part of the Discuss is to confirm that my reasoning is valid).
The main goal of downgrade protection is to be able to distinguish a node
that only supports v1 (or in general, any single version, or set of
versions that only has one overlapping version with the peer) from one
that supports a different shared version but was tricked by an attacker
into using v1 when it otherwise would have used a different version.
I'll call that different version v2 for clarity.  However, if the peer
only supports v1, there's nothing to distinguish and nothing to
negotiate; it suffices to ensure that all nodes that are capable of v2
support the downgrade protection scheme.  That is, an attacker can only
change the negotiated protocol version (as opposed to just causing
connection failure, which can be done in many other ways) if there is
some shared version other than v1 that would have been negotiated in the
absence of the attacker.  So, if v2 is definitly going to be
defined+implemented before other versions, and all nodes that support v2
support downgrade protection, we are guaranteed that in any case where
two peers would negotiate v2 in the absence of an attack, both peers
support the downgrade protection mechanism and thus that mechanism will
be effective in the face of an attack.  Peers that don't support the
mechanism only do v1 and so there is no downgrade possible when they are
participating in the connection.  (We would, of course, still need to be
confident that we could define such a downgrade protection scheme in a
backwards-compatible manner, though this seems like a fairly low bar
given the extensibility provided by transport parameters and frame
types.)

However, it's not clear to me that this assumption holds that v2 is
going to be the next version and that every node that implements v1 and
some other version will definitely implement v2.  In particular, we
currently have a very open registration policy for new versions, and
there may be a desire to have some custom version of QUIC, perhaps that
only has a small difference from v1, and furthermore a desire to use
that custom version when available but be able to use v1 when not
available.  There might be multiple such new versions in development in
parallel, with no clear "first new version" tasked with the
responsibility to develop a downgrade protection mechanism for global
use.  The interaction between multiple competing downgrade-protection
mechanisms seems likely to become quite messy quite quickly, so I am
inclined to see "make each non-standards-track version specify their own
downgrade protection" as a non-starter.

I think that the lack of a secure downgrade protection mechanism is
fundamentally incompatible with an open procedure for creating new
versions while claiming that the protocol is a secure protocol.  While it
would not be a pleasant choice, I think we might be forced to require
standards action for new QUIC versions until we have a single global
downgrade protection mechanism defined.  Or perhaps I misunderstand the
ecosystem that we are trying to produce, or am making erroneous
assumptions.  I'd love to hear more about how the WG decided to proceed
with the current formulation, especially with regard to what
consideration was given to non-standards-track new versions.

The above notwithstanding, I support this protocol and I expect to
change my position to Yes once this point is resolved in some manner.

[Ballot comment]
This protocol is nicely done and the document well-written and
well-organized.  It's really exciting to see what we can do with a
nearly clear slate and the accumulated modern knowledge about protocol
design.  Congratulations and thanks to all who contributed!
Special thanks (in advance) to the chairs for helping translate my
comments into github issues.

I have some editorial suggestions that I put up at
https://github.com/quicwg/base-drafts/pull/4597 .

Abstract, Section 1

My understanding is that "exemplary" typically is used to refer to not
just any example of the topic in question, but to one that is the
pinnacle of achievement or the best of its kind.  Do we intend to make
such a claim about the congestion control algorithm in [QUIC-RECOVERY]?

Section 1.3

  x (E) ...:  Indicates that x is repeated zero or more times (and that
      each instance is length E)

Does "repeated zero or more times" mean that there is zero or more
instances in total, or one or more instances in total?  (I assume the
latter, and would suggest additional wording if the former is what was
intended.)  I am specifically curious about the application to the Ack
Range field of the ACK Frame, since it seems like early on in a
connection it is not always possible to construct a valid Gap field, but
will not duplicate the question there.

Section 2.4

  *  write data, understanding when stream flow control credit
      (Section 4.1) has successfully been reserved to send the written
      data;

(side note) I note that "flow control credit has been reserved" is
different than "has been ACKd by the peer".  I guess the expectation is
that if such information is needed, an application-layer ACK should be
used, since QUIC ACKs can be sent before the peer application has
consumed the received data?

Section 3.1

I'm not sure why "Peer Creates Bidirectional Stream" appears on two
transitions in the figure.  The prose suggests that the copy on the
Ready->Send transition is erroneous.

Section 4.1

  QUIC employs a limit-based flow-control scheme where a receiver
  advertises the limit of total bytes it is prepared to receive on a
  given stream or for the entire connection.  [...]

Should I be reading some distinction into "limit-based" (here) vs
"credit-based" (earlier) flow control?

Section 4.2

  When a sender receives credit after being blocked, it might be able
  to send a large amount of data in response, resulting in short-term
  congestion; see Section 6.9 in [QUIC-RECOVERY] for a discussion of
  how a sender can avoid this congestion.

No such section exists in the -33; perhaps §7.7 is intended?

Section 5.1.1

  An endpoint SHOULD ensure that its peer has a sufficient number of
  available and unused connection IDs.  Endpoints advertise the number
  of active connection IDs they are willing to maintain using the
  active_connection_id_limit transport parameter.  An endpoint MUST NOT
  provide more connection IDs than the peer's limit.  [...]

IIUC, the reason that a negotiated limit is needed here is not exactly
for the storage of the connection ID values themselves (though the
requirement to explicitly use RETIRE_CONNECTION_ID makes it not as
simple as it might be), but rather due to the requirement to recognize
the associated stateless reset tokens.  Is that correct?  If so, perhaps
it could be mentioned as a factor, here.

Section 5.2.2

                                  Servers SHOULD respond with a Version
  Negotiation packet, provided that the datagram is sufficiently long.

This SHOULD seems redundant with the first sentence of the section?

  Packets with a supported version, or no version field, are matched to
  a connection using the connection ID or - for packets with zero-
  length connection IDs - the local address and port.  These packets
  are processed using the selected connection; otherwise, the server
  continues below.

(side note) Packets with a short header do not indicate the connection
ID length (or version).  I think we admit the possibility that a server
could advertise a zero-length connection ID to some but not all clients;
does that imply that a lookup by address/port in the local connection
database would be needed to determine whether such a short-header packet
would have a zero-length connection ID or not?

Section 6.2

                                              A client MUST discard any
  Version Negotiation packet if it has received and successfully
  processed any other packet, including an earlier Version Negotiation
  packet.  [...]

It seems like this requirement might be too strict, in that it could
prevent otherwise successful communication when a limited on-path
attacker injects a Version Negotiation packet.

Section 7.2

  When an Initial packet is sent by a client that has not previously
  received an Initial or Retry packet from the server, the client
  populates the Destination Connection ID field with an unpredictable
  value.  This Destination Connection ID MUST be at least 8 bytes in
  length.  [...]

My usual policy on seeing a random nonce shorter than 128 bits is to ask
for explanation of why the shorter value is safe for the use it is being
put to.  (How bad would it be to bump this to 16?)

                                                          Once a client
  has received a valid Initial packet from the server, it MUST discard
  any subsequent packet it receives with a different Source Connection
  ID.

This seems over-zealous as written, since it would seem to prevent the
server from ever using a new Source Connection ID on that connection,
even in response to a client migration event.  Is it intended to be
scoped to just Initial (and Handshake?) packets as is done for the
server in the following paragraph?

Section 7.4

                  Application protocols can recommend values for
  transport parameters, such as the initial flow control limits.
  However, application protocols that set constraints on values for
  transport parameters could make it impossible for a client to offer
  multiple application protocols if these constraints conflict.

Should we go a step further and forbid application protocols from making
such requirements?

Section 7.5

  Once the handshake completes, if an endpoint is unable to buffer all
  data in a CRYPTO frame, it MAY discard that CRYPTO frame and all
  CRYPTO frames received in the future, or it MAY close the connection
  with a CRYPTO_BUFFER_EXCEEDED error code.  [...]

How future-proof is this?  NewSessionTicket is "safe" to discard in that
doing so has no negative consequences for the current connection (it may
indicate that previously received tickets have been invalidated, but
that is also fairly benign and can happen for other reasons), but in
general post-handshake CRYPTO frames are not constrained in what TLS
messages they can carry, including any TLS messages defined in the
future.  I am not sure that we can effectively require all future TLS
post-handshake messages to be safe to discard.

Section 8.1.3

  Clients that want to break continuity of identity with a server MAY
  discard tokens provided using the NEW_TOKEN frame.  [...]

This seems more like a SHOULD than a MAY, given the precondition.

                                                    A server SHOULD
  encode tokens provided with NEW_TOKEN frames and Retry packets
  differently, and validate the latter more strictly.  [...]

Didn't we already have a MUST-level requirement for being able to tell
them apart, in §8.1.1?

Section 8.1.4

  An address validation token MUST be difficult to guess.  Including a
  large enough random value in the token would be sufficient, but this
  depends on the server remembering the value it sends to clients.

(How large is "large enough?")

Section 8.2

  Path validation is used by both peers during connection migration
  (see Section 9) to verify reachability after a change of address.  In
  path validation, endpoints test reachability between a specific local
  address and a specific peer address, where an address is the two-
  tuple of IP address and port.

In light of the toplevel definition of "address" in this document, the
last clause seems unnecessary.

Section 9

  The design of QUIC relies on endpoints retaining a stable address for
  the duration of the handshake.  [...]

Why do we allow PATH_CHALLENGE (and the impossible PATH_RESPONSE) to be
sent in 0-RTT frames, then?  (This might dupe a comment later...)

Section 9.5

  Similarly, an endpoint MUST NOT reuse a connection ID when sending to
  more than one destination address.  Due to network changes outside
  the control of its peer, an endpoint might receive packets from a new
  source address with the same destination connection ID, in which case
  it MAY continue to use the current connection ID with the new remote
  address while still sending from the same local address.

The MAY seems like it may be in conflict with the MUST.

Section 10.2.1

  An endpoint's selected connection ID and the QUIC version are
  sufficient information to identify packets for a closing connection;
  the endpoint MAY discard all other connection state.  [...]

Are the packet protection keys for outgoing traffic (or the literal
CONNECTION_CLOSE packet contents) not considered part of "connection
state"?

Section 10.3

Just to check my understanding: it is "safe" for a server to decide that
it will never use stateless reset and send random values in the
stateless_reset_token fields that it immediately forgets?  (It would
then not be able to ever send stateless reset, of course, but AFAICT
that is the only consequence.  The client still has to track the
relevant state, and the server has to track
per-connection-ID-sequence-number state.)  I don't know if that's worth
mentioning, since the field is otherwise essentially mandatory when
server connection IDs are in use.

                                                                An
  endpoint that sends a stateless reset in response to a packet that is
  43 bytes or shorter SHOULD send a stateless reset that is one byte
  shorter than the packet it responds to.

(side note) We haven't gotten to the anti-looping stuff in §10.3.3 yet,
so the "one byte shorter" is a bit out of the blue until we get there.

Section 10.3.2

I'm not sure whether it should be here or earlier, but somewhere we
should motivate this construction as being something that can be
generated statelessly, e.g., by a server restarting after a crash, based
only on attributes (e.g., Connection ID) of a received packet from a
previous connection.  The value is computed in advance and given to the
peer so that the peer will know what to expect if the stateless reset
functionality needs to be used, and then generated at runtime by an
endpoint that has lost state.  The scheme described in the first
paragraph requires state, and thus is hard to justify describing as a
stateless reset...

  A single static key can be used across all connections to the same
  endpoint by generating the proof using a second iteration of a
  preimage-resistant function that takes a static key and the
  connection ID chosen by the endpoint (see Section 5.1) as input.  [...]

The phrase "second iteration" doesn't seem to be explained at all.

  This design relies on the peer always sending a connection ID in its
  packets so that the endpoint can use the connection ID from a packet
  to reset the connection.  An endpoint that uses this design MUST
  either use the same connection ID length for all connections or
  encode the length of the connection ID such that it can be recovered
  without state.  In addition, it cannot provide a zero-length
  connection ID.

(There is a corollary that the length of the connection ID has to be
enough so that multiple connection IDs can be issued to all potential
peers cumulatively over the lifetime of the static key, though perhaps
it's sufficiently obvious so as to go without saying.)

Section 12.4

A forward-reference to §19.21 for how extension frames can be used might
be useful.

Why are PATH_CHALLENGE/PATH_RESPONSE allowed in the 0-RTT packet number
space?  (Hmm, the prose and table may be inconsistent here, too.  I
touch some things in my PR but I think not all of them.)  The server
isn't allowed to send at that level, so it seems that even if a client
did sent PATH_CHALLENGE in 0-RTT, the PATH_RESPONSE would have to come
back in 1-RTT.  (And with no challenge to reply to, the client can't
very well send a PATH_RESPONSE in 0-RTT.)  Also, IIRC, we state
elsewhere that we require a stable path for the duration of the
handshake.  Even preferred-address probing can't occur until the client
has the server's transport parameters, which aren't usable until 1-RTT
keys are available (even if they may technically be available prior to
then).

Section 13.2.3

  ACK frames SHOULD always acknowledge the most recently received
  packets, and the more out-of-order the packets are, the more
  important it is to send an updated ACK frame quickly, [...]

Do we have a strict definition of "out of order" that we adhere to?  I
didn't see one in [QUIC-RECOVERY] on a quick search, but haven't read it
in depth yet.
(TCP RACK used roughly "X is out of order when X has lower sequence
number than Y and X is received after Y is received", which is what I'll
use as a mental model until I read otherwise.)

Section 13.2.5

  When the measured acknowledgement delay is larger than its
  max_ack_delay, an endpoint SHOULD report the measured delay.  This
  information is especially useful during the handshake when delays
  might be large; see Section 13.2.1.

I'm not sure I understand when this delay would not be reported even in
the absence of this guidance.  Is the idea that you should specifically
send an ACK with Largest Acknowledged corresponding to the highly
delayed packet, even if you could send an ACK with a larger Largest
Acknowledged (but lower delay)?

Section 17

(side note) I don't know that it would be of particular benefit to have
it explained in the document, but I do find myself curious why there is
a Fixed Bit.

Section 17.2.5

Should we give some guidance on the (minimum) length of the Retry Token
(possibly in a subsection)?  I am not sure that the "MUST be
non-zero-length" from §17.2.5.2 is the only guidance we want to give...

Section 17.2.5.1

  A server MAY send Retry packets in response to Initial and 0-RTT
  packets.  A server can either discard or buffer 0-RTT packets that it
  receives.  A server can send multiple Retry packets as it receives
  Initial or 0-RTT packets.  A server MUST NOT send more than one Retry
  packet in response to a single UDP datagram.

When the server sends multiple Retry packets in such a scenario, do the
Source Connection ID fields need to be different (or the same) across
all of them?  (Or does it not matter?)

Section 17.2.5.2

  Token field to the token provided in the Retry.  The client MUST NOT
  change the Source Connection ID because the server could include the
  connection ID as part of its token validation logic; see
  Section 8.1.4.

It looks like Section 8.1.4 doesn't actually talk specifically about
connection IDs being bound to the token, just "additional information
about clients".  Perhaps it should?

Section 19.16

  Retiring a connection ID invalidates the stateless reset token
  associated with that connection ID.

Is it the sending or the ACKing of the frame that effectuates the
invalidation?

Section 19.17

As above, please confirm that the 64-bit nonce is wide enough to support
the purpose for which it is being used.

Section 19.19

  Reason Phrase:  A human-readable explanation for why the connection
      was closed.  This can be zero length if the sender chooses not to
      give details beyond the Error Code.  This SHOULD be a UTF-8
      encoded string [RFC3629].

Does "human-readable" engage BCP 18 and the SHOULD-level requirement for
carrying information about language?

Section 20.1

  TRANSPORT_PARAMETER_ERROR (0x8):  An endpoint received transport
      parameters that were badly formatted, included an invalid value,
      was absent even though it is mandatory, was present though it is
      forbidden, or is otherwise in error.

(nit) maybe some singluar/plural mismatch here, though the RFC Editor
would probably have a better suggested fix than I could come up with.

Section 21

Should we reiterate somewhere that 1-RTT data sent by the server prior
to handshake completion is being sent to an unauthenticated client?

Section 21.1

As was noted by others, the terminology used for the taxonomy of
attackers is a bit unusual (i.e., divergent from [SEC-CONS]) and
surprising.  It does seem to be fairly clearly specified, though, so is
probably not worth trying to change at this point.

Section 21.1.1

[Just noting here for visibility that my editorial PR adds some text
here to emphasize that the peer authentication provided by the TLS
handshake is a vital property as well.  Clients that do not check TLS
server certificates against the identity of the endpoint they're
attempting to contact are not guaranteed secure operation.]

Section 21.1.3.1

  *  Split and merge datagrams along packet boundaries

Those packet boundaries are obfuscated by header protection, though,
right?

Section 21.1.3.3

  3.  A limited on-path attacker can cause an idle connection to be
      deemed lost if the server is the first to resume activity.

Pedantically, if the client resumes activity after the server does, but
within, say, 2*PTO, I don't think the connection would actually be lost.
But perhaps I am missing something.

Section 21.2

  The Source and Destination Connection ID fields are the primary means
  of protection against off-path attack during the handshake.  These

Presumably we should then give some guidance on how to generate the
Connection IDs so that they can fulfill this role effectively.  Though it
is likely to change significantly as a result of IETF Review,
draft-gont-numeric-ids-sec-considerations may have some useful advice
here.  In particular, it seems like they actually do need to be
unpredictable in order to fulfill this role, and very short Connection
IDs will not be very effective either.

Section 21.3

  Servers SHOULD provide mitigations for this attack by limiting the
  usage and lifetime of address validation tokens; see Section 8.1.3.

I recognize that it is probably an advanced implementation feature to do
so, but implementations can also mitigate by detecting elevated rates
across all connections or some identifiable cateogry of connections, of
sending responses to 0-RTT data that are declared lost, treating that as
indication of an ongoing attack, and racheting down the congestion
window it uses for such data for the duration of the attack.  This in
theory could improve the stability of the Internet as a whole, which
would be the motivation for mentioning it in this document as opposed to
leaving it at the discretion of implementors.

Section 21.5

  For example, cross-site request forgery [CSRF] exploits on the Web
  cause a client to issue requests that include authorization cookies
  [COOKIE], allowing one site access to information and actions that
  are intended to be restricted to a different site.

Server-side request forgery is also a powerful example of this type of
attack.  Though it's not really clear that we need more than one example
here, so "no change" is okay with me.

Section 21.5.2

  Clients however are not obligated to use the NEW_TOKEN frame.
  Request forgery attacks that rely on the Token field can be avoided
  if clients send an empty Token field when the server address has
  changed from when the NEW_TOKEN frame was received.

  Clients could avoid using NEW_TOKEN if the server address changes.
  However, not including a Token field could adversely affect
  performance.  Servers could rely on NEW_TOKEN to enable sending of
  data in excess of the three times limit on sending data; see
  Section 8.1.  In particular, this affects cases where clients use
  0-RTT to request data from servers.

This seems to be setting us up to specifically recommend trading away
security in favor of performance.  Is that the right tradeoff?
(Also, in the vein of my earlier comment, advanced implementation
strategies involving detecting the presence of an attack might provide
global benefit to the Internet, though the case is a bit weaker here
than it was in the other situation.)

Section 21.10

  An on-the-side attacker can duplicate and send packets with modified

This is the only instance of "on-the-side" (or "on the side") in the
document; I suggest rephrasing to conform to the prevailing terminology.

Section 21.11

This would be a good place (or §10.3) to discuss the procedures for
rotating the static key used by stateless reset, per BCP 107.

Section 21.13

                      Ideally, routing decisions are made independently
  of client-selected values; a Source Connection ID can be selected to
  route later packets to the same server.

Is the client's address considered to be "client-selected"?  It's not
clear to me that ignoring IP address locality and routing efficiency is
going to be the ideal behavior.

Section 22.1.1

Are there going to be PII concerns with requiring contact information in
the (public) registry?

Section 22.1.2

  Applications to register codepoints in QUIC registries MAY include a
  codepoint as part of the registration.  IANA MUST allocate the
  selected codepoint if the codepoint is unassigned and the
  requirements of the registration policy are met.

Is this intended to preclude the experts from requiring an allocation to
be made from a range with a different-length encoding?

Section 22.1.4

Should we require an expectation that the publicly available
specification is going to be stable and/or continue to be accessible, as
a condition of a permanent registration?

Section 23.1

I think RFC 4086 is typically listed only as an Informative reference.

It is amusing that IPv4 is a normative reference but IPv6 only
informative.  (Given how they are referenced, I don't fault this
categorization.)

Section 23.2

Should [QUIC-INVARIANTS] also be required reading?

[Ballot discuss]
With so many "Yes" votes from other ADs, I feel like I'm swimming against the flow by raising a discuss ...

Firstly, I would like the thank the authors and WG on such a well written document.  I am  supportive of this protocol and hope that it will be good for the Internet.

However, I do have some discuss questions relating to the Spin Bit and the ability to manage and monitor networks.  I appreciate that there has already been a lot of (presumably heated) discussion on the spin bit, which I've not read or participated in, but I am concerned about the operational manageability aspect of QUIC.

Firstly, I have two comments on clarifying the spin bit behaviour/specification:

1) It would be helpful to clarify what the expected behaviour is for an implementation that chooses not to support the spin-bit.  Does it just leave the bit set as 0, or is it meant to follow the same behaviour as if spin-bit is supported but disabled?

2) This may not be discuss worthy, but some of the spin bit behaviour is inconsistently defined between the quic transport and quic manageability drafts.  Specifically:
  - The transport draft states that at least 1 in 16 connections "MUST" disable spinning, whereas the manageability draft states this as "recommended".
  - In the case that the spin bit is disabled, the transport draft uses "RECOMMENDED" to use a random value for each packet, or chosen independently for each connection.  Whereas the manageability draft uses "can" and lists the two options in the opposite order.
 
  For this review, since it is in IESG review, I've presumed that the transport draft has the definitive definitions and the manageability draft is lagging.


But my two main discuss questions/comments relate to whether the spin-bit, as specified in quic transport, achieves its goal.  I appreciate that there are individuals who don't think that it is required at all, conversely some network operators believe that they will lose vital information needed to help manage their networks, and presumably we are trying to find a pragmatic compromise between these two positions.

1) I find it hard to understand why a server is allowed to independently decide whether or not to support the spin bit on a connection?  Shouldn't the client (or administrator of the client system) that opened the connection be able to choose whether they want the RTT to be monitorable via the spin bit?  What is the reasoning for allowing the server (or server administrator) to be able to independently be able to decide what is best for the client?


2) In the case that the spin-bit is disabled, I don't understand the benefit of injecting a random spin bit value in each packet rather than always setting it to a per connection random value.  It seems that whether or not the randomness is injected, it is expected to be feasible to extract the RTT for those connections that are genuinely spinning the bit (or otherwise the spin bit is entirely pointless), but it just seems to make it computationally harder to extract the signal from the noise.  Perhaps the goal here is reduce the ability for pervasive monitoring to occur, but that feels a bit like security through obscurity.

Some enlightenment for these questions would be appreciated.

Regards,
Rob

[Ballot comment]
Comments:

    1.2.  Terms and Definitions

    Frame: A unit of structured protocol information. There are multiple frame types, each of which carries different information. Frames are contained in QUIC packets.

Perhaps indicate that a quic packet can contain multiple frames?  The terminology states that a datagram contains multiple quick packets, but it wasn't obvious to me that a quick packet can contain multple frames.

    This document uses the terms "QUIC packets", "UDP datagrams", and "IP packets" to refer to the units of the respective protocols. That is, one or more QUIC packets can be encapsulated in a UDP datagram, which is in turn encapsulated in an IP packet.

Frame is a widely used term in L2.  Hence, it might be helpful if this description also covered "Frames".  Perhaps this would also be a helpful place (or an alternative place) to mention that a QUIC packet contains one or more QUIC frames.

    3.  Stream States

    Bidirectional streams use both state machines

Maybe clarify this to indicate that it means that both state machines are used at each endpoint.  Otherwise, even unidirection steams use both state machines, one at each endpoint.

    3.2.  Receiving Stream States

    Figure 3: States for Receiving Parts of Streams

Perhaps expand "App Read RST" to "App Read RESET", since there doesn't seem a great reason to abbreviate it.

    3.2.  Receiving Stream States

    The receiving part of a stream enters the "Recv" state when the
    sending part of a bidirectional stream initiated by the endpoint
    (type 0 for a client, type 1 for a server) enters the "Ready" state.

This might be slightly clearer if the conditional predicate was moved to the beginning of the sentence.  E.g., For bidirectional streams, ...


    4.1.  Data Flow Control

    * Stream flow control, which prevents a single stream from consuming the entire receive buffer for a connection by limiting the amount of data that can be sent on any stream

Perhaps "on a stream" would be better than "on any stream".

    4.6.  Controlling Concurrency

    An endpoint that is unable to open a new stream due to the peer's limits SHOULD send a STREAMS_BLOCKED frame (Section 19.14). This signal is considered useful for debugging. An endpoint MUST NOT wait to receive this signal before advertising additional credit, since Iyengar & Thomson Expires 16 June 2021 [Page 29] Internet-Draft QUIC Transport Protocol December 2020 doing so will mean that the peer will be blocked for at least an entire round trip, and potentially indefinitely if the peer chooses not to send STREAMS_BLOCKED frames.

By additional credit, does it sending MAX_STREAMS?  If so, it might be helpful to clarify that.

    5.1.  Connection ID

    5.1.1.  Issuing Connection IDs

      Additional connection IDs are communicated to the peer using
      NEW_CONNECTION_ID frames (Section 19.15).  The sequence number on
      each newly issued connection ID MUST increase by 1.  The connection
      ID randomly selected by the client in the Initial packet and any
      connection ID provided by a Retry packet are not assigned sequence
      numbers unless a server opts to retain them as its initial connection
      ID.

I was slightly confused by the "The connection ID randomly selected by the client".  Elsewhere in section 5.1 it says that connection id allocation are implementation specific.  Are there any constraints on how connection ids can be allocated (other than not repeating as already stated).  E.g., could an implementation just allocate them as integers starting at 1?  Or can all connection ids (including NEW_CONNECTION_IDs) be randomly allocated?


    16. Variable-Length Integer Encoding

    No requirement to send integers in smallest encoding possible?  E.g. okay to send the value 3 in an 8 byte field?

This section doesn't indicate whether a sender is allowed to send integers not using the smallest possible encoding, and doesn't indicate whether a receive is expected to process non optimal encodings.  It might be helpful to be explicit.

    17.  Packet Formats

    Version: The QUIC Version is a 32-bit field that follows the first byte. This field indicates the version of QUIC that is in use and determines how the rest of the protocol fields are interpreted.

By "rest of the protocol fields", I had incorrectly interpreted this as meaning all subsequent fields described after the version field are determined  Perhaps worth clarifying - although I recall that it does become clear elsewhere.

    17.  Packet Formats

    Type-Specific Bits: The lower four bits (those with a mask of 0x0f) of byte 0 are type-specific

Perhaps "packet type specific" rather than just "type-specific"?

[Ballot comment]
Thanks for the great work on this important protocol, and for a very well written document!  Just some very minor editorial comments:


— Section 3.5 —

  An endpoint SHOULD copy the error code from the STOP_SENDING frame to
  the RESET_STREAM frame it sends, but MAY use any application error
  code.

— Section 9.6.2 —
  It SHOULD drop packets
  for this connection received on the old IP address, but MAY continue
  to process delayed packets.

Do as you think best with cases such as these, but for my part, I dislike the “SHOULD... but MAY” formulation, as I find it contradictory when it’s read strictly.  In general, I prefer to simply avoid the BCP 14 key word for the second part (“SHOULD do x, but may make other choices”).  In both cases here, I’d probably just leave off the second part, as it doesn’t seem to add anything.  At the least, I encourage making it “may” (or “can”).  But again, as you think best.

— Section 4 —

  It is necessary to limit the amount of data that a receiver could
  buffer, to prevent a fast sender from overwhelming a slow receiver,
  or to prevent a malicious sender from consuming a large amount of
  memory at a receiver.

You’re not talking about limiting the ability of the receiver (“could buffer”), but limiting the potential buffering requirement on the client (“has to buffer”), yes?

— Section 4.1 —

  Once a receiver advertises a limit for the connection or a stream, it
  MAY advertise a smaller limit, but this has no effect.

I don’t think this really fits the spirit of “MAY”.  I would say, “it is not an error to advertise a smaller limit, but....”

— Section 7 —

  Once completed, endpoints are able to exchange
  application data.

The antecedent to “once completed” is dangling, and the previous sentence talks about exchanging application data earlier.  I suggest, “Once the handshake is completed, endpoints are able to exchange application data freely.”

[Ballot comment]
Thank you to the WG and implementation community for this document.

** Section 3.  Per “The state machines shown in this section are largely informative ”, why the qualifier of “largely”?

** Section 8.1.  Per “Servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time”, is there any guidance on what a short time is here?

** Section 21.5.  Per “QUIC servers SHOULD NOT be deployed in networks that also have inadequately secured UDP endpoints”, I was wondering if this caution is realistic.

[Ballot comment]
Thank you to the WG and implementation community for this document.

** Section 3.  Per “The state machines shown in this section are largely informative ”, why the qualifier of “largely”?

** Section 8.1.  Per “Servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time”, is there any guidance on what a short time is here?

** Section 21.5.  Per “QUIC servers SHOULD NOT be deployed in networks that also have inadequately secured UDP endpoints”, I was wondering if this caution is a realistic.

[Ballot comment]
Thanks to the WG and implementation community for this document.

** Section 3.  Per “The state machines shown in this section are largely informative ”, why the qualifier of “largely”?

** Section 8.1.  Per “Servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time”, is there any guidance on what a short time is here?

** Section 21.5.  Per “QUIC servers SHOULD NOT be deployed in networks that also have inadequately secured UDP endpoints”, I was wondering if this caution is a realistic.

[Ballot comment]
Hello,

thank you for this document.

NITs
This appears twice:
  This document defines version 1 of QUIC, which conforms to the version-independent properties of QUIC defined in [QUIC-INVARIANTS].
First time at te beginning of 1 and then at the end of 1.1

[Ballot comment]
Thank you for the work put into this long but easy to read document. It is clearly a major change for the Internet.

Special thanks to Bernie Volz for his internet directorate review.

I support Erik Kline's comments about sections 9.6.3 (interaction of NAT64 and preferred address) and 14.1 (IPv6 extension headers).

Please bear with some comments from a non-transport oriented person... I have yet to review QUIC-RECOVERY so I will assume for now that packet loss by the network (such as RED) will also reduce the "QUIC congestion window".

NB: I still wonder why QUIC is in upper case if it is a name and not an acronym ;-)

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"QUIC packets are carried in UDP datagrams ([UDP]) to better facilitate deployment in existing systems and networks.", this is an assumption presented as a fact without citing any reference... This does not seem too good to me.

-- Section 2.2 --
  "an endpoint MAY treat receipt of different data at
  the same offset within a stream as a connection error of type
  PROTOCOL_VIOLATION."
 
Should it be a SHOULD or even a MUST rather than a MAY ? Even if streams are protected, isn't it a security issue to allow overwrite of a stream ? Esp when the endpoints could deliver out-of-order to the application ?

-- Section 3.1 (and others) --
It would have been nice to use the SVG alternate graphic format for such an fundamental document ;-)

-- Section 4.2 and others  --
The specification is rather vague about the behavior (no default timer, no default "window", nothing said about increasing the credit, ...) and leaves a lot to implantations. Is it an issue or is it described in QUIC-RECOVERY ?

-- Section 5.1 --
It would be nice for the reader to explain the rationale for having multiple connection IDs for the same connection.

-- Section 7 --
Please state before that QUIC version 0x00000001 is the version specified by the document or use "This version of QUIC" rather than "Version 0x00000001 of QUIC"

-- Section 8.1 --
Out of curiosity, why selecting a UDP payload of at least 1200 octets? I would assume that 1232 would have worked as well (1280 IPv6 MTU - 40 IPv6 header - 8 UDP header). Of course, 1200 is a nicer number ;-)

-- Section 9 (and also 9.4 and possibly others) --
Please also consider adding another reason for an endpoint to change its IPv6 address due to RFC 4941 ("privacy extensions for IPv6 addresses") and not only NAT ;-)

-- Section 9.1 --
Can this mechanism also be used not only when changing of IP address but also of IP version ?

Did the QUIC WG/authors consider using happy eyeball (RFC 8305) to probe whether IPvfoo could become better than IPvbar regularly during a QUIC connection (using the preferred addresses) ?

-- Section 9.7 --
Why a SHOULD for the use of a hash, IMHO a good pseudo-random number would also work (as explained in RFC 6437).

-- Section 13 --
Should the text provide a forward reference to section 14 (datagram size) ?

-- Section 14.1 --
This padding on the initial packets is quite a smart technique ;-)

-- Section 17.2.1 --
I find a little weird that the "unused" field have a SHOULD setting for the MSB... Suggest to keep the F bit apart and use a 6-bit "unused" field.

-- Section 18.2 --
I am not a transport expert, so, I can be wrong but usually, rather than using "::.0",  "[::]:0" is used.

-- Section 19.2 --
Suggest to also mention "keeping NAT binding states alive" as a use case for PING.


== NITS ==

-- Section 1 --
In "QUIC authenticates all packets and encrypts as much as is practical." it is a little unclear to me whether the 'as much' applies only to 'encrypts' or also on 'authenticates'. Or is it clear for an English-native speaker (that I am not).

-- Section 1.3 --
Rather than using "described by ?" why not using the letter 'l' (as in length) rather than a '?'. It is confusing at first sight.

-- Section 4.5 --
"the final size is the number of bytes sent" is slightly ambiguous as it could either be the number of bytes sent by the application or sent as UDP payload. The rest of the paragraph kind of answers the question though.

-- Section 5.2.2 --
"If a server receives a packet that indicates an unsupported version but is large enough to initiate a new connection" it is unclear what is the subject of "is"...

-- Section 6.3 --
The use of "0x?a?a?a?a" with undefined syntax brings only question marks in the reader's mind => suggest to remove "0x?a?a?a?a" but keep the forward pointer to section 15.

-- Section 8.2 --
Why using "two-tuple" rather than the simpler "pair" ?

-- Section 23.1 --
Why using the anchor [IPv4] rather than [RFC791] ? Just curious...

[Ballot comment]
[[ comments ]]

[ section 8.2.3 ]

* I found this wording a tad odd:

    If the PATH_CHALLENGE frame that resulted in successful path
    validation was sent in a datagram that was not expanded to at least
    1200 bytes, the endpoint can regard the address as valid.

  It seems like whether the frame was padded to 1200 or not, if the response
  data matches the challenge data the address can be considered validated.

  I think the point at the end of the sentence is to say that *only* the
  address, but not the MTU, can be taken as validated.

[ section 9.6.3 ]

* Entirely optional, but I wonder if it's worth noting that in certain
  situations, for example an IPv6-only client and IPv4-only server, the
  client might be required to evaluate use of an alternate address family
  address if, for example, some transition mechanism (a la NAT64) was in
  use.

[ section 9.7 ]

* "as this would enable..." reads to me like the opposite of what's intended.
  Perhaps: "as failure to do so would enable..."?

[ section 14.1 ]

* I think it might be important to note that this strategy places some
  restrictions on the use of things like IPv6 extension headers that can be
  used in these packets.

  For example, on an IPv6-only link with a 1280 MTU, enforcing a 1200 byte
  UDP payload in these packets leaves only 32 bytes of space for any
  extension headers.

  I think this is likely fine for these initial packets (vis. section 8.1 and
  so on ), but as a general requirement for all packets this could
  artificially constrain use of new extension headers.

[ section 19.3.1 ]

* This seems intricate enough that it might be nice if there were an
  Appendix (A.5?) section walking through an example computation or two.

[ section 19.18 ]

* I'm idly wondering if there would be any debugging value in the response
  including the IP & port to which the response is being sent (i.e. from
  which the path challenge was received) ... assuming the packet with the
  PATH_RESPONSE frame is protected.

  Not important though, and perhaps it was already discussed and rejected.
  (or maybe it's better as some future, entirely separate PATH_INFO frame)


[[ questions ]]

[ section 8.2.4 ]

* To be clear, this document is effectively saying that it takes no position
  on the interpretation of any ICMP errors received?  Is it up to the
  implementer to decide if "validated" (in as much as ICMP messages can be
  validated) Admin Prohibited messages, for example, should constitute a
  positive confirmation of path failure?  Or is there some very specific
  stance that should be taken ("never trust that lyin' ICMP!")?

[ section 10.3 ]

* Does this "datagram ends with stateless reset token" scheme mean that
  implementations must check the output of every packet, including post
  encryption, and take some action if a (very low probability) collision
  occurs (meaning the output accidentally produces this 16 byte value
  but the packet is not intended to be a stateless reset)?


[[ nits ]]

[ section 7 ]

* There seem to be two paragraphs with the same text about how an endpoint
  validates ECN support.  Seems like maybe only the first paragraph is really
  necessary (or, put another way: I can't see what new information the second
  paragraph adds).

  (the paragraph below Figure 4 seems to be repeated information)

[ section 8.1.1 ]

* "a NEW_TOKEN frames" -> "a NEW_TOKEN frame" or "NEW_TOKEN frames"

[ section 17.2.3 ]

* ", as defined Section" -> ", as defined in Section"

[Ballot comment]
Thanks for a clear and complete document.

Section 17.4: For someone coming to this new, it might not be obvious why requiring the disabling of the spin bit on a fraction of connections is useful. This may be worth a sentence of explanation.

[Ballot 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.

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.

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?

NITS:

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

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

13.3 I believe MAX_STREAM_DATA retransmissions should cease in state RESET_RECVD.

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.

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.

16 The CID length field is another exception to varint encoding.

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

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].

[Ballot 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.

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.

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?

NITS:

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

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

13.3 I believe MAX_STREAM_DATA retransmissions should cease in state RESET_RECVD.

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.

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.

16 The CID length field is another exception to varint encoding.

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

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].

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-quic-transport-32. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has questions about the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, a new registry page will be created on the IANA Matrix located at:

https://www.iana.org/protocols

the new registry page will be titled "QUIC" and have a reference of [ RFC-to-be ].

IANA Question --> Regarding the detailed instructions in section 22.1 of the current document, it's not clear to us what information should be captured in a note. Can you provide the notes that should be added to the top of each registry?

Second, a new registry will be created on the registry page created above called the QUIC Transport Parameters registry. The new registry will be managed via the Specification Required policy as defined by RFC8126.

IANA will add a note to the registry indicating that: " each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved."

IANA Question --> are those values to be marked as reserved in the new registry?

IANA Question --> Section 22.1.2 says, "Use of the first codepoint in a range is
intended for use by specifications that are developed through the
standards process [STD] and its allocation MUST be negotiated with
IANA before use."
 
What does "negotiation with IANA" mean? When there's an expert, normally this would be handled by an expert, but we understand that future documents might use this guidance but apply it to registries that have other registration procedures. Does this mean that if IESG Approval were being used, or a future registry that applied this guidance were to use a registration procedure like IETF Review, which requires only an IETF-stream RFC and does not require expert review, and the registration were being requested in an informational or experimental I-D, IANA would need to be aware of this requirement and refuse to register that codepoint? We really want to know what IANA has to know vs. what the other people such as the expert have to know.

Also, does this mean that codepoints can generally be used before they've been allocated?

IANA Question --> Section 22.1.2 says, "Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration.  IANA MUST allocate the selected codepoint unless that codepoint is already assigned or the
codepoint is the first unallocated codepoint in the registry."

What if it's the first unallocated codepoint in a range, but not in the registry?

There are initial registrations in the new registry as follows:

+=======+=====================================+=============================+
| Value | Parameter Name | Reference |
+=======+=====================================+=============================+
| 0x00 | original_destination_connection_id | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x01 | max_idle_timeout | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x02 | stateless_reset_token | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x03 | max_udp_payload_size | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x04 | initial_max_data | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x05 | initial_max_stream_data_bidi_local | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x06 | initial_max_stream_data_bidi_remote | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x07 | initial_max_stream_data_uni | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x08 | initial_max_streams_bidi | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x09 | initial_max_streams_uni | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x0a | ack_delay_exponent | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x0b | max_ack_delay | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x0c | disable_active_migration | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x0d | preferred_address | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x0e | active_connection_id_limit | [ RFC-to-be Section 18.2 ] | +-------+-------------------------------------+-----------------------------+
| 0x0f | initial_source_connection_id | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+
| 0x10 | retry_source_connection_id | [ RFC-to-be Section 18.2 ] |
+-------+-------------------------------------+-----------------------------+

Third, a new registry will be created on the QUIC registry page created above called the QUIC Frame Types registry.

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

There are initial registrations in the new registry as follows:

+=============+======================+=============================+
| Type Value | Frame Type Name | Definition |
+=============+======================+=============================+
| 0x00 | PADDING | [ RFC-to-be Section 19.1 ] |
+-------------+----------------------+-----------------------------+
| 0x01 | PING | [ RFC-to-be Section 19.2 ] |
+-------------+----------------------+-----------------------------+
| 0x02 - 0x03 | ACK | [ RFC-to-be Section 19.3 ] |
+-------------+----------------------+-----------------------------+
| 0x04 | RESET_STREAM | [ RFC-to-be Section 19.4 ] |
+-------------+----------------------+-----------------------------+
| 0x05 | STOP_SENDING | [ RFC-to-be Section 19.5 ] |
+-------------+----------------------+-----------------------------+
| 0x06 | CRYPTO | [ RFC-to-be Section 19.6 ] |
+-------------+----------------------+-----------------------------+
| 0x07 | NEW_TOKEN | [ RFC-to-be Section 19.7 ] |
+-------------+----------------------+-----------------------------+
| 0x08 - 0x0f | STREAM | [ RFC-to-be Section 19.8 ] |
+-------------+----------------------+-----------------------------+
| 0x10 | MAX_DATA | [ RFC-to-be Section 19.9 ] |
+-------------+----------------------+-----------------------------+
| 0x11 | MAX_STREAM_DATA | [ RFC-to-be Section 19.10 ] |
+-------------+----------------------+-----------------------------+
| 0x12 - 0x13 | MAX_STREAMS | [ RFC-to-be Section 19.11 ] |
+-------------+----------------------+---------------+
| 0x14 | DATA_BLOCKED | [ RFC-to-be Section 19.12 ] |
+-------------+----------------------+-----------------------------+
| 0x15 | STREAM_DATA_BLOCKED | [ RFC-to-be Section 19.13 ] |
+-------------+----------------------+-----------------------------+
| 0x16 - 0x17 | STREAMS_BLOCKED | [ RFC-to-be Section 19.14 ] |
+-------------+----------------------+-----------------------------+
| 0x18 | NEW_CONNECTION_ID | [ RFC-to-be Section 19.15 ] |
+-------------+----------------------+-----------------------------+
| 0x19 | RETIRE_CONNECTION_ID | [ RFC-to-be Section 19.16 ] |
+-------------+----------------------+-----------------------------+
| 0x1a | PATH_CHALLENGE | [ RFC-to-be Section 19.17 ] |
+-------------+----------------------+-----------------------------+
| 0x1b | PATH_RESPONSE | [ RFC-to-be Section 19.18 ] |
+-------------+----------------------+-----------------------------+
| 0x1c - 0x1d | CONNECTION_CLOSE | [ RFC-to-be Section 19.19 ] |
+-------------+----------------------+-----------------------------+
| 0x1e | HANDSHAKE_DONE | [ RFC-to-be Section 19.20 ] |
+-------------+----------------------+-----------------------------+

Fourth, a new registry will be created on the QUIC registry page created above called the QUIC Error Codes registry.

The registration policy for the new registry is as follows:

0x00 - 0x3f - Standards Action or IESG Approval
0x40 - 3FFFFFFFFFFFFFFF - Specification Required

There are initial registrations in the new registry as follows:

+======+===========================+================+=============================+
|Value | Error |Description | Specification |
+======+===========================+================+=============================+
|0x0 | NO_ERROR |No error | [ RFC-to-be Section 20 ] |
+------+---------------------------+----------------+-----------------------------+
|0x1 | INTERNAL_ERROR |Implementation | [ RFC-to-be Section 20 ] |
| | |error | |
+------+---------------------------+----------------+-----------------------------+
|0x2 | CONNECTION_REFUSED |Server refuses a| [ RFC-to-be Section 20 ] |
| | |connection | |
+------+---------------------------+----------------+-----------------------------+
|0x3 | FLOW_CONTROL_ERROR |Flow control | [ RFC-to-be Section 20 ] |
| | |error | |
+------+---------------------------+----------------+-----------------------------+
|0x4 | STREAM_LIMIT_ERROR |Too many streams| [ RFC-to-be Section 20 ] |
| | |opened | |
+------+---------------------------+----------------+-----------------------------+
|0x5 | STREAM_STATE_ERROR |Frame received | [ RFC-to-be Section 20 ] |
| | |in invalid | |
| | |stream state | |
+------+---------------------------+----------------+-----------------------------+
|0x6 | FINAL_SIZE_ERROR |Change to final | [ RFC-to-be Section 20 ] |
| | |size | |
+------+---------------------------+----------------+-----------------------------+
|0x7 | FRAME_ENCODING_ERROR |Frame encoding | [ RFC-to-be Section 20 ] |
| | |error | |
+------+---------------------------+----------------+-----------------------------+
|0x8 | TRANSPORT_PARAMETER_ERROR |Error in | [ RFC-to-be Section 20 ] |
| | |transport | |
| | |parameters | |
+------+---------------------------+----------------+-----------------------------+
|0x9 | CONNECTION_ID_LIMIT_ERROR |Too many | [ RFC-to-be Section 20 ] |
| | |connection IDs | |
| | |received | |
+------+---------------------------+----------------+-----------------------------+
|0xa | PROTOCOL_VIOLATION |Generic protocol| [ RFC-to-be Section 20 ] |
| | |violation | |
+------+---------------------------+----------------+-----------------------------+
|0xb | INVALID_TOKEN |Invalid Token | [ RFC-to-be Section 20 ] |
| | |Received | |
+------+---------------------------+----------------+-----------------------------+
|0xc | APPLICATION_ERROR |Application | [ RFC-to-be Section 20 ] |
| | |error | |
+------+---------------------------+----------------+-----------------------------+
|0xd | CRYPTO_BUFFER_EXCEEDED |CRYPTO data | [ RFC-to-be Section 20 ] |
| | |buffer | |
| | |overflowed | |
+------+---------------------------+----------------+-----------------------------+
|0xe | KEY_UPDATE_ERROR |Invalid packet | [ RFC-to-be Section 20 ] |
| | |protection | |
| | |update | |
+------+---------------------------+----------------+-----------------------------+
|0xf | AEAD_LIMIT_REACHED |Excessive use of| [ RFC-to-be Section 20 ] |
| | |packet | |
| | |protection keys | |
+------+---------------------------+----------------+-----------------------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-11-16):

From: The IESG
To: IETF-Announce
CC: quic-chairs@ietf.org, draft-ietf-quic-transport@ietf.org, quic@ietf.org, magnus.westerlund@ericsson.com, lars@eggert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (QUIC: A UDP-Based Multiplexed and Secure Transport) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'QUIC: A UDP-Based Multiplexed and Secure Transport'
  as Proposed Standard

This document is part of a combined 26-day last call for multiple
related documents that defines the QUIC protocol and the HTTP mapping
onto QUIC. The documents are:

  - draft-ietf-quic-transport
  - draft-ietf-quic-recovery
  - draft-ietf-quic-tls
  - draft-ietf-quic-invariants
  - draft-ietf-quic-http
  - draft-ietf-quic-qpack

Due to its GitHub-centric work style, the QUIC WG requests that LC review
comments are individually filed as issues in the WG repository at
https://github.com/quicwg/base-drafts if at all possible. A summary email with
URLs to the individual issue should then also be sent to the relevant mailing list
(Primarily last-call@ietf.org and quic@ietf.org).

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-11-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.


Abstract


  This document defines the core of the QUIC transport protocol.
  Accompanying documents describe QUIC's loss detection and congestion
  control and the use of TLS for key negotiation.

Note to Readers

  Discussion of this draft takes place on the QUIC working group
  mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
  archived at https://mailarchive.ietf.org/arch/search/?email_list=quic

  Working Group information can be found at https://github.com/quicwg;
  source code and issues list for this draft can be found at
  https://github.com/quicwg/base-drafts/labels/-transport.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

No IPR declarations have been submitted directly on this I-D.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.

Shepherd Writeup for QUIC “base drafts”

1. Summary

This publication requests covers the following I-Ds that together define
the QUIC protocol:

-  QUIC: A UDP-Based Multiplexed and Secure Transport,
    draft-ietf-quic-transport-31
-  QUIC Loss Detection and Congestion Control,
    draft-ietf-quic-recovery-31
-  Using TLS to Secure QUIC, draft-ietf-quic-tls-31
-  Version-Independent Properties of QUIC,
    draft-ietf-quic-invariants-11
-  Hypertext Transfer Protocol Version 3 (HTTP/3),
    draft-ietf-quic-http-31
-  QPACK: Header Compression for HTTP/3, draft-ietf-quic-qpack-18

All of these I-Ds are intended to become Proposed Standard RFCs, and
that intended status is indicated in their respective title page
headers.

2. Document Announcement Write-Up

Technical Summary:

QUIC is a standards-track, UDP-based, stream-multiplexing, encrypted
transport protocol. Its main features are minimizing connection
establishment and overall transport latency for applications such as
HTTP/3, providing multiplexing without head-of-line blocking, requiring
only changes to path endpoints to enable deployment, providing
always-secure transport using TLS 1.3.

This document set specifies the QUIC transport protocol and it
version-independent invariants, its loss detection and recovery
approach, its use of TLS1.3 for providing security, and a new version of
HTTP that uses QUIC (HTTP/3), along with QPACK for header compression in
that protocol.

Working Group Summary:

As can be expected, discussion on many aspects of QUIC was quite
intense. The resulting consensus, however, was judged by the chairs to
be both strong and broad.

Document Quality:

There are over twenty implementations of QUIC that are participating in
interop testing, including all major web browsers and many server, CDN
and standalone library implementations.

The acknowledgements sections of the I-Ds highlight the individuals that
made major contributions to a given document.

Personnel:

The document shepherds for the individual I-Ds are:

-  Lucas Pardue:
    -  draft-ietf-quic-http-31
    -  draft-ietf-quic-qpack-18
-  Lars Eggert:
    -  draft-ietf-quic-transport-31
    -  draft-ietf-quic-recovery-31
-  Mark Nottingham:
    -  draft-ietf-quic-tls-31
    -  draft-ietf-quic-invariants-11

The responsible AD for the document set is Magnus Westerlund.

3. Document Shepherd Review

The document shepherds extensively reviewed the documents before this
publication request.

4. Document Shepherd Review Concerns

The document shepherds have no concerns about the depth or breadth of
the reviews for these documents.

5. Broader Reviews

Parts of the document set benefited from specialized reviews from the
TLS, HTTP and transport IETF communities.

6. Document Shepherd General Concerns

The document shepherds have no general concerns about these documents.

7. IPR Disclosure Obligation

The editors of the I-Ds have all declared that they have filed any and
all appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79.

8. Filed IPR Disclosures

draft-ietf-quic-recovery has had an IPR disclosure filed on it. No
resulting technical changes were argued for.

9. Strength of Consensus

The consensus behind the document set is very strong, also as evidenced
by the substantial number of existing implementations.

The WG last calls were forwarded to the TLS and HTTP WGs, due to the
topical relationships.

10. Discontent

No discontent was voiced.

11. Document Nits

The IDNits tool does not appear to be functioning correctly, both
locally and using the Web service, so it’s difficult to ascertain
whether its results are accurate (there are many “Failure fetching the
file, proceeding without it.” errors).

12. Formal Review Criteria

No formal review requirements are applicable to this document set.

13. Split References

All references within this document set have been identified as either
normative or informative.

14. Normative References

The document set contains the following normative references to I-Ds:

-  draft-ietf-httpbis-cache
-  draft-ietf-httpbis-semantics

All of these are on track for timely publication in their respective
WGs.

15. Downward References

The TLS document has the following downrefs: * RFC8439 (CHACHA) * AES

16. RFC Status Changes

Publication of this document set will not change the status of any
existing RFCs.

17. IANA Considerations Review

The IANA considerations of the document set have been reviewed and no
issues were identified.

18. New “Expert Review” Registries

The document set defines several IANA registries that allow for
“Provisional Registrations” and “Permanent Registrations”, which both
require Expert review. The IESG should select subject matter experts for
these registration types; candidates include the document editors and
the individuals named as contributors in the acknowledgment sections.

19. Validation of Formal Language Parts

No formal code exists in the document set. draft-ietf-quic-transport,
draft-ietf-quic-recovery and draft-ietf-quic-qpack contain python-like
pseudo code, but not at a level of detail that would lend itself to
automated checking.

20. YANG

The document set does not contain a YANG model.