LSR and packet filters

Mailman List Mirror (Read Only)
1

How does a security policy of "turn off LSR handling" translate
into anything other than an admission of completely
missing the point that one should never ever ever ever
trust any data based soley on where the network leads one
to believe it has come from?

Hey, LSR is useful for all kinds of very interesting
denial of service attacks. A clever combination of LSR and
forged source addresses may make the attack virtually
untraceable.

Turning off a useful but under-implemented network service...

Useful for what? 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.

Quoting Radia Perlman:

"The goal is to design a network that will guarantee that
a packet transmitted between two nonfaulty end systems A
and B will have a high probability of being delivered,
provided that at least one path consists of nonfaulty
components connects the two end systems. [...] The
network layer makes no attempt to keep conversations
private. If privacy is necessary, encryption must be
done at a higher layer. Also, the network layer need not
certify data that it delivers. For instance, it is
possible for some malicious node C to generate data, get
it delivered to B, and claim that the data was from A.
It is up to the higher layer in B to differentiate
between corrupted or counterfeit data and real data,
using known cryptographic techniques".

Encryption is an overkill for 99% of all applications. Disabling
LSR and doing SA filtering can take care of _most_ security
problems. And it is computationally cheap.

The proposal to turn off LSRR is a tremendously incomplete
proposal to have the network certify the validity of the
origin, at the cost of some additional utility and
robustness from the point of view of end systems.

I would wholeheartedly agree with that proposal, if some
useful substitute for traceroute -g is provided.

This will not make the network absolutely secure (there ain't
no such thing as absolute security), but it definitely will
make it _more_ secure.

In any event I don't think that disabling LSRR in any way
makes networking equipment more robust, and that is what
you appear to be arguing.

To make equipment more robust you may want to use gold-plated
connectors, have redundant power, etc. I love playing
dumb :slight_smile:

I will note that its none of someone else's business what
one's internal topology looks like.

Sure it is. Or rather, it is useful to be able to infer a
number of path characteristics between two communicating
endpoints for such things as flow control and route
selection.

That should be a matter of preference. Knowing network
topology of a large corporation can give tremendous amounts
of information about the corporation's structure and
give clues to what projects the company's working on.
Connection analysis is an old and venerable intelligence tool.

Networks and computers exist to offer services to users,
and obscuring information that makes service use or
selection difficult is a poor policy.

Hey. What information to disclose should be a voluntary
choice.

How does LSR reduce network availability except in the
case of implementations that slow-switch option-ridden IP
datagrams and have no equivalent of SPD, or intermediate
systems (gee, it's OSIspeek day, isn't it?) that don't
use reasonable means to authenticate and keep private
things like routing information exchanges or management sessions{

How'd you like to get a stream of nasty bogons aimed at
your router(s) and arriving from virtually all directions?
There's a number of ways to kill ciscos with pretty low-rate
streams.

--vadim

2

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.

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.

Not to discourage you and others from developing better tools. Please!

randy

3

> 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

4

Vadim Antonov <avg@pluris.com> writes:

Hey, LSR is useful for all kinds of very interesting
denial of service attacks. A clever combination of LSR and
forged source addresses may make the attack virtually
untraceable.

The denials-of-service are generally driven by poor
implementation of networking software, much of which has
been corrected. Moreover, in the case of LSR-using
source-forged attacks, tracing becomes *easier* because
you need only trap on LSR traffic and work backwards.

What is *hard* is source-forged attacks which are in
profile and option-free.

Useful for what? 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.

There are several people here who have mentioned on and
off that LSR telnet is extremely handy to them.

If you could send traffic using LSR and pay less severely
for using the option in older routers, then I can think of
several applications for sending lots of traffic with the
LSR option toggled at the source. I can equally think of
useful applications for SSR.

Encryption is an overkill for 99% of all applications.

No argument here. :slight_smile:

Disabling LSR and doing SA filtering can take care of
_most_ security problems. And it is computationally
cheap.

SA filtering is more useful than disabling LSR.
What does the additional disabling of LSR on top of
ubiquitous source address filtering buy you really?

This will not make the network absolutely secure (there ain't
no such thing as absolute security), but it definitely will
make it _more_ secure.

So will turning it all off, the ultimate in the utility vs
security trade-off.

How'd you like to get a stream of nasty bogons aimed at
your router(s) and arriving from virtually all directions?
There's a number of ways to kill ciscos with pretty low-rate
streams.

If I had a BFR up and running, this would make an
interesting test to prove the design point of handling
fully-decorated micropackets at line rate across fully
half of all the interfaces in a fully-decked-out box.
Talk to Peter about beating on one of his, or come back to
me and BC in a couple weeks.

(It would be equally interesting to beat on a fully decked
out 75xx box with modern VIPs and dFIB, I guess. We both
already know what happens when you even sneeze funny in the
presence of an RP, although SPD is pretty cool at avoiding
the "gee your router is unavailable" problem.)

  Sean.

5

Sean M. Doran wrote:

The denials-of-service are generally driven by poor
implementation of networking software, much of which has
been corrected.

Sean, that only goes to show that belief in quality software
seems to be endemic to tomato-growing countries located far
from places where software is actually written :slight_smile:

Moreover, in the case of LSR-using
source-forged attacks, tracing becomes *easier* because
you need only trap on LSR traffic and work backwards.

There's fauly logic in this statment: catching LSR
traffic is easy as long as LSR is not being widely used.
And vice versa.

> Useful for what? 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.

There are several people here who have mentioned on and
off that LSR telnet is extremely handy to them.

Yep. To defeat other people's routing policies. How handy.

Now, i'd call that cracking. I certainly would use LSR
telnet to get around unannounced route only with recognition
that it is ethically equivalent to using sniffer to get
around not knowing a root password.

If you could send traffic using LSR and pay less severely
for using the option in older routers, then I can think of
several applications for sending lots of traffic with the
LSR option toggled at the source. I can equally think of
useful applications for SSR.

I'd like to hear about any useful application of SR in production
traffic.

SA filtering is more useful than disabling LSR.

No argument here. But totally deployed SA filtering is
no more realistic than perfect aggregation. In other
words, why a SCUMNET would care to protect others?

What does the additional disabling of LSR on top of
ubiquitous source address filtering buy you really?

Ubiquotus SA filtering? Did you borrow the stuff from Vint?

In any case, besides forged SAs, LSR allows uncontrollable
overriding of routing policies. As a network admin you don't
want customers to do that en mass.
  

If I had a BFR up and running, this would make an
interesting test to prove the design point of handling
fully-decorated micropackets at line rate across fully
half of all the interfaces in a fully-decked-out box.
Talk to Peter about beating on one of his, or come back to
me and BC in a couple weeks.

(It would be equally interesting to beat on a fully decked
out 75xx box with modern VIPs and dFIB, I guess. We both
already know what happens when you even sneeze funny in the
presence of an RP, although SPD is pretty cool at avoiding
the "gee your router is unavailable" problem.)

Why should i care? I'm not working for cisco.

BTW, handling fully-decorated micropackets is rather irrelevant
to eradicating the DoS vulnerabilities i had in mind.

--vadim

6

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.

No? Why not? It is because you consider that they do not need to know how
you route traffic on your backbone?

No.

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.

Not a problem, as I do not have to peer with them.

randy