- Test - lists.nanog.org

Re: How about a game of chess? (was Re: Vulnerbilities of Interconnection)
by sgorman1＠gmu.edu 07 Sep '02

07 Sep '02

Actually I do not know how to play chess maybe *Risk*, but your point is well taken. The intent is not provide a public recipe for taking down the Internet, that would be the opposite goal of the research to begin with. Regardless it is difficult line to tread and it is best to err on the side of caution. As for sampling biases - that is why it is only anecdotal evidence and the need for it to be questioned. Reports of Vinny accidently announcing his router as AS701 do not make it to the media very often. That aside the suggestion of how to model the Internet are very useful and the closer these models can get to operational reality the better. The intent being methodology not revealing data. Waites' approach is a good first step, but what next. Also if you know capacties how do you model a cascading effect that encompasses intra- network and inter-network traffic flows. Also it might be easier to calculate transition probabilities by summing across the rows of the adjaceny matrix then dividing the row components by the sum. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Friday, September 6, 2002 12:52 pm Subject: How about a game of chess? (was Re: Vulnerbilities of Interconnection) > > On Thu, 5 Sep 2002 sgorman1(a)gmu.edu wrote: > > Is there a general consensus that cyber/internal attacks are more > > effective/dangerous than physical attacks. Anecdotally it seems the > > largest Internet downages have been from physical cuts or failures. > > I think you have a sampling bias problem. > > The "biggest" national/international network disruptions have > generallybeen the result of operator error or software error. Its > not always easy > to tell the difference. It may be better for carrier PR spin > control to > blame a software/router/switch vendor. > > Until recently physical disruptions have been due to causes which > don'teffect the stock price, carriers were more willing to talk > about them. > Carriers usually don't fire people due to backhoes, hurricanes, > floods, or > train derailments. > > What does this say about the effect of an external or internal > cyber-attack? > > Not much. Naturally occuring physical and procedural disruptions have > different properties than a directed attack. Not the least is > hurricanesand trains don't read NANOG, and generally don't alter > their behavior > based on the "recommendations" posted. > > Wouldn't you prefer a good game of chess? > > >

3 3

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 06 Sep '02

06 Sep '02

Quite a few researchers have looked at the topology of AS interconnection. They have found that AS connectivity follows a power law - i.e. the vast majority have a few connections while a small minority has the majority of connections. Same as an earthquake - most are small and not noticable but a few are huge, smash a boulder and you get the same thing. Lots of dynamic networks follow this topology. The upside is that they are incredibly robust to random failures but very susceptible to targeted failures. For details see: http://www.physicsweb.org/article/world/14/7/09 ----- Original Message ----- From: Jared Mauch <jared(a)puck.Nether.net> Date: Friday, September 6, 2002 2:20 pm Subject: Re: Vulnerbilities of Interconnection > > On Fri, Sep 06, 2002 at 01:55:40PM -0400, batz wrote: > > On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: > > :would be difficult to reach. I'd have to run a model to be > sure, but > > :every one of the major seven have rerouting methodologies that > would> :recover from the loss. And I don't think they exclusively > peer at > > > > ASN's to "fail", then see who is still connected, but we are > > still dealing with connectivity relatve to us and our peers, > > even 5+ AS-hops away. > > > > I would imagine this is one of the tasks CAIDA.org is probably > > working on, as it seems to fall within their mission. > > Coming up with the as interconnection data is actaully fairly > easy if you parse route-views data. This obviously doesn't cover > every possible interconnection that exists but it does provide > a large swath of data to review for the interconnection > postulation. > > Looking at that data, (this is an old snapshot) the top ten > networks are: (in #10->#1 order) > > conn ASN > ----+---- > 161 3356 > 229 1 > 242 2914 > 248 209 > 274 6461 > 277 3561 > 295 3549 > 328 7018 > 484 701 > 493 1239 > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are > only mine. > >

1 0

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 06 Sep '02

06 Sep '02

