Document request forgery by version negotiation #4339
Conversation
It's pretty bad. Personally, I'm still comfortable with it. Server deployments are far less likely to made without due consideration to the environment into which they find themselves. Closes #4258.
... unless you start considering p2p deployments. |
|
Fair point; though I would suggest that p2p doesn't need version negotiation. Once you have to do NAT traversal, you can also ensure that you don't have to ever send Version Negotiation. |
|
I don't think that works in the general case. A node won't know if it's behind a NAT when it's started (it will learn after a while of interacting with other nodes). And even if you solve that problem, you'll need to do some extra work to communicate QUIC versions during hole punching. |
| No specific countermeasures are provided for this attack, though generic | ||
| protections {{forgery-generic}} could apply. In this case, ingress filtering | ||
| {{?BCP38}} is also effective. | ||
|
|
There was a problem hiding this comment.
I have been thinking about potential defenses, and I could not find something obvious there. Rate limiting does not help much, since this is not a volumetric attack. I think this text is about the best we can do.
There was a problem hiding this comment.
Ugh. Yeah, this isn't great. I agree that we can lean on servers... but documenting this is super important. This is a pretty big hole... but I think it's ok to leave it as it is in this PR.
Let's leave this open for a while longer to ensure that it gets more visibility, and to see if anyone can come up with any other ideas.
martinthomson
added
the
editorial
It's pretty bad.
Personally, I'm still comfortable with it. Server deployments are far
less likely to made without due consideration to the environment into
which they find themselves.
Closes #4258.