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