Subject: [quicwg/base-drafts] Client that does not PAD does not negotiate? (#4021)

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Aug 2020 07:32:37 -0700

(Broken out of #3214.)

> The size of the first packet sent by a client will determine whether
>   a server sends a Version Negotiation packet.  Clients that support
>   multiple QUIC versions SHOULD pad the first packet they send to the
>   largest of the minimum packet sizes across all versions they support.
>   This ensures that the server responds if there is a mutually
>   supported version.

- Are you saying a client that does not PAD does not negotiate? If so: What is the logic behind that design decision?
- I don’t read that as it assures what it say. To me, the padding assures the client can send this side of packet to the remote endpoint.
- Does this agree with what is written in section 8.1 on padding? and Section 14?

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Aug 2020 13:00:30 -0700

Yes, a client that does not pad to at least the minimum packet size for some version the server supports will not receive a Version Negotiation packet in response.  The corresponding server text is in 5.2.2:

> If a server receives a packet that indicates an unsupported version but is large enough to initiate a new connection for any supported version, the server SHOULD send a Version Negotiation packet as described in Section 6.1. A server MAY limit the number of packets to which it responds with a Version Negotiation packet. Servers MUST drop smaller packets that specify unsupported versions.

This is both to prevent an attack vector from spoofed packets, and to reduce the risk that a non-QUIC packet will trigger Version Negotiation in response.  There is a slight risk that the client might only support version of QUIC with smaller minima and the connection attempt will time out instead of discovering via VN that there are no mutually supported versions.  However, if there is any overlap, compliance with this SHOULD enables the client to trigger the server's VN response.

Yes, this aligns with the guidance in Section 8.1:

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

and Section 14:

> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see Section 12.2.
> ...
> A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.

However, those are in regards to a packet from *this* QUIC version, while the text you're asking about regards packets when the peer's QUIC version is unknown as of yet.

-- 
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/4021#issuecomment-676631755

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Aug 2020 15:49:37 -0700

Not seeing any action here.  As Mike says, the text describes sender requirements and explains why.

-- 
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/4021#issuecomment-676788587

---

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Aug 2020 23:30:16 -0700

@gorryfair?

-- 
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/4021#issuecomment-677287663

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 Aug 2020 01:14:14 -0700

I agree with the logic in this thread, but this seems far too subtle/clever and others will be confused at this point. However, I read this as the remote checks that the minimum size is sufficient. That means not padding this breaks the protocol. Why doesn't that require a MUST for any version (sec 14). If it doesn't then this doesn't yet explain under what cases the present "SHOULD" can be violated.

-- 
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/4021#issuecomment-677449924

---

From: Mike Bishop <[email-masked]>
Date: Thu, 20 Aug 2020 11:01:30 -0700

Not padding breaks the protocol, so there's a MUST in Section 14.  That MUST *does* apply to all versions that the client supports; the client obviously can't know the details of versions it doesn't support, including any the server supports, so that's all it can reference.  There's no minimum first-packet size in the invariants.

The server SHOULD send Version Negotiation in response to a packet of unknown version but an appropriate size; if it doesn't, the client won't know what versions it supports, but it might choose not to do so every time.  (Hence the "MAY limit" in the next sentence.)

Is the thing that's missing for you a linkage between "SHOULD send" and "MAY limit"?

-- 
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/4021#issuecomment-677814200

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 Aug 2020 23:58:45 -0700

All of this makes sense, but it was the sentence in section 6 which I found unclear, which says: "Clients that support multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support." That made me ask what happens when they support a version and didn't pad to the min size required by that version? 

-- 
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/4021#issuecomment-678078500

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 Aug 2020 00:19:25 -0700

Then they are violating the requirements of that version and won't get a 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/4021#issuecomment-678086447

---

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Aug 2020 06:58:51 -0700

So let's say a hypothetical client supports versions with the following minimum packet sizes to open a connection:
- A: 1250 bytes
- B: 1200 bytes
- C: 1720 bytes

The client is trying to open a connection with version B, so they MUST send at least 1200 bytes.  However, if the server only supports A and C, this won't provoke a Version Negotiation packet and the connection attempt will time out.  That's not incorrect, because the server doesn't support the attempted version.

The client SHOULD send at least 1720 bytes, because that guarantees the packet is large enough to trigger a Version Negotiation packet in the event there's any overlap in their supported version sets.  It's only a SHOULD, not a MUST, because there might be legitimate reasons a client would opt not to send a 1720-byte packet, such as expecting a 1500-byte MTU on the network.

-- 
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/4021#issuecomment-678304671

---

From: Lars Eggert <[email-masked]>
Date: Mon, 24 Aug 2020 23:58:06 -0700

@gorryfair?

-- 
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/4021#issuecomment-679841820

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Aug 2020 02:27:16 -0700

So if this confused me (a little), I am assuming it could confuse others, so one way to make this clear is add a sentence (albeit a little long) after the SHOULD in section 6 that says what happens and explicitly includes a forward ref to Section 14.1 i.e.

AFTER THIS CURRENT TEXT:    “The size of the first packet sent by a client will determine whether    a server sends a Version Negotiation packet.  Clients that support    multiple QUIC versions SHOULD pad the first packet they send to the    largest of the minimum packet sizes across all versions they support.    This ensures that the server responds if there is a mutually    supported version.” 

ADD SOMETHING LIKE:     "If a client sends an Initial packet (see section 14.1) less than the smallest allowed  packet size for the version of QUIC supported at the server  (e.g., when this size is not permitted by the local interface),  the server would not reply with a Version Negotiation packet and the connection attempt will time out.

-- 
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/4021#issuecomment-679913680

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Aug 2020 15:23:35 -0700

> A server might not send a Version Negotiation packet if the datagram it receives is smaller than the minimum size specified in a different version.
?

-- 
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/4021#issuecomment-680299093

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 27 Aug 2020 01:41:23 -0700

I think you know what to  expect, to me the text just needs to explain what you expect can happen. 

-- 
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/4021#issuecomment-681797571

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Aug 2020 01:49:47 -0700

@gorryfair does #4058 resolve this issue for you?

-- 
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/4021#issuecomment-681810652

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 27 Aug 2020 11:15:30 -0700

Closed #4021 via #4058.

-- 
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/4021#event-3700850058