[nsp] Path MTU discovery

[Daniel Roesen]

On Mon, Apr 19, 2004 at 07:45:17AM +0200, Oliver Boehmer (oboehmer) wrote:
> > I would think twice about enabling it though, because it makes your
> > BGP and LDP sessions vulnerable to ICMP frag-need-but-TTL-exceeded
> > attacks, where MD5 authentication doesn't help at all.
> 
> Agreed. But the performance gain achieved by it warrents the effort
> protecting your control plane against such and similar attacks.

The problem is that Cisco offers no way to protect against this attack
in a direct way like Juniper does (running BGP over IPSEC). IPSEC
is not available in typical ISP-used trains (S-trains). Applying
IPSEC SAs per neighbor is also more difficult... has to be done via
ACLs.

> BTW: Are such attacks seen in the field?

I've never seen it happen myself, but I guess we will see such
attacks soon being tried in a new wave of interested in TCP flaws.
:-)

> As the "attack window" is pretty short (only a sec or so, while
> TCP opens the connections and performs PMTUD), not sure how
> "attractive" such attacks are.

Classic PMTUD is something _always_ being done. Classic PMTUD means
that all TCP packets are sent with DF bit set and TCP stack always
reacts to ICMP frag-needed-but-DF-set in order to cope with changed
path MTU. So you're attack window is the whole time of persistance of
the TCP session.

There is an effort underway to redefine PMTUD because of two main
reasons: the security (DoS) problem described above, and the general
cluelessness of firewall admins who filter ICMP.

Quote from http://www.ietf.org/html.charters/pmtud-charter.html:

 The proposed new method does not rely on ICMP or other messages from
 the network. It finds the proper MTU by starting a connection using
 relatively small packets (e.g. TCP segments) and searching upwards by
 probing with progressively larger test packets (containing application
 data). If a probe packet is successfully delivered, then the path MTU
 is raised. The isolated loss of a probe packet (with or without an
 ICMP can't fragment message) is treated as an indication of a MTU
 limit, and not a congestion indicator.

I guess Cisco implements classic PMTUD, not the "new style" proposed
here?


Best regards,
Daniel