LSR and packet filters

Sat Sep 13 21:23:50 UTC 1997

rja at corp.home.net (Ran Atkinson) writes:

> A reasonable security policy is focused on maintaining
> network availability and uptime.

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?

Turning off a useful but under-implemented network service
because it might be used to spoof the network origin of
management instructions or routing information misses the
point that the network origin is a really poor proof of
validity of the messages or authority to issue them.

Moreover, the under-implemented service itself may improve
the security of communications between end systems.

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".

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.

However, maybe this isn't so surprising as I've seen you
support another incredibly braindamaged security scheme
that trades off scalability of the Internet in general 
for some degree of security between end systems.

The problem isn't one of ES-to-ES security but one of
endpoint to endpoint, where the ultimately the endpoints
are the data generators and receivers (human or
automation) who communicate through the end systems.

The lesson of Kerberos and SSH and so forth is that
ES-to-ES security is useless if one of the ESes itself is
compromised.

> If one focuses exclusively on diagnostic tools, one's
> network will be down much more often than if one strikes
> a reasonably balanced overall perspective on things.
> All IMHO.

But at least you will know WHY your network went down, and
might be have enough information to get it back up again,
and prevent the same thing from happening again.  --:)

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.

> 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.

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

I would agree with you if you modified your note to,
"it is no business of anyone not authorized to use a
network what that network looks like beyond how it
presents itself externally", although this is incomplete
because it doesn't preclude marketers telling whopping
lies to potential authorized users.  (caveat emptor? :) )

> The only _legitimate_ need of a peer is to be able to
> isolate the problem to one's network (or someone else's
> network) so that the peer can then come after one (or
> one's NOC) to fix the problem(s).

Again, networks exist to benefit users.  The need of the
aggregate of networks called the Internet is to make users
happy, and usually involves more than "oh it's *their* problem".

Tools to provide meaningful diagnoses of ES-to-ES
connectivity that users can run on end systems is
work-reducing for network operators, particularly as those
network operators obviously would have access to the same
tools.

> So I'm not trying to kill off LSR as a diagnostic tool, merely
> limit the downside operational risks of LSR to a reasonable
> level.  The ultimate goal of my proposal is to _enhance_
> network availability.

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{

	Sean.