- NANOG - lists.nanog.org

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

Updated DNS monitoring, take 2
by Rob Thomas 06 Sep '02

06 Sep '02

Hi, NANOGers. Rodney Joffe (thanks, Rodney!) correctly pointed out that my gTLD monitoring was only tracking the Verisign gTLD (com, net, org) name servers. I have now added the other TLDs to the mix. It can all be found in two places: http://www.cymru.com/DNS/ http://bgp.lcs.mit.edu/dnsmirror/ I will shortly have an additional web server on a much faster set of links, as well as another mirror. For the impatient, I recommend the MIT site. Don't forget to check the Lame Report while you're there. :) Comments and feedback are always welcome! Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

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

06 Sep '02

Sean, I completely agree with statement. It is not a matter of wanting to know where the importants hubs are - we have a pretty good handle on that, but what the impacts would be of a hub loss from an operational stand point. Maybe this is a discussion that needs to be off-line. My goal is to provide some context and validation for the research that is being carried out. There have been some interesting discussion on this forum about multi- provider cooperation in case of emergencies/catastropes. Your suggestion of the creation of a directory for contacts across providers was an insightful addition. I believe more discussion along these lines would be of benefit. The desire is for something high level, not any network details that could prove compromising. Thanks, sean ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Thursday, September 5, 2002 12:48 pm Subject: Re: Vulnerbilities of Interconnection > > On Thu, 5 Sep 2002 sgorman1(a)gmu.edu wrote: > > 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 > http://www.infosecuritymag.com/2002/sep/2002survey/voices/verylarge.sht ml > > On security reporting... > "Since Sept. 11, state, local and federal authorities have tried > to get > their arms around the potential threats to the nation's > infrastructure--including the telecommunications infrastructure. > They have > asked us questions like, 'What are your 100 most vulnerable places > in the > network?'" > > "As much as we would like to help the government in its attempt to > helpus, we believe it would be counterproductive to share such > informationwidely because if it were released, it would provide a > terrorist with a > roadmap to our key locations. Unless the government agrees that it can > protect our information, we will continue to respectfully decline such > blanket requests." > > Bill Smith > CTO and President of Interconnection Services, BellSouth > > > >

3 2