- Test - lists.nanog.org

The Cidr Report
by Tony Bates 19 Sep '97

19 Sep '97

1 0

Routing without source information and Traffic self-similarity
by Nathan Boyd 19 Sep '97

19 Sep '97

Hello all, I would appreciate any help with the following. First, what problems arise in a network that routes without information about the sender? In other words, imagine that the IP header did not contain the source address - what problems would this raise? Are optimal routing, security, billing, traceability, network management, etc., suddenly intractable? Second, to what degree do you believe Internet traffic exhibits self-similarity, and how does this change with varying levels of traffic aggregation? I have read papers from Bellcore and others suggesting that no matter the level of aggregation (be it a single Internet user or a major NAP), Internet traffic exhibits high degrees of self-similarity - but more recent research does not seem to agree with this. I am sorry if this is an inappropriate forum for the topics I have raised, however after reading through this list for some time it is apparent that we have assembled here a good deal of real-world experience, something I believe is requisite for a meaningful discussion of real-world network issues. Very interested to hear what you have to say, Nate Boyd MIT Laboratory for Computer Science

3 2

Test....
by Huohom 19 Sep '97

19 Sep '97

Test....

1 0

Re: LSR and packet filters
by Vadim Antonov 19 Sep '97

19 Sep '97

Sean M. Doran <smd(a)clock.org> 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

3 3

Re: Traffic Engineering (fwd)
by shields＠crosslink.net 19 Sep '97

19 Sep '97

In article <ytafhal5xz.fsf(a)cesium.clock.org>, "Sean M. Doran" <smd(a)clock.org> wrote: > Why? ping and traceroute are poor predictors of locality > and available bandwidth between the originator and target > of those tools. You can get an interesting set of data by sending a few rounds of pings of different sizes. Make a scatterplot of ping packet size vs. delay and find the line that fits the data; its slope represents the inverse of available bandwidth and the y-intercept represents the raw latency. Standard deviation gives you an idea of congestion. Is it crude? Yes, but I don't know of anything better. Is it ugly? Yes, but no uglier than traceroute. This isn't my idea; I saw it in "bing". Once you have a metric coded up, you can have each potential data source measure the quality of their connectivity to the endpoint. After they have agreed amongst themselves (probably via an intermediary server) which server is best they can cause the session to be moved to the most probably optimal server. -- Shields, CrossLink.

1 0

Re: Traffic Engineering (fwd)
by Sean M. Doran 19 Sep '97

19 Sep '97

Avi Freedman <freedman(a)netaxs.com> writes: > The cyclic stuff in News recently has hammered home that the search > for elegance pays off. I "initially" solved the problem of having > multiple machines with the same IP by postulating IP-stack hackery > involving forwarding any packets that come in for sockets that > don't exist to a central database-forwarder machine that keeps track > of all open tcp sessions on all replicated machines, but it turns > out that there are some much easier non-stack-hackery-mandatory > solutions. Your approach also is not a neat solution for two further reasons. Firstly, it requires maintaining connection state for all connections on a central repository, and secondly, it requires that your network be stable at the point when a connection needs to migrate. You should be able to deal with the case that during the lifetime of a TCP session something causes traffic that was hitting site A suddenly arrive at similarly-numbered site B at a time when connectivity within your network is unstable. (This likely can be done with tunnels, following the NAT approach, if synchronization is between things located at the edges of your network, rather than in a star pattern from something inside your network). You should also avoid scaling limits inherent in dumping lots of traffic at some central host rather than doing content-driven fail-over checkpointing for bulk data transfers from "static" content. Sean. P.S.: do you go about guaranteeing that you have unique connection "names" across all your simliarly-numbered hosts?

3 2

Re: Traffic Engineering (fwd)
by Sean M. Doran 19 Sep '97

19 Sep '97

