Re: not rewriting next-hop, pointing default, ...

On Sep 11 15:54, Randy Bush wrote: } Subject: Re: not rewriting next-hop, pointing default, ...
LSR is actually a significant security issue. So, while I do understand and am sympathetic to the operational debugging issues that LSR addresses, I think that requiring a peer to enable LSR more than 2 hops inside their network from the outside world is unreasonable.
% So, you're comfortable with asking for LSR at the IX and a hop behind? "Comfortable" isn't the word I'd choose. Ideally, I'd filter out LSR entirely [1], but there are real operational issues. Letting LSR in two hops lets outsiders trying to debug (e.g. some routing problem) at least perform first-level fault-isolation so they know whose NOC to call for further debugging assistance. So I view the 2-hop notion as an attempt at "reasonable compromise".
In a world where SSH were available in cisco routers and/or IPsec were more widely deployed, I might have different views.
% K5 does not give you sufficient warm fuzzies? No, I'm afraid that Kerberos 5 doesn't give me sufficient warm fuzzies. I don't care to be very detailed on a public list such as NANOG. I will note that aside from my non-public concerns, Kerberos-5 is expensive to deploy and maintain. Kerberos can also adversely impact network availability if it isn't installed in exactly the right way (surprisingly few folks seem to do it right). Ran rja@home.net [1] DISCLAIMERS: - I'm not a security expert, so my opinion probably doesn't mean very much in the grand scheme of things. - I am NOT with @Home's Security Group, which is ably managed by Mike StJohns, who is a Security Expert. So don't blame them for my comments. - I don't make policy for @Home, so my opinions are just mine not my employer's. - I haven't had enough coffee yet today. :-)

In a world where SSH were available in cisco routers and/or IPsec were more widely deployed, I might have different views.
Failing this, the ability to disable responding to packets (*) with source route set on the Cisco *host* TCP/IP stack (and continue to forward them), would allow it to be easilly enabled in your core, and filtered at borders with machines and vulnerable equipment attached. IE you filter out such packets as part of your normal firewalling. This would prevent the telnet to Cisco with LSR poblem. Thus traceroute -g would give you the useful information, then star out if you were tracing to (say) www.uu.net. (*) - urm, except responding to traceroutes etc. :-) Alex Bligh Xara Networks
participants (2)
-
Alex.Bligh
-
rja@corp.home.net