Path MTU discovery (PMTUD) is far from a new concept to IT folk. A sending node sets the Don’t Fragment bit in its IPv4 header which is the nodes way of telling any router along the journey to the packet’s destination that it may not fragment the packet into smaller parts. The router, being an obedient device, honours the instructions in the packet and, when the exit interface does not support the size of the packet, it drops it (rather than fragmenting it). Now, it is polite, but not required, for routers to tell you when they do such things. The router that dropped your unfragmentable packet can (should) send you back an nice ICMP message that effectively says, “…just wanted you to know that the packet you just sent was too big to go out my interface so I dropped it. The biggest MTU I can handle on that interface is ____________ bytes. If you want to you can try again with an MTU no bigger than that.”. This ICMP message originates from the router that dropped your packet and is sent back to you (also note that routers can be configured to quietly discard the packets, sending you no ICMP Packet-too-Big message). The problem we have had for years is that firewall administrators, who live in a perpetual state of fear of all things ICMP, frequently disable ip unreachable packet generation on routers and also block most, if not all, incoming ICMP traffic from the Internet. This was a problem in IPv4 which can provide for some interesting troubleshooting scenarios. Disabling IP unreachables (using the ‘no ip unreachables’ command on Cisco routers) is considered a security best-practice even though it is widely known to cause PMTUD issues. The problem persists in IPv6 and is arguably worse.
Intermediate IPv6 nodes (e.g. IPv6 routers) are not allowed to fragment IPv6 packets. This is by both standard and design. The originating node can fragment but doesn’t initially think to do such things. The Don’t Fragment bit doesn’t exist in the IPv6 packet header (no need to tell a router ‘yes’ or ‘no’ when they aren’t allowed to fragment anyway). This means that Path MTU Discovery is implicitly always on for IPv6. And in most cases where there is an MTU issue it is likely to always be failing. Why? Those pesky security-minded firewall admins, of course. Many firewalls around this lovely planet are configured to drop pretty much all incoming ICMP, packet-too-big included.
The failure of PMTUD leads to two possibilities: failed connections or more network overhead. Failed connections because TCP connections time out and more network overhead because of excessively small payloads. RFC’s 1981 and 2923 address the issue of Path MTU Discovery but don’t provide strict guidance on what an IPv6 node is supposed to do when big packets don’t make it through and no Packet Too Big message is received by the source. RFC 2923 only suggests that v6 nodes could fall back to a default of 1280 bytes (the IPv6 minimum MTU). If that is what nodes do then …wow …what a waste of a header that could be; potentially losing more than 200 bytes per packet just because a router disabled PMTUD or a firewall drops the ICMP Packet-to-Big message? 200 bytes isn’t a lot of data. But 200 bytes multiplied by a gazillion packets is a lot of data. And as our networks continue to get busier and ever more unified (what don’t we jam into IP packets these days?) we really can’t afford to have packets defaulting to minimum MTUs. The network needs to be better.
Interestingly, the most obvious security issue (per RFC 1981) with allowing packet-too-big messages to come inbound is that someone could spoof an artificially low MTU in a packet-too-big message thereby causing a node to ‘slow down’ (e.g. have to create more packets with smaller payloads). If such an attack were to occur it can’t make the node send smaller than 1,280 bytes (the minimum). This is theoretically equal to the damage caused by the firewall admin not allowing the packet-too-big message in the first place. Arguably, the attacker is doing less damage than the firewall admin.
RFC 4821 proposes a (standards track) solution using TCP and increasingly larger packets in order to determine the path MTU. This feature is supported by Linux but, to the best of my knowledge, is not enabled by default. Microsoft has its own way of doing this, too (a registry setting called EnablePMTUBHDetect). Another way to fix the issue (sometimes) is the use ‘MSS clamping’, a process where an intermediate router locks the MTU to the TCP MSS.
It sure does seem like we are jumping through a lot of hoops to work around the problem when the real fix to the problem is so much easier: configure routers to generate packet-too-big messages when appropriate and configure firewalls to allow packet-too-big messages to come inbound. When discussing this topic in class I suggest that organizations need to re-visit their firewall mantra. And it’s usually at that point that the security people in attendance always start shaking their heads, dismissing the idea outright (e.g, applying their IPv4 mentality to IPv6 networking). On more than one occasion I have had people reference the NSA’s guidelines on ICMP. Those guidelines, I suggest, are a bit dichotomous; they recommend disabling ip unreachables on routers (which includes sending packet-too-big messages, Type 3, Code 4 in IPv4 ICMP) but suggest that it’s OK to configure firewalls to allow packet-too-big messages inbound. Routers, being a pretty common device through which packets pass on their way from A to B are likely candidates for generating packet-too-big messages so turning off their ability to do so while letting a firewall pass them when originated is fairly odd to me. Note that I am referencing this document: www.nsa.gov/ia/_files/routers/C4-040R-02.pdf. The NSA seems to soften on their position in this document titled Firewall Design in IPv6, suggesting (but not blatantly stating) that “it will no longer be tolerable to drop other ICMP messages due to new IPv6 features”. Path MTU Discovery is not a new feature but I’m hoping that this signals a change in position.
Networks need to be secure. That’s a bit of a “Duh!” thing to write, I know. But I find myself reminded of the good ol’ Confidentiality-Availability-Integrity triad we so often see in security literature; the need to balance security with availability. And network throughput is a subset of availability. Our IPv6 networks need to be able to negotiate MTU or many packets may be limited to 1280 bytes. And in this day of ever-increasing loads, that simply isn’t going to work.
Cheers,
Colin Weaver
colin@itdojo.com
www.itdojo.com
Colin Weaver is co-owner and lead instructor at ITdojo, Inc., a network security and information assurance training center and consulting firm located in Virginia Beach, VA. His passion for technology, networks, and security has led him to become enthralled with the idea of IPv6 and its implementation. In this blog he will share with you glimpses of what he has learned and a hint at what you’ll learn in his classes. Visit https://www.itdojo.com to learn more about ITdojo IPv6 course offerings.
