|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: LSR and packet filters
Sean M. Doran <[email protected]> wrote: >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 :) >> 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
|