Subject: Re: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)

From: ekr <[email-masked]>
Date: Tue, 04 Feb 2020 01:53:37 -0800

I actually don't think this is editorial. The CID match requirement is clearly technical and, as has been noted before, this would cause problems with Neqo's padding strategy.

-- 
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/3340#issuecomment-581828307

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Feb 2020 02:56:14 -0800

This came up in the room as well.  The current proposal is:

If a packet is successfully processed, then the bytes of the datagram that it was contained in count toward the amplification limit.

There is some question about whether servers are permitted to include other datagrams that are sent on the same path.  This might be easier for some people to manage, but @marten-seemann is concerned that it could lead to inconsistencies and therefore bugs.  Personally, I find the idea that purely junk datagrams MAY be counted to be acceptable.

-- 
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/3340#issuecomment-581852698

---

From: ianswett <[email-masked]>
Date: Tue, 04 Feb 2020 03:09:29 -0800

To add normative language to Martin's statement, "If a packet is successfully processed, then the bytes of the datagram that it was contained in MUST count toward the amplification limit."

Additionally, I'd suggest if the long header matches, but it's not processable(ie: 0-RTT), then it SHOULD count and pure junk MAY count.  As such clients cannot rely on non processable packets to increase amplification limits.

-- 
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/3340#issuecomment-581857902

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Feb 2020 03:26:12 -0800

I share @ianswett's concern regarding 0-RTT packets.

At the moment, [section 8.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1-4) states:
> In order to avoid this causing a handshake deadlock, clients SHOULD send a packet upon a probe timeout, as described in [QUIC-RECOVERY]. If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.

As you can see, we do not require the probe to be an Initial packet. They could be purely 0-RTT packets. If we are to allow an endpoint calculate amplification factor at QUIC packet level, we need to change this provision.

And that change should require the client to send probes as Initial packets that are large enough. It cannot simply be a packet that contains only one byte PADDING (or PING).

To me, that seems a bit too complicated.

-- 
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/3340#issuecomment-581864001

---

From: ianswett <[email-masked]>
Date: Tue, 04 Feb 2020 03:34:22 -0800

All client Initial packets are in full-sized datagrams, based on my understanding, so a PING is fine in practice.

And the PTO is never armed for 0-RTT, so the probe packets would not be 0-RTT.  That being said, I'm a bit concerned those are SHOULDs and not MUSTs.

-- 
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/3340#issuecomment-581866631

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 04 Feb 2020 05:27:26 -0800

@ianswett 
> And the PTO is never armed for 0-RTT, so the probe packets would not be 0-RTT. That being said, I'm a bit concerned those are SHOULDs and not MUSTs.

Yeah, I am concerned that it might be fragile to rely on the behavior of recovery. Moreover, if the client has large amount of data to send, it'd me natural for that client to continue sending datagrams, each of them consisting of a tiny Initial packet and a large 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/3340#issuecomment-581908868

---

From: ianswett <[email-masked]>
Date: Wed, 05 Feb 2020 10:36:15 -0800

So the interesting case is when 0-RTT is accepted, but address validation is not?  And therefore, the server can process 0-RTT packets but cannot send much in response?

If so, I hadn't considered that, but I could document that case in recovery if it's helpful?

-- 
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/3340#issuecomment-582549587