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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 18:04:37 +0000

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 ([email-masked]) and the QUIC

   working group ([email-masked] (mailto:[email-masked])).

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 8 Jul 2020 18:05:29 +0000

Fixing draft alias.

/Magnus

From: Magnus Westerlund 
Sent: den 8 juli 2020 20:05
To: [email-masked]; [email-masked]
Subject: WG last call comments on draft-ietf-quic-transport-29

Hi

 

1.       Section 1.3: 

3.       Section 4.1: "

If a sender is blocked

4.       Section 7.4.1: "

6.       Section 9.2:

7.       Section 9.3.1: 

8.       Section 10.1: 

10.   Section 10.2: "

11.   Section 10.3:

Such an

12.   Section 12.4:

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

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

13.   Section 17.2.2:

14.   Section 17.2.5:

 

15.   Section 19.9:

 16. Section 22.1.4: 

   and list as contact both the IESG ([email-masked] <mailto:[email-masked]> )
and the QUIC

   working group ([email-masked] <mailto:[email-masked]>
(mailto:[email-masked])).

17.	Section 22:

 

 

Editorials:

2.       Section 9.1: 

3.       Section 9.6.3:

"

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 Jul 2020 16:27:42 +1000

Hi Magnus,

Thanks for taking the time to review.  These are all good.  I've opened a PR that addresses most of these, but some might require some discussion.

https://github.com/quicwg/base-drafts/pull/3881

On Thu, Jul 9, 2020, at 04:04, Magnus Westerlund wrote:
...
> 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. 

This is a length of a field in bits, which means that "no set upper limit" is fine in my view.  There is often an upper limit, but it depends on how much space is left in the packet.  Note that the 2^62 cap doesn't have to apply to lengths in bits.

> 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

There are a few places in the diagrams where a single event causes multiple transitions.  For instance, receiving STREAM with FIN can cause a transition from the starting state, through Recv and Size Known, to Data Recvd.  I thought that we had noted that this can happen, but I see that this didn't happen.

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

The receiver.  Addressed in the PR.

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

The rule is that when you remember a ticket, you need to remember a bunch of stuff with that in order for 0-RTT to work.  You don't get to remember part of that and expect to have 0-RTT work.  I've added a little more context.

I've also opened https://github.com/quicwg/base-drafts/pull/3879 to improve on the context in the -tls draft.

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

Right.  The cost to the client is:

1. The server can correlate the attempt with a previous connection.
2. The client uses up the token.

I think that the text in 8.1.3 is adequate on this point.

> exception also needs to be noted in the last paragraph in Section 9.2.

Oh, good catch.  The point about acknowledgments is just wrong.  This is just old text that should have been fixed.

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

This is a tough question, and entirely subjective.  No number is good here.  I've heard that some implementations limit this to a day, other to an hour.  I suspect that we just have to live with this.

I've opened an issue: https://github.com/quicwg/base-drafts/issues/3880

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

Yes.  I think that this generally only applies to use of ephemeral ports on client systems, where the reuse period is relatively long. 

More importantly, the consequence is that the new user of the port has to filter out some residual garbage.  As everything in QUIC is authenticated, this is not a serious problem in the same way that it might be for another protocol.

> 10. Section 10.2: "
...
> 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. 
This was found and a fix prepared already: https://github.com/quicwg/base-drafts/pull/3847

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

The 3PTO was a backstop for cases where the idle timeout was set too low relative to the RTT.  Our advice on keeping connections alive is not to do that unless you have committed state that you don't want to lose.  For instance, an HTTP client might send keep-alives only while it is waiting for a response to a request.

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

This was raised in https://github.com/quicwg/base-drafts/issues/3845

I agree that this is vague.  I have proposed a solution here based on our anti-amplification limit: https://github.com/quicwg/base-drafts/pull/3864

Note also that this is limited to the duration of the closing period, so this is not a permanent state.  A small amount of amplification is likely tolerable on that time frame.

> 12. Section 12.4:
...
>  Frame (1..) 1...,

Yes.  Frame (8..) ..., But I don't think that we can capture the requirement to include at least one frame.  That's OK, it's just for illustration purposes :)

> contains the total length of the Initial Packet in bytes but that 
> should be defined. Applies also to the 0-RTT and Handshake packet.

They are mentioned and defined earlier, but their mentions don't reference the definition.  Fixed.

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

Fixed.  Thanks.

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

Yes, that is the current thinking.  Note that there were proposals to scale the values in MAX_DATA to allow for more data to be sent.  However, this proposal wasn't that favourably viewed as it increased complexity quite a bit, and 2^62 is really a very big number and having to create another connection at that rate isn't that much of an imposition.

(Also, I've learned that you don't get to make many such connections before you wear out the AEAD functions we have here.)

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

Corrected.  Thanks.

>  1. 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? 

I think that leaving that problem to future iterations of this group is best.  I know that future me will have ample cause to resent the decisions of present me anyway.

If QUICv2 wants to reuse these, then no change is necessary.  However, if they/we want to make new registries, then renaming these registries requires little effort.