Subject: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Sep 2019 17:17:12 -0700

At the moment, [section 8.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1) states, quote: "_Clients MUST ensure that UDP datagrams containing **only** Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary._"

I think this is incorrect and that "only" should be dropped, as it excludes a UDP datagram that contains an Initial and a 0-RTT packet. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Sep 2019 23:14:30 -0700

Technically a design change.  I think that it should be any packets that contain Initial and don't contain Handshake or 1-RTT packets.  At least, that's what I implemented.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533422287

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Sep 2019 23:51:17 -0700

I'll note that I think there are other requirements formulated in other sections. Perhaps define a term such a minimal initial datagram size and have the requirement in one place rather than sprinkling 1200 bytes in multiple places where it can be difficult to get the finer points (such as UDP vs QUIC packets and with or without header size).

For example section 14 in transport:

> The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by coalescing the Initial packet (see Section 12.2). 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533431679

---

From: ianswett <[email-masked]>
Date: Fri, 20 Sep 2019 06:07:04 -0700

@martinthomson What you implemented should be fine.  However, Initial + 0-RTT coalesced in a datagram should be padded I believe and I don't think we're clear on that today.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533546680

---

From: David Schinazi <[email-masked]>
Date: Fri, 20 Sep 2019 17:49:48 -0700

It might be simpler to require every UDP packet that contains an Initial be padded to at least 1200?

I'm worried that only requiring that of Initial if there is no Handshake/1-RTT present might be tricky on the receiver: what do I do if I receive a non-padded Initial with Handshake but I can't decrypt the Handshake data?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533753588

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 20 Sep 2019 19:20:22 -0700

@martinthomson 
>  I think that it should be any packets that contain Initial and don't contain Handshake or 1-RTT packets.

What we are talking here is a requirement specific to clients, and I am not sure if a client has a chance of sending Initial and Handshake packets at the same time. Quoting [Section 4.9.1](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.9.1) of the TLS draft, "_a client MUST discard Initial keys when it first sends a Handshake packet_."

And even if there is a possibility of a client sending Initial and Handshake at the same moment, I do not think requiring the client to pad a packet that contains only an Initial is correct, as coalescing is an optional behavior to the send side. It would mean that clients coalescing the QUIC packets would send a non-padded packet, while clients not coalescing would send a padded Initial packet. That seems like an odd behavior.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533759994

---

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Sep 2019 16:39:42 -0700

> I am not sure if a client has a chance of sending Initial and Handshake packets at the same time

And yet another issue gets sucked into the wormhole that is the key discard mess.  I guess that we will have to make a final determination based on the outcome of that stuff.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533928935

---

From: Martin Thomson <[email-masked]>
Date: Sun, 22 Sep 2019 19:39:39 -0700

On consideration, I think that the requirement is simple and we don't have to stress about interactions with discarding keys.  If the packet contains an Initial, it's possible that the Initial packet is the only packet that can be used by a server.  Therefore, the datagram should be padded to 1200, regardless of whatever else is included.

So we strike the "only" and we're good.  See 6cfcbe26385f17072ccd330aea619f65bf3bdcb4.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533944616

---

From: MikkelFJ <[email-masked]>
Date: Mon, 23 Sep 2019 00:35:15 -0700

I wonder - if 0-RTT does not have huge certificates, would it not make sense to permit small packets in this case, provided the auth token validates. But in other cases 1200 bytes must be provided. But since 0-RTT might fail, this could then require a retransmission. Restrained devices might be prefer the latter.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-533989748

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Sep 2019 18:21:09 -0700

@mikkelfj Regardless of 0-RTT, for bandwidth constrained deployments, it makes sense to _always_ send a small packet and let the server validate the path.

That said, the chartered goal of V1 is to reduce the connection establishment latency, and we have explicitly decided to require clients to send full-sized packets until the path is validated. I do not think we should revisit that design. Maybe we can in v2.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-534346725

---

From: ekr <[email-masked]>
Date: Sun, 29 Sep 2019 17:20:04 -0700

I do not believe that this is necessarily correct. The reason is that we have not yet nailed down Initial key discard and in at least one version, an Initial ACK would appear in the client's second flight, but that need not be padded.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3053#issuecomment-536356446