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

Apply the 3x amplification-limit to migration too #4264

Merged
merged 21 commits into from Dec 10, 2020
Merged

Apply the 3x amplification-limit to migration too #4264

Changes from 1 commit
Commits
Show all changes
21 commits
Select commit Hold shift + click to select a range
51423d0
Add a blanket 3x anti-amplification limit
martinthomson Oct 28, 2020
3bf6b2f
Some stuff I missed
martinthomson Oct 28, 2020
97ba8a6
MUST be consistent
martinthomson Oct 28, 2020
59f5a3a
Small corrections
martinthomson Oct 28, 2020
2df832a
Reword the second validation requirement slightly
martinthomson Oct 28, 2020
549564f
Make it clearer
martinthomson Oct 29, 2020
8c0c1f9
Wrap stuff
martinthomson Oct 29, 2020
fb033df
Jana's comments
martinthomson Nov 4, 2020
fb253e9
Merge branch 'master' into migration-amplification
martinthomson Nov 4, 2020
66b7c2a
Merge branch 'master' into migration-amplification
martinthomson Nov 4, 2020
593d552
Reword and use addresses, not paths
martinthomson Nov 4, 2020
4769dbe
Add an error code for when the path fails
martinthomson Nov 5, 2020
3527972
moar
martinthomson Nov 5, 2020
2ffb2ab
Fewer words = good
martinthomson Nov 5, 2020
bbc0711
Merge pull request #4331 from quicwg/no-viable-path
martinthomson Nov 5, 2020
54f48ce
use parentheses for adjunct citations
martinthomson Nov 6, 2020
fae20ab
A section reference is all we really need here.
martinthomson Nov 16, 2020
3e5b0fd
Merge branch 'master' into migration-amplification
martinthomson Nov 16, 2020
8324d82
No-enforcement clause for path validation datagram size
martinthomson Dec 10, 2020
c549aee
gramma
martinthomson Dec 10, 2020
07989a2
Suggestion
martinthomson Dec 10, 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
10 changes: 6 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2219,10 +2219,12 @@ from the endpoint to the peer can be used for QUIC; see {{datagram-size}}.

Copy link
Contributor

Choose a reason for hiding this comment

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

I know it is late in the process, but I would much prefer the paragraph to say that "An endpoint SHOULD expand datagrams that contain a PATH_CHALLENGE frame..." The reason is that if we say MUST, picky implementations will account the number of bytes sent and discard un-padded path challenges if they sent 400 bytes of data or more. Such measurements are very hard to get right, so we will end up with interoperability issues.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is specifically an issue for server responses to NAT traversal. A man on the side could trigger a number "fake" NAT traversal, and it makes sense for servers to avoid sending large packets in response to that.

Copy link
Contributor

Choose a reason for hiding this comment

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

In practice, these fake NAT traversals don't seem so concerning because most ports on a NAT are going to be unused and dropped by the NAT itself. And I believe most Large(ie: Carrier Grade) NATs are symmetric, so even if the port was open, the traffic would be dropped.

Copy link
Contributor

Choose a reason for hiding this comment

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

The problem happens when the attacker is not behind a NAT, say is using IPv6. Suppose the attacker is an evil client, intent on targeting IPv6 address X, or maybe IPv6 prefix X/64. It can set up a connection, then manufacture a series of short packets with faked source addresses and ports -- packets less than 100 bytes including the IP header, each triggering a 1200 byte response. The evil client can set up an arbitrary number of good connections to do that, effectively getting a factor 12 amplification for a large stream of data.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that if the IP changes, assuming it is a NAT migration is a bit dangerous, so I only had port in mind.

Copy link
Contributor

Choose a reason for hiding this comment

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

@martinthomson the padding enforcement rule says "an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints; the endpoint MAY however discard such datagrams." The latter behavior, discarding the datagram, is exactly what leads to interop failure when the server does not pad because of amplification concerns, and the client drops because it interprets the clause as "MUST pad".

Copy link
Member Author

Choose a reason for hiding this comment

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

Happy to add text specific to this instance that prohibits enforcement.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added some text that prohibits dropping. I will note that at the point that you detect this violation, you have likely already started to process the packet, so enforcement of the requirement is a little dangerous.

Copy link
Contributor

Choose a reason for hiding this comment

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

IMO the added text prohibiting dropping resolves this problem

Copy link
Contributor

Choose a reason for hiding this comment

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

The added text solves my issue.

If an endpoint is unable to expand the datagram payload to 1200 bytes, no
padding is necessary. However, this means that the path MTU will not be
validated. The endpoint MUST perform a second path validation with a datagram
of at least 1200 bytes once a PATH_RESPONSE is successfully received or when
enough bytes have been received on the path that sending the larger datagram
will not result in exceeding the anti-amplification limit.
validated. To ensure that the path MTU is large enough, the endpoint MUST
perform a second path validation by sending a PATH_CHALLENGE frame in a
datagram of at least 1200 bytes. This additional validation can be
performed after a PATH_RESPONSE is successfully received or when enough
bytes have been received on the path that sending the larger datagram will
not result in exceeding the anti-amplification limit.


### Path Validation Responses
Expand Down