The question is what if someone was gunning for your fiber. To date cuts have been unintentional. Obviously the risk level is much higher doing a phyisical attack, but the bad guys in this scenario are not teenage hackers in the parents basement. There is a good foundation of knowledge on the implications of cyber attacks, but the what-if of an intentional physical attack is an important question I believe. The context in this discussion has been very valuable and many thanks to everyone that has offered opinions. ----- Original Message ----- From: Dave Israel <davei(a)algx.net> Date: Thursday, September 5, 2002 3:50 pm Subject: Re: Vulnerbilities of Interconnection > > The thing is, the major cuts are not "attacks;" the backhoe operators > aren't gunning for our fiber (no matter how much it seems like they > are). If I wanted to disrupt traffic, intentionally and maliciously, > I would not derail a train into a fiber path. Doing so would be very > difficult, and the legal ramifications (murder, destruction of > property, etc, etc) are quite clear and severe. However, if I > ping-bomb you from a thousand "0wn3d" PCs on cable modems, I never had > to leave my parents' basement, I'm harder to trace by normal police > methods, and the question of which laws that can be applied to me is > less clear. > > -Dave > > On 9/5/2002 at 15:38:56 -0400, sgorman1(a)gmu.edu said: > > > > "Again, it seems more likely and more technically effective to > attack > > internally than physically. Focus again here on the cost/benefit > > analysis from both the provider and disrupter perspective and > you will > > see what I mean." > > > > Is there a general consensus that cyber/internal attacks are > more > > effective/dangerous than physical attacks. Anecdotally it seems > the > > largest Internet downages have been from physical cuts or failures. > > > > 2001 Baltimore train tunnel vs. code red worm (see keynote report) > > 1999 Mclean fiber cut - cement truck > > AT&T cascading switch failure > > Utah fiber cut (date??) > > Not sure where the MAI mess up at MAE east falls > > Utah fiber cut (date??) > > > > Then again this is the biased perspetive of the facet I'm > researching> > > Secondly it seems that problems arise from physical cuts not > because > > of a lack of redundant paths but a bottlneck in peering and > transit - > > resulting in ripple effects seen with the Baltimore incident. > > > > > > > > ----- Original Message ----- > > From: "William B. Norton" <wbn(a)equinix.com> > > Date: Thursday, September 5, 2002 3:04 pm > > Subject: Re: Vulnerbilities of Interconnection > > > > > > > > At 02:45 PM 9/5/2002 -0400, alex(a)yuriev.com wrote: > > > >This obviously would be a thesis of Equinix and other collo > space > > > providers,>since this is exactly the service that they > provide. It > > > won't, hower, be a > > > >thesis of any major network that either already has a lot of > > > infrastructure>in place or has to be a network that is > supposed to > > > survive a physical > > > >attack. > > > > > > Actually, the underlying assumption of this paper is that > major > > > networks > > > already have a large global backbone that need to interconnect > in > > > n-regions. The choice between Direct Circuits and Colo-based > cross > > > connects > > > is discussed and documented with costs and tradeoffs. > Surviving a > > > major > > > attack was not the focus of the paper...but... > > > > > > When I did this research I asked ISPs how many Exchange Points > > > they felt > > > were needed in a region. Many said one was sufficient, that > they > > > were > > > resilient across multiple exchange points and transit > > > relationships, and > > > preferred to engineer their own diversity separate from > regional > > > exchanges. > > > A bunch said that two was the right number, each with > different > > > operating > > > procedures, geographic locations, providers of fiber, etc. , > as > > > different > > > as possible. Folks seemed unanimous about there not being more > > > than two > > > IXes in a region, that to do so would splinter the peering > > population. > > > > > > Bill Woodcock was the exception to this last claim, positing > > > (paraphrasing) > > > that peering is an local routing optimization and that many > > > inexpensive > > > (relatively insecured) IXes are acceptable. The loss of any > one > > > simply > > > removes the local routing optimization and that transit is > always > > > an > > > alternative for that traffic. > > > > > > > > > > > > A couple physical security considerations came out of that > > > research:> > 1) Consider that man holes are not always > secured, > > > providing access to > > > > > metro fiber runs, while there is generally greater > security > > within > > > > > colocation environments > > > > > > > >This is all great, except that the same metro fiber runs are > used > > > to get > > > >carriers into the super-secure facility, and, since neither > those > > who > > > >originate information, nor those who ultimately consume the > > > information are > > > >located completely within facility, you still have the same > > > problem. If we > > > >add to it that the diverse fibers tend to aggregate in the > > > basement of the > > > >building that houses the facility, multiple carriers use the > same > > > manholes>for their diverse fiber and so on. > > > > > > Fine - we both agree that no transport provider is entirely > > > protected from > > > physical tampering if its fiber travels through insecure > > > passageways. Note > > > that some transport capacity into an IX doesn't necessarily > travel > > > along > > > the same path as the metro providers, particularly those IXes > > > located > > > outside a metro region. There are also a multitude of paths, > > > proportional > > > to the # of providers still around in the metro area, that > provide > > > alternative paths into the IX. Within an IX therefore is a > > > concentration of > > > alternative providers, and these alternative providers can be > > > used as > > > needed in the event of a path cut. > > > > > > > > > > > 2) It is faster to repair physical disruptions at fewer > > > points, leveraging > > > > > cutovers to alternative providers present in the > collocation > > > IX model, as > > > > > opposed to the Direct Circuit model where provisioning > additional> > > > capacities to many end points may take days or > months.> > > > > > >This again is great in theory, unless you are talking about > > > someone who > > > >is planning on taking out the IX not accidently, but > > > deliberately. To > > > >illustrate this, one just needs to recall the infamous fiber > cut > > > in McLean > > > >in 1999 when a backhoe not just cut Worldcom and Level(3) > > > circuits, but > > > >somehow let a cement truck to pour cement into Verizon's > manhole > > > that was > > > >used by Level(3) and Worldcom. > > > > > > Terrorists in cement trucks? > > > > > > Again, it seems more likely and more technically effective to > > > attack > > > internally than physically. Focus again here on the > cost/benefit > > > analysis > > > from both the provider and disrupter perspective and you will > see > > > what I mean. > > > > > > > > > >Alex > > > > > > > > > > > > > -- > Dave Israel > Senior Manager, DNE SE > >

