[QUIC] Review of draft-hamilton-quic-transport-protocol-01

[Jim Roskind <[e-mail]>]

I've provided a set of section comments below, separated by lines of
hyphens.

As I've mentioned, I'd be pleased to serve as an an additional editor for
this document, especially considering the years I spent working on this
protocol.

Although I don't expect to be present at the impending IETF meeting, I'm
hopeful that I'll be able to attend future meetings and continue my
participation.

Thanks,

Jim

Note: Opinions expressed are mine, and not that of my employer.


------------------

Section 3: A QUIC Overview

One of the key features of QUIC is missing from the list:

"QUIC (UDP) packets are individually encrypted, and decryptable."

This is in sharp contrast with routine use of TLS over TCP, where
encryption blocks are not aligned with IP packet boundaries.  This QUIC
feature of aligning expected loss of packets (full UDP packets generally
survive, or are lost) is critical to avoiding head-of-line blocking, in the
face of packet loss.

Section 3.3 discusses head-of-line blocking in the context of TCP
streaming, but but does not mention the potential impact of (larger)
encryption blocks on packet loss recovery.  Even if TCP did not require
sequential exposure of the stream (inducing head-of-line blocking), the
requirement for full TLS blocks to be decrypted would generally cause even
a single IP packet loss to delay data contained in a multitude of related
packets.

It is plausible that the above information should be added to section 3.3,
but I'd suggest that it merits a separate bullet point, and section. It
represents a rather significant and innovative intertwining of the
encryption activity, with the packetization (relative to the status quo).
Section 3.3 currently only discusses the intertwining of stream
multiplexing, with packetization.

It is also plausible that mention should be made of the fact that QUIC uses
encryption algorithms that don't use cipher-block-chaining, which is again
critical to the independent decryption of each packet (independent of
losses of other packets). I'd argue that this point should be mentioned in
the same section, which ever one that is.

--------------------

Section 3.4 doesn't expand on another key element:

"When a QUIC packet is lost, rather than retransmitting the now aging
packet with its old packet number, the data in missing packet is optionally
rebundled in a future packets with a new packet number."

This feature allows a QUIC transmitter to significantly compress
specification of a packet number in a QUIC packet header, supplying only
the low-order-bits of a packet number.  When combined with the
cryptographic authentication which keys on the complete packet number, any
old, resurrected, or previously assumed-to-be-lost packet, routinely fails
authentication, and is automatically discarded.

The above is hinted at with the second section of 3.4, but it is pretty
important to understanding QUIC, and probably should be pulled out to
either a new section, or a second paragraph of the existing overview
section.

--------------------

Section 3.7 probably overstates and understates aspects of a Connection ID.


The understatement should perhaps expand to note that the connection ID
serves to encode the name of the connection and all state (negotiated
version, crypto settlement, congestion avoidance algorithm agreement,
etc.), independent of changes in transport details, such as source IP or
port number.  This compact encoding allows ongoing data packets to be very
efficiently packed, without need for perpetual restatement of the state.

The possible overstatement is that

"The connection ID remains consistent across ..."

The intent of the design of QUIC was for the connection ID to encode the
state, but it may, upon agreement by both endpoints, it may vary across the
life of the connection.  It could be that later discussion in section 4.1
discussion is enough, but I suspect that the current use of the singular
phrase:

"The connection ID"

along with the word "consistent," suggests that the connection ID is
"invariant," which would be confusing to readers of this overview.

Suggestion: Perhaps  remove the entire trailing sentence in section 3.7.
Perhaps change the sentence to optionally pluralize the subject, and use a
word other than "consistent," such as:

"The connection ID(s) used in a QUIC connection can specify a connection
independent of changes in the client's and the server's network addresses."

--------------------

Section 4.2.1: IMO, the four bullets are confusing, because they are
written backwards from the what I consider the intent.  For example, the
fourth bullet would read better as:

"When a sender has more than (2^6) packets in flight, it MUST set the
PACKET_SIZE_NUMBER to 01, 10, or 11."