Avi Freedman <freedman(a)netaxs.com> writes: > We at Net Access have figured out a way (we believe) to get > around the stability-of-routing issue for already-established > TCP sessions in the above approach (multiple machines with the > same IP externally, plus an internally different IP, each > running gated to announce their /32(s) to your IGP) - > hint: a question I asked on NANOG a few days back - > And Alec Peterson (now of Erols) has figured out an even > arguably slicker way to do it. > > I'll see if Merit wants to have Alec and I do a presentation > on the methods @ NANOG. If you have neatly solved the problem of undetectable route flutter, whereby something distant from your similarly-numbered machines causes datagrams destined for those machines to flip among several of them at intervals (particularly relatively short intervals) then I think that would be worthy of a talk almost anywhere. Moreover, if you can generalize the "slick" solution into moving traffic by choice from one of your similarly- numbered machines to another (thinking of reboots & backups, server-driven load balancing and the like) independent of service (although you could require it to be a NAT-friendly service, I guess) then that might make a trip to Phoenix worthwhile. Sean.

2 1

Re: Traffic Engineering (fwd)
by Eric Germann 18 Sep '97

18 Sep '97

At 04:31 PM 9/18/97 -0400, Sean M. Doran wrote: > >Perhaps you could explain to me how you can find the >shortest path between A and B using ping times, traceroute >hop counts, and AS_PATHS observed at C, assuming that >traffic between A and B is not exchanged through C? > You're not trying to find it between A and B. A connects to B, but B has every intention of redirecting to C1, C2, or C3, etc. If B can communicate with some measurement tool on Cx, they can all report back on their "connectivity" to A. B can then redirect A to the "best" Cx node. If the results are inconclusive, round robin it. If B had knowledge of BGP and AS's, maybe it wouldn't have to decide on distance but instead search for a Cx which was nearest to B in the AS_PATH. The premise being it may be better to pick a Cx nearest me in my upstream, as opposed to driving it through some overloaded exchange point. Granted, ping tends to get dropped on the floor at overloaded points, and traceroute probably isn't a) too much better b) probably blocked in some (most) cases, but are there any better alternatives? Anyone know of some reasonably available methods for measuring end to end "performance" which are almost universally implemented? Kind of making do with what we have. #Included junk >From Network World Olympic effort could be much more ------------------------------------------------------------------------ By Marc Myers 07/29/96 If you, like me, are among the six million people that have succumbed to the temptation of visiting IBM's Olympics Web site (http://www. atlanta.olympic.org) don't feel bad for having wasted company time. Just tell your boss that you are reviewing one of the most phenomenal technological feats of the decade: a worldwide network constructed in just 15 months. The project - though it has run into some technical snags during the early going - demonstrates how much can be accomplished when an immutable deadline is accompanied by a virtually unlimited budget. IBM provided a $40 million sponsorship, but the company's actual expenses probably exceeded $1 billion. The Internet setup utilizes two primary RS/6000 SP2 multiprocessing servers, one of which hums away on 52 processors in Southbury, Conn., while its buddy chugs along on 16 processors in Hawthorne, N.Y. Mirror servers run in Asia, Europe and the U.S. IBM developed new load-balancing software as part of its Web Object Manager that optimizes traffic, automatically finding and tapping the most available servers. Other aspects of the system - including the Global Shared Data Center - are so secret that we don't even know where they operate from. For surfers who are into the Olympics, the services offered are superlative: You can get game results almost as fast as the major networks, download images and flicks of the world's greatest athletes and shop for official Olympic products. But what I find most appealing about this system is that it was built so quickly and with such creativity. What if IBM decided that this was something that could be done more than once? [snip ...] ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

2 1

Re: need contact info -Forwarded
by CRL Information 18 Sep '97

18 Sep '97

You may wish to email info(a)crl.com, sales(a)crl.com, accounting(a)crl.com, admin@crl.com,support@crl.com. What is the nature of your request ? > Sender: owner-nanog(a)merit.edu > From: Naiming Shen <nshen(a)mci.net> > To: nanog(a)merit.edu > Cc: nshen(a)mci.net > Subject: need contact info > Any one has good contact info for crl.net? I tried noc(a)crl.net, > peering(a)crl.net, routing(a)crl.net, all failed. > ------------------------------------------------------------------- > - Naiming Shen MCI > - MCI Internet Engineering 2100 Reston Parkway > - +1 703-715-7056 fax: 703-715-7066 v272-7056 Reston, VA 20191 > >