7 7

Re: IP address fee??
by Dave Israel 06 Sep '02

06 Sep '02

On 9/6/2002 at 13:18:54 -0400, Richard A Steenbergen said: > And half the internet's users type "u r kewl", and think that ethernet is > a broadband connection. > > Just because a misconception is popular doesn't mean we should indulge it. > :) > > Think of it as a public service, if you make an effort to say "/24", and > someone asks and you explain it, thats one less confused person > circulating around teaching others. Think of it as a service towards your own future, too. An awful lot of the new protocols and services arise out of college environments, and hence the proliferation of protocols that work fine in a campus network but somehow just don't fly in the "real" world.

1 0

Re: IP address fee??
by Ted Fischer 06 Sep '02

06 Sep '02

At 12:42 PM 9/6/02 -0400, you wrote: >Was this reply directed at me, particularly? > > >Joe Joe, Most definitely not. I felt that the two comments I included most closely represented the discussion and information I wanted to pass. No offense meant, I hope none taken, apologies if they were. Ted >On Fri, Sep 06, 2002 at 12:33:09PM -0400, Ted Fischer wrote: > > At 10:00 AM 9/6/02 -0400, Joe Abley postulated: > > > > >On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: > > >> Because "Cee" is easier to pronounce than "slash twenty-four". Ease of > > >use > > >> trumps open standards yet again :) > > > > > >Nobody was talking. "/24" is easier to type than "class C". No > > >trumps! Everybody loses! > > > > > >How many people learn about networks from certification courses or > > >in school, anyway? It was always my impression that people learnt > > >mainly by listening to other people. > > > > > >If networking on the front lines is an informal oral tradition more > > >than it is a taught science, then perhaps it's natural for obsolete > > >terminology to continue to be "taught" long after it stopped having > > >any relevance. > > > > > > > > >Joe > > > > The class of an address is determined by the bit-pattern of the first > > octet of the address. 10.0.0.0 will always be a Class A > > address. 172.16.0.0 will always be a Class B address, and 192.168.0.0 > will > > always be Class C address. I'm not aware of any RFC that rescinded the > > definition of the Class of an address. > > > > Masks, when associated with an address, enable one to determine (a), > > what network I'm on (if I'm an IP host) or (b) how many addresses exist > > within a given range of addresses (if I'm a routing table). > > > > Subnetting (robbing mask host bits (0's) to make network bits (1's) > > allowed one to more effectively use the decreasing amounts of networks > that > > required less than the default number of addresses (65,536 in the case > of a > > Class B) by more effeciently using the space one had been allocated. With > > subnetting, I can take one Classful network and make many (sub)networks > > from it. There was no way prior to 1993, however, to effectively > represent > > the range of addresses in more than one Classful network. > > > > CIDR, simply stated, says that one can use any address with any mask, > > regardless of the original class of the address, to represent a range of > > addresses (i.e. rob network bits to make host bits). It allows the > > properties of IP to be more effectively used for IP host addressing (only > > need a /23 to support 400 IP hosts (a very effecient 78% use of the > > allocated space), as well as (one of the original, primary reasons for > > CIDR) aggregate ("Supernet") "X" traditional Class C's into one routing > > statement (who today would advertise delivery to the range of 4,096 > > addresses from, for example, 192.168.192.0 through 192.168.207.255 with 16 > > individual traditional Class C statements?). > > > > Since NANOG is "the front line", then perhaps that is where the oral > > tradition should be teaching the history of IP addressing, from Classful > > addressing (default masks) to Subnetting (other than default) to > > Supernetting (ranges of addresses regardless of original - or legacy if > you > > will - class (Classless)). > > > > The prefix, of course, does not refer to the class of the address, but > > the number of contiguous ones in the mask. As far as pronounciation goes, > > I prefer "slash 24" to "two fifty five dot two fifty five dot two fifty > > five dot zero" :) > > > > $.02 > > > > Ted Fischer > >

