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

Use address validation tokens, not STK #1045

Merged
merged 2 commits into from
Jan 12, 2018
Merged

Use address validation tokens, not STK #1045

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
33343b9
Use address validation tokens, not STK
martinthomson Jan 9, 2018
632add9
Grammo
martinthomson Jan 10, 2018
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
11 changes: 6 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3649,12 +3649,13 @@ transport to cancel a stream in response to receipt of a STOP_SENDING frame.

## Spoofed ACK Attack

An attacker receives an STK from the server and then releases the IP address on
which it received the STK. The attacker may, in the future, spoof this same
An attacker might be able to receive an address validation token
({{address-validation}}) from the server and then release the IP address it
used to acquire that token. The attacker may, in the future, spoof this same
address (which now presumably addresses a different endpoint), and initiate a
0-RTT connection with a server on the victim's behalf. The attacker then spoofs
ACK frames to the server which cause the server to potentially drown the victim
in data.
0-RTT connection with a server on the victim's behalf. The attacker can then
spoof ACK frames to the server which cause the server to send excessive amounts
of data toward the new owner of the IP address.

There are two possible mitigations to this attack. The simplest one is that a
server can unilaterally create a gap in packet-number space. In the non-attack
Expand Down