> 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.
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),
Mourn the death of TUBA telnet...
What you might want is to make sure that management
functions can only happen over a separate private IP
network. This has been a long-time engineering goal of
one network at some priority or other.
Then, some protection for routing protocols to make them
both more robust and more secure, and life is a bit nicer.
(Although taking an axe to all the routing protocols in
use today has a strong appeal, actually, but that'll come
later...)
Unfortunately, though, in the absence of a method to query
routers about their forwarding (i.e., "what would you do
with this traffic profile?"), route calculation and NLRI
redistribution policies, any tool which can help infer
that from anywhere in the Internet is of use.
I hate traceroute, I think it's a dreadful hack, and it is
really hard to use it correctly for all sorts of reasons,
lots of them having to do with the observer problem. LSRR
helps enormously, and has been of critical use in the
past. Killing it off to provide some warm fuzzies to
operators who are still going to be exposed to lots of
serious attacks on their routers and hosts strikes me as
nearly as unreasonable as simply turning off routers and
encasing them in concrete to make them safe.
What would be REALLY nice is if lots of new hardware and
software that doesn't keel over dead or use a really slow
path to forward packets decorated with the LSRR option
were deployed in everyone's networks.
% Then, some protection for routing protocols to make them
% both more robust and more secure, and life is a bit nicer.
IMHO, any serious network operator using OSPF or BGP should
have already deployed the techniques below (as applicable):
OSPF with Keyed MD5 Authentication
BGP-4 with the Keyed MD5 Authentication extension
as a TCP option.
WRT ISIS, lack of a CLNP infrastructure limits the ability of
outsiders to attack a network. Nonetheless, ISIS should probably
also get some kind of cryptographic authentication extension.
IMHO, any serious network operator using OSPF or BGP should
have already deployed the techniques below (as applicable):
OSPF with Keyed MD5 Authentication
BGP-4 with the Keyed MD5 Authentication extension
as a TCP option.
Well, it does not protect against the threat #1 -- namely source
of perfectly good-looking but bogus routes.
In fact, cryptography is not the best (or most useful) solution
for protecting routing infrastructure from barge-in attacks.
The real solutuion is very simple -- the packets carrying routing
data should _not_ be routable. ARP is a good example.
Unfortunately the present braindeadedness of IGPs which makes
kludges like iBGP hack necessary makes multihop routing of
network control information inevitable. I would say we should
concentrate on fixing the original problem, not trying to patch
holes in the broken-as-designed architecture.
WRT ISIS, lack of a CLNP infrastructure limits the ability of
outsiders to attack a network. Nonetheless, ISIS should probably
also get some kind of cryptographic authentication extension.
Heh. CLNP is quite widely routed. At some point it was very
useful as a way to defeat access-filter based protection in
ciscos (that was fixed, though).
