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@xxxxxxxxxxx || fgont@xxxxxxx