LSR and packet filters

Alex "Mr. Worf" Yuriev alex at
Sun Sep 14 06:22:08 UTC 1997

On Sat, 13 Sep 1997, Randy Bush wrote:

> > 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.
> Vadim.  I am just a stoopid operator with a network to run.  I am not at all
> cheered by trading a tool that works for a theory that could be designed and
> implemented some day.

I hate to spoil this nice "but it works" line but the reality is that
enabled LSR is dangerous, therefore unless it is required for day-to-day
operations, it should not be enabled. The line "that allows me to see what
is going on in routers of my peers" is not something that could be
considered acceptable based on a security policy. 

Randy, would you mind giving your peers access to your routers so they can
see how you configured your own routers just to make sure that it is
configured "right"? No? Why not? It is because you consider that they do
not need to know how you route traffic on your backbone? 

> Until inter-NOC operation is facile, we have few tools for debugging inter-
> provider routing problems.  So we use what we have although we realize that
> they have flaws.

That is up to the NOC you deal with. Just because you decide that you want
them to do it that way, does not mean that their security policy allows
them to do it. 

As far as attacks that utilize source routing go, as soon as I finish the
Wargames tutorial for NETSEC97, I would be glad to take a day and write a
complete description of how to make life of networks with LSR enabled very

Best wishes,

Alex "Mr. Worf" Yuriev         Nationwide ISP Bandwidth:  []
Net Access                     Outsourced News Reading:   [ ]
[email protected]{|}   Outsourced Shell Accounts: []
   RIP is irrelevant. Spoofing is futile. Your routes will be aggregated.

More information about the NANOG mailing list