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 inconvinient. Best wishes, Alex ----------------------------------------------------------------------------- Alex "Mr. Worf" Yuriev Nationwide ISP Bandwidth: [www.netaxs.net] Net Access Outsourced News Reading: [www.newsread.com ] alex@{netaxs.com|yuriev.com} Outsourced Shell Accounts: [shellaccounts.com] RIP is irrelevant. Spoofing is futile. Your routes will be aggregated. -----------------------------------------------------------------------------