September 2002 - Test - lists.nanog.org

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

17 Sep '02

"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 > > >

25 43

Testing BGP with real UPDATEs
by Sathya Perla 17 Sep '02

17 Sep '02

Hi, How is a BGP implementation tested with real Internet routing data (BGP UPDATEs)? Are there any experimental/test networks that can be connected to for testing a BGP implementation? Thanks, -Sathya

1 0

Inter-ISP security procedures?
by Rajesh Talpade 17 Sep '02

17 Sep '02

Hi! Could someone please point me to BCP documents or products that permit an ISP to better interact with its peers/upstreams in case of DoS and worm attacks that cross ISP network boundaries? The approach I have seen so far involves a judicious combination of abuse@isp emails and frantic phone calls to NOC contacts. Thanks! Rajesh.

7 14

NSP Security List
by Barry Raveendran Greene 16 Sep '02

16 Sep '02

Hello Everyone, Thanks to Jared's sponsorship, we are creating a nsp-* mailing list for the NSP Security Operations community. We will use the nsp-security for NSP security coordination and consultation. We expect most of the consultation to be on procedures, polices, tools, mitigation techniques, and other proactive activities. We will also try to use the list as an incident response alias - tracking and mitigating attacks in progress. Membership to the alias will be restricted to those actively mitigating of NSP Security incidents. Therefore, it will be limited to operators, vendors, researchers, and FIRST team and other people in the NSP operations community working to stop attacks. That means no press and (hopefully) none of the "bad guys." We will use a simple trust/peering relationship used on some of the other aliases. This model is not as "secure" as an encrypted conversation, but better than a wide-open public dialog. We will establish the trust by asking members of the list to vouch for new subscriber requests. If the list administrators know the person, then they can vouch for them. Yes, we have had similar "security" lists in the past. With nsp-security we will connection the E-mail dialog with face-to-face meetings in the operations conferences. The first "meeting" is the ISP Security BOF at the next NANOG. Like NANOG's Peering BOF, the ISP Security BOF is a facilitation tool ... bring together people living with the daily pain of ISP Security incidents. So the hope is the combination of face-to-face and private E-mail list will help use take forward steps. So apply for subscription, send a note to: nsp-security-request(a)puck.nether.net with the word "subscribe" in the subject or body of the message. Alternatively, you can use the web page at: http://puck.nether.net/mailman/listinfo/nsp-security Barry PS - Looking for a couple more volunteers to help as administrators. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Barry Raveendran Greene | || || | Senior Consultant | || || | CTO Corporate Consulting | |||| |||| | | ..:||||||:..:||||||:.. | e-mail: bgreene(a)cisco.com | C i s c o S y s t e m s | Phone: +1 408 525-8089 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Recent NANOG postings
by hrs＠hushmail.com 16 Sep '02

16 Sep '02

I am very pleased to see the recent decrease in off-topic postings. I was having great difficulty blocking mail. Husan R. Sarris, Ph.D. (Pig-headed Dictator) Nerit Metwork Get your free encrypted email at https://www.hushmail.com

7 7

the "worm" (apache ssl) source code
by Len Rose 16 Sep '02

16 Sep '02

Just in case anyone is interested, the source is located at ftp://ftp.netsys.com/len/bugtraq.c

1 0

Re: How do you stop outgoing spam?
by Dave Crocker 16 Sep '02

16 Sep '02

At 02:11 PM 9/16/2002 -0400, Greg A. Woods wrote: > > 2. The issue with email is authentication, not privacy. Authentication > can > > be achieved can be achieved easily over port 25, without encryption. > >Well, no, not securely it can't. You cannot have a secure authenticated >service running over a raw TCP circuit across public networks. 1. You are adding to the requirement. No matter how reasonable or advisable, encryption (privacy) is a separate function from authentication. And the rationale for doing port 25 port blocking has to do with accountability, not privacy. 2. Just so there is no confusion, I meant encryption as in privacy (content encryption) rather than as part of an authentication mechanism. 3. SMTPAUTH does not require an alternate port, yet it is sufficient for ensuring accountability. Hence it is sufficient for dealing with the reason that port 25 is blocked, without requiring that it be blocked. > > Hence, blocking port 25 blocks legitimately validated email, > > as well as possible spam. > >Well, yes, but obviously that doesn't matter. This is the real world Dave. Thanks for noticing that. That is why I keep citing the impact on real, mobile users and the implication for such minor opportunities such as wireless hotspots. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

Additional Pre-NANOG Raft Trip info and Signup, online
by Daniel Golding 16 Sep '02

16 Sep '02

Check out http://www.users.qwest.net/~mdrose7/ for more information on the pre-NANOG raft trip and festivities. Thanks, Daniel Golding and Mitchell Rose

1 0

Re: Calling all researchers (was Re: Vulnerbilities of Interconnection)
by sgorman1＠gmu.edu 16 Sep '02

16 Sep '02

