[AusNOG] Best Practice for IPv4 PMTU discovery?

[Mark ZZZ Smith]

----- Original Message -----
> From: "Dobbins, Roland" <rdobbins at arbor.net>
> To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Cc: 
> Sent: Tuesday, 11 February 2014 5:25 PM
> Subject: Re: [AusNOG] Best Practice for IPv4 PMTU discovery?
> 
> 
> On Feb 11, 2014, at 11:34 AM, Paul Gear <ausnog at libertysys.com.au> wrote:
> 
>>  Google searches have returned only hits which reinforce my current 
> understanding [2][3][4][5].  Your collective wisdom on the point would 
> appreciated.
> 
> They should allow Type-3/Code-4, as you indicate.
> 
> Unfortunately, a lot of Confused Information Systems Security Professionals and 
> the like have absorbed the myth that all ICMP is bad and ought to be blocked, 
> just as they've likewise absorbed the myth that DNS over TCP/53 represents a 
> security threat.  
> 

+1

It's never been good practice to block ICMP Dest Unreachables Packet Too Big. 

Unfortunately because it has become fairly common, one of the consequences is that ISPs have had to resort to MSS hacking, which means fiddling with the Max Segment Size value in every TCP connection they see. There are number of problems with that.

Firstly, it means that the the router doing the MSS hacking has to look further into the packet than just the outer IP header, looking for the TCP MSS option. The TCP MSS option doesn't have to be in the same place when it is present, so that makes MSS hacking more complicated and therefore harder.

Secondly, not all traffic is TCP. MSS hacking won't work with UDP, GRE, OSPF, or IPsec etc., because they don't have the MSS equivalent fields. So they'll break if they try to use the full interface MTU and there is a lower MTU somewhere in the path.

The other way people get around PMTUD is to switch it off, and send smaller packets e.g., 1420, 1380 or similar, that can also be further fragmented. There are number of problems with those.

Smaller packets are less efficient, although it may not be a significant inefficiency.

Fragmentation requires a router to generate at least another new packet when it fragments the original, and this is unlikely to be done in fast forwarding plane hardware. So either the packet gets punted to slower software forwarding, which may also be run on the control plane CPU, or the to-be-fragmented packet may be dropped.

Some stateful firewalls will want to see the whole packet before they decide to forward it or drop it, which means waiting for all fragments to arrive and reassembling them to then make the forward/drop decision. With enough fragments, or fragments that never arrive, the fragmentation reassembly buffers can be exhausted - which also creates another firewall DoS vector.

Not only has blocking ICMP DU PTBs never been good practice, it has actually been very bad practice!

There is a version of PMTUD that uses probing and packet loss to determine PMTU, described in RFC4821. IIRC, it is available in Linux and Windows, but at least in Linux, last I looked, wasn't switched on by default. That doesn't mean though it is now safe to block ICMP DU PTBs, as there will be legacy hosts that don't do it (Windows XP?).


> Generally speaking (not always), enterprises have considerably less clue with 
> regards to networking, TCP/IP, and actual security than ISPs.  And so they dork 
> up their DNS by blocking TCP/53, and dork up PMTU-D by blocking all ICMP, 
> including Type-3/Code-4.
> 
> The problem isn't buggy code; it's lack of clue, which leads people to 
> do things like put stateful firewalls in front of servers where they serve no 
> useful purpose, to block all ICMP, to block TCP/53, to block UDP/53 DNS packets 
> greater than 512 bytes in length (thus breaking EDNS0 & DNSSEC), et. al.
> 
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // 
> <http://www.arbornetworks.com>
> 
>       Luck is the residue of opportunity and design.
> 
>                -- John Milton
> 
> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>