Re: LSR and packet filters

[Vadim Antonov <avg () pluris com>]

Sean M. Doran wrote:

> The denials-of-service are generally driven by poor
> implementation of networking software, much of which has
> been corrected.  

Sean, that only goes to show that belief in quality software
seems to be endemic to tomato-growing countries located far
from places where software is actually written :)

> Moreover, in the case of LSR-using
> source-forged attacks, tracing becomes *easier* because
> you need only trap on LSR traffic and work backwards.

There's fauly logic in this statment: catching LSR 
traffic is easy as long as LSR is not being widely used.
And vice versa.

> > Useful for what?  traceroute -g  is the _only_ useful
> > application for LSR.  Disabling LSR and adding an application
> > level service for tracing back would be just as useful.
>
> There are several people here who have mentioned on and
> off that LSR telnet is extremely handy to them.

Yep. To defeat other people's routing policies.  How handy.

Now, i'd call that cracking.  I certainly would use LSR
telnet to get around unannounced route only with recognition
that it is ethically equivalent to using sniffer to get 
around not knowing a root password.

> If you could send traffic using LSR and pay less severely
> for using the option in older routers, then I can think of
> several applications for sending lots of traffic with the
> LSR option toggled at the source.  I can equally think of
> useful applications for SSR.

I'd like to hear about any useful application of SR in production
traffic.
 
> SA filtering is more useful than disabling LSR.

No argument here.  But totally deployed SA filtering is
no more realistic than perfect aggregation.  In other
words, why a SCUMNET would care to protect others?
 
> What does the additional disabling of LSR on top of
> ubiquitous source address filtering buy you really?

Ubiquotus SA filtering?  Did you borrow the stuff from Vint?
 
In any case, besides forged SAs, LSR allows uncontrollable 
overriding of routing policies.  As a network admin you don't
want customers to do that en mass.
  
> If I had a BFR up and running, this would make an
> interesting test to prove the design point of handling
> fully-decorated micropackets at line rate across fully
> half of all the interfaces in a fully-decked-out box.
> Talk to Peter about beating on one of his, or come back to
> me and BC in a couple weeks.
>
> (It would be equally interesting to beat on a fully decked
> out 75xx box with modern VIPs and dFIB, I guess.  We both
> already know what happens when you even sneeze funny in the
> presence of an RP, although SPD is pretty cool at avoiding
> the "gee your router is unavailable" problem.)

Why should i care?  I'm not working for cisco.

BTW, handling fully-decorated micropackets is rather irrelevant
to eradicating the DoS vulnerabilities i had in mind.

--vadim