- Test - lists.nanog.org

Re: preventing future situations like panix
by Todd Underwood 23 Jan '06

23 Jan '06

bill,all, On Mon, Jan 23, 2006 at 12:08:11PM -0800, Bill Woodcock wrote: > > On Mon, 23 Jan 2006, Josh Karlin wrote: > > The idea is simply to consider 'suspicious' looking routes as a last > > resort in the decision process (~1 day). Thus if no alternative route > > for a prefix exists, the suspicious route is used regardless, no harm > > done. > > It seems like most of the routers which would need to make this decision > wouldn't have adequate information upon which to do so... not necessarily. the decision could be made in "near real time" by building prefix filters based on the algorithms that josh and co have worked on and leaving a 'default deny' in place. this moves the routing decision off of the router (which i agree does not have the history or resources to take these additional vectors of information into account) and over to a server with more storage and computational capacity. it has the side effect of denying announcements of valid prefixes from customers that are not in the prefix list until the list is next updated, but we already pay that price now; well, networks that maintain prefix filter lists on customer-facing ports pay that price now. this just describes a different way of building and maintaining those lists. the idea of incorporating history into the validation process for routing tremendously useful and worth considering seriously. at least until we get all signed updates. how is that whole thing going? :-) t. -- _____________________________________________________________________ todd underwood chief of operations & security renesys - internet intelligence todd(a)renesys.com www.renesys.com

1 0

Re: preventing future situations like panix
by Bill Woodcock 23 Jan '06

23 Jan '06

On Mon, 23 Jan 2006, Todd Underwood wrote: > > It seems like most of the routers which would need to make this decision > > wouldn't have adequate information upon which to do so... > not necessarily. the decision could be made in "near real time" by > building prefix filters based on the algorithms that josh and co have > worked on and leaving a 'default deny' in place. this moves the > routing decision off of the router (which i agree does not have the > history or resources to take these additional vectors of information > into account) and over to a server with more storage and computational > capacity. Agreed, if you're willing to suppose that routing decisions will be centralized, and static RIBs pushed down into things that look more like switches, many many many problems go away, to be replaced by the other problem: out-of-band control plane and detection of forwarding plane failures. I did a bunch of work with the Agilent guys on that five years ago or so, and found it really fascinating, in a what-if alternate-universe sort of way. -Bill

1 0

cctld server traffic
by Randy Bush 23 Jan '06

23 Jan '06

any cctld ops seeing unusual traffic in the last hours? randy

5 4

Re: oof. panix sidelined by incompetence... again.
by Fergie 23 Jan '06

23 Jan '06

Out of curiousity, why must these be in .pdf format? I mean, what's wrong with .html? Just curious, - ferg -- Manish Karir <mkarir(a)merit.edu> wrote: in case some people want to look at routeviews data for themselves, I have archived a couple of pdf file at: http://bgpinspect.merit.edu/reports.php -manish [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Re: oof. panix sidelined by incompetence... again. (fwd)
by Manish Karir 23 Jan '06

23 Jan '06

I forgot to mention that you can get the RIPE data perspective on this as well by running a prefix-exact query for "166.84.0.0/16" at bgp-inspect-RIPE: http://bgpinspect.merit.edu:9090 If there are enough requests I will probably archive those as well. thanks -manish ---------- Forwarded message ---------- Date: Mon, 23 Jan 2006 11:25:58 -0500 (EST) From: Manish Karir <mkarir(a)merit.edu> To: NANOG <nanog(a)merit.edu> Subject: Re: oof. panix sidelined by incompetence... again. in case some people want to look at routeviews data for themselves, I have archived a couple of pdf file at: http://bgpinspect.merit.edu/reports.php -manish ----- > Re: oof. panix sidelined by incompetence... again. > > * From: william(at)elan.net > * Date: Sun Jan 22 13:34:47 2006 > > Can there be a confirmation of this? I see no such MOTD at > http://www.panix.com/panix/help/Announcements/ > and my connection to panix is fine and route I see is 166.84.0.0/17 > with origin in 2033. I also checked at routeviews.org and similarly > all their peers see origin in in 2033. Is there some other route > that has been hijacked then or has it now ben resolved? > BTW - Its interesting to note that its almost exactly one year after > their domain hijacking which happened on weekend of Jan 15 & 16, 2005 (friday > jan 14th to be more precise). -------------

