Subject: Re: Comments on draft-ietf-quic-transport-00

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Dec 2016 10:59:41 +1100

Hi Martin,

I've opened issues for your versioning and flags questions.  See inline.

On 1 December 2016 at 16:41, Martin Duke <[email-masked]> wrote:
> Section 4.1. Common Header.

https://github.com/quicwg/base-drafts/issues/55
https://github.com/quicwg/base-drafts/issues/56

> Section 4.2. Regular Packets. The version field should immediately follow
> the public flags

Note that Google might have a hard time deploying your suggestion for
changing the packet layout; but I won't argue that point because I
have no deployed code :)  But see the above issues.

> Section 4.2.1. Should receivers enforce that packet numbers are long enough?

https://github.com/quicwg/base-drafts/issues/57

> Section 4.2.2 Frame types. I think we need an "experimental" frame type,

It's so refreshing to have this conversation early in the design process.
https://github.com/quicwg/base-drafts/issues/58

> Section 4.4. Public Reset.

Yep, let's continue that discussion separately.

> Separately, what is the Connection ID we MUST use if the client never
> generated one?

I don't understand.  The client is obligated to generate one, right?
"This must be set in all packets until negotiated to a different value
for a given direction."

> Section 5.1. Version Negotiation. This mechanism is completely vulnerable to
> DoS by eavesdropper at connection startup. An attacker can sniff the client
> hello and spoof a server version negotiation message that only advertises
> nonexistent versions, preventing connection.

Yes.  An attacker can also tweak the TLS ServerHello or ClientHello in
any way they choose to prevent that from completing too.  I don't
believe that there is any defense against this style of DoS prior to
having a shared secret.

> As with Public Resets, a short waiting period before abandoning the
> connection would solve the problem.

This is harder than you think.  TLS implementations generally don't
defend against this over TCP either, though the attack is perfectly
feasible there as well (though the attack arguably requires more
resources to break into TCP).  The problem is that there are lots of
perfectly valid TLS messages and processing any of them creates a
bunch of state.  Reverting that state is non-trivial.

Yeah, we could do it, but I'm not sure that anyone will implement it.

> Section 5.2.1. ICSL is missing here, even though it is listed as mandatory
> in 5.4.

https://github.com/quicwg/base-drafts/issues/59

> Section 5.2.2. You mention "stateless rejects" here, but the draft could
> really use a full section on it.

https://github.com/quicwg/base-drafts/issues/60

> Section 5.3. Do we need an ADD_ADDR message to advertise additional
> addresses, in the event that address is unreachable from the peer's
> currently known addresses?

Given how big the pile of work is already, I would prefer to defer
working on this sort of thing.  Feel free to open an issue though.

> What is a "silent close option?" Is this negotiated or just a
> sysctl/sockopt? If negotiated, we need more details.

https://github.com/quicwg/base-drafts/issues/61

> Instead, I recommend that all fields necessary for frame length computation
> are first in the frame.

https://github.com/quicwg/base-drafts/issues/62

> section 6.2 Ack frames: I am unclear about the procedure for including ACK
> blocks in a particular frame.

https://github.com/quicwg/base-drafts/issues/63

> Section 7. PMTU discovery:

https://github.com/quicwg/base-drafts/issues/64

> Section 9. Why are BLOCKED frames a MUST? They are sort of like TCP persist
> probes, but WINDOW_UPDATE messages are delivered reliably in QUIC, so
> BLOCKED has no input on operation. If the purpose is debugging only this
> ought to be no more than a SHOULD, and probably a MAY.

Ahh, the BLOCKED issue was a sore point in HTTP/2.  I look forward to
another lively discussion.  AIUI, it's not a deadlock issue, because
you can always recover from flow control issues, but it is useful in
providing feedback for performance tuning.

https://github.com/quicwg/base-drafts/issues/65

> Nits:

I got most of these, thanks.

> Section 7. Withholding packets to wait for more frames: I suggest some sort
> of bound on how long the sender can wait.

That's a design issue, I think, but I don't know what to write in it.

---

From: Asgeir Eiriksson <[email-masked]>
Date: Thu, 8 Dec 2016 11:30:19 -0800

> On Nov 30, 2016, at 10:00 PM, Aron . <[email-masked]> wrote:
> 
> On Thu, Dec 1, 2016 at 12:41 AM, Martin Duke <[email-masked] <mailto:[email-masked]>> wrote: 
> Section 6. Frame Formats. Another broad comment: one common task will be take a piece of a packet corresponding to a frame and passing it into some handling function. Similarly, we would want some basic sanity checks on frame length (i.e. <= remaining packet length) before starting processing. It would be helpful if it were easy to parse the first few bytes of the frame to find its length. Length computation requires reading the flags, and sometimes checking additional fields that are variable lengths from the start of the frame. This is very cumbersome to implement. If you're trying in plain old C, as I am, the macros are horrendous.
> 
> Have the frame handling function return the number of bytes it consumed or -1 on error.
> 
>   Aron.
> 

The length field is optional see Section 6.1 The ’D’ bit indicates whether a Data Length field is present in the STREAM header

It might be helpful to contrast the above sw implementation discussion and a hw implementation 

If the packet parsing is happening in hw e.g. NIC then there are 8B/16B/32B to be processed/parsed per clock cycle, and if the processing is proceeding in cut-through mode (which is typical), the Ethernet CRC, the UDP checksum check, and QUIC parsing, etc. are all happening at the same time, and then the various error flags are gathered up after the end of the packet, and the packet either dropped, or processed further, or handed off to sw

I’m new to QUIC and it is not clear to me if the QUIC use case(s) extend to 10Gbps and 100Gbps implied by the 16B and 32B above (which are used in 10Gbps and 100Gbps TCP processing designs)

‘Asgeir