Datagram 1200 #1548
Datagram 1200 #1548
Conversation
martinthomson
added
editorial
draft-ietf-quic-tls.md
Outdated
|
|
||
| QUIC packet and framing overheads add at least 36 octets of overheads to the | ||
| ClientHello message. That overhead increases if the client chooses connection | ||
| ID without zero length, nor does it include the token or a connection ID longer |
There was a problem hiding this comment.
a connection ID with non-zero length, perhaps?
There was a problem hiding this comment.
A QUIC packet can hardly fit into more than a single UDP datagram, so perhaps be clear that the TLS message must fit within the first Initial QUIC packet. - if that is the intention.
draft-ietf-quic-tls.md
Outdated
| QUIC packet and framing overheads add at least 36 octets of overheads to the | ||
| ClientHello message. That overhead increases if the client chooses connection | ||
| ID without zero length, nor does it include the token or a connection ID longer | ||
| than octets that might be required if a server sends a Retry packet. |
draft-ietf-quic-tls.md
Outdated
| With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet | ||
| with ample space remaining. However, aside from the overheads added by QUIC, | ||
| there are several variables that could cause this limit to be exceeded. Large | ||
| session tickets or HelloRetryRequest cookies, multiple or large key shares, and |
There was a problem hiding this comment.
You say below that HelloRetryRequest-triggered ClientHellos are exempt from this restriction, so it might be less confusing to omit that from your list of examples.
draft-ietf-quic-tls.md
Outdated
| message to grow. | ||
|
|
||
| For servers, in addition to connection ID and tokens, the size of TLS session | ||
| tickets and HelloRetryRequest cookie extensions can have an effect on a client's |
draft-ietf-quic-tls.md
Outdated
| ID without zero length, nor does it include the token or a connection ID longer | ||
| than octets that might be required if a server sends a Retry packet. | ||
|
|
||
| With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet |
There was a problem hiding this comment.
Given that 1200 is a minimum, not a maximum, it might be worth calling out that the datagram can be larger than 1200 if needed.
draft-ietf-quic-tls.md
Outdated
| values can be successfully used by a client. | ||
|
|
||
| A client is not required to fit a ClientHello that is sent in response to | ||
| HelloRetryRequest in a single UDP datagram. |
There was a problem hiding this comment.
Consistency nits:
- You use "a" before other TLS handshake messages, so "a HelloRetryRequest"
- You use "fit into" elsewhere, but "fit ... in" here.
draft-ietf-quic-transport.md
Outdated
|
|
||
| An Initial packet MAY exceed 1200 octets if the client knows that the Path | ||
| Maximum Transmission Unit (PMTU) supports the size that it chooses. | ||
| The datagram containing an Initial packet MAY exceed 1200 octets if the client |
There was a problem hiding this comment.
Since we're still talking about "the first Initial packet [the client] sends," perhaps "the first" or "this" instead of "an"?
draft-ietf-quic-transport.md
Outdated
| response to an Initial packet smaller than 1200 octets. It MUST NOT send any | ||
| other frame type in response, or otherwise behave as if any part of the | ||
| offending packet was processed as valid. | ||
| response to an Initial packet contained in a UDP datagram that is smaller than |
There was a problem hiding this comment.
...but only if it's the first Initial packet on the connection, right?
|
EDIT: Never mind, fixed in latest commit that just landed. @martinthomson not sure you saw my comment since you just made and update to that section that didn't address it, or perhaps you disagree, but:
This sentence doesn't make sense to me because all QUIC packets are necessarily placed in a UDP single datagram. The intention is of course the the initial client hello TLS message must fit within the QUIC initial packet. |
|
@mikkelfj, email got through, and I've pushed an update that should help. |
draft-ietf-quic-transport.md
Outdated
| network path supports a reasonably sized packet, and helps reduce the amplitude | ||
| of amplification attacks caused by server responses toward an unverified client | ||
| address. | ||
| Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP |
There was a problem hiding this comment.
MUST pad ensure that? Should pad be removed here?
draft-ietf-quic-tls.md
Outdated
| the likelihood that a packet is accepted if it ensures that the first | ||
| ClientHello message is small enough to stay within this limit. | ||
|
|
||
| QUIC packet and framing overheads add at least 36 octets of overheads to the |
There was a problem hiding this comment.
I think the first "overheads" is unnecessary and the second can be "overhead"
draft-ietf-quic-tls.md
Outdated
|
|
||
| QUIC packet and framing overheads add at least 36 octets of overheads to the | ||
| ClientHello message. That overhead increases if the client chooses a connection | ||
| ID without zero length, nor does it include the token or a connection ID longer |
There was a problem hiding this comment.
nor does it -> and does not
draft-ietf-quic-tls.md
Outdated
| QUIC packet and framing overheads add at least 36 octets of overheads to the | ||
| ClientHello message. That overhead increases if the client chooses a connection | ||
| ID without zero length, nor does it include the token or a connection ID longer | ||
| than 8 octets that might be required if a server sends a Retry packet. |
There was a problem hiding this comment.
This sentence is long, maybe a comma after "octets"
| size of these values increases the probability that they can be successfully | ||
| used by a client. | ||
|
|
||
| A client is not required to fit the ClientHello that it sends in response to a |
There was a problem hiding this comment.
Is this because HRR is assumed to be stateful?
draft-ietf-quic-transport.md
Outdated
| network path supports a reasonably sized packet, and helps reduce the amplitude | ||
| of amplification attacks caused by server responses toward an unverified client | ||
| address. | ||
| Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP |
draft-ietf-quic-transport.md
Outdated
| address. | ||
| Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP | ||
| datagram that is at least 1200 octets. Padding the Initial packet is a good way | ||
| to ensure this, though including a 0-RTT packet in the same datagram is also a |
There was a problem hiding this comment.
How about: "Padding the Initial packet or including a 0-RTT packet in the same datagram are ways to meet this requirement." Feel free to add good if you want, but that seems unnecessary.
draft-ietf-quic-transport.md
Outdated
| An Initial packet MAY exceed 1200 octets if the client knows that the Path | ||
| Maximum Transmission Unit (PMTU) supports the size that it chooses. | ||
| The datagram containing the first Initial packet from a client MAY exceed 1200 | ||
| octets if the client knows that the Path Maximum Transmission Unit (PMTU) |
draft-ietf-quic-transport.md
Outdated
| toward an unproven remote address. | ||
| handshake packet is sent in a UDP datagram that contains at least 1200 octets of | ||
| payload. This allows a server to send a similar amount of data without risking | ||
| causing an amplification attack toward an unproven remote address. | ||
|
|
There was a problem hiding this comment.
1200 octets of UDP payload?
I know this is implicit, but we also use payload to refer to the part of a QUIC packet that follows the header.
This fixes inconsistencies throughout in our treatment of the 1200 octet limit.
I also took another tilt at the ClientHello limitations section, which hadn't taken the addition of the token into account. I don't explicitly calculate a limit, but I do mention the size of the minimal overheads, and mention other ways in which the limit might be reduced.
Closes #1546.