Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.protocols.tcp-ip    |    TCP and IP network protocols.    |    14,669 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 14,038 of 14,669    |
|    Martijn Lievaart to Rick Jones    |
|    Re: icmp echo to a host with smaller mtu    |
|    20 Jun 13 16:53:49    |
      From: m@rtij.nl.invlalid              On Fri, 14 Jun 2013 17:44:55 +0000, Rick Jones wrote:              > While the conditions are not identical, there was an amplification       > attack possible against some TCP stacks (one of which used to be near       > and dear to my paycheck) which did something similar with non-local       > destinations. When speaking with the remote destination, they would       > send an ICMP Echo Request with the DF bit set in the IP header, while       > the rest of the traffic being sent to the destination was sent with the       > DF bit cleared. The idea was to try to see if there was effective       > PathMTU discovery possible along the path to the remote. Only once there       > was an ICMP Echo Reply recieved would the DF bit start being set on the       > "real" traffic. A rather clever thing to do, save for one thing...              Ugh. I assume you are talking about HP/UX? This behavior caused lots of       troubles for us. The least being that ping was blocked everywhere in our       network, so it did not work at all. Sadly I cannot remember what other       troubles it caused, but it made a lot of architects against PMTUD where       there was no real problem with it, but a huge problem without it.              Although I still think the HP/UX implementation was moronic, the response       by architects and admins to the PMTU troubles in said network was even       more moronic. All token ring interfaces had their MTU set to 1500. I did       predict that the first tunnel would cause no end of trouble, which it did.              In the end, as we were responsible for said tunnel, we just forcibly       stripped of the DF bit as it was impossible to convince the network       owners of the correct solutions.              In our part of the network PMTUD did work as designed, except for one       stupid firewall that neither allowed fragmentation-needed errors by       default in an intelligent way, in general, or even could be made to allow       them at all without allowing all ICMP. This was high-end, expensive       stuff...              M4               -- The "fun" I had with PMTU, yuck! --              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca