Access to the Internic Blocked

Curtis wrote:

>I've said many times that if security in your network is weak enough
>that you need to worry about LSRR packets you need to worry about
>security in your network.

Not at all. LSRR is a nice tool to mount practically untraceable
flooding attack (hint -- just forge source address and spread
intermediate points evenly across the network). Shutting you
down may be exactly what the attacker wants.

Oh come on. Like they're not going to get caught stuffing an entire
T1 with LSRR packets. Face it. You're grabbing at straws.

Besides the fact that with your suggestion of traceroute using ICMP
echo requests they'd just send a T1s worth of ICMP echo requests with
LSRR and accomplish the same thing.

There are particularly nasty man-in-the-middle attacks (which
defeat one-time-password login authentication, like that) if you
can combine LSRR with bogus routing.

Who said one time passwords were secure. Kerberos mutual
authentication with encrypted payload is my choice. Some people
prefer SSL. AFS is nice if you can afford it. Skey just doesn't cut
it. Skey is only slightly better than passwords in the clear.

Besides, man in the middle is really easy if you're already on the LAN
due to the guy that just unpacked his first Sun workstation. Much
easier to do than LSRR with bogus routing.

I never argued that blocking LSRR plugs all security holes. However
it is one thing _not_ used in normal operations; and everything not
used _must_ be shut down by a prudent security. And, again, there
are several LSRR-based attacks.

LSRR is just too useful for diagnosing network problems to shut down
on a backbone.

If you want to be secure, have your security group assume someone has
already broken onto your local LAN segment. Explain how he would be
prevented from any further breach and how his unusual activities would
be quickly detected and dealt with. For example, we don't run certain
common services so any activity on these ports is automatically logged
as unusual.

Packet filters and disabling LSRR where you have NM machines and other
network operations machines that can't be behind firewalls are just
another barrier but mostly for alarms and audits for post mortems.


Curtis Villamizar <> writes (to Vadim Antonov):

Oh come on. Like they're not going to get caught stuffing an entire
T1 with LSRR packets. Face it. You're grabbing at

Can I grab at one too?

I'd love to see LSRR (and SSRR) dead because it
slows down single-path forwarding considerably,
and complicates fast-path/slow-path systems in
gross ways for what I believe is minimal added utility.

Some folks may have run across more uses for one
or the other that involve more than 'traceroute -g'
or 'telnet @foo:bar', both of some utility, I suppose,
but one is easily replaced with application-level
proxying, and the other is just weird. Or vice-versa.

Of course, I don't have a religious feeling about this,
since I try to persuade my vendor(s) to supply routers
which can handle tiny Christmas-tree packets (those that
are fully decorated with options) at line speed without
loss. Then again, I work for a company with deep pockets
that can afford what it takes to buy per-packet time
budgets that can satisfy that kind of design criterion...

(Others may want to consider encouraging people to keep
fast Internetworking cheap by using things like MTU
discovery and getting rid of things like IP options)