>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 (at) gont.com (dot) ar [email concealed] || fgont (at) acm (dot) org [email concealed]
>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 (at) gont.com (dot) ar [email concealed] || fgont (at) acm (dot) org [email concealed]
[ reply ]