Subject: [quicwg/base-drafts] Define the payload size of the initial packet rather than the total packet size (#472)

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Apr 2017 22:20:29 -0700

The entity that creates the packet is not always aware of the existence of header extensions.  That makes hitting the 1280 octet limit hard.  Worse, if they are aware of extensions, they might reduce the size and then encounter a server that enforces the limit.  That server will discard the packet.  That makes enforcement risky.

This change places the limit on the payload.  It mandates 1232/1252 for v6/v4.

This is the uncomplicated version.  The complicated version that I didn't write up allows a client that knows more about overheads to reduce the payload size as long as they keep above some floor value (e.g., 1180).  We might consider doing that later if we want to allow QUIC to operate on paths with a much tighter MTU overhead.  Evidence suggests that we don't need this though (open an issue if you disagree).

Closes #267
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/472

-- Commit Summary --

  * Define the payload size of the initial packet rather than the packet size
  * Missed a number

-- File Changes --

    M draft-ietf-quic-transport.md (31)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/472.patch
https://github.com/quicwg/base-drafts/pull/472.diff

-- 
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/pull/472

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 18:49:10 -0700

@martinthomson pushed 1 commit.

8259275  Add limits to TLS draft

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/472/files/e1bab536358b31d4edf067f73a4ac50380489ddd..82592750933c0ff382a2fc54105a7ac393548200

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 23:15:14 -0700

@janaiyengar, this has been discussed and I'm just enacting the agreed solution.  I'd like to merge this before 2017-05-02.

-- 
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/pull/472#issuecomment-297916433

---

From: ekr <[email-masked]>
Date: Fri, 28 Apr 2017 00:31:25 -0700

ekr commented on this pull request.

> @@ -532,9 +532,10 @@ older than 1.3 is negotiated.
 
 ## ClientHello Size
 
-QUIC requires that the initial handshake packet from a client fit within a
-single packet of at least 1280 octets.  With framing and packet overheads this
-value could be reduced.
+QUIC requires that the initial handshake packet from a client fit within the
+payload of a single packet.  A minimum-sized initial packet in IPv6 has space
+for a single TLS record of 1197 octets once the QUIC header and minimal framing
+is added.

This is phrased awkwardly, and also seems to semi-conflict with {{#packetization}}.

I would consolidate these, and you also need to fix the requirement in {{#packetization}} that things be exactly 1280 because the client has no control over that.

I think rather what we need to say is:

1. The client needs to ensure that the initial packet has at least X bytes of UDP payload
2. When you add the QUIC header, that means CH can be up to Y bytes.
3. The rest of the space MUST be used by PADDING frames.

Based on the text, I believe that X == 1232 (I wouldn't bother to adjust between v4 and v6).
How do you get 1197? If we have 1232 bytes for UDP payload and then a 17-byte minimal QUIC header and a 3 byte STREAM frame header....

And I would put all of this in this space and leave the general guidance in {{#packetization}}.

-- 
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/pull/472#pullrequestreview-35293690

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 20:57:08 -0700

martinthomson commented on this pull request.

 ## ClientHello Size

A STREAM frame header can be two octets.  And then there is the FNV-1a hash, which I know isn't in the current draft, but I'm trying to avoid having to update this once that lands.

I really only wanted to say point 2 here.  I'll take another stab at it.

-- 
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/pull/472#discussion_r114096622

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 20:57:22 -0700

127e548  Take 2

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/472/files/82592750933c0ff382a2fc54105a7ac393548200..127e5485513e3a20bccd40d4b636eeae44104bd9

---

From: janaiyengar <[email-masked]>
Date: Sun, 30 Apr 2017 22:18:06 -0700

janaiyengar commented on this pull request.

> @@ -1138,9 +1138,9 @@ use the server to send more data toward the victim than it would be able to send
 on its own.
 
 Several methods are used in QUIC to mitigate this attack.  Firstly, the initial
-handshake packet from a client is padded to at least 1280 octets.  This allows a
-server to send a similar amount of data without risking causing an amplication
-attack toward an unproven remote address.
+handshake packet is padded to at least 1280 octets.  This allows a server to
+send a similar amount of data without risking causing an amplication attack

typo: amplication --> amplification

> @@ -1952,16 +1952,19 @@ An endpoint MUST NOT reduce their MTU below this number, even if it receives
 signals that indicate a smaller limit might exist.
 
 Clients MUST ensure that the first packet in a connection, and any
-retransmissions of those octets, has a total size (including IP and UDP headers)
-of at least 1280 bytes. This might require inclusion of PADDING frames. It is
-RECOMMENDED that a packet be padded to exactly 1280 octets unless the client has
-a reasonable assurance that the PMTU is larger. Sending a packet of this size
-ensures that the network path supports an MTU of this size and helps mitigate
-amplification attacks caused by server responses toward an unverified client
-address.
-
-Servers MUST reject the first plaintext packet received from a client if it its
-total size is less than 1280 octets, to mitigate amplification attacks.
+retransmissions of those octets, has a payload of least 1232 octets for an IPv6
+datagram and 1252 octets for an IPv4 datagram.  In the absence of extensions to
+the IP or UDP header, padding to exactly these values will result in a packet

Do UDP header extensions exist?

 ## ClientHello Size

Ekr: There's 16 octets of FNV hash. I think it's off too though, since adding 16 bytes to your number (which I believe is correct otherwise) gives 1233 bytes.

I don't think it's necessary to articulate how many bytes of QUIC payload, since it just gets confusing. I think it's enough to say 1252 and 1232 bytes of UDP payload (or QUIC packet size) for v4 and v6. I think it's useful and important to separate v4 and v6 -- 20 bytes in the common v4 case is a fair bit.

-- 
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/pull/472#pullrequestreview-35540020

---

From: ekr <[email-masked]>
Date: Sun, 30 Apr 2017 22:55:26 -0700

No, I think not

-- 
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/pull/472#discussion_r114101076

---

From: ekr <[email-masked]>
Date: Sun, 30 Apr 2017 22:58:20 -0700

Well, as I understood it, MT was trying to say how big the ClientHello could be, and that's the thing that fits in the frame. I could live with either set of calculations as long as the numbers are correct.

With regard to v4 or v6, do you plan to do happy eyeballs by sending the QUIC packet 0 over both paths? In that case, you need a CH which will fit in either versio, as you can't change it later.

-- 
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/pull/472#issuecomment-298290850