The point is that the decision about the PACKET_NUMBER_SIZE is based upon
the current amount of potential ambiguity in the packet number
interpretation. I found reading it the other way (as currently written)
confusing, though it may be logically equivalent.

-------------------

Section 4.2.1: Consider removing the  DISCUSS comment  asking "Should a
receiver enforce ..."

If the receiver is able to authenticate and decrypt a packet, then it
should dod so.  I would note that the algorithm for extending a truncated
packet number to a complete packet number is given explicitly, so I don't
believe any heroic efforts should be taken beyond that algorithm (though if
some better(?) quality implementation emerges, there seems no reason to
preclude it). Given the potential loss of packets, it probably becomes
untestable to standardize on such a "receiver enforcement rule."  Old
packets can arrive at any time in the future, but the receiver should not
take enforcement actions (e.g., connection termination? signal an error?)
when they are observed.


--------------------

Section 5.2.2: There should be discussion about when a STK can be reused at
more than one site (for more than one hostname).  This feature,
significantly accelerating connectivity to applicable hosts, is visible in
the open source code of Chromium, but appears unmentioned in the this
document.

--------------------

Section 5.2.3: I think it is too strong to say "The crypto handshake MUST
ensure that the final negotiated key is unique for every connection between
two endpoints."  This should be a probabilistic guarantee, and should not
require saving all keys for all time, to achieve currently stated result
(re: unique).


--------------------

section 5.2.3: Discussion should be included of packet padding in the first
packet sent, as this combats any amplification attack.  Specifically, "The
CHLO packet MUST be at least NNNN bytes, whether due to data content, or
via padding." I'd suggest adding it as one of the bullets, as it should be
independent of the encryption method used.

--------------------


Section 5.4: Item 3: A public reset was not intended for use in the given
example, where a machine reboots and loses cryptographic state. Public
reset was intended for use when the crypto state is known, and can
affirmatively be indicated with an authenticated Public Reset. When folks
eventually(?) get around to supporting an authenticated Public reset
(authentication required!), this example will be unachievable.  As a
result, it should probably be removed.


--------------------

Section 6.2:  The indicated defense against an opportunistic ack attack,
via skipping packets, is potentially very expensive in terms of bandwidth
in the reverse direction.  It should be hoped that such defense will only
be employed  when the congestion window is large, and hence when many
responsive ACK frames are in flight.  In such a case, an honest client will
waste a fair amount of bandwidth in the reverse direction (all ACKs for the
duration of one RTT will specify the missing packet).  Is this desirable?

--------------------

Section 7, Paragraph 1.  I don't believe RFC4821 (PMTU) is generally
workable, as I don't believe ICMP packets would be properly routed to the
host computer (recall there is only a potentially NATed UDP connection),
and the host computer generally does not even expect ICMP packets to arrive
that relate to a UDP sequence (I haven't seen library calls that could
access such data in the OS).  I think PMTU is only (currently) applicable
to TCP.

Discussion can/should/could be added to indicate that QUIC can perform MTU
exploration, but I don't believe ICMP (and PMTU) would come into play.


--------------------

Section 8.4, bullet 2: Please provide some motivation for excluding
additional streams from both stream and connection flow control.

--------------------

Section 9.1: Can you explain how the deadlock can be achieved, other than
by a faulty implementation?  Notification of available window space should
eventually be acked, or retransmitted.  What is the issue here? If this is
not possible, with a working implementation, it probably should not be
mentioned.


--------------------

Section 11.1: line 2: typo   s/attacked/attacker/

--------------------


Section 14.3:  The reference to my design document is sadly encoded with a
flavor of a TinyURL.  Please add the following text (analogously to the way
that QUIC-CRYPTO is referenced 2 lines above):

[1]
      Roskind, J. "QUIC: Design Document and Specification Rationale", May
2015
      https://goo.gl/dMVtFi

<https://goo.gl/dMVtFi>

<https://goo.gl/dMVtFi>

<https://goo.gl/dMVtFi>
- <https://goo.gl/dMVtFi>--------------------------


Thanks!