Subject: Re: [quicwg/base-drafts] amplification attack using Retry and VN triggered by coalesced Initial packets (#2259)

From: ianswett <[email-masked]>
Date: Tue, 01 Jan 2019 18:43:12 -0800

I think I prefer the suggestion of @marten-seemann of not allowing two packets with the same encryption levels in a datagram.  Given you can't change CID, the only other purpose of multiple packets would be to supply different versions. I had been assuming all QUIC packets in a datagram have a single version.  If we want to allow that, I think we should explicitly decide that.

If we want to allow that, I think we need to both add a rule about sending one Retry per datagram and a rule about what to do with the rest of the QUIC packets in the datagram once you send a Retry.  Presumably you should drop/ignore them as @nibanks suggested?

-- 
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/2259#issuecomment-450778541

---

From: Nick Banks <[email-masked]>
Date: Wed, 02 Jan 2019 06:59:27 -0800

I am in agreement with @kazuho here. I don't see a need to limit the type or number of QUIC packets in a datagram. In my implementation that would just increase the state and complexity.

I also don't think we need to support different QUIC versions in the same datagram. Push the little bit of extra work to the client in this case, and have it send different datagrams instead. Perhaps we should explicitly disallow this scenario in the spec.

-- 
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/2259#issuecomment-450884937

---

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 14:48:10 -0800

The current text on coalescing packets is:
> `Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram. Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram.`

We could solve this amplification attack by changing that quote to `Destination Connection ID or Version`, and add text like: `If a server receives a coalesced QUIC packet that causes it to send a Retry or Version Negotiation packet, the server MUST silently drop all subsequent coalesced packets in this UDP datagram.` This has the advantage of not limiting the type or number of coalesced 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/2259#issuecomment-451302488

---

From: MikkelFJ <[email-masked]>
Date: Thu, 03 Jan 2019 15:05:12 -0800

Currently coalescing only makes sense in early packets, but as a general concept I don't like forcing ordering on processing independent packets because it affects concurrency design.

Since the problem relates to stateless transmission there is only the datagram to latch onto as a substitute for state and this sort of requires ordering as @DavidSchinazi suggests.

If instead we require that a VN or Retry can only be sent if it is triggered by the very first QUIC packet in a datagram then we avoid most of the ordering. A recommendation could be to silently drop further packets, but not require it. What could go wrong if subsequent packets were to be processed (keeping in mind that it will cause a stateful transition of successful)?

-- 
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/2259#issuecomment-451306262

---

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 15:23:10 -0800

@mikkelfj I didn't suggest enforcing ordering. Whichever packets causes sending Retry/VN causes all subsequent packets to be dropped. I don't see having the third packet trigger a Retry as an an issue.

-- 
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/2259#issuecomment-451309890

---

From: MikkelFJ <[email-masked]>
Date: Thu, 03 Jan 2019 15:34:14 -0800

@DavidSchinazi even if there is no strict ordering, there is still coordination. And reading you text verbatim you also require the first Reset / VN triggering packet to win.

For the sake of argument assume packets were coalesced in the general case. A single preprocessor locates packet boundaries and pushes each packet to a queue handled by several processing units which picks a packet whenever it is available for processing. Suddenly one of these processors wants to emit a Reset. It then has to signal all other processors that they should stop doing what they are doing if they happen to be processing the same datagram. Furthermore, the processor must figure out if there is another processor also wanting to send a VN or Reset on the same datagram, and if so, if it is earlier in the datagram such that the correct winner can be identified.

In praxis such complexity would not be implemented as long as coalescing only happens during handshake, but it illustrates that ordering constraints are difficult when introducing concurrency in processing.

-- 
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/2259#issuecomment-451312132

---

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 15:43:43 -0800

@mikkelfj Ah I see, I thought you meant requiring/enforcing in which order packets are sent, but you meant that now the order in which they are sent matters when it didn't used to. I agree with you, and I see how this could be an issue for some implementations.

Another solution would be to prohibit sending Retry/VN in response to packets that are smaller than 601 bytes (the idea behind the number 601=1200/2+1 is that if well-behaved clients always pad their largest long header it should meet this 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/2259#issuecomment-451313928

---

From: MikkelFJ <[email-masked]>
Date: Fri, 04 Jan 2019 01:51:48 -0800

I was about to suggest that VN / Retry could only be sent if the QUIC packet had at least 1200 bytes, but that goes against the idea of using coalesced packets. I'm not sure that 600 bytes is much better because it limits how much you can send in a second coalesced package when you want to stay below the minimum PMTU.

By requiring that only the first QUIC packet in a datagram can trigger VN / Retry you avoid these problems, and I can't imagine a reasonable case where you want to coalesce packets in a way where later packets actually trigger a VN / Retry.

One could also add that coalesced packets must belong to the same logical connection or connection attempt and that an implementation MAY ignore part or all of the packets in a datagram that does not conform (without requiring this to be enforced because that could get complex fast).

-- 
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/2259#issuecomment-451399498

---

From: ianswett <[email-masked]>
Date: Sun, 06 Jan 2019 12:43:35 -0800

@DavidSchinazi I think a tweak to your previous suggestion is probably best here: "If a server receives a coalesced QUIC packet that causes it to send a Retry or Version Negotiation packet, the server SHOULD silently drop all subsequent coalesced packets in this UDP datagram.

-- 
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/2259#issuecomment-451773143

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 06 Jan 2019 16:51:01 -0800

@ianswett 
> "If a server receives a coalesced QUIC packet that causes it to send a Retry or Version Negotiation packet, the server SHOULD silently drop all subsequent coalesced packets in this UDP datagram.

That sounds a bit odd to me, because IIRC we decided in #1514 that servers can buffer 0-RTT packets when sending a Retry. Recommending a server to drop a 0-RTT packet that wes coalesced to an Initial packet will have a negative impact to servers that choose such a strategy.

I still think that the best text is "one Retry per UDP datagram" suggested by @martinthomson. It allows the behavior you suggested with more freedom.

-- 
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/2259#issuecomment-451791875

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Jan 2019 08:52:05 -0800

Is there any case where it a VN / Retry would reasonably be triggered after the first packet in a datagram? If not, why not simply restrict VN / Retry to the first 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/2259#issuecomment-452001462

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Jan 2019 23:41:41 -0800

> Is there any case where it a VN / Retry would reasonably be triggered after the first packet in a datagram?

I do not think such a case exists, because a QUIC packet belonging to different connections are never coalesced, and because v1 requires every packet of a connection to use the same version number.

Therefore, I agree that endpoints can restrict VN / Retry to the first packet. It might be a good idea to clarify that.

Though I am not sure if that should be the normative requirement. IMO, the requirement is that a server MUST NOT send too many (possible no more than one) datagram in response. The way you describe is one way of achieving 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/2259#issuecomment-452601070

---

From: MikkelFJ <[email-masked]>
Date: Wed, 09 Jan 2019 00:56:12 -0800

If it is normative it would prevent certain reorderings of packets that receivers would otherwise need to consider, however little sense such reorderings make.

-- 
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/2259#issuecomment-452619665

---

From: janaiyengar <[email-masked]>
Date: Wed, 16 Jan 2019 00:14:50 +0000 (UTC)

Closed #2259 via #2303.

-- 
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/2259#event-2076119458

---

From: janaiyengar <[email-masked]>
Date: Tue, 15 Jan 2019 16:15:06 -0800

Please reopen the issue if you think this ought to be discussed further, especially in Tokyo.

-- 
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/2259#issuecomment-454601517