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

Move server send limitations #1843

Closed
wants to merge 1 commit into from
Closed

Move server send limitations #1843

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
25 changes: 12 additions & 13 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -664,6 +664,18 @@ packets are protected with connection- and version-specific keys
provide confidentiality or integrity against on-path attackers, but
provides some level of protection against off-path attackers.

Servers MUST NOT send more than three times as many bytes as the number of bytes
received prior to verifying the client's address. Source addresses can be
verified through an address validation token (delivered via a Retry packet or
a NEW_TOKEN frame) or by processing any message from the client encrypted using
the Handshake keys. This limit exists to mitigate amplification attacks.

In order to prevent this limit causing a handshake deadlock, the client SHOULD
always send a packet upon a handshake timeout, as described in
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be "crypto handshake timeout" now?

Copy link
Contributor

Choose a reason for hiding this comment

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

Bump. Also, I'm not sure what the status of this is now that the restructure PR is outstanding?

Copy link
Contributor

Choose a reason for hiding this comment

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

How exactly is number of bytes measures?

{{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have
Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least
1200 octets. If the client has Handshake keys, it SHOULD send a Handshake
packet.

## Initial Packet {#packet-initial}

Expand Down Expand Up @@ -882,19 +894,6 @@ The first Handshake packet sent by a server contains a packet number of 0.
Handshake packets are their own packet number space. Packet numbers are
incremented normally for other Handshake packets.

Servers MUST NOT send more than three times as many bytes as the number of bytes
received prior to verifying the client's address. Source addresses can be
verified through an address validation token (delivered via a Retry packet or
a NEW_TOKEN frame) or by processing any message from the client encrypted using
the Handshake keys. This limit exists to mitigate amplification attacks.

In order to prevent this limit causing a handshake deadlock, the client SHOULD
always send a packet upon a handshake timeout, as described in
{{QUIC-RECOVERY}}. If the client has no data to retransmit and does not have
Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least
1200 octets. If the client has Handshake keys, it SHOULD send a Handshake
packet.

The payload of this packet contains CRYPTO frames and could contain PADDING, or
ACK frames. Handshake packets MAY contain CONNECTION_CLOSE or APPLICATION_CLOSE
frames. Endpoints MUST treat receipt of Handshake packets with other frames as
Expand Down