Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove some cruft from packet size section #3262

Merged
merged 2 commits into from Nov 26, 2019
Merged

Remove some cruft from packet size section #3262

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
12d3abd
Remove some cruft from packet size section
martinthomson Nov 19, 2019
f831a87
iyengareditorialization
martinthomson Nov 26, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
29 changes: 12 additions & 17 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3410,27 +3410,22 @@ later time in the connection.
The QUIC packet size includes the QUIC header and protected payload, but not the
UDP or IP header.

Clients MUST ensure they send the first Initial packet in a single IP packet.
Similarly, the first Initial packet sent after receiving a Retry packet MUST be
sent in a single IP packet.

The payload of a UDP datagram carrying the first Initial packet MUST be expanded
to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by
A client MUST expand the payload of all UDP datagrams carrying Initial packets
to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
coalescing the Initial packet (see {{packet-coalesce}}). Sending a UDP datagram
of this size ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks
caused by server responses toward an unverified client address; see
{{address-validation}}.
of this size ensures that the network path from the client to the server
supports a reasonable Maximum Transmission Unit (MTU). Padding datagrams also
helps reduce the amplitude of amplification attacks caused by server responses
toward an unverified client address; see {{address-validation}}.

The datagram containing the first Initial packet from a client MAY exceed 1200
bytes if the client believes that the Path Maximum Transmission Unit (PMTU)
supports the size that it chooses.
Datagrams containing Initial packets MAY exceed 1200 bytes if the client
believes that the Path Maximum Transmission Unit (PMTU) supports the size that
it chooses.

A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
response to the first Initial packet it receives from a client if the UDP
datagram is smaller than 1200 bytes. 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 it receives from a client if the UDP datagram is
smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
Comment on lines 3425 to +3427
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it's not part of this PR, but why do we let what is essentially an unauthenticated packet to kill the connection? Shouldn't the packet just be dropped and ignored?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At that point, this is not creating the connection as opposed to removing an existing connection. So this is functionally equivalent to dropping, but adds the friendly signal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm more worried about this as an attack vector. Now that we support multiple initial packets for the client initial, there is more of a windows for an attacker to race a bad initial packet. Sending a 1 byte initial packet to kill your connection would be pretty easy; especially since the size validation check is going to happen pre-decryption, so the attacker doesn't even need to craft a well-formed packet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, I see what you mean. Opening an issue.

otherwise behave as if any part of the offending packet was processed as valid.

The server MUST also limit the number of bytes it sends before validating the
address of the client; see {{address-validation}}.
Expand Down