ICMP DOS

[mikkelfj]

I read through the recent PR #2036 which cleans up the packet size discussion. The text does touch upon ICMP denial of service attacks but I'm afraid the protection is too fragile because it is required that transmission stops on a path where PMTU is suspected to have been decreased. It is not explicitly stated (as far as I can tell) that ICMP packet too big is used for this decision, but it is used in PMTU discovery.

There is no major problem with attacks on discovery, but if ICMP can later close a connection, that is a big problem.

There is protection against off path attackers, but it is easy for a man on the side attack to generate ICMP messages that would pass validation. This only requires one compromised machine on a LAN.

This issue also relates to the ongoing discussion on protection against the initial handshake by man on the side stopping handshake by generating invalid early handshake packets, only here it can happen long after the connection is established.

A possible mitigation could be that a path should not be dropped based in ICMP messages alone but only after one or two new new PMTU probes. However, these new probes could also be vulnerable to forged ICMP messages.

[mikkelfj]

A possible resolution is to never allow ICMP to reduce a path below 1200 bytes or so, corresponding to the handshake discovery. Dropping a path should then solely be based on a) having a better path to switch to, or b) that packets loss rate is getting too high for the application to tolerate.

[martinthomson]

Not allowing ICMP to reduce the PMTU below 1280 was always the intent. I can't see that anywhere, so we should add it.

[ekr]

I just caught this and I don't think that mandating it like this is appropriate. There are other ways to get a lower MTU (e.g., your interface MTU shrinks). I'm happy to have it forbid lowering in response to ICMP, but this is too broad.

[martinthomson]

I disagree. The fix was to specifically a prohibition against accepting an ICMP PTB. We also had consensus not to support QUIC on paths that had a lower PMTU, but we don't have any text suggesting others.

[ekr]

I agree we had consensus not to support QUIC on paths with a lower MTU, but the problem is the over-specific requirement that I do something about it.

[martinthomson]

What are you being asked to do? The only requirement in text is that you ignore ICMP PTB with a size of <1280.

[ekr]

the relevant text is in 14.1.

   If a QUIC endpoint determines that the PMTU between any pair of local
   and remote IP addresses has fallen below the size needed to support
   the smallest allowed maximum packet size, it MUST immediately cease
   sending QUIC packets on the affected path.  An endpoint MAY terminate
   the connection if an alternative path cannot be found.

This would apply to other methods than ICMP PTB, for instance, Ethernet or VPN MTU reduction

[martinthomson]

Yep. We had consensus for that text.

[ekr]

Can you please point me to where that consensus call was taken?

[martinthomson]

This text is in -02, and the chairs made a call here: https://mailarchive.ietf.org/arch/msg/quic/ZGN6z-5oYnEXRGafi_zvqKjDcnM

That lists "#139 - Minimum MTU"

[ekr]

I don't really read the thread that way, but It's not worth fighting over.