September 1997 - Test - lists.nanog.org

Re: too many routes
by Sean M. Doran 14 Sep '97

14 Sep '97

"Chris A. Icide" <chris(a)nap.net> writes: > We use ATM for two > reasons, 1) it's still significantly cheaper than long-haul circuits of the > same capacity, My canonical explanation for this is that people are actually deluding themselves into thinking that ABR will work and the "quiet moments" across a large number of VCs can effectively be statmuxed out of existence without hurting goodput. The apocryphal reason is that people with too much influence in carriers' decision making processes are desperately trying to gain enough revenue to justify the ridiculously large amount of money spent on deploying ATM and convincing everyone it was the way the truth and the light of the future, even if that revenue isn't as profitable as selling raw bandwidth. (cf. the canonical explanation) There are cases, however, involving inter-carrier handoffs where muxing at the virtual tributary/virtual container level doesn't work particularly well end-to-end, thus making ATM an alternative to SDH<>PDH<>SDH conversions. These cases are becoming rarer over time as people deploy modern SONET/SDH muxing and terminal equipment. > 2) it provides some interesting abilites that are only > now beginning to show up in the mainstream IP hardware. Ok, I'll bite: which ones? The only ones I can think of right off the top of my head involve the counting problem. (Modulo easy deployment of cisco's rate limiting and/or the ability to make tunnels fast). Rather, I guess the question is, which of the "interesting abilities" (which I agree are interesting in a theoretical sense) are actually practically useful when running part of the Internet? Sean.

5 6

Re: ATM (was Re: too many routes)
by Sean M. Doran 14 Sep '97

14 Sep '97

Steve Goldstein <sgoldste(a)nsf.gov> writes: > At 9:37 PM -0400 9/11/97, Richard Irving wrote: > ... > >Now, the North American Continent is about a 4000 mile trip .... This is > >a VERY ROUGH estimate. > > DARN! And here United has been crediting me with just 24xx Frequent Flier > miles for the trip. I wanna recount! He did say "the North American Continent", and it does get slightly wider farther north. (The Trans-Canada Highway, for example, is 7600 km long, or 4720 or so miles). North America is also very long north-to-south. http://www-nais.ccm.emr.ca:80/wwwnais/select/northamr/english/html/en-a.html gives a decent view of the continent. Don't let your mind be as narrow as the "contiguous" parts of your country. :-) Sean.

2 1

Re: LSR and packet filters
by Sean M. Doran 14 Sep '97

14 Sep '97

"Alex \"Mr. Worf\" Yuriev" <alex(a)netaxs.com> writes: > It is called KISS principle. In computer security it is also called > minimizing possible risk. Cool, as I just recently said, I love learning brand new things from people older and wiser than me. > Well, then he is *WRONG*. Dr Perlman's excellent book, _Interconnections_, ISBN 0-201-56332-0, Addison-Wesley, 1992, is probably the definitive text on routing to that date, and subsequently (désolé, Christian :) ) I would look forward to a new version which would take recent developments in integrated IS-IS for IP (and in IP), BGP with all its many new features, IDRP, and the specification of NIMROD into account, since Dr Perlman is not only very informative but also a fun read. > 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". The latter group are lazy. The former group has lazy people too, but it also has people who use rather neat encryption on the physical transmissions layers to prevent people with vampire taps, microwave interceptors, or little satellite dishes eavesdropping or forging traffic. However, security at the physical layer, as with security at the next two or so transport layers, is non-transitive. You do not become more secure because you scramble the bits inside your IP datagram than when you scramble the bits in your TCP segment, and you make it harder to scale using NATs and ALGs, which are the fundamental building blocks of the growing Internet. You also make it less possible to be fair using Van Jacobson's excellent pleas to implement profile enforcement towards the edges, or indeed, to implement anything like RED/WRED/WFQ along parts of the path between two endpoints scrambling everything inside IP datagrams. Moreover, scrambling *all* communications or authenticating *all* communications (thus preventing things like Vixie's and Cisco's various web-query-redirection software from working correctly) is an insane waste of CPU time. Consequently, encryption and authentication *is* something you want explicitly turned on by applications, and if possible it should generate sane (if not necessarily transparently descriptive) TCP headers. Implementation details are up to you host people types. Throwing it back at network operators is silly. Our market is in getting traffic around, not in solving people's security problems (as if any solution proposed or implmented by any ISP or set of ISPs would really seriously be believed to be secure anyway). > Face it, the security of any chain is equal to security of its weakest > link and currently that link is not host security. Yah, multiuser systems are really secure. > > 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. Ticket stealing is an old game. All you need is the right file permissions and decent timing (it's usually a big window). Ran Atkinson mentioned that K5 doesn't give him particularly warm fuzzies. I'm sure you could ask him some of his reasons, and get a lucid explanation of them. He's bright, even if I don't find myself liking the IPSEC model very much. > While disabling LSR does not make network equipment more robust, it > prevents a series of very interesting attacks including DOS attacks > against that equipment. Which of those denials-of-service are not implementation dependent, where the implementation generally is now fully end-of-line Cisco 7000+RP or RSP-only equipment? > > 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? Mostly because SNMP is a bad misdesign compared to earlier efforts before SNMP's standardization, and the ability to dig out what you really need to know is sometimes more challenging using SNMP than observing TCP timings and using hacks like provoking ttl exceededs. > I think the answer to this question is simple - such ability would > conflict with a security policy I have trouble understanding why infering things about the path, for instance, the amount of congestion, the round trip times, the behaviour of queues, and so forth gets in the way of security policies, but people who believe that are, of course, more than welcome to use ALGs and firewalling techniques to prevent access to their networks. Remember, the point is that only people authorized to use your network should have access to the things you seem to think are possibly heavy secrets. If you don't want random people finding these things out, you don't let random people use your network. It's quite simple. However, if you do let random people use your network, you probably should not cripple your own use of that connectivity by doing stupid things in the name of some slightly additional warm fuzzy security. Sean.

