Re: ICMP fragmentation required but DF set problems.

[antirez <antirez () invece org>]

On Sun, Jan 21, 2001 at 04:40:53PM +0100, Pavel Kankovsky wrote:
> On Mon, 15 Jan 2001, antirez wrote:
>
> >   It's possible to slowdown (a lot) connections between two
> >   arbirary hosts (but at least one with the PMTU discovery enabled)
> >   using some spoofed TCP/IP packet. Maybe you can do more
> >   against some TCP/IP stack.
> ...
> >   There isn't a clear solution.
>
> PMTU discovery is used by TCP (primarily if not exclusively). Isn't it
> possible to 1. check TCP sequence numbers in ICMP frag. needed messages
> generated as a response to a TCP datagram (in the same way they should be
> checked on any ICMP dest. unreachable to prevent a trivial DoS),
> 2. disregard any other ICMP frag. needed message?

You can't if you wan't break the UDP PMTU discovery API
that applications can use, and to look-up UDP non-connections
don't seems possible.

Anyway we may use this semi-fix:

When the DF bit is set the IP-ID field isn't used at all.
Also only packets with the DF bit set will generate the ICMP
frag needed in respose, so the trick is to sign the outgoing
packets with the DF bit set and store the (only 16 bit) HMAC(srcip|dstip)
in the ip-id field. The key is generated at start-up and
updated every X packets and/or Y seconds. When we got back
the ICMP we can check the signature since the IP header is
quoted. Note that you need to check the signature against
the current and the last key, so in the middle case the attack
may be mounted anyway using 2^14 spoofed ICMP packets in the middle case.

This isn't perfect security but it's better than nothing,
if you consider that this don't break anything of standard.
To reach more security you may break the TOS and the
HMAC will be of 24 bits, 2^23 packets required in the middle
case, but actually 2^22 since you check with a bogus key (one of the two
between the last and the current).

Anyway this combined with a reasonable MTU-info short expiration
time will make the attack quite hard, at least compared
with the one packet needed with the current implementations.
Obviuosly this will load your CPU, but the hash function
can be quite weak&fast, since the attacker can collect just
an HMAC for every phisical IP address he owns.

I implemented this as a netfilter hook for linux 2.4 and it
works well. I wan't release beta code, expecially when
in kernel space, so I'll double check it and then send it
to bugtraq.
My implementation uses the MD4-based trasformation that
you can find under linux/drivers/char/random.c

This sounds reasonable?

regards,
antirez

--
Salvatore Sanfilippo              |                      <antirez () invece org>
http://www.kyuzz.org/antirez      |      PGP: finger antirez () tella alicom com