1 0

Re: oof. panix sidelined by incompetence... again.
by Manish Karir 23 Jan '06

23 Jan '06

in case some people want to look at routeviews data for themselves, I have archived a couple of pdf file at: http://bgpinspect.merit.edu/reports.php -manish ----- > Re: oof. panix sidelined by incompetence... again. > > * From: william(at)elan.net > * Date: Sun Jan 22 13:34:47 2006 > > Can there be a confirmation of this? I see no such MOTD at > http://www.panix.com/panix/help/Announcements/ > and my connection to panix is fine and route I see is 166.84.0.0/17 > with origin in 2033. I also checked at routeviews.org and similarly > all their peers see origin in in 2033. Is there some other route > that has been hijacked then or has it now ben resolved? > BTW - Its interesting to note that its almost exactly one year after > their domain hijacking which happened on weekend of Jan 15 & 16, 2005 > (friday jan 14th to be more precise). -------------

1 0

is this like a peering war somehow?
by Paul Vixie 23 Jan '06

23 Jan '06

proving once again that "peering ratios" only matter if the other guy's customers can live without your "assymetric" content, here are two articles i saw today via slashdot. what's interesting to me is whether bellsouth will be sued some time later by some other content provider for de-peering them without also having applied the same rules to google. note, this isn't a bellsouth-specific rant, they just happen to be mentioned in today's story. -------- http://www.networkingpipeline.com/blog/archives/2006/01/google_we_wont.html Google: We Won't Pay Broadband Cyberextortion January 18, 2006 BellSouth and Verizon have been trying to force big Web sites to pay extortion-type fees if the sites want adequate bandwidth, with Google a prime target. But Google has news for them: It won't pay. [...] -------- http://www.networkingpipeline.com/blog/archives/2006/01/bellsouth_cyber.html BellSouth: Cyberextortion Pays Off January 17, 2006 BellSouth's new business model, a slightly more polite form of the kind of extortion practiced by Tony Soprano, is starting to pay off. The company says it is in negotiations with several Web sites willing to pay extra fees to BellSouth for more bandwidth than it provides to other sites. [...] --------

21 28

RE: The Backhoe: A Real Cyberthreat?
by Wallace Keith 23 Jan '06

23 Jan '06