Thanks for the lead on research feedback session at NANOG - sounds very useful. Guess I need to whip out an abstract pretty quickly. > Due to policy constraints the commercial Internet more closely mimics > a collection of decentralized networks. It is the collection of several competitive decentralized networks that has caused the collective Internet not to be a decentralized network, and more along the lines of what was discussed in the previous post. > But during a disaster, capacity is capacity. No doubt there is lots of capacity and plenty of it is as you describe "shadow capacity". Several studies have found backbone utilization to be as low as 10-15% on average. An often asked question is not if there is extra capacity in case of disaster but the ability to provide multi-proivder cooperation to take advantage of it - assuming that the problem is alrge enough cannot be handled by providers individually. > The missing piece from most of the previous papers I've > read is how do you find out how much unused capacity exists? Yup - capacity is the missing piece, largely because the data is considered proprietary and cannot be obtained through non-invasive probing. Running a path char takes aggggessssss and is not really practical. Trying to put together a model based on advertised link capacity is sketchy at best, but might be useful for a best case scenario. > The operational community comes back out from > behindthe curtain and tells the research community our network > doesn't have > that problem. And if it did, its fixed now :-) A nice analogy of the stats quo, but the problem is it is like going up on the Eiffel tower and trying to get a view of Paris by looking through a toliet paper tube. You suffer from tunnel vision. It would seem to get an accurate picture you need to look at the aggregate and not just individual networks. Then you get the proprietary rub and you are back to square one. Government types get edgy and point fingers and the providers say that there is not a problem. There are several ways this can play out, and I would hope none of which would involve the big R word - regulation. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Sunday, September 15, 2002 1:19 am Subject: Calling all researchers (was Re: Vulnerbilities of Interconnection) > > On Sat, 14 Sep 2002 sgorman1(a)gmu.edu wrote: > > The point being from a structural stand point there is convincing > > empirical evidence that the Internet is not a distributed network. > > Due to policy constraints the commercial Internet more closely mimics > a collection of decentralized networks. However, things are more > complicated because IP permits networks of any size to interconnect > a almost any level over almost any communications technology. We > normallyconsider it an error when external traffic transits an > intranet or > extranet. But during a disaster, capacity is capacity. > > > a small minority has the vast majority of conections. The > applied side > > of this I think I've posted about before, so please pardon the > > redundancy, is that Internet as the AS and router level is very > > resilent to random failures but highly susceptible to targeted > > failures. This has become so predominant in the literature it > has left > > many folks asking questions along the lines of security. > > This has come up on this list and others before. I've previously > commented on some of the published papers. I'll try not to repeat > everything. The missing piece from most of the previous papers I've > read is how do you find out how much unused capacity exists? BGP views > and Skitter data is very good at finding used paths, but it tells you > nothing about how much "shadow" capacity exists. > > Generally, after a disaster you'll discover new capacity exists in > the Internet which you couldn't detect before the disaster. Where > does that capacity come from, and why couldn't you detect it before > the disaster? And how much capacity exists in the shadows? > > > This has led a scramble to come up with new Internet topology > > generators - another laundry list of references and approaches - but > > the reported security implications have had a bumpier road. Are all > > these computer scientist and physicists wrong, I'm sure a good case > > could be made against them, but it leaves several open questions. > > There have been several good cases made for the resilence of the > statas> quo and good arguments that there could be problems. The > question is > > how much of it is political. One side looking for problems they can > > point fingers at in the name of homeland security and one side > denying> any problem at all because it is a lot cheaper if there > is no problem. > > The research community comes up with a model how the Internet works. > They hypothesize various outcomes based on that model. The final > sectionof any research report is a list of problems requiring more > research :-) > > The operational community looks at the model, goes behind the curtain > and compares the model to their operational networks. We find the > modeldoesn't match. The operational community comes back out from > behindthe curtain and tells the research community our network > doesn't have > that problem. And if it did, its fixed now :-) > > The research community asks can we please peek behind the curtain? > The > operational community says we respectfully must decline. > > Rinse. Repeat. > > I probably won't make it to the next NANOG in Eugene, but on Sunday > afternoon NANOG is hosting a research/operation forum to allow > researchersto solicit feedback from the operations community. The > proposal deadline > is Monday, September 16. > > >

2 1

Re: How do you stop outgoing spam?
by Dave Crocker 16 Sep '02

16 Sep '02

At 02:07 PM 9/11/2002 +0200, Brad Knowles wrote: >At 10:16 AM -0700 2002/09/10, Dave Crocker wrote: >> Laptop mobile users cannot use their home SMTP server. > Depends on the configuration of the SMTP server and the mail > server & client running on the laptop. With SMTPAUTH and/or TLSSMTP, and > using a different (unfiltered) port, this shouldn't be a problem. 1. The basic issue is with control over outbound ports. Whatever hacks might deal with the particular details of problems in blocking outbound port 25, the problem resurfaces for other ports. For example, I have been in a number of installations that block all but a few outbound ports, so that even non-25 email is not accessible. It is the philosophy of blocking outbound ports that is the real mistake. 2. The issue with email is authentication, not privacy. Authentication can be achieved can be achieved easily over port 25, without encryption. Hence, blocking port 25 blocks legitimately validated email, as well as possible spam. >> In other words, by blocking output SMTP, mobile users are hurt >> badly. > Can be. Yup. Think of all the iPass and GRiC customers who > don't even know who the local provider is that they're dialing up, so > that they can get a network connection? Exactly correct. And all the people who visit an organization and use their LAN access. And all the people who visit 802.11 hotspots. >> I know that *I* certainly am. Constantly and serously. > I'm very sorry to hear this. Maybe we can help you get SMTPAUTH > and/or TLSSMTP set up on your server and/or client? SMTPAUTH works over port 25. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0