nanog mailing list archives
Re: Vulnerbilities of Interconnection
From: "Pawlukiewicz Jane" <pawlukiewicz_jane () bah com>
Date: Fri, 06 Sep 2002 09:11:35 -0400
Hi, sgorman1 () gmu edu wrote:
"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.
It depends on what you consider and internet outage. Or how you define that. IMHO. Jane
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 () equinix com> Date: Thursday, September 5, 2002 3:04 pm Subject: Re: Vulnerbilities of InterconnectionAt 02:45 PM 9/5/2002 -0400, alex () yuriev com wrote:This obviously would be a thesis of Equinix and other collo spaceproviders,>since this is exactly the service that they provide. It won't, hower, be athesis of any major network that either already has a lot ofinfrastructure>in place or has to be a network that is supposed to survive a physicalattack.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 peeringpopulation.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 thatresearch:> > 1) Consider that man holes are not always secured, providing access tometro fiber runs, while there is generally greater securitywithincolocation environmentsThis is all great, except that the same metro fiber runs are usedto getcarriers into the super-secure facility, and, since neither thosewhooriginate information, nor those who ultimately consume theinformation arelocated completely within facility, you still have the sameproblem. If weadd to it that the diverse fibers tend to aggregate in thebasement of thebuilding that houses the facility, multiple carriers use the samemanholes>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 fewerpoints, leveragingcutovers to alternative providers present in the collocationIX model, asopposed 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 aboutsomeone whois planning on taking out the IX not accidently, butdeliberately. Toillustrate this, one just needs to recall the infamous fiber cutin McLeanin 1999 when a backhoe not just cut Worldcom and Level(3)circuits, butsomehow let a cement truck to pour cement into Verizon's manholethat wasused 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
Current thread:
- Re: Vulnerbilities of Interconnection, (continued)
- Re: Vulnerbilities of Interconnection sgorman1 (Sep 05)
- Re: RE: Vulnerbilities of Interconnection sgorman1 (Sep 05)
- Re: Vulnerbilities of Interconnection sgorman1 (Sep 05)
- Re: Vulnerbilities of Interconnection Dave Israel (Sep 05)
- Re: Vulnerbilities of Interconnection alex (Sep 05)
- Re: Vulnerbilities of Interconnection Dave Israel (Sep 05)
- Re: Vulnerbilities of Interconnection alex (Sep 05)
- RE: Vulnerbilities of Interconnection Al Rowland (Sep 05)
- RE: Vulnerbilities of Interconnection Dave Israel (Sep 05)
- RE: Vulnerbilities of Interconnection alex (Sep 06)
- Re: Vulnerbilities of Interconnection Dave Israel (Sep 05)
- Re: Vulnerbilities of Interconnection alex (Sep 06)
- Re: Vulnerbilities of Interconnection Ryan Fox (Sep 06)
- Re: Vulnerbilities of Interconnection Pawlukiewicz Jane (Sep 06)
- Re: Vulnerbilities of Interconnection alex (Sep 06)
- Re: Vulnerbilities of Interconnection Pawlukiewicz Jane (Sep 06)
- Re: Vulnerbilities of Interconnection Christopher L. Morrow (Sep 06)
- Re: Vulnerbilities of Interconnection alex (Sep 06)