1 0

Re: too many routes
by Sean M. Doran 14 Sep '97

14 Sep '97

Alan Hannan <hannan(a)bythetrees.com> writes: > > Sprint recently announced that they are deploying 622Mbps > > POS cross-country links, and the GSRs are the only things > > you can put on the ends of such beasts that are available > > today. > > This is untrue. Other people have pointed out that the statement is perfectly true, but we can ignore the semantic misunderstanding. AFAICT there is only one orderable, deployable and tested IP router which observably terminates multiple 622-Mbit/s bit pipes, notably that made by cisco. One thing I find amusing is your own company's recent heavy investment in cisco's only likely competitor. Maybe this will mean cisco will stop paying so much attention to the ridiculous requirements UUWHO coughs up because it insists on a heavily meshed architechture for what has since become essentially purely political reasons, and start paying attention to people who are building sensible hierarchical networks that display much better scaling properties on nearly all fronts. (I hope so). Maybe this will also make people shy about helping Juniper because that translates directly into helping UUWHO as well. Who knows, maybe such things aren't so important, especially since the cisco product a/ works and b/ is *cheap*. > These can be disaggregated into OC3 ATM pipes that can be fed into > many routers with proven technology and reliability. Granted, the > disproportionality of the edge ckts to the backbone ckts provides > for interesting flow aggregation dynamics, but it does work. Oh sure it works if you turn LS IGPs on their head and try to avoid thinking too hard about how to build spanning trees without building a physical VC topology for multicast and can put up with interesting buffering and switching effects and, as you say, the dynamics of WHY it works vs. why it doesn't work when things break. I hate to say it but I think I have become old and this might explain why I like really simple and straightforward failure modes. > Your disdain for ATM does not stop its existence and use by the > larger NSPs. Technical merit has only been offered up as a reason for using cells by your organization and ATMNET, AFAIK. Everyone else who has been using ATM has done so because it was one of only three obvious scaling paths, with the other two being also gross (large numbers of parallel DS3s using load-balancing and flattening the network with lots of DS3s resembling lots of VCs, which is essentially what UUNET did with its physical topology anyway). > Aggressive statement, though the timbre is occasionally marked by > usefulness. I wonder how the world would develop without Sean's > input..... {music, clouds, harps... visions of ATM faeries > dancing with sugarplums...} Hahah. Well, don't forget the Russian and the Swede who also sang from the same songbook, and the other congregation members who were at NANOG meetings when everyone was angry at the BELLCORE twits prior to the NSFNET wind-down (hi Curtis). Many of the people who did actual engineering work at cisco were also not very agnostic when it came to cells, and had an effect on the company, which is one of the reasons I have always liked cisco compared to its competitors, who were not quite agnostic either but in the opposite direction. > There is another router vendor who has OC-12 router interfaces > about ready for production. Another (#3) is expected to release a > bang-up product real soon now. As Peter Löthberg pointed out, there are BFRs in production right now. Sprint is also not the only vendor who is using them to move traffic, although the majority of other users are currently using the BFRs as really fast star-shaped LANs, essentially. (I expect this to change very soon) > There is a choice in the market today for OC12 router interfaces. Not today there isn't. Maybe next month. There may be choice in what you can put at the end of an OC12 though, but it's either something smart or something you'd find at Hobson's Tavern. Sean.

2 1

Re: LSR and packet filters
by Sean M. Doran 14 Sep '97

14 Sep '97

rja(a)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.

2 1

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 13 Sep '97

13 Sep '97

Avi Freedman <freedman(a)netaxs.com> writes: > The danger with this approach is, obviously, that the router that you > try to do this to can go away. In which case you shoot yourself in the > foot. Some day, someone will send me a valid use of 'set ip next-hop' > but I haven't seen a good one yet. I believe initially it was dropped into route-maps to deal with situations involving having three different ASes share a broadcast LAN in Washington D.C. as an internal link. (AS 1239, AS 1790, both sharing a single IGP instance, AS 1800 with a different IGP instance, to be specific. Running two independent iIS-IS instances on a single wire was fun too.) FSVO "valid use", but it did make things work. Sean.

1 0

Re: not rewriting next-hop, pointing default, ...
by Sean M. Doran 13 Sep '97

13 Sep '97

"Alex.Bligh" <amb(a)xara.net> writes: > Failing this, the ability to disable responding to packets (*) > with source route set on the Cisco *host* TCP/IP stack > (and continue to forward them), Mourn the death of TUBA telnet... :) What you might want is to make sure that management functions can only happen over a separate private IP network. This has been a long-time engineering goal of one network at some priority or other. Then, some protection for routing protocols to make them both more robust and more secure, and life is a bit nicer. (Although taking an axe to all the routing protocols in use today has a strong appeal, actually, but that'll come later...) Unfortunately, though, in the absence of a method to query routers about their forwarding (i.e., "what would you do with this traffic profile?"), route calculation and NLRI redistribution policies, any tool which can help infer that from anywhere in the Internet is of use. I hate traceroute, I think it's a dreadful hack, and it is really hard to use it correctly for all sorts of reasons, lots of them having to do with the observer problem. LSRR helps enormously, and has been of critical use in the past. Killing it off to provide some warm fuzzies to operators who are still going to be exposed to lots of serious attacks on their routers and hosts strikes me as nearly as unreasonable as simply turning off routers and encasing them in concrete to make them safe. What would be REALLY nice is if lots of new hardware and software that doesn't keel over dead or use a really slow path to forward packets decorated with the LSRR option were deployed in everyone's networks. Sean.

1 0

Re: switching versus routing ATM redux
by Vadim Antonov 13 Sep '97

13 Sep '97

>> Who is Richard Irving? > >Tim Bass with a new spelling? Thanks, Sean. I'm curious if anybody knows why abundance of ellipsis in text is such a good indicator of TBism? You can make a five-liner bogon rejector based on the phenomenon, and in most cases it'll work wonderfully. --vadim PS Now, don't argue that bogon filtering is irrelevant to NANOG. Get a life :)

1 0

Re: switching versus routing ATM redux
by Sean M. Doran 13 Sep '97

13 Sep '97

Richard Irving <rirving(a)onecall.net> writes: > Who is Richard Irving? Tim Bass with a new spelling? > It is sort of an obsession of mine Wow, good guess, Sean. Sean.

1 0

Re: switching versus routing ATM redux
by Richard Irving 13 Sep '97

13 Sep '97

On Sat, 13 Sep 1997, William Allen Simpson wrote: > Wading thru the flood in the past two days, I was wondering why Carmen > Hillenburg <carmenh(a)onecall.net> is answering Richard Irving > <rirving(a)onecall.net> email? My significant other used my email while I was at work ;> > > Thus, ATM takes more bandwidth (is slower) and more cell switches (is > slower), cumulatively at every hop. Slower is slower is slower.... > Interesting note, I think all cross country timing data coming in is across ATM paths. Anyone have HSSI ? Regarding the deluge. It started when someone said, "Ok, what advantage does ATM have that IP doesn't" and I named 2. It started a Holy war. I had no Idea... Chris, I may never respond to you again.... ;) However, it is dragging to an end. *phew* We will know a fairly close representation of the ratio of overhead to cross the country, vs the speed of light ;). We have had input from some of the more interesting people in the field. And many interesting , yet *differing* views, yours is yet another. I would have stopped it long ago, but I felt obliged to at least answer. It is sort of an obsession of mine to make the data I *see*, correlate with the information the experts in the industry are offering...... Who is Richard Irving? No one! Just a tech like you, tasked with "The Net". Our company is an IXC, we run a hybrid-exchange (Giga-POP), and also carry our own ATM and IP circuits. (Routers, ATM Switches, IP Switches, and Telco:(ISDN/Pots) Switches.) We have a couple thousand T's around the country , (not all ip ;( ), Lots of "Hot glass" (up to OC48), and clean circuits. (Bandwidth Heaven) We buy/sell pipe from MFS, TWarner, Ameritech, etc.. And provide advanced communications to customers: U.S. based ATM, IP, LD, LDIP, and Frame. We function primarily as a bandwidth/advanced communications *wholesaler*, so you don't hear of us much. We are a C based shop, and also provide "Custom" Data services to the Carrier/Communications industry. Want a brochure? : mailto://techsale@onecall.net, or mailto://techsale@indyx.net as I am beginning to sound too much like a salesman for comfort. ;) No one, Just a tech who has to deal with so many technologies throughout the course of a week, that I begin to "bleed over" acronyms, and confuse everyone when I post ;) But, I am a member of NANOG, I think that counts! ;) Richard

1 0