WG last call comments on draft-ietf-quic-transport-29

[Magnus Westerlund <[e-mail]>]

Hi

 

Sorry for not filing issues and instead giving you this dump. A bit short of
time so I wanted to get these in before the end of the last call. 

 

And I have noticed that some are really edge cases. So think them through
and then it is fine to say this is not relevant because of .

 

 

1.       Section 1.3: 

x (A..B):  Indicates that x can be any length from A to B; A can be
      omitted to indicate a minimum of zero bits and B can be omitted to
      indicate no set upper limit; values in this format always end on
      an octet boundary

There is an upper limit based on the protocol even in these cases, either
due to encoding restrictions or the protocol. 2^62-1 bytes in most cases for
length or data limits or the per packet limit where MPS will be a
restriction. Should that be made more explicit. 

 

2.       Section 3.2, Figure 3: 
The top most RESET_STREAM which leads to the Recv state. Shouldn't that go
to the RESET Recvd state immediately. If I interpret the figure it will take
two RESET_STREAMS until one end up in RESET RECVD
 

3.       Section 4.1: "

If a sender is blocked
   for a period longer than the idle timeout (Section 10.2), the
   connection might be closed even when data is available for
   transmission."

Who may close the conenction? both peers, or the sender that is blocked or
the receiver?

 

4.       Section 7.4.1: "

   In particular, a server that accepts 0-RTT data
   MUST NOT set values for the following parameters (Section 18.2) that
   are smaller than the remembered value of the parameters."

 

So far I have not seen any definition for how long TP parameters will be
remembered. I guess that there is a time limit on the 0-RTT keying material
stored in the client that is relevant her, however this is not at all
referenced here. Should there be a pointer or explanation? Because the above
normative statement appears to be missing the tie into how long the client
will remember theses remembered values.

 

5.       Section 8.1.3 and 8.1.4:

First of all I got the wrong impression of this section as the details about
address validation part, that you actually include the address is in the
next section 8.1.4. I don't know if there should be something done about
this or not. But my impression after 8.1.3 and before I read 8.1.4 that this
was not address validation, only client validation, i.e. this is a client I
talked to before. 

My actual question I have on these section is if it there should be
clarification on that the client should keep track of the token on a server
authority + client address/network scope. So that the client will not send
the token unless it is on the same network it was before. 

But maybe this last is unnecessary as the server will ignore the token if it
doesn't match. 
 

6.       Section 9.2:
 

  Receiving acknowledgments for data sent on the new path serves as
   proof of the peer's reachability from the new address.

 

This contradicts the text in Section 8.5:

 

Receipt of an acknowledgment for a packet containing

   a PATH_CHALLENGE frame is not adequate validation, since the

   acknowledgment can be spoofed by a malicious peer.

So this might be an intended differenation between path validation and
indication of basic reachability (assuming no hostility). Maybe that
exception also needs to be noted in the last paragraph in Section 9.2.

 

7.       Section 9.3.1: 

   If an endpoint skips validation of a peer address as described in
   Section 9.3, it does not need to limit its sending rate.
 

So I assume what is referenced in Section 9.3 is this: 
 

An endpoint MAY skip validation of a peer address if
   that address has been seen recently.  In particular, if an endpoint
   returns to a previously-validated path after detecting some form of
   spurious migration, skipping address validation and restoring loss
   detection and congestion state can reduce the performance impact of
   the attack.

 

So the question here is what is considered recently. I think the lifetime of
a address validation is significantly longer than the validity of the
congestion control state. 

 

8.       Section 10.1: 
"Endpoints that have some alternative
   means to ensure that late-arriving packets on the connection do not
   induce a response, such as those that are able to close the UDP
   socket, MAY use an abbreviated draining period which can allow for
   faster resource recovery."

 

So to me this assumes that the underlying system will not reuse the local
UDP port in the time it takes to drain the network. I assume even
applications may shoot itself in the foot if it insist on a local source
port for an outgoing QUIC connections and that was recently used. I assume
that this will not have any significant impact on a QUIC instance, and what
it does to another UDP protocol is all dependent.

 

10.   Section 10.2: "

If a max_idle_timeout is specified by either peer in its transport
   parameters (Section 18.2), the connection is silently closed and its
   state is discarded when it remains idle for longer than the minimum
   of both peers max_idle_timeout values and three times the current
   Probe Timeout (PTO)."

 

