Access to the Internic Blocked

Curtis Villamizar curtis at
Fri Aug 23 04:18:48 UTC 1996

In message <199608230202.TAA00281 at>, Vadim Antonov writes:
> 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.


More information about the NANOG mailing list