Re: LSR and packet filters

["Alex \"Mr. Worf\" Yuriev" <alex () netaxs com>]

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

It is called KISS principle. In computer security it is also called
minimizing possible risk.

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

Correct. Fortunately, this does not mean that one should give up on it.

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

Well, then he is *WRONG*. Authentication and privacy should be a function
of the network layer, not the application layer because it is a lot easier
to attack application layer encryption compared to lower layers.

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

I think it is funny that network operators say "It must be done at the
application layer because otherwise my network won't scale" while
people that deal with applied crypto say "Are you nuts? Why do you want to
make every application utilize its own cryptographic method? You are
creating a weakness".

Face it, the security of any chain is equal to security of its weakest
link and currently that link is not host security.

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

Since when is that the case for Kerberos? Only if you compromise the KDC
you break security of the model. As ssh does not have any 3rd trusted
party that verifies credentials, it is definitely a case for ssh. Earlier
versions of it had some very interesting properties that could under
certain conditions have been used to impersonate a client and a server.

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

While disabling LSR does not make network equipment more robust, it
prevents a series of very interesting attacks including DOS attacks
against that equipment.

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

So why don't we all have at least SNMP access to the routers of those
networks? A lot of people would surely want to what is going on inside
there? 

I think the answer to this question is simple - such ability would
conflict with a security policy

Alex