At 03:43 a.m. 22/06/2005, Steven M. Bellovin wrote:

[quoting the OP]

>In message <20050621180211.GA360@panix.com>, Ed Ravin writes:
> >One of my customers with NetBSD 2.0 was recently hit with an interesting
> >DoS attack.  The attacker opened up an HTTP connection to the customer's
> >NetBSD webserver, sent an HTTP GET, and then when the response came flowing
> >down the pipe, sent an ICMP unreachable, "fragmentation needed" message,
> >with the "MTU wanted" size set to 1500.  NetBSD would then start
> >retransmitting the data in the TCP window, only to get another ICMP
> >unreachable message with the "MTU wanted" set to 1500.

I'm not sure I understood your explanation. But if I did, that behaviour is 
really weird.
If you receive an ICMP "fragmentation neded and DF bit" that would make you 
*reduce* the assumed Path-MTU, you should honor it, and retransmit the 
corresponding data.

But I'd appreciate if you could clarify the explanation a bit.



> >1) ignore the ICMP unreachable "need to fragment" message if the "MTU size
> >wanted" in the message is equal to or larger than the current MTU size for
> >this connection.

This is aready stated in the Path-MTU specifications (for IPv4 & IPv6) 
themselves.



>This will limit the attacker to sending "only" 1431
> >messages before reaching the minimum MTU, 68.  Not enough to stop the
> >attack, but at least it blunts it.

Please visit http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html
You will find an entire internet-draft devoted to the discussion of ICMP 
attacks against TCP, including the Path-MTU one.

I announced this draft here or in the security mailing list at some point, 
and even one NetBSD guy (Miles Nordin) contributed to make the draft better.


[quoting smb]

>Wearing my security researcher hat, that's cool -- the attack is
>described in RFC 1191, but I haven't heard of it in the wild before
>this...  (Well, not this attack, but several variants of Path MTU
>attack are mentioned.)

RFC 1191 itself says that you should not increase the assmed Path-MTU in 
response to ICMP "fragmentation needed and DF bit set" error messages.


>Option 1 is clearly correct -- there's no reason to send anything
>larger than the link's MTU.

I think the OP meant the assumed Path-MTU for the connection, and not the 
MTU of the interface. Thus, the advertised Next-Hop MTU could be higher 
than the assumed Path-MTU, but stil lower than the link's MTU.



>But the attacker's response would be to
>oscillate between different MTU sizes.  I suspect that any Path MTU
>message that specifies a higher MTU than what is currently being used
>should be ignored, since it can't legitimately be generated.  In other
>words, Path MTU messages should only be able to lower the MTU, not
>raise it.  Raising it should be done as described in the RFC.  (Aside:
>I haven't looked at our code, so I don't know if that's being done.

This is already specified in the PMTUD specs.


>Option 2 is probably best, but we may want to rethink the table.  The
>current values are based on more-or-less obsolete hardware.

This option does not solve the problem. You can still be attacked. And 
there are packet-radio devices that would ake you support MTUs as low as 
296 or so.

Also, this policy could result harmful. Think about midleboxes that must 
tweak ICMP "fragmentation needed and DF bit set" because a tunnel is in use 
in the path to destination. This would lead to more ICMP blacholes than the 
one we are already dealing with. Please don't do this.

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