1 0

Re: Vulnerbilities of Interconnection
by Dave Israel 06 Sep '02

06 Sep '02

alex(a)yuriev.com said: >Taking out an a collo would more than just increase time to download porn >for a few days. and went on to say: > > > Is there a general consensus that cyber/internal attacks are more > > > effective/dangerous than physical attacks. Anecdotally it seems the > > > largest Internet downages have been from physical cuts or failures. > > > > It depends on what you consider and internet outage. Or how you define > > that. IMHO. > > Lets bring this discussion to a some common ground - > > What kind of implact on the global internet would we see should we observe > nearly simultaneous detonation of 500 kilogramms of high explosives at N of the > major known interconnect facilities? The answer to the first thing is "Yes, it would be back at full speed in 24 hours" and the second thing is "Unless N is unreasonably large, not much." The reason is that people like us work on running the internet. In case 1, suppose I am a porn magnate. (Obviously, I am not, or I would dress better and work less, but stay with me for a moment.) I sell two products: pictures, and online strippers. The pictures are a static gold mine, so chances are, I have them backed up. The strippers are at a studio near my hosting/colocation site, and backhauled via your favorite fiber-based protocol. I get a call saying, "Hey, a terrorist from group X walked into the colo facility with a 12008 chassis filled with plastique, and, well, the entire site is a charred hole in the ground." After a few seconds of horror, greed takes over, and I call other nearby providers to see who can get me back up today, pay the telco a nice hefty fee to reroute my SONET connection to that provider, and the money is rolling in before sunset. In case 2, suppose it is 4 major peering points. No big deal for the bulk of traffic, because the bulk of traffic goes between the big players, and they are all privately peering. So are many of the medium-sized folks. Smaller folks often buy transit from a larger provider to reach everybody they cannot peer with. And even if you don't buy transit and don't have overseas peering and lose your connectivity because they picked your 4 favorite sites, you're not going to be down for long, because somewhere, you are close enough to a UUnet or a AT&T or a Level 3 who can toss you a cable until you can get back on your feet. Yeah, an attack can make the Internet uncomfortable and cause a lot of scurrying and odd deals, but the provider who is completely screwed by an attack on 1 colo or 4 peering points is going to be an exception, not the rule. -Dave

1 0

Bad Dog, no biscuit, Interland
by John M. Brown 06 Sep '02

06 Sep '02

So after four different phone calls to Interland, and four different hangups by the techs and a refusal to do anything Interland, your client is being bad. Five minute rate was very high Folks need to take security and abuse issues seriously. The time has come for operators to have responsive staff, and to use technology to thwart known bad things. Folks look at DOS/DDOS/IDS tools to check ingress traffic, lets also use them to check EGRESS as well.. Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3753 xx.yy.36.94:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3755 xx.yy.36.96:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3756 xx.yy.36.97:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3760 xx.yy.36.101:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3762 xx.yy.36.103:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3764 xx.yy.36.105:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3766 xx.yy.36.107:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3765 xx.yy.36.106:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3719 xx.yy.36.60:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3721 xx.yy.36.62:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3722 xx.yy.36.63:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3725 xx.yy.36.66:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3727 xx.yy.36.68:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3730 xx.yy.36.71:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3736 xx.yy.36.77:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3738 xx.yy.36.79:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3739 xx.yy.36.80:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3741 xx.yy.36.82:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3743 xx.yy.36.84:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3744 xx.yy.36.85:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3746 xx.yy.36.87:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3748 xx.yy.36.89:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3752 xx.yy.36.93:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3754 xx.yy.36.95:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3757 xx.yy.36.98:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3758 xx.yy.36.99:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3759 xx.yy.36.100:80 in via sis0

