lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <6.2.0.14.0.20050720194708.038d8140@pop.frh.utn.edu.ar> Date: Wed Jul 20 23:59:33 2005 From: fernando at frh.utn.edu.ar (Fernando Gont) Subject: Re: ICMP-based blind performance-degrading attack At 07:42 p.m. 20/07/2005, Darren Reed wrote: >Go look in the bugtraq archives for 8 July 2001 and you might find an >email like the one below. THere was a thread on this topic then. > >It would be nice if you included a referral or something in your IETF >draft to my original work on this, 4 years ago. Unless you want to >try and proclaim that discussion on bugtraq isn't public knowledge >and your discoveries are somehow "new". Did you read the "Introduction" of the draft? Where are the claims you mention? The new stuff is the counter-measures, not the attacks. >This is just one pointer to a start of the thread then... >http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00124.html This attack was even mentioned in RFC 1191. So nobody could "discover" it, because the authors of RFC 1191 themselves stated that this attack could be performed. Now, provide a pointer to a discussion of the counter-measures proposed in my internet-draft. [Quoting your "old e-mail"] >What's most surprising is that there does not appear to be a documented >minimum, just as there is no "minimum MTU" size for IP. If there is, >please correct me. Yes, there is: 68 bytes for IPv4, 1280 for IPv6. >About the only bonus to this is that there does not appear to be an >easy way to affect the MSS sent in the initial SYN packet. > >Oh, so how's this a potential denial of service attack? Generally, >network efficiency comes through sending lots of large packets...but >don't tell ATM folks that, of course :-) Does it work? *shrug* It >is not easy to test...the only testing I could do (with NetBSD) was >to use the TCP_MAXSEG setsockopt BUT this only affects the sending >MSS (now what use is that ? :-), but in testing, changing it from >the default 1460 to 1 caused number of packets to go from 9 to 2260 >to write 1436 bytes of data to discard. To send 100 * 1436 from >the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with >an MSS of 1460. This doesn't sound like an ICMP-based attack, BTW. >So, what are defences ? Quite clearly the host operating system >needs to set a much more sane minimum MSS than 1. Given there is >no minimum MTU for IP - well, maybe "68" - it's hard to derive >what it should be. Anything below 40 should just be banned (that's >the point at which you're transmitting 50% data, 50% headers). >Most of the defaults, above, are chosen because it fits in well >with their internal network buffering (some use a default MSS of >512 rather than 536 for similar reasons). But above that, what >do you choose? 80 for a 25/75 or something higher still? Whatever >the choice and however it is calculated, it is not enough to just >enforce it when the MSS option is received. It also needs to be >enforced when the MTU parameter is checked in ICMP "need frag" >packets. So I must assume this e-mail discusses a blind ICMP-based attacks? -- Fernando Gont e-mail: fernando@...t.com.ar || fgont@....org
Powered by blists - more mailing lists