search

nibanks / quic-new-path

QUIC Extension for Unilaterally Creating New Paths
0 stars 0 forks source link

Security Consideration -- what about request forgery attacks? #1

Open huitema opened 3 years ago

huitema commented 3 years ago

We had a discussion of request forgery attacks for the QUIC protocol: if a node can convince a peer to send packets to unsuspecting addresses, that can be exploited in hard to predict ways. The defense is to limit the targets to something that "sounds legit", e.g., not a local site if the source is remote. The ICE/STUN probes need to not enable such attacks.

This is a bit of a bummer, because one of the legit P2P scenario is two hosts discovering that they are on the same link, and switching to some kind of local address. My take is that "same link discovery" works OK with IPv6 (just use the public prefix of the link) but not so much with IPv4, for which two hosts may have IP address in the same /24, yet be on different networks.

nibanks commented 3 years ago

My first though is how much of this is already possible with existing migration logic and address spoofing? Next, if we do allow probes to go to any addresses, without restriction, why is it that much different from spoofing public addresses? I know you say "hard to predict" but what do you have in mind? The packets are still encrypted, and if we limit our probes/punches to small packets only, it should be too disruptive as far as load is concerned. From there, I could only imagine issues coming up from "side effects" that happen to occur because the path was sent or received in general. One solution, if a network is known to have certain restrictions, is enable restrictions on where it would try to probe. These could be off-by-default restrictions, that some scenarios just always turn on (e.g. servers in the cloud behind a load balancer, never need to enable local addresses, right?).

huitema commented 3 years ago

Or maybe we do a two step approach. First look at an IPv6 solution, in which the only problem is a stateful firewall, not a NAT. Then deal with the additional complexity of NAT probes, and the security implications.