Re: ICMP-based blind performance-degrading attack

[Fernando Gont <fernando () frh utn edu ar>]

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 () gont com ar || fgont () acm org