Subject: [quicwg/base-drafts] Recommended response for empty packets (#1835)

From: Christian Huitema <[email-masked]>
Date: Thu, 04 Oct 2018 22:52:42 -0700

Draft-15 says in section 5 that "_QUIC payloads MUST contain at least one frame, and MAY contain
multiple frames and multiple frame types._" That's fine, but there is no text specifying the receiver behavior. How about, "_Nodes who receive a packet with an empty payload MUST terminate the connection with error PROTOCOL_VIOLATION_"?

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 05 Oct 2018 00:10:16 -0700

That won't work in early handshake but it could make sense later on. Why have this restriction and complication in the first place rather than just allowing empty frames?

-- 
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/1835#issuecomment-427267820

---

From: Nick Banks <[email-masked]>
Date: Fri, 05 Oct 2018 13:58:09 +0000 (UTC)

I also disagreed with adding the extra complexity added on the receiver side. Personally, I'd prefer to add that the receiver MAY terminate the connection.

-- 
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/1835#issuecomment-427375133

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 05 Oct 2018 07:22:48 -0700

I might argue that there is possibly a security implication on allowing empty packets.

If we allow the receiver to handle an empty packet as non-error, the endpoint might be tempted to skip verifying the AEAD tag, because it can be sure that there is no payload once it decrypts the packet number. This is obviously incorrect, because the AEAD tag is the only thing we have in protection against packet injection.

Requiring the sender to always send a non-empty payload and also requiring the receiver to return an error in case it sees an empty payload is one way to resolve such concern.

I might agree that the concern is not really that practical, but OTOH, I think implementing the rule is near to zero-cost as well.

-- 
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/1835#issuecomment-427383093

---

From: MikkelFJ <[email-masked]>
Date: Fri, 05 Oct 2018 07:57:42 -0700

Hmm, I'm not sure the protocol should be designed around babysitting special cases. You argument could just as well apply to packets with padding only or packets with only NEW_CONNECTION_ID when there are no support for changing CID's, etc.  It is already stated that a packet cannot be dropped without veryfying the AEAD tag.

-- 
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/1835#issuecomment-427394748

---

From: MikkelFJ <[email-masked]>
Date: Fri, 05 Oct 2018 08:00:06 -0700

Empty packets also serve a keep-alive purpose. That said, there is another PR, or something, suggesting packets should have a minimum length to simplify PNE. That would naturally void empty packets.

-- 
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/1835#issuecomment-427395555

---

From: Christian Huitema <[email-masked]>
Date: Fri, 05 Oct 2018 15:22:16 +0000 (UTC)

My main point is that the spec says MUST NOT be empty without specifying receiver behavior. So the spec should either not say that, or specify the 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/1835#issuecomment-427402973

---

From: MikkelFJ <[email-masked]>
Date: Fri, 05 Oct 2018 08:33:07 -0700

I agree with your point, I'm just mentioning that any resolution needs to consider handshake behavior in a way that does open for DoS injection.

-- 
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/1835#issuecomment-427406446

---

From: ianswett <[email-masked]>
Date: Mon, 08 Oct 2018 07:03:08 -0700

I sent out a PR with a variant of Christian's suggestion using MAY.

If one wants a keepalive, a packet containing a PING likely makes more sense than an empty one, since an empty one won't cause an ACK to be sent in response.

-- 
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/1835#issuecomment-427846403

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 08 Oct 2018 08:59:31 -0700

If a client wants to keep its NAT binding alive, it may want to send a PADDING (or nothing at all, if it were supported).

-- 
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/1835#issuecomment-427888937

---

From: janaiyengar <[email-masked]>
Date: Tue, 09 Oct 2018 15:24:33 -0700

Closed #1835 via #1839.

-- 
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/1835#event-1894106968