[nsp] Path MTU discovery

[Oliver Boehmer (oboehmer)]

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

Yes, ACLs are a way to do it. But anti-spoofing ACL at your edges along
with a receive-ACL/Control-plane-policy permitting only ICMP-frag-needed
from your own core addresses should do it just fine for most cases.

> 
> > 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 your attack window is the whole time of persistance of
> the TCP session.

I stand corrected, misread the code (was too early in the morning ;-). 
 
> I guess Cisco implements classic PMTUD, not the "new style" proposed
> here?

yes, as far as I can tell.

	oli