I for one have spoken in the past in favor of making the FCC Outage Reports public again. If you want to deliberatley destroy fiber infrastructure, you can gain more knowledge quicker by stepping outside your door and gazing upon clearly marked routes, than by reading outage reports. Want to find a bldg where multiple carriers are housed? Read the carrier hotel advertisements on the internet and in print or read NANOG. I have suffered more from trying to figure out (quickly) over the past few years what's going on in a multi carrier fiber outage situation, especially when a given carrier has IRU's on the competitor's fiber which I have also provisioned my redundany on (and they seem to "forget" that). Many times during outages people in NOCs are spinning in their chairs trying get a grip. The information that is purposely being suppressed from the public by DHS initiatives with the FCC, is also frequently inadvertantly obfuscated within a given orginisation due to turnover, layoffs, mergers and acquisitions, etc. So besides government interference, we are at times our own worst enemy due to lack of adequate knowledge transfer and change mgmt. procedures. Imagine if you will 2 competing carriers, 1 has a cut 22.1 km east of X, the other 3 km west of Y, crews are dispatched, and bingo- collide at the scene.....how many times has THAT happened. Neither realizes they share some form of infrastructure until they are having coffee together while looking at the muddy hole in the ground that the contractor for a 3rd company just dug. It IS a less than perfect world within the industry. On a slightly different rant - Forget attacking the glass. Take down DNS and SS7 at the same time...hmmm wonder what one company has a lock on a big piece of THAT. enough said. Hope their infrastructure for those things stays totally diverse (no offense meant). Just another thing that I think about at times... -Keith -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of sgorman1(a)gmu.edu Sent: Friday, January 20, 2006 3:05 PM To: frank(a)dticonsulting.com Cc: nanog(a)merit.edu Subject: Re: The Backhoe: A Real Cyberthreat? What data went into the system would depend on what questions you were looking to answer. I spend most of my time looking at the geographic diversity of fiber routes, so I'll use that as a very simple example. To answer that particular set of questions you would need the fiber routes for each provider, and they would need to be georeferenced. Other useful data would be the buildings lit by those fiber routes and lease costs. Users would then enter the buildings they want connectivity for. The system would find all the providers that could service that combination of buildings then calculate what the diversity of each provider is for that set of buildings, or what the diversity was if the user wanted to use more than one provider. Each provider would be given a score for that particular connectivity combination and a price, or the scores for each combination of providers. The user would then have a market indicator for diversity. You could have a vairety of metrics - the total distance between network paths, average distance, the variance, the number of times paths come with 100 feet of each other, the number of routes that are colocated etc. The providers do not give up any proprietary data and the customers have a set of indicators to make a more informed choice. Not the ideal solution, but the game was to come up with something that would be palatable to the providers. Companies like Last Mile Connections already keep provider supplied databases of lit buildings and prices to run auctions. This would just be another indicator for customers that also value diversity and resiliency. Protecting the master database would be important, but there are lots of mechanisms to do that effectively. The metrics are the key, and that of course is my angle on the game. ----- Original Message ----- From: Frank Coluccio <frank(a)dticonsulting.com> Date: Friday, January 20, 2006 1:53 pm Subject: Re: The Backhoe: A Real Cyberthreat? > > >My argument simply is if this kind of awareness > > >can be made more broadly available you end up with > > >a more resilient infrastructure overall. > > > > Sean, would you care to list the route, facility, ownership and > customer > attributes of the data base that you'd make public, and briefly > explain the > > access controls you would impose on same? > > > > If this is not what you originally intended, then please show me > the way ... thanks. > > > > > > Frank > > > > On Fri Jan 20 9:19 , sgorman1(a)gmu.edu sent: > > > > > > > > As you mentioned before this is largely because the customer > (SIAC) was savvy > > enough to set the reuirements and had the money to do it. A lot of > that saviness > > came from lessons learned from 9/11 and fund transfer. Similar > measures were > > taken with DoD's GIG-BE, again because the customer was > knowlegable and had the > > financial clout to enforce the requirements and demand the > information. An > > anonymous data pool is just one suggestion of a market based > mechanism to do it. > > > > ----- Original Message ----- > > From: Michael.Dillon(a)btradianz.com > > Date: Friday, January 20, 2006 5:37 am > > Subject: > > > > > > > > > Imagine if 60 Hudson and 111 8th > > > > were to go down at the same time? Finding means to > mitigate this > > > > threat is not frivolously spending the taxpayer's money, IMO; > > > > although perhaps removing fiber maps is not the best way to > > > > address this. > > > > > > No, removing fiber maps will not address this problem > > > now that you have pinpointed the addresses that they > > > should attack. > > > > > > Separacy is the key to addressing this problem. Separate > > > circuits along separate routes connecting separate routers > > > in separate PoPs. Separacy should be the mantra, not > > > obscurity. > > > > > > End-to-end separation of circuits is how SFTI and other > > > financial industry networks deal with the issue of continuity > > > in the face of terrorism and other disasters. In fact, now > > > that trading is mediated by networked computers, the physical > > > location of the exchange is less vulnerable to terrorists > because > > the real action takes place in redundant data centers connected > > > by diverse separate networks. Since 9-11 was a direct attack on > > > the financial services industry, people within the industry > > > worldwide, have been applying the lessons learned in New York. > > > Another 9-11 is simply not possible today. > > > > > > --Michael Dillon > > > > > > > > > > > > > >

