Subject: Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)

From: Christian Huitema <[email-masked]>
Date: Tue, 08 Dec 2020 19:06:43 -0800

I am seeing interop failures. Picoquic avoids sending full size datagrams in response to short natted packets; it just send short challenges to both client addresses, and will perform PMTUD later. Some implementations see "unpadded challenges" as some kind of protocol violation and just ignore them, leading to connection failures.

This is a difficult situation, because implementations end up having to choose between sending long challenge packets in response to NAT and risking participating in reflection DDOS, or sending short challenge packets and risking connection failures.

I think this is a case in which the behavior of clients and servers vary. When clients send PATH CHALLENGE, they are either deliberately attempting to probe a new path, or maybe verifying a NAT response from the server. In both cases, padding is appropriate. For servers, padding is appropriate in response to a padded client message, but it is mostly inappropriate in response to a short natted 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/4257#issuecomment-741496159

---

From: Lars Eggert <[email-masked]>
Date: Wed, 09 Dec 2020 05:44:05 -0800

So at least my implementation requires padded PATH_CHALLENGES, because Section 8.2.1 says:
> An endpoint MUST expand datagrams that contain a PATH_CHALLENGE frame
to at least the smallest allowed maximum datagram size of 1200 bytes.

Is there an inconsistency in the spec 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/4257#issuecomment-741779560

---

From: ianswett <[email-masked]>
Date: Wed, 09 Dec 2020 07:36:41 -0800

> Is there an inconsistency in the spec here?

The PR adds ", unless the anti-amplification limit for the path does not permit sending a datagram of this size."

-- 
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/4257#issuecomment-741851438

---

From: Mike Bishop <[email-masked]>
Date: Wed, 09 Dec 2020 08:13:17 -0800

Given that you can't validate the "unless" criteria for the peer, it seems like the client isn't able to enforce this MUST.

-- 
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/4257#issuecomment-741876737

---

From: Christian Huitema <[email-masked]>
Date: Wed, 09 Dec 2020 08:25:13 -0800

What Mike says. "MUST ... unless" is not standard per RFC 2119 and 8174, and that leaves implementers with fuzzy guidance, leading to interop failures. The proper text would be something like:
```
Client endpoints MUST expand datagrams that contain a PATH_CHALLENGE frame
to at least the smallest allowed maximum datagram size of 1200 bytes. Server endpoints
SHOULD do the same, unless the anti-amplification limit for the path does not permit
sending a datagram of this size.
```

-- 
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/4257#issuecomment-741884681

---

From: David Schinazi <[email-masked]>
Date: Wed, 09 Dec 2020 15:59:26 -0800

I agree with @huitema here, client MUST + server SHOULD sounds like the easiest way to resolve this 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/4257#issuecomment-742140025

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 09 Dec 2020 16:37:26 -0800

> Given that you can't validate the "unless" criteria for the peer, it seems like the client isn't able to enforce this MUST.

I'm not sure if I follow. IIUC, we do have MUSTs that are not enforceable by the peer.

IMO "MUST unless" is better than "SHOULD unless", because it is clear that the sender is required to behave as specified whenever the exception is _not_ being met. SHOULD sounds like there are other cases when a sender can send a smaller sized datagrams.

-- 
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/4257#issuecomment-742154441

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 09 Dec 2020 20:25:10 -0800

FTR, this is now resolved, see discussion: https://github.com/quicwg/base-drafts/pull/4264/files#r538962489.
The editorial fix is in this commit: https://github.com/quicwg/base-drafts/pull/4264/commits/8324d829dbf4add57887e10ce7cdb829b6afde3f

-- 
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/4257#issuecomment-742230410

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Dec 2020 20:53:23 -0800

Closed #4257 via #4264.

-- 
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/4257#event-4093165445

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Dec 2020 20:53:53 -0800

Reopened #4257.

-- 
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/4257#event-4093166546

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Dec 2020 04:53:53 +0000 (UTC)

Reopening as requested by chairs.

-- 
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/4257#issuecomment-742238719