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

What needs to be checked for address validation #3327

Merged
merged 7 commits into from Mar 22, 2020
Merged

What needs to be checked for address validation #3327

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
bc10a8e
Tweak
martinthomson Feb 8, 2020
4c848c6
what needs to be checked for address validation
martinthomson Jan 8, 2020
3fc2b78
Editorial changes
martinthomson Feb 12, 2020
55dfc6f
A little less detail
martinthomson Feb 14, 2020
01b60ac
But 'stable' needs definition or it is just weaselly
martinthomson Feb 14, 2020
d9ccbdc
Tighten requirement; explain it some
martinthomson Feb 17, 2020
9c5c738
Take ekr's suggestion, remove note.
martinthomson Feb 8, 2020
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
22 changes: 18 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1829,10 +1829,24 @@ tokens that would be accepted by the server. Only the server requires access to
the integrity protection key for tokens.

There is no need for a single well-defined format for the token because the
server that generates the token also consumes it. A token could include
information about the claimed client address (IP and port), a timestamp, and any
other supplementary information the server will need to validate the token in
the future.
server that generates the token also consumes it. Tokens sent in Retry packets
SHOULD include information that allows the server to verify that the source IP
Copy link
Member

Choose a reason for hiding this comment

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

I am unsure if this SHOULD is necessary. As we suggest in the preceding paragraph, offloading state to client is just one way of implementing retries, the proposed text changes that to a recommendation.

If there is a need to better clarify the requirements on a server performing address validation, I think we should make changes to 8.1.2.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree with @kazuho: suppose that one has a scheme where you store tokens, then the token wouldn't contain this information. Isn't the requirement here that the token be bound to an IP.

Copy link
Member Author

Choose a reason for hiding this comment

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

maybe it doesn't use that word, but that is what it says

address and port in client packets remains constant.
Copy link
Collaborator

Choose a reason for hiding this comment

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

As you suggest in your comment, I think i would remove "port" here, as there are not that many applications where returning clients will have the same port.

Copy link
Member Author

Choose a reason for hiding this comment

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

As this is just for Retry, we can include port.


Tokens sent in NEW_TOKEN frames MUST include information that allows the server
to verify that the client IP address has not changed from when the token was
issued. Servers can use tokens from NEW_TOKEN in deciding not to send a Retry
packet, even if the client address has changed. If the client IP address has
changed, the server MUST adhere to the anti-amplification limits found in
{{validate-handshake}}. Note that in the presence of NAT, this requirement
might be insufficient to protect other hosts that share the NAT from
amplification attack.

Servers MUST ensure that replay of tokens is prevented or limited. For
instance, servers might limit the time over which a token is accepted. Tokens
provided in NEW_TOKEN frames might need to allow longer validity periods.
Tokens MAY include additional information about clients to further narrow
applicability or reuse.


## Path Validation {#migrate-validate}
Expand Down