Bugtraq mailing list archives
Re: ICMP fragmentation required but DF set problems.
From: antirez <antirez () invece org>
Date: Tue, 23 Jan 2001 06:42:16 +0100
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
Current thread:
- ICMP fragmentation required but DF set problems. antirez (Jan 15)
- Re: ICMP fragmentation required but DF set problems. Ofir Arkin (Jan 16)
- Re: ICMP fragmentation required but DF set problems. antirez (Jan 16)
- Re: ICMP fragmentation required but DF set problems. Peter Mathiasson (Jan 16)
- Re: ICMP fragmentation required but DF set problems. Pavel Kankovsky (Jan 22)
- Re: ICMP fragmentation required but DF set problems. antirez (Jan 23)
- <Possible follow-ups>
- Re: ICMP fragmentation required but DF set problems. Niels Provos (Jan 23)
- Re: ICMP fragmentation required but DF set problems. antirez (Jan 23)
- Re: ICMP fragmentation required but DF set problems. Mark . Andrews (Jan 24)
- Re: ICMP fragmentation required but DF set problems. Felix von Leitner (Jan 25)
- Re: ICMP fragmentation required but DF set problems. Ofir Arkin (Jan 16)