3

Many documents indicates that in QUIC solves IP spoofing problem by a server generated token. Specifically, server issues a token so that the client can use it to identify itself, then the server will only respond to those with valid tokens.

But can't the attacker just IP-spoof the initial connection? Wouldn't that achieve the same effect of IP spoofing of DNS or NTP server?

  • IP spoofing has a specific meaning in infosec. You can hide your IP address using VPNs, ToR, etc. but that isn't "spoofing". In this narrow sense, IP spoofing has been solved by TCP for 30-odd years. QUIC just borrows the same technique. – paj28 Oct 9 '16 at 21:37
2

But can't the attacker just IP-spoof the initial connection? Wouldn't that achieve the same effect of IP spoofing of DNS or NTP server?

The problem with IP spoofing in DNS or NTP is not that the reply will go back to the spoofed IP address instead of the real sender because this is also true if you spoof the IP address in a TCP SYN. The problem instead is that often the response is much larger than the request and thus an attacker can use a small bandwidth with spoofed IP addresses to cause a large bandwidth attack against the spoofed IP (i.e. amplification attack).

TCP solves this problem by having only a small response to a small request so that nothing gets amplified. Unfortunately I cannot easily find information about the actual size of the source address token in QUIC but I hope that amplification attacks are considered.

EDIT: thanks for paj28 to point to an article where the problem of amplification in QUIC is addressed in more detail: ...the client hello will always be larger than, or equal to the size of the server response.... This means that amplification attacks as the main problem of IP spoofing will not work.

  • 1
    I don't think OP is asking about DDOS amplification. But it turns out QUIC is designed to resist this. – paj28 Oct 9 '16 at 21:31
  • DDOS amplification was what led me to the question. So thanks for the link! – Victor Oct 10 '16 at 20:08
2

Depends on what do you mean by "IP spoofing problem"?

The QUIC protocol belongs in the transport layer rather than the network layer.

Mitigating the effects of spoofing can be done in the tranport layer, just as it has been done in TCP, the client needs to both send and receive packets to open a data stream. If the 3-way-handshake is not complete, the client will not be able to talk with the application. But this does not really solve the problem. IP spoofing is still taking place.

I believe the "IP spoofing problem" cannot be fixed in the transport layer, because it does not relate to how packets travels from A to B on the Internet.

If an an application can receive data from spoofed IP-addresses, and the underlying transport protocol does not protect the application from this, then take a look at take a look at Steffen Ullrichs answer for further explanation on how this make amplification attacks possible.

0

We can't stop the attacker sending us packets with spoofed source addreses (the attackers ISP can prevent them from sending them but that is another issue), we can only mitigate the effects.

There are two main scenarios we need to protect against.

  1. An attacker wants to perfom an action on the server with a faked source address(maybe to bypass access control).
  2. An attacker wants to use the server to amplify a DDOS attack by sending small requests that triffer large response.

Inroducing the token solves both problems. The spoofer can send "initial" packets all day long but they can't perform any other actions because they never receive the token.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.