1 0

Re: Traffic Engineering (fwd)
by Sean M. Doran 18 Sep '97

18 Sep '97

<osborne(a)terra.net> writes: > AS_PATH was the first idea - other such tools could include ping times and > traceroute hop counts. It's been pointed out to me that IBM supposedly did > something like this for the '96 Olympics. Perhaps you could explain to me how you can find the shortest path between A and B using ping times, traceroute hop counts, and AS_PATHS observed at C, assuming that traffic between A and B is not exchanged through C? > True - having a search engine look at its own BGP table is not the best > indicator of distance, especially if the search client is "distant" (many > AS's away) from the engine. However, given the prevalence of things like > the Merit tools that show the BGP exchanges at major NAPs, it's conceivable > that a search engine could grabe these tables on a regular basis, and from > there it becomes pretty much an SPF tree through AS's. An AS_PATH does not describe a connectivity graph. It is attached to reachability information to avoid looping NLRI propagation; in essence, it is an audit trail of who has already seen the route and passed it on. That is, when you look at an AS path like 1239 1800 1755 19999 you are trying to discover who has already apparently seen the announcement, and therefore, who should not see it again from you. Any modern use or understanding of the AS path beyond this is an overloading of the attribute and is probably a bad idea. (I expect some disagreement over this, particularly as a BGP-talking router is expected to tell the truth about which path it actually is using.) Unfortunately, a popular modern use is in using the length of the AS_PATH to influence routing policy by guessing what other ASes will do with the AS_PATH length in the route selection process. This leads to the belief that the AS_PATH can be used as a primitive metric, but this is unreliable, and depends on the prevalence of a particular selection process which hopefully someday will be dead, as has been talked about for more than a year. (Hi Paul, hi Ravi, where's the code?) Also unfortunately, a popular modern misunderstanding of the AS_PATH is that it describes the current best (or even ANY) path from somewhere back to the origin. While as-path prepending and the like has side effects on a certain path-selection scheme, it also has a more interesting side effect in the sense that you may scope an advertisement by enumerating ASes that should not hear the announcement. That is, if I stuffed 9999 into the AS_PATH of an announcement I generated or learned from elsewhere, AS 9999 would never hear the announcement from anyone who heard it only from me. The presence of 9999 in the AS_PATH does not indicate connectivity between the surrounding ASes in this case. There are two simple things to observe: * an editable AS_PATH guarantees that the AS_PATH cannot reliably be used to determine which ASes will carry traffic towards the advertised prefix nor that any two adjacent ASes in the path are directly connected with one able and willing to send traffic directly to the other for that prefix * the reason one wants to edit an AS_PATH is almost always to make up for the fact that the AS_PATH length is commonly used as a primitive sort of metric, and without breaking the loop-prevention scheme, one cannot usually DECREASE the length of the AS_PATH except by playing icky games with AS_SETs. To calm fears about the first point, anyone who advertises a prefix to you declares that the prefix is reachable through that neighbour. (Although you should worry about whether what you reach is a _local_ version of that prefix that is routed to Null0 and the like, but that's a social problem regarding trust, which of course is the scary detail of using BGP for global dynamic routing). The primary reason sed(1) was never implemented in OFRV's code for a long time was that the AS_PATH was understood to be an audit trail primarily to prevent announcement loops, and that the formation of an announcement loop was the obvious Bad Thing sed(1) could lead to. > I do concur, though, that ping and traceroute are probably more sensible > metrics to use. Why? ping and traceroute are poor predictors of locality and available bandwidth between the originator and target of those tools. Sean. (who had a long dinner break in the middle of this and probably left many loose ends. sorry.)

3 4