Subject: [quicwg/base-drafts] Clarify padding of INITIAL packets (#3255)

From: Robin Marx <[email-masked]>
Date: Sun, 17 Nov 2019 20:04:34 -0800

Following a discussion on Slack (cc @jlaine, @nibanks, @rpaulo ), I feel a clarification might be needed on how/which INITIAL packets should be padded to 1200 bytes.

E.g.,  https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1 states:

> Clients MUST ensure that UDP datagrams containing Initial packets
   have UDP payloads of at least 1200 bytes, adding padding to packets
   in the datagram as necessary.

Some people (cc @nibanks) interpret this to mean ALL packets containing initials should be padded (e.g., also an initial ACK from the client to the server) and not just the first initials with crypto data from the client. 

However, https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-14 somewhat contradicts/restates this:

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

@nibanks said he feels this should be removed/restated.

I personally don't know why ALL initials should be padded outside of the first flight... @nibanks mentioned the stateless LB use case, where they could drop all initials < 1200 bytes, though I'm not sure why a LB would do this... @rpaulo mentioned that padding the client's initial ACKs gives additional allowance towards the 3X amplification factor limit, but as those intitial ACKS will arrive with/close to the client's first handshake packet (which validates the path, IIUC, https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1). 

Either way, I feel the text should be tightened to clarify the intended use.
Full disclosure: we're working on some dirty stuff that spoofs/abuses QUIC initials to carry in-band metadata, so we'd really not like intermediaries dropping < 1200 byte initials by default. 

-- 
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/3255

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 17 Nov 2019 20:48:28 -0800

"Some people (cc @nibanks) interpret this to mean ALL packets containing initials should be padded"

This matches my interpretation and sounds simple and straightforward.

-- 
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/3255#issuecomment-554849445

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 17 Nov 2019 21:52:18 -0800

Yes. We have the consensus to require *every* datagram containing an Initial packet to be padded. See #2522.

-- 
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/3255#issuecomment-554863484

---

From: ianswett <[email-masked]>
Date: Sun, 17 Nov 2019 21:59:21 -0800

To clarify, section 8.1 talks about client Initials.  @RyanAtGoogle at @kazuho are you saying all datagrams containing client Initial packets or all datagrams containing Initial packets?

I think there are some uses for non-padded server to client Initials, such as a CONNECTION_CLOSE.

-- 
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/3255#issuecomment-554865374

---

From: Robin Marx <[email-masked]>
Date: Sun, 17 Nov 2019 22:35:43 -0800

I also meant client-sent initials. Though, I assume for asymmetric PMTU reasons, the server's initials should also be 1200+ bytes?

IIUC correctly from the comments above: requiring client initial ACKs to also be 1200+ is mainly out of convenience/consistency (#2522)?  In that case, the text in section 14 should indeed be updated to make that more clear? I can submit a PR for that. 

-- 
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/3255#issuecomment-554873537

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 17 Nov 2019 22:48:26 -0800

@rmarx That is my understanding, and I think that a PR would be very welcome.

To clarify, the following statement in section 8.1 is correct as I understand: _Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary._.

The text in section 14 seems to be incorrect (likely out-of-date).

-- 
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/3255#issuecomment-554876575

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Nov 2019 01:56:58 -0800

I'm pretty sure that the text in Section 14 is outdated, and should probably be removed, with a short reference to section 8.1.

-- 
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/3255#issuecomment-554941852

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Nov 2019 16:13:28 -0800

That's right, that's just cruft.

-- 
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/3255#issuecomment-555270164

---

From: Robin Marx <[email-masked]>
Date: Mon, 18 Nov 2019 19:04:23 -0800

Thank you for the PR Martin. 

Just for my understanding: the requirement to pad client initials from the second flight onward (i.e., after receiving server packets, ACKing server initials) is purely for convenience. It is not necessary for PMTU or anti-amplification-allowance. As such, the limit should also not be enforced at intermediaries wholesale?   

-- 
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/3255#issuecomment-555311145

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Nov 2019 02:02:04 -0800

For the most part, yes, the second flight is generally sent with some evidence that the return address is live, however we can't guarantee that the second flight carries sufficient entropy.

For instance, HelloRetryRequest causes a second flight that still requires anti-amplification.

Initial packets with acknowledgments in the second flight might still require padding in the case that the client isn't able to send Handshake packets (which can happen when you have a partial server flight).

In the end, this is just simpler.  I would be sad if intermediaries were to "enforce" MUSTs from QUIC.

-- 
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/3255#issuecomment-555428354

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 19 Nov 2019 14:09:31 -0800

In thinking about this a bit more, I wonder if 8.1 says everything we want it to say:

_Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary._

What about INITIAL packets which contain only a CONNECTION_CLOSE frame? Should those be padded? It doesn't seem terribly necessary to do this...

-- 
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/3255#issuecomment-555739048

---

From: ianswett <[email-masked]>
Date: Tue, 19 Nov 2019 14:42:12 -0800

For the client, I think requiring padding even a CONNECTION_CLOSE is the right thing to do, since it simplifies processing on the server side.  On the server, I definitely do not want to require padding Initials that only contain CONNECTION_CLOSE.

-- 
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/3255#issuecomment-555750292

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 Nov 2019 22:08:51 -0800

Yeah, it should be super uncommon for a client to send a CONNECTION_CLOSE in Initial, and I don't think the cost of padding it is terribly high in that uncommon case. I think keeping it simple is probably best here.

-- 
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/3255#issuecomment-555854598

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 19 Nov 2019 22:59:36 -0800

The far most likely case of a server receiving a CONNECTION_CLOSE is a middlebox trying to disrupt the handshake (i.e. RST injection). I do not think we should help them by relaxing the full-size padding requirement.

-- 
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/3255#issuecomment-555867556

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2019 16:32:47 -0800

Closed #3255 via #3262.

-- 
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/3255#event-2830107184