ICMP attacks?

[Martin Duke]

Is there any mechanism to protect against ICMP PMTU attacks? The router is only required to echo the first 8 bytes of protocol header, which only gets you to the end of the UDP header.

Any thoughts on how QUIC can be made as robust as TCP to these attacks? Do we have to store lower lower info, like UDP checksums or IP IDs, in the segment queue to avoid successful blind attacks?

[Robbie Shade]

Hi Martin,

Can you explain exactly what attack you are talking about? If the concern is breaking PMTU discovery by sending fake ICMP packets then I don't think that's a concern, as QUIC deliberately doesn't use ICMP for PMTUD.

R.

On Fri, Nov 20, 2015 at 6:30 PM, Martin Duke <martin...@gmail.com> wrote:

Is there any mechanism to protect against ICMP PMTU attacks? The router is only required to echo the first 8 bytes of protocol header, which only gets you to the end of the UDP header.

Any thoughts on how QUIC can be made as robust as TCP to these attacks? Do we have to store lower lower info, like UDP checksums or IP IDs, in the segment queue to avoid successful blind attacks?

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Martin Duke]

The attack is sending ICMP packets with arbitrary low MTU values to cause most packets to be mostly overhead. In TCP, the attacker has to guess the sequence number properly.

But I agree if we just ignore ICMP packets then there's no issue. I didn't actually see PTMUD mentioned in the spec at all, so that could well be the case, but if there's some other mechanism then great.

[Jana Iyengar]

Hi Martin,

There's no mechanism for PMTUD yet with QUIC. There unfortunately is no *reliable* mechanism for PMTUD besides using packet loss as a proxy (or PLPMTUD, see RFC 4821)... ICMP errors are often not reliably communicated back.

- jana

[Jim Roskind]

As Robbie noted, QUIC doesn't use ICMP to do PMTUD.  One significant reason is that the OS (certainly Windows) doesn't recognize QUIC as a "flow," and hence has no idea of "who to tell" about an arriving ICMP packet (and I don't believe there is an API for an application communicating via UDP to register an interest in such arrivals).

When researching the design, I was also repeatedly told that PMTUD is a nightmare to use, so there was little to lose by avoiding it.  For instance, many routers block ICMP messages.

With very explicit ACKs in QUIC, and the potential for sending redundant but identifiable data, QUIC has the implicit capability of sending experimental (oversized?) packets and detecting whether they arrived or not.  As a result, we knew that we could use these features in QUIC to discover what a reasonable MTU is.  There are gotchas here though, as routing can potentially vary over time... and hence MTU limitations may vary <sigh>.

One part of QUIC, providing minimalistic MTU discovery, takes place during the CHLO transmission, where packets are "padded" to their full (planned) size.  This is not only an effective deterrent to amplification attacks, it also verifies that the current path is sufficient for the planned MTU...  (and ensures that QUIC does not need to fall-back to TCP).

Jim