Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
The Internet

MSS Initiative Makes Progress 114

Phil writes "The MSS Initiative was started by Richard van den Berg and myself to combat sites that are broken (enable Path MTU Discovery AND block ICMP 3,4) which include such big sites as SecurityFocus and CERT (causing those behind PPPoE and other less-than-1500-MTU-protocols to be unable to view the sites). This past week we were priveleged enough to be able to present a paper at the 16th LISA Systems Administration Conference! Check out the paper and slides and be sure, like many members of the audience, to fix the sites you administer!"
This discussion has been archived. No new comments can be posted.

MSS Initiative Makes Progress

Comments Filter:
  • Can't read pdf (Score:1, Offtopic)

    by Deton8 ( 522248 )
    For some reason I can't read the .pdf file. Got the latest M$ XP Pro, and Adobe...
    • Re:Can't read pdf (Score:3, Insightful)

      by 0x0d0a ( 568518 )
      Got the latest M$ XP Pro, and Adobe...

      I wish people wouldn't do this. You don't "have Adobe" any more than you "have the Internet" or something similar.

      I'd guess from the context that you're talking about Acrobat Reader. Unfortunately, people also use the term "I've got Adobe" to refer to Photoshop.

      Granted, the origin of all this was companies, not consumers, with people like Microsoft and Netscape putting their company names into their product name, but it's confusing, and it's consumers that are keeping it going.
      • People also use "iso", "rs" and "ansi" for "ISO 9660", "EIA RS-232", and "ANSI X3.64", respectively.

        I guess that the name of the standards organization should be enough. No need for these pesky numbers.
    • Boot a Linux cd (Debiang GNU/Linux for me, but you should start with mandrake) and use it to ERASE DOS(winshit 5.1 is DOS) and install a real operating system (Linux, or any UNIX derivitive) in place of it. Then install xpdf and galeon ('apt-get install xpdf galeon' in Debian and 'urpmi xpdf galeon' in Mandrake). Run Galeon in X and view the page. TaDa!

      You can download ISO images of both Debian GNU/Linux [] and Mandrake [] at [].
  • Both sites work with me. I have an MTU of 1492 and PPPoE.
    But if he says so, then I won't access them, due to the 'problem'...
  • by Anonymous Coward on Monday November 11, 2002 @08:40AM (#4641833)
    MTU: Maximum Transfer Unit.
    This is the maximum number of bytes that your computer will send out in a packet. This should be set according to what your connection can handle. For ethernet this should be set to 1500. For PPPoE links this should be set to 1492.

    MSS: Maximum Segment Size.
    This is used in negotiating what the MTU of a connection between two hosts will be. Essentially this is saying "please don't send me packets bigger than X." This should typically be set to 40 less than your MTU to allow room for headers.
  • And here I was thinking that securityfocus and CERT had been rooted by script kiddies!
  • by Anonymous Coward
    ...see the redundancy of creating a blacklist for networks you can't reach to begin with?
  • by wowbagger ( 69688 ) on Monday November 11, 2002 @08:58AM (#4641891) Homepage Journal
    The PDF of the paper refuses to render with any Ghostscript derived viewer.

    It sure would be nice if those who wish to cast stones would make sure their own position is clean.

    That said, I've had to ding webmasters about having their routers set up to block packets with explicit congestion notify set - that is now an accepted part of TCP/IP, and failing to accept packets with ECN set is a violation of the standard.
  • by jilles ( 20976 ) on Monday November 11, 2002 @08:58AM (#4641892) Homepage
    This problem is way to technical to explain to most sysadmins. Expecting them to fix it after a kind notification seems naive at best. Instead focus on firewall product manufacturers. In many cases sysadmins just use some sort of generated rules from some firewall product or duplicate sections of howto's. if you make sure the generated stuff is ok and the howto's & manuals don't misinform the sysadmins, there's a lot to gain.
    • You aren't very specific here. If you're talking about people who are Microsoft Admins (which imo don't qualify for the term "sysadmin" in large part) then maybe. Even then you're only talking about a segment of the group...arguably a large one, but still a segment. There are still some MS admins with a clue.

      If you're talking about (real|unix) sysadmins then I think you're probably way off base. Or at least I certainly hope so. If you're right, then we've had some serious degeneration going on. I've got a rather cynical view as it is considering the number of clueless people I run into even on the unix side but the majority I meet still do know what the hell they're talking about. And few if any would just use some pre-defined firewall ruleset, and even fewer would be unable to understand a request of this nature.

      • I'm specifically referring to overzealous linux sysadmins who tend to overconfigure their systems or to sysadmins who just go with the defaults of the redhat/mandrake firewall.

        Real UNIX sysadmins are expensive and rare. You should see the monkeys that maintain our local network. If I want a virtual server added to our apache server it is more efficient for me to look up the documentation and take our sysadmin by the hand to guide him through the process (this actually happened). Most organizations have shitty sysadmins. Luckily ours never tried their hands on a firewall (that means security sucks by default and there are no restrictions on network usage :-).
  • Thank You (Score:5, Interesting)

    by w1r3sp33d ( 593084 ) on Monday November 11, 2002 @08:59AM (#4641896)
    MTU has turned into the bane of my existence, between atm header problems, VPN's which can't have their packets fragmented without blowing up their crc's, and voice and video apps over low speed links adjusting the MTU down isn't an option anymore, many times it is required. Maybe a site here or there won't display, but usually its downloads that die, like a norton update for example. If I reset the mtu back to 1500 then the vpn's drop and voice develops jitter or drops (using a vovpn as an example)but everyone can download their updates (and of course more importantly their mp3's.) My point is that allowing your ftp server to service a packet at 750 won't kill you or your server. How much overhead do you add by sending two packets at 750 over one at 1500 and how much bandwidth will you save? Until this problem completely disappears I will keep a copy of DR. TCP on my laptops, I believe you can free copies of it from Cisco (might need to be registered)
    • Re:Thank You (Score:3, Informative)

      by gmack ( 197796 )
      That's not the reason why they do it. It['s usually a side affect of doing a generic block on ICMP at the firewall. The generic block seems logical to your average clueless sysadmin since now the local network is harder to flood with ICMP Pings or used to bounce them. Unfortunatly people keep forgetting that ICMP is more than just PING and TRACEROUTE.

  • by _Spirit ( 23983 )
    I didn't think anybody used LISA's anymore ;-)

    Anybody know what LISA stands for ?
  • Why on earth do idiots feel the need to bastardize everything. This whole thing is about PPOE not MTU size. The better solution is to get rid of the bastardization (PPOE) .
    • by jdh28 ( 19903 ) <> on Monday November 11, 2002 @09:37AM (#4642075) Homepage

      I agree that PPPoE (note the 3 P's) is not the most elegant solution, but it is perfectly valid to have smaller MTUs. It is peoples' firewalls that are broken here.


      • by Anonymous Coward
        And yet modems work without problems.

        It is PPPoE reliance (not use) on path discovery that is causing the issue here.

        It's not surprising that security sites are blocking ICMP 3,4. Allowing it potentially allows a DoS attack to be attempted with relatively low bandwidth. (Set MTU to minimum, send large amount of traffic, packet overhead increases).

        If you need that functionality in your own network, go for it. But I don't see why other should make themselves more vulnerable just because a minority are having trouble when everyone else is fine. (BTW that 70% figure sounds impressive, but keep in mind the low percentage of broadband users)
        • by Anonymous Coward
          Heard the saying "just enough knowledge to be dangerous"? That's a good way to describe folks who think they need to disallow ICMP 3,4 to secure themselves from DoS attacks.

          Allowing ICMP 3,4 at your firewall does not make your site more vulnerable if have enough knowledge to do it right. See _icmp.html for a description of how to do it right.
    • And what do you offer in exchange? Raw Ethernet? Sorry but that's overbastardization for some tasks. You ignore that virtual networks, private networks and several security tasks need such things as PPOE, VPN, PPTP and alikes. However there is a price to pay. In the case of PPOE it is a logical price as you need to low the MTU of the inner package so that the whole thing fits into a classical 1500 byte data envelope and the host will not break his head with oversized datapacks. If no one gets the idea why this should be done, then it is him who's the idiot and not the protocol. And if one doesn't get the idea why such kind of protocols exist than better RTFM a little before calling others idiots. A lot of my colleagues use virtual networks for tons of tasks as solving things in a single raw physical basis is becoming near to impossible today. It is becoming overexpensive and risks are getting bigger and bigger.
    • by Anonymous Coward
      PPPoE may be a silly idea, but destroying path MTU discovery is WRONG. Not only PPPoE has problem with this, but anyone on a network that uses larger packets than the link to the rest of the net.

      PMTUD was made long before PPPoE, and is an integrated part of the IP protocol.
    • Why on earth do idiots feel the need to bastardize everything. This whole thing is about PPOE not MTU size. The better solution is to get rid of the bastardization (PPOE) .
      Why on earth do idiots feel the need to bastardize everything. This whole thing is about cholesterol buildup within blood vessels, not dying because one eats too much. The better solution is to get rid of the bastardization (cholesterol buildup).

      Like if you had the choice of avoiding PPPoE.

    • Agreed! These people that defend this protocol have probably never had the displeasure of being forced to use it. It's sole purpose seems to be to allow phone companies to micromanage the DSL connections a little more.

      The PPPoE software (client AND server side) is terrible for the most part, and it took YEARS to get them even as stable as their are now.

      For a broadband connection, it's horrible. Originally, everyone used DHCP to assign you the necessary info, but now it's all done through PPP. It's just like dial-up again, even the connection procedures! Add to that the fact that most ISPs use dynamic IP addressing and you'll get a new IP *every* time you connect (not so bad in itself, but coupled with the frequent disconnections, see terrible software above..) It's a nightmare for the end user.

      Protocols are supposed to be TRANSPARENT to the end user. PPPoE is anything but. There's a reason there's a ton of support sites to help people with it's bizarre configuration. It's a failure.
    • The better solution is to get rid of the bastardization (PPOE) .
      You obviously don't have to manage an ISP.. PPPoE allows a much greater control than PVC based, with:
      -session accounting
      -flexible user login control (radius, realms and so on)
      You don't need to reconfig a router manually for each customer, play with MAC addresses etc.

      By the way, most PPPoE have an MTU set for 1492. But since most ISPs are using a telco platform and the sessions are forwarded over L2TP to their router, there's another 40 bytes to remove from the 1492.. The ideal MTU now being 1452 for PPPoE customers. If all clients had this set, nobody would have heard of MTU/MSS at all :-)
  • The linked paper seems to be broken, and I'm feeling rather lost in this sea of acronyms...
  • by Jacco de Leeuw ( 4646 ) on Monday November 11, 2002 @09:23AM (#4642008) Homepage
    The PDF on this mirror [] seems to work.
  • i love the fact that the slideshow presentation is available in Open Office format (.sxi)

    sure would love to see more of this in the real world.
  • Its a good start (Score:5, Informative)

    by anticypher ( 48312 ) <anticypher&gmail,com> on Monday November 11, 2002 @09:26AM (#4642029) Homepage
    There needs to be more awareness in the internet world about not breaking some of the underlying technologies. What the authors are talking about is sites with fuckheaded admins who blindly block all ICMP traffic with their firewalls.

    Path Maximum Transmission Unit Discovery, ICMP type 3 code 4, is sent to an IP stack telling it to send smaller IP packets so the packets don't get fragmented along the way. When nearly 75% of broadband users in Europe are forced to use PPPOE, they count on a working PMTUD message making things work.

    There is a workaround, called MSS clamping, built into Roaring Penguin PPPOE (great software, guys!) which tweaks the TCP stack for web traffic. Unfortunately, it breaks all kinds of other traffic which doesn't expect the MSS to change.

    So this paper is a good start to informing network admins there is no security risk in allowing some types of ICMP traffic. MSS clamping and PMTUD problems were a main topic of coffee break discussions at the last RIPE meeting. Now it remains to convince the firewall manufacturers to change their defaults so that they aren't breaking more and more of the internet. Adding this information to Firewall-HOWTOs would also be a good idea.

    the AC
  • Too bad they didn't run the paper through spell-check [].

    Also, the PDF [] seems to be broken. It won't display on my system. (Anyone else have that problem?)

    Overall, pretty impressive.

    The version on the USENIX [] site seems at least to have the correct spelling in the title, but you need a password to download the PDF there.

  • by 51c4r1u5 ( 614079 ) on Monday November 11, 2002 @09:45AM (#4642113)

    Assuming you use your linux machine as a router there is a solution. Using a recent distro/kernel there should be an ipt_TCPMSS module available. Running iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss -to-pmtu "does the trick" of adjusting packet sizes. Sites like CERT, SecurityFocus or are accessible then.

    Further readings here [] and here [].

  • I wonder if this is related... I had for awhile used a D-Link 'router, just a little one, on a PPPoE line. Well, for the most part it worked well, but sometimes it would just drop connections. (very annoying that several times a night ssh sessions would die.) I finally narrowed it down to certain pages/streams(streaming mp3) would cauase it(the dlink) to reset. I also have heard of somewhat similar problems with the linksys versions of the same.

    So, my question would be, did anyone else have these problems? Is it maybe related, or just a bad PPPoE setup in those 'routers'?

    On another related note, I replaced the D-Link with an OpenBSD firewall, and haven't looked back... performance increase was moderate, and control I have over it is just great... Will never try to get out easy on a firewall/NAT thing again, just do it right the first time:)
    • I doubt it was a pppoe issue with the router since it started the applications/streams, likely it was a version bug combined with a reoccurring set of conditions (buffer size, event log size, nat translation tables, whatever.) I had similar problems with my netgear router until I upgraded the version. Someone correct me if I am wrong, but I don't think streaming mp3's and ssh packets shouldn't ever hit the mtu, if you had been downloading mp3's that would be a likely culprit. Congrats on working around the problem for yourself, sounds like a fine solution for the home user since you get to learn more about networking, internet, and an os.
      • Congrats on working around the problem for yourself, sounds like a fine solution for the home user since you get to learn more about networking, internet, and an os.

        Well, hehe:) I already do that stuff for work:) Did learn a bit about OpenBSD, though(had mostly stuck with Solaris and Linux before that) It was just a matter of not wanting to do any more work-related things at home, and taking the cheap/easy way out, and getting the little d-link.
        I have actually heard reports of similar problems from other people, but I'm guessing it was the firmware on the router. A co-worker had trouble with a linksys getting slower and slower, as well... Quite likely it's a problem with Ameriwreck DSL/d-link/linksys routers, was just wondering if anyone else had had anything similar, or a solution to it. At the time(about two months ago, I was using the latest firmware, and it actually fixed a few problems from the previous one, but not all of them...)
  • by MaoTse ( 624765 ) on Monday November 11, 2002 @10:09AM (#4642243)

    Just noticed this in the netfilter section of linux config file:


    This is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
    1) Web browsers connect, then hang with no data received.
    2) Small mail works fine, but large emails hang.
    3) ssh works fine, but scp hangs after initial handshaking.

    Don't know about you but myself I can't remember actually using this nf option...
    Maybe the reason is I always let the ICMP packets go ;-)

    Any thoughts about those other dangers of blocking ICMP3,4 ?

    • I did some research on this many moons ago. I wanted to block ICMP and did so blindly for a while until I did some research as to which ICMP i wanted to block. I came up with this:

      deny icmp any any
      permit icmp any any ttl-exceeded
      permit icmp any any parameter-problem
      permit icmp any any host-unreachable
      permit icmp any any port-unreachable
      permit icmp any any packet-too-big
      permit icmp any any host-unknown

      I think I was able to get everything that's "harmless". That's only on the ingress by the way. All applied to Serial0/0
      • ACL isn't correct. Cisco devices parse from the start to finish and exit at the first match (with an implied "deny any" at the end). Your ACL would match any ICMP packets with the first line, deny it, and exit the ACL.

        permit icmp any any ttl-exceeded
        permit icmp any any parameter-problem
        permit icmp any any host-unreachable
        permit icmp any any port-unreachable
        permit icmp any any packet-too-big
        permit icmp any any host-unknown

        This would allow the above and block all else (probably bad, since your data wouldn't get through).

        permit icmp any any ttl-exceeded
        permit icmp any any parameter-problem
        permit icmp any any host-unreachable
        permit icmp any any port-unreachable
        permit icmp any any packet-too-big
        permit icmp any any host-unknown
        deny icmp any any

        This is probably what you want, but remember there is still an implicit deny any at the end (unless you've got the firewall feature-set which dynamically opens things up as needed).

        Most likely you want something like this on a border router:

        permit icmp any any ttl-exceeded
        permit icmp any any parameter-problem
        permit icmp any any host-unreachable
        permit icmp any any port-unreachable
        permit icmp any any packet-too-big
        permit icmp any any host-unknown
        deny icmp any any
        permit ip any any

        Then firewall elsewhere (initial firewalling on your exterior router is ok, but use a dedicated firewall if possible).
        • Well I didn't post the entire ACL but I can't believe I had that miffed up. That's a rookie mistake.

          And yes there are actually two different firewalls from that point on depending on the which interface of the NM4E you go out on.
    • [odd thought] Is this one of the causes of the infamous "Document contains no data" error??

      I've noticed that some sites began producing that error after switching to Solaris 9 running a particular webserver (on checking netcraft, I learned that my intended example apparently moved away from this combo, so I can't tell you more since I don't recall the webserver's name :(

  • As a frequent visitor of

    The companies they mail must be seriously confused as to what this has to do with their site... :)

    Jokes aside, that "frequent visitor" phrase is nice, and _may_ help getting their message through to the right persons.

    But probably not - and it is lying (which is easy to deduce when visiting their site - the url is given in the same mail). Pretending to be a regular visitor may hurt these guys in the long run, even if they do stuff for a good cause... I don't know if they do, I read the explanations and still couldn't figure out if this was something worth bothering about. :)
  • I think it's utopic to think one can fix so many's ISPs problems. It's like closing open relays, even with big real-time blocking lists, a lot still slip thru.
    A good paper explaining MTU/MSS is on Cisco []. If your ISP can't just 'adjust-mss' on his router, either he will fragment a lot and drop the DF (don't fragment) packets, or you will have to use Dr TCP [] to fix the MTU on your side.
  • by bhsx ( 458600 ) on Monday November 11, 2002 @11:36AM (#4642737)
    If you don't use PPPoE and want to test some of these theories, you can try a "ifconfig eth0 mtu 1400" where eth0 is your network connection.
  • (from the MSS Initiative [] page)
    ...notify sysadmins about the "brokenage" of their sites

    Please help me understand this initiative by not making up words. Yes, I can guess the meaning, but if that's the purpose (i.e. to keep the audience guessing) then why not just post random text? If the goal is to demonstrate you k3wlne55, then post in haCk15h. If the goal is to convey an idea, sway public opinion, convince a group of skeptics, form a consensus, and ultimately, build a coalition, you might want to consider restricting your phraseology to a more mainstream subset of English.

    This is only a suggestion.

  • by Anonymous Coward
    Astonishingly, the paper neglected to mention the best solution for site admins that I have yet seen for the problem -- rate limiting as a protection from DoS attacks. Cisco describes their implementation of this at _icmp.html. I don't know how widespread router vendor support for this is, but the concept is spot-on. If behaviors which are normally both legal and helpful can turn deadly when they take on a certain pattern then don't blanketly prohibit the behavior, identify when that pattern is developing and then cut it off. Wasn't that the whole concept behind stateful packet inspection anyways?

  • ip tcp adjust-mss 1460
  • These guys are setting a good example. Their 7-page PDF is 80KB expanded, 24KB zipped. That's for 20K non-space formatted characters plus a simple figure. Less formatting overhead than the average HTML 3.0 page. Looks good, too; it is groff output run through Distiller and it renders well on Acrobat Reader and is typeset well.
  • how long would a lisa [] last before exploding from the /. effect?
  • I have wondered for some time why is the MTU exactly 1500. I found out why the smallest is 64 (48+headers). But why 1500? is it because it is a nice round number?
    • It corresponds to the maximum packet size for Ethernet.
      • Yes, I know it is the maximum size for 802.3 CSMA/CD, but why exactly that number? Why not for example 1600? Or whatever.
        • It's a fairly arbitrary decision. The minimum packet size can be derived from collision detection scheme used by Ethernet and the maximum length of an Ethernet segment. The maximum size is a compromise between efficiency, network latency and keeping the memory allocated to packet buffers to an affordable size. DIX Ethernet (10 Megabit/Sec) was scaled up from experimental Ethernet (3 Megabit/Sec), which limited packet size to approx. 4000 bits. See the original papers by Metcalfe and Boggs.
  • Just got back from LISA, where all the good presentations were double-booked and the CD-ROM of the slides cost another couple hundred over and above the $695 (Usenix member's price!) for the conference itself. I don't think I'll be going to the next one -- not if they don't at least include an electronic copy of the procedings.

    Saw the blurb in the LISA program (it appeared as "Overzealous Security Administrators Are Breaking the Internet" -- sheah, right, let's put six exclamation points on it) but had no idea what it was about until I got to this article.

    Score one for /. Let's do Dan Klein on "Constitutional and Financial Arguments Against Spam" next.
  • For those who noticed the 'local copy' of the PDF was toast, earthlink's servers were somehow nuking the PDF on download... but a nice gzip'd fixed it as well as limiting the slashdot effect (I'm shocked earthlink hasn't shut the site down yet - yay for text sites). Phil MSS Initiative
  • "Yes, let's consider," said Bruno, putting his thumb into his
    mouth again, and sitting down upon a dead mouse.
    "What do you keep that mouse for?" I said. "You should either
    bury it or else throw it into the brook."
    "Why, it's to measure with!" cried Bruno. "How ever would you
    do a garden without one? We make each bed three mouses and a half
    long, and two mouses wide."
    I stopped him as he was dragging it off by the tail to show me
    how it was used...
    -- Lewis Carroll, "Sylvie and Bruno"

    - this post brought to you by the Automated Last Post Generator...

I came, I saw, I deleted all your files.