Should this really be the minimum and not the maximum. For very low values
of MAX_IDLE_TIMEOUT the QUIC stack is not even given a fair chance of
probing if the path is still there or not? And for larger value the 3*PTO
will always be setting the value. I would have expected the maximum, that
below 3*PTO it will not timeout, and when MAX_IDLE_TIMEOUT > 3*PTO that
value will be limit for how long probing is done. 

 

Doesn't the rule also prevent a stack being silent for longer than 3*PTOs?
That appears wasteful to force continuos communication if there  are no data
be sent. 

 

11.   Section 10.3:

Such an
   endpoint SHOULD limit the number of packets it generates containing a
   CONNECTION_CLOSE frame.

 

To what level should it be limited, e.g. one packet per 1/4 RTT? Or is the
argument that 

Any reduction is sufficient. To me it looks like a simple packet mirror on
path that sends the packets back to the sender will maintain the number of
packets in flight unless there is a reduction factor.

 

12.   Section 12.4:

Packet Payload {
     Frame (..) ...,
   }

   The payload of a packet that contains frames MUST contain at least
   one frame, and MAY contain multiple frames and multiple frame types.

 

Shouldn't the above be written as:

 

Packet Payload {
     Frame (1..) 1...,
   }

 

Each frame has  a minimal length of one octet, and there is a requirement of
at least one frame. I did note that there are no x.y definition. And that
the definition says there are 0 or more entries which isn't true here. I
don't know how much to do about the inconsistency in the notation for this
case?

 

13.   Section 17.2.2:

Length field for the Packet header is undefined. I would guess that it
contains the total length of the Initial Packet in bytes but that should be
defined. Applies also to the 0-RTT and Handshake packet.
 

14.   Section 17.2.5:

The value in the Unused field is selected randomly by the
   server.

Should this say that the receiver should ignore the value in the field?

 

 

15.   Section 19.9:

The Maximum Data (i) field as currently defined will be in many connections
the upper limit for how many packets can be sent in any connection due to
its bit limit. As this is a maximum value due to usage of the variable
encoding to 2^62-1 bytes. It is possible that this value could be reached as
around 2^52 packets approximately. An QUIC packet will be possible to
contain at least 1024 bytes, i.e. 10 bits worth of bytes. In a DC center
network with larger MTUs it is possible that already after 2^50 packets this
value will be exhausted.

Should I simply assume that this amount of data is such a big number that if
an application runs into the limit forcing it to restart the connection is a
minor issue. However considering that the limit in packets are relatively
more discussed, this limit is not much discussed and in fact there are no
mention in 19.9 what to do if that value reaches maximum that can be
encoded, i.e. close the connection. 
 


 16. Section 22.1.4: 

 

   All registrations in this document are assigned a permanent status

   and list as contact both the IESG ([e-mail]) and the QUIC

   working group ([e-mail] (mailto:[e-mail])).

 

The IESG is recommending that registration owner for IETF STD documents are
IETF. The arguments are in this doc: 

https://datatracker.ietf.org/doc/draft-leiba-ietf-iana-registrations/

 

17.	Section 22:

 

An important question that for the high level structure of the registries
are the question if these registries are Version 1 specific, or  expected to
be used across multiple versions of QUIC? Because if the former then the
general heading for the registries should say QUIC Version 1. If they are
intended to be for multiple versions, what type of indication for which
version particular entries are valid are needed? 

 

 

 

 

 

 

Editorials:

 

A.      Section 8.2 uses PMTU without expansion. Before this point it is
only used in TOC. 

 

B.      Section 9.1: 

An endpoint MAY probe for peer reachability from a new local address
   using path validation Section 8.2 prior to migrating the connection
   to the new local address.

 

Missing parenthis around Section ref. 

 

C.      Section 9.6.3:

"

If the connection to the server's preferred address is not from the
   same client address, the server MUST protect against potential
   attacks as described in Section 9.3.1 and Section 9.3.2."

 

Shouldn't it say something more like:

If the client's packet flow to the server's preferred address for the
connection is not from the same client address, the server MUST protect
against potential attacks as described in Section 9.3.1 and Section 9.3.2.