www.netheaven.com/pmtu.html
PMTU (Path MTU) Discovery Some servers are unusable for many internet users Summary Internet computers, mostly servers, sometimes send packets too large for part of a given path. Not handling this correctly can make the server unusable for some people. Correct handling of oversize packets is by one of two means, as chosen b y the sending computer (the server): * Permitting Packet fragmentation - used mostly by older systems * Path MTU discovery - asking for ICMP notification when fragmentation would be needed By default, modern servers disable fragmentation and try to use path MTU discovery, but sometimes the system administrators block the ICMP noti fications. Overall, these servers ask for ICMP notification of packets that are too large and then refuse to accept the notifications they as k for. Unable to learn that they are sending packets are too big for some paths , the servers are unable to send data to some users. To overcome this they need to accept appropriate ICMP types or allow fragmentation.
list of some web servers with broken path MTU discovery. Path MTU Discovery Every network link has a maximum packet size called the link's MTU (Maxi mum Transmission Unit). The full path from one computer to another may travel across many links with different MTUs. The smallest MTU for al l the links in a path is the path MTU If a packet starts out on a network segment with a large MTU, it may arr ive at a link with a smaller MTU and be too big to fit. Most servers a re on segments with large MTUs, but it is increasingly common for inter net users to be connected via links with reduced MTUs, so it is becomin g common for some packets to be too big. How the problem of oversize packets has been handled has evolved conside rably over time. The original approach was to send only small packets corresponding to the TCP/IP default MTU (576 bytes). The fragments can be reassembled downstream to reconstruct the original large packet, but this packet fragmentation h as several problems involving both efficiency and security. Newer servers try to optimize their transmissions by discovering the pat h MTU and sending packets of the maximum size when there's enough data to fill them.
RFC 1191 in 1990, but it did not become widely deployed until years later. By mid 2002, 80% to 90% of computers on the internet used path MTU discovery. The basic procedure is simple - send the largest packet you can, and if it won't fit through some link get back a notification saying what size will fit. The notifications arrive as ICMP (Internet Control Message Protocol) packets known as "fragmentation needed" ICMPs (ICMP type 3, s ubtype 4). The notifications are requested by setting the "do not frag ment" (DF) bit in packets that are sent out. Some network and system administrators view all ICMPs as risky and block them all, disabling path MTU discovery, usually without even realizing it. Of the several dozen ICMP types and subtypes, some do pose some r isk, but the risk is mostly mild and is of the "denial of service" natu re. That is, an attacker can use them to interfere with service on and from the network. By blocking all ICMPs the administrator himself interferes with service on and from his own network. Unless he also turns off path MTU discove ry on his network's servers, he makes his servers unusable by users wit h reduced-MTU links in their paths. Because service is affected only i n relatively unusual cases, it can be difficult to convince the adminis trator that a problem exists. The prevalence of such "unusual" cases i s growing rapidly though. Administrators who want to block all ICMPs should disable path MTU disco very on their computers, especially on their servers. It makes no sense to ask for ICMP notifications and then refuse to accept them. In addi tion, doing so opens the server to a special type of distributed denial of service attack based on resource exhaustion from a large number of fully-open connections.
path_mtu_discovery * On Cisco routers,with the configuration command no ip tcp mtu-path discovery Example Path MTU Discovery Failure Scenario Joe User has a DSL line. Like many DSL lines, Joe's line actually comes from a large DSL wholesaler and uses PPPoE (PPP over Ethernet) to crea te a logical channel between Joe and his favorite ISP. The DSL line ph ysically connects to a small PPPoE router with a built-in hub, which Jo e uses as the basis for his home network. The MTU on Joe's network is Ethernet's usual 1500 bytes. The MTU on his DSL line is also 1500 bytes, but PPPoE uses 8 of these bytes for an 8- byte PPPoE header, so the MTU of his PPPoE channel to his ISP is only 1 492 bytes. A computer on Joe's Ethernet doesn't know about the PPPoE channel. The largest packet it can receive is a 1500-byte Ethernet packet, so when J oe uses his computer to connect to a remote server, his computer tells the server it's ok to send packets up to 1500 bytes.
Establishing connections uses only very small packets, so Joe can connec t to the server without any MTU issues, but as soon as Joe asks for eno ugh data to fill a 1500-byte packet, the server sends a 1500-byte packe t When that packet gets to Joe's ISP, it doesn't fit down the PPPoE c hannel. The packet has the DF bit set, telling Joe's ISP to drop the p acket and send the server an ICMP saying what packet size will fit. Th e ISP sends an ICMP saying the largest size is 1492 bytes. If the server gets that ICMP, it re-sends the first 1492 bytes as a new packet. This new packets fits down the PPPoE channel, so Joe's compute r gets it and sends back an acknowledgement. The server continues send ing 1492-byte packets until Joe has what he asked for. In most cases t he server will remember the reduced path MTU, typically for ten minutes , and use it for future connections from Joe's computer. However, if the server does not get that ICMP, things go downhill fast. The server is expecting an acknowledgement from Joe's computer, but Jo e's computer didn't get the packet, so the acknowledgment never comes. After awhile, the server gives up waiting and sends the same 1500-byte packet again. Joe's ISP sends back another ICMP The server doesn't get it again and tries sending the 1500-byte packet a third time, then a fourth, a fifth, and so on. Meanwhile Joe's computer can't tell this is happening and is waiting for a response from the server. Eventually, it gives up and sends the ser ver a connection reset. It reports a network failure to Joe, who is le ft wondering what happened. He may soon discover he can access nearly all other sites, just not the one he wanted. If the server he's trying to access is a web server, he may get part of the website, such as getting the ads but not the main page content. Th is happens because the pages normally displayed for many websites are a ssembled from data obtained from multiple servers on a variety of netwo rks. The networks dispensing the ads all support path MTU discovery. If Joe complains to the server operator, they may tell him the problem h as to be his ISP because other users can view their server. However, J oe's ISP is not doing anything wrong, but the server operator is. PPPo E and other connections with reduced MTUs are perfectly legitimate and increasingly common. Having a server ask for ICMP noptification that it refuses to accept is what's broken behavior. Some later day, when the server site has gotten enough complaints from people like Joe to belie ve something is wrong, it may either stop asking for the ICMPs or start accepting the useful ones.
What Joe's computer actually tells the remote server is that the lar gest payload it can send in any packet is 1460 bytes, which is the 1500 -byte maximum Ethernet packet size minus 40 bytes of overhead. This ma ximum payload is called the MSS (Maximum Segment Size). Workarounds There is something Joe can do in the meantime. He can reduce the MTU se tting on his computer's Ethernet interface to the PPPoE MTU, 1492 bytes . Then when his computer first connects to the server, the maximum all owed packet size it gives the server will be 1492 bytes, and the server 's packets will fit down the PPPoE channel. In ot...
|
http://csua.com/feed/