3 2

The Backhoe: A Real Cyberthreat? [ & Re: cyber-redundancy ]
by Frank Coluccio 23 Jan '06

23 Jan '06

>>Trust is a very nebulous concept.<< And mistrust is a far less nebulous concept, obviously. It seems to me that you will dispel just about anything I present in this regard. Do you trust banks that hold your escrow funds during home purchasing? How does Iron Mountain gain the trust of its enterprise customers who archive their IP, tapes, sofware and family jewels with them? The following is very interesting to me: >There is a working group involving several carriers, >financial institutions and the government to create >something for customers with these types of requirements. Which standards body are you referring to that has such a working group? ----Sean Donelan <sean(a)donelan.com>: Sent: Fri Jan 20 19:51: If CPA's were trusted, why aren't there big six CPA firms anymore? Who was the CPA for ENRON? If you trusted them to audit ENRON's financial books, would you also trust them to audit their route information? Why do you think CPA firms would do a better job doing at auditing ENRON's routes than they did their financial books? Trust is a very nebulous concept. Every industry opposes more rules and regulations. Do we really want ordering an ordinary telephone line to require as much paperwork as getting a mortgage? On the other hand, as you know, when you actually read all that paperwork, tariffs, standards, technical practices, etc; carriers don't promise very much. And they usually deliver on that promise. Banks refuse to promise they will never be robbed, and carriers refuse to promise their circuits will never go down. There is a working group involving several carriers, financial institutions and the government to create something for customers with these types of requirements. The challenge is for everyone is deciding what it actually means, how to implement it, and what will it cost. And even after all that, circuits will still go down. Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile

3 2

oof. panix sidelined by incompetence... again.
by Thor Lancelot Simon 23 Jan '06

23 Jan '06

This is hardly as serious as the last incident -- but, well, some people do seem to have all the luck, eh? Of course, there are measures one can take against this sort of thing; but it's hard to deploy some of them effectively when the party stealing your routes was in fact once authorized to offer them, and its own peers may be explicitly allowing them in filter lists (which, I think, is the case here). Sometimes "budget" network connectivity isn't -- even when you've already realized that and turned off the tap! The text below is what's currently in the MOTD on Panix's NetBSD hosts: ====== Con Ed 'stealing' Panix routes (alexis) Sun Jan 22 12:38:16 2006 All Panix services are currently unreachable from large portions of the Internet (though not all of it). This is because Con Ed Communications, a competence-challenged ISP in New York, is announcing our routes to the Internet. In English, that means that they are claiming that all our traffic should be passing through them, when of course it should not. Those portions of the net that are "closer" (in network topology terms) to Con Ed will send them our traffic, which makes us unreachable. We are taking several steps to deal with this: 1) We are announcing "more specific" routes to our peers. More specific routes are always preferred. However, we have to contact network admins at those peers to get them to change their route filters, before this workaround will be effective. 2) We are attempting to reach Con Ed Communications. Unfortunately, so far we've been unable to do so. They don't seem to answer their phones on Sunday. 3) We are attempting to reach Verio, which is "upstream" from Con Ed, because they could (and should!!) choose to ignore the rogue routes from Con Ed. Since all of these depend on humans outside of Panix, we can't give a specific time at which we expect this problem to be worked around (I don't expect a real resolution for a while, because Con Ed is hopeless, but the workaround will be perfect until then). But we do expect to be able to reach responsible parties at our peers within a few hours at most. We don't know how long it will take for them to change their filters, but that's not a challenging job technically, so we hope it won't take long. I'll post another MOTD as soon as we know anything more.

6 5