1 0

RE: Vulnerbilities of Interconnection
by Kris Foster 06 Sep '02

06 Sep '02

> What kind of implact on the global internet would we see > should we observe > nearly simultaneous detonation of 500 kilogramms of high > explosives at N of the > major known interconnect facilities? Not knowing how much damage would result from 500kg of explosives.. What is the typical size of pipe a carrier would pull into an interconnect facility, how many carriers, how much traffic? Now how much traffic would shift to other facilities if one went down? How many would it take to saturate the pipes? And at what point would congestion be bad enough to render them useless? At some point traffic will shift over to private interconnects either through complete loss of peering in third party facilities, or through manual intervention. Kris

1 0

RE: Vulnerbilities of Interconnection
by Dave Israel 06 Sep '02

06 Sep '02

My explanation accounts for suicide bombers in the statement: "Even terrorist that will die to kill will probably not die to inconvenience." This does not presume a western value system, either, as somebody suggested. Many a terrorist will gladly give their lives to destroy a hated enemy, or to terrify them, or to change their way of life. I cannot believe, however, that there are people who will give their lives to increase the download times for porn for a few days. -Dave On 9/5/2002 at 13:49:29 -0700, Al Rowland said: > To reinforce a dissenting opinion, And your explanation accounts for > suicide bombers how? I would think a smoking hole in the ground > containing a train or whatever, particularly if lose of life is > involved, would be much more appealing to the motivations of most > terrorists than a couple of computers with blue screens of death. I > would think 9-11 would provide a compelling example of current terrorist > practice. > > Just my 2¢ > > Best regards, > _________________________ > Alan Rowland > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Dave Israel > Sent: Thursday, September 05, 2002 1:29 PM > To: alex(a)yuriev.com > Cc: Dave Israel; sgorman1(a)gmu.edu; nanog(a)merit.edu > Subject: Re: Vulnerbilities of Interconnection > > > > On 9/5/2002 at 16:01:02 -0400, alex(a)yuriev.com said: > > > > > > The thing is, the major cuts are not "attacks;" the backhoe > > > operators aren't gunning for our fiber (no matter how much it seems > > > like they are). If I wanted to disrupt traffic, intentionally and > > > maliciously, I would not derail a train into a fiber path. Doing so > > > > would be very difficult, and the legal ramifications (murder, > > > destruction of property, etc, etc) are quite clear and severe. > > > However, if I ping-bomb you from a thousand "0wn3d" PCs on cable > > > modems, I never had to leave my parents' basement, I'm harder to > > > trace by normal police methods, and the question of which laws that > > > can be applied to me is less clear. > > > > This fails to address how this affects someone who has no problem with > > > legal ramfications - i.e. a terrorist. > > Even a terrorist will tend towards things that allow him to continue to > be a terrorist. If I can do X amount of damage, and get caught, or do X > amount of damage, and not get caught, then he'll do the second. Even a > terrorist that will die to kill will probably not die to inconvenience. > > > -- Dave Israel Senior Manager, DNE SE

2 1

Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 06 Sep '02

06 Sep '02

Thanks for all the answers on the previous question about Equinix. The reason for the question is that we are working on a study here at George Mason on assesing the vulnerbilities of the Internet and telecommunications infrastructure to physical attack. One part that we are looking at are the vulnerbilites of interconnection facilites. Doomsday scenarios like 60 Hudson street being a target instead of the WTC or the loss of MAE east, etc. The earlier question about Equinix and the Big 7 was really a vulnerbility question. Are interonnection locations aggreating or dispersing. How real of a threat is the physical loss of a major interconnection point. Incidents like the Balitmore train tunnel wreck point in one direction. We are working on putting several models together to try and simulate some of these scenarios with varying degrees of success, but I would very much like to avoid doing the research in a vaccuum. I was hoping a discussion on NANOG wold be a good first step. The project is quite hot with the politicos and I very much want to make sure to best recommendations are made. Formal industrsy cooperation is one side of this, but I think a lot of information can be gained from an informal approach as well. Any and all feedback is greatly appreciated Thanks, sean

7 9