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.

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

Server sends a PING-only packet if it's limited #3162

Closed
wants to merge 6 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 9 additions & 22 deletions draft-ietf-quic-recovery.md
Original file line number Diff line number Diff line change
Expand Up @@ -494,19 +494,15 @@ A connection MAY use the delay between sending a PATH_CHALLENGE and receiving
a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
be considered an RTT sample.

Until the server has validated the client's address on the path, the amount of
data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
Data at Initial encryption MUST be retransmitted before Handshake data and
data at Handshake encryption MUST be retransmitted before any ApplicationData
data. If no data can be sent, then the PTO alarm MUST NOT be armed until
data has been received from the client.
data.

Since the server could be blocked until more packets are received from the
client, it is the client's responsibility to send packets to unblock the server
until it is certain that the server has finished its address validation
(see Section 8 of {{QUIC-TRANSPORT}}). That is, the client MUST set the
probe timer if the client has not received an acknowledgement for one of its
Handshake or 1-RTT packets.
Until the server has validated the client's address on the path, the amount of
data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
If the limit has been reached when the PTO expires, a single packet containing
a PING with no PADDING MUST be sent. This packet elicits a full-sized Initial
packet from the client, allowing the server to send data again.

Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to an
Expand Down Expand Up @@ -1150,18 +1146,9 @@ OnLossDetectionTimeout():
SetLossDetectionTimer()
return

if (endpoint is client without 1-RTT keys):
// Client sends an anti-deadlock packet: Initial is padded
// to earn more anti-amplification credit,
// a Handshake packet proves address ownership.
if (has Handshake keys):
SendOneAckElicitingHandshakePacket()
else:
SendOneAckElicitingPaddedInitialPacket()
else:
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
SendOneOrTwoAckElicitingPackets()
// PTO. Send new data if available, else retransmit old data.
// If neither is available, send a single PING frame.
SendOneOrTwoAckElicitingPackets()

pto_count++
SetLossDetectionTimer()
Expand Down
9 changes: 5 additions & 4 deletions draft-ietf-quic-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -1592,10 +1592,11 @@ server has successfully processed a Handshake packet from the client, it can
consider the client address to have been validated.

Prior to validating the client address, servers MUST NOT send more than three
times as many bytes as the number of bytes they have received. This limits the
magnitude of any amplification attack that can be mounted using spoofed source
addresses. In determining this limit, servers only count the size of
successfully processed packets.
times as many bytes as the number of bytes they have received, except upon the
probe timeout expiring, when servers can send a single PING-only packet.
This limits the magnitude of any amplification attack that can be mounted
using spoofed source addresses. In determining this limit, servers only count
the size of successfully processed packets.

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
Expand Down