Request Forgery Attacks through Version Negotiation

[huitema]

The version negotiation packet is described in the QUIC Invariant specification as:

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}

The two connection ID fields, of length up to 255 bytes, contain data directly copied from an incoming packet that is not authenticated or verified in any way. Aren't we worried that this is a great avenue for request forgery attacks? Should that be documented in the security section of the invariant draft?

[martinthomson]

@marten-seemann, trying to move discussion here.

You suggest that in a p2p deployment, the ability to control deployment of "server" instances is limited.

My response is that in general you need some sort of signaling between peers to communicate addresses for p2p. NAT traversal generally requires it, and - if nothing else - you usually need to ship IP addresses for peers around. Given that, I think that it is reasonable to include - in that signaling - information about supported protocols such that you should never need to generate a QUIC Version Negotiation in that context.

Maybe you don't care for that, but I think that it is probably better than accepting the exposure.

If you have an idea for how we might avoid this particular sort of request forgery without that, then I'm open to suggestions. Right now, the proposal is that servers accept the risk and manage it. But if there is a protocol change that would improve the situation, that might be better. Assuming that it is minimally disruptive, of course.

[marten-seemann]

My response is that in general you need some sort of signaling between peers to communicate addresses for p2p. NAT traversal generally requires it, and - if nothing else - you usually need to ship IP addresses for peers around.

This independent of NAT traversal then. You'd also need to advertise addresses in a world where NATs wouldn't exist, and you could include QUIC version information in those address advertisements.

This still leaves the Bootstrap nodes susceptible to this attack (assuming you only hard-code a list of IP:ports without QUIC version information), but maybe that's ok, since you typically control those nodes yourself, or at least you can ask people running those nodes to take precautionary steps.