Re: soBGP deployment
On Thu, 26 May 2005, Tony Li wrote: You're not going to like this. The simplest way to stop the hijacking is going to end up looking a LOT like one of the s*BGP proposals. Here's why: The threat model includes: - Forged origin ASs - Unauthorized advertisements from authenticatable sources - Unauthorized longer prefixes - Forged AS paths and AS path segments - Replay attacks on any of the above The solution, no matter how simple, is constrained: - No single point of failure/single point of attack - Must demonstrate that the AS path is authentic (i.e., not forged) If you cannot authenticate the entire AS path, then all you know is that someone out there wants you to send traffic to them. Any unauthenticated portions of the AS path could easily be forgeries and cover up AS path hackery. - Must demonstrate that the origin is authorized to advertise a prefix Even if the AS path is authenticated, it doesn't mean that I have a right to advertise that space. - Must be reasonably secure, and thus will involve some amount of crypto Thus, from what I can see, the SIMPLEST solution will have: - A distributed means of getting authorization information. Since address space can be delegated in a hierarchical fashion, this mechanism must be able represent that hierarchy, down to the origin AS level. - A distributed means of getting certificate information to authenticate each step on the AS path. The biggest simplification that I can see is to remove any expectation for real-time or near-real-time authentication and authorization, as well as the need for real-time access to the above two distributed databases. If, for example, the several gigabytes (?) of information could be stored locally on all systems before authentication began, that could eliminate some of the requirements for distribution. However, this would require a different mechanism to distribute the information, effectively turning the solution from a secure "pull" model to a secure "push" model. In my (alleged) mind, the hard part about the secure "pull" model was the word 'secure', not the word 'pull', so that doesn't sound too promising. Thus, I'm not seeing anything that seems like it is an order of magnitude less complex than s*BGP. A big +1 from me for EVERYTHING Tony just said. If you want security that can prevent hijacking (and not just act after the fact), then you need to authenticate AS path from the the origin to destination and including authorization of right to announce the ip block itself. And I also don't see any way to avoid hierarchy certificate distribution with root at RIRs. What is possible is that RIRs would only be involved in providing certificate and actual distribution of this information would be done by routing registries (to avoid having RIR directly involved in maintaining routing infrastructure and keep separation of policy & allocations from operations). As far as downloading entire data for authorization - you can cache it, but ultimately you can not rely on it being distributed by protocol which itself depends on routing infrastructure, so it must be possible to pass information as part of BGP from peer-peer. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: soBGP deployment
Daniel, Todd, > The most significant problem is hijacking of IP address space for various > purposes. That's it. Solve that in the SIMPLEST way possible, lets implement > it (because everyone sees the problem) than we can either iteratively > improve the solution or start working on the next solution. You're not going to like this. The simplest way to stop the hijacking is going to end up looking a LOT like one of the s*BGP proposals. Here's why: The threat model includes: - Forged origin ASs - Unauthorized advertisements from authenticatable sources - Unauthorized longer prefixes - Forged AS paths and AS path segments - Replay attacks on any of the above The solution, no matter how simple, is constrained: - No single point of failure/single point of attack - Must demonstrate that the AS path is authentic (i.e., not forged) If you cannot authenticate the entire AS path, then all you know is that someone out there wants you to send traffic to them. Any unauthenticated portions of the AS path could easily be forgeries and cover up AS path hackery. - Must demonstrate that the origin is authorized to advertise a prefix Even if the AS path is authenticated, it doesn't mean that I have a right to advertise that space. - Must be reasonably secure, and thus will involve some amount of crypto Thus, from what I can see, the SIMPLEST solution will have: - A distributed means of getting authorization information. Since address space can be delegated in a hierarchical fashion, this mechanism must be able represent that hierarchy, down to the origin AS level. - A distributed means of getting certificate information to authenticate each step on the AS path. The biggest simplification that I can see is to remove any expectation for real-time or near-real-time authentication and authorization, as well as the need for real-time access to the above two distributed databases. If, for example, the several gigabytes (?) of information could be stored locally on all systems before authentication began, that could eliminate some of the requirements for distribution. However, this would require a different mechanism to distribute the information, effectively turning the solution from a secure "pull" model to a secure "push" model. In my (alleged) mind, the hard part about the secure "pull" model was the word 'secure', not the word 'pull', so that doesn't sound too promising. Thus, I'm not seeing anything that seems like it is an order of magnitude less complex than s*BGP. Regards, Tony
Re: Stanford Hack Exposes 10,000
Thus spake "Jon Lewis" <[EMAIL PROTECTED]> > How hard is it for a university to generate their own student "serial > numbers" as students register? Generating them is trivial. Getting students to remember them is difficult. > Personally, I'd like to see much harsher penalties for identity theft > though (and I'm including simple credit card fraud / use of stolen > credit card info in "identity theft"). This is happening so much, and > is so often just brushed under the rug by the big credit card > companies (banks), that kids do it with impunity, knowing that > odds are they won't be looked for, much less caught. My credit card number was stolen a couple months ago; they went on quite a shopping spree across several states before I discovered it and got the number cancelled. Here's my experience: I filed (or tried to file) police reports in each jurisdiction where the charges occurred, since my bank required the report numbers to process the charge disputes. Two cities simply refused to accept my report since I wasn't a resident, and another required that I file it in person (hundreds of miles away). All but one of the cities that accepted my reports stated flat-out that they wouldn't even attempt to investigate unless _I_ provided _them_ with a suspect. One PD, from a rural town in Oklahoma, was actually very helpful. They went out, pulled all the video tapes, interviewed cashiers and waitresses, etc. and the best they could do was provide a description of the man and his car. I tried forwarding this new info to the other PDs involved, and they uniformly said they still wouldn't investigate unless I provided them with the _name_ of a suspect. Since most of the items purchased were gift certificates from department stores, I called the various stores' loss-prevention departments to give them the transaction numbers and suggest they cancel the certificates before they were redeemed and try to check ID on the perp. Over half refused to talk to me, saying they needed official contact from the local PD (WalMart went so far as to say they'd destroy the tapes if they didn't hear from the cops within 24 hours). The ones that did were happy to provide tapes to the local PD of the person who had already redeemed several certificates, but they had no means to inform a cashier to check someone's ID when they presented the remaining ones which had been cancelled. Of course, the redemption stores were all in different cities than the purchase stores, so when I tried to get the local PDs involved, they refused saying "no crime occurred in our jurisdiction", and the stores wouldn't send the tapes to the PD where the certificates were purchased. All told, about $2300 worth of certificates was redeemed and about $1000 of liquor, food, and gasoline was purchased -- in under a week. Who says crime doesn't pay? > Put a few credit card frauders up in front of a firing squad, and see if > things change. But that would require actually picking them up first, > which LE doesn't seem to be motivated or have the time to do. As long as the card networks are willing to chalk the fraud up to a "cost of doing business", nothing will change. When it starts getting out of hand, you can be sure they'll see to it a special task force in the FBI is started. And it won't help, because the vast majority of fraud is isolated incidents by opportunists, not the rings of professional criminals the FBI understands. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
Re: soBGP deployment
> The thing we should keep in mind is that the problem set is really very > limited. and if we just stick our heads in the sand, it will stay so? have we learned nothing about internet threat models in the last decade? there are very smart and nasty people out there, and there is a very high payoff for them to do bad things to the net. leave a hole, and they will find a way to profit using it. randy
Re: Stanford Hack Exposes 10,000
Howdy all, Somewhere in this thread there is the issue of description of data collection practices, and for those mammals who care (see "Ice Age" with someone under 10 if you need help decoding that), you can do the following: Review the latest working draft (4 January 2005) of the P3P Spec http://www.w3.org/TR/2005/WD-P3P11-20050104/Overview.html and send issues to [EMAIL PROTECTED] and/or post to Bugzilla http://www.w3.org/Bugs/Public/ The activity you'll be assisting is getting P3P 1.1 to (W3C) last call. Like all IMF work, its unpaid, and in the event of capture, the Secretary will disavow ... Eric
Re: Stanford Hack Exposes 10,000
* Jon Lewis: > How hard is it for a university to generate their own student "serial > numbers" as students register? It's probably hard to restructure your databases and rewrite most of your software. 8-( Of course, any unique identifier will do, but it's hard to make the switch.
Re: Route instability in the N.E. US this morning?
maybe this is the cause? -- http://apnews.excite.com/article/20050526/D8AATRQ00.html
Re: Stanford Hack Exposes 10,000
Yes, that seems obvious, but it doesn't happen. Considering the sort of free wheeling environment prevalent in University networks, you would think they would be a bastion of high security. Sadly, this isn't the case. This isn't meant to be a bashing session on universities and other educational systems, just an observation. I would think, and I may be wrong, that a educational network would be subject to - stakeholders (students, faculty, alumni) that turn over quickly, calendar-tied fluctuations in activity, and a user base that tends to be more liberal and risk-tolerant than a typical end user network. I would think that these traits would work against the accumulation of tested operational techniques, appreciation of the time and cost of a reliable service, and stiff enough penalties for anti-cyber-social behavior. Also working against this is the availability of time (like between semesters) when major upgrades can be done, because in the rush to do so sound techniques can be over looked. I don't mean to cast dispersions on educational campus IT functions. There is a lot of good security research and energy available in those environment. I'm just saying the environment is harsher than for other end users. No - I'm not leading up to a suggestion to quarantine them from the rest of the Internet. Stories like this just serve as the example headlines of why any organization ought to take preventative measures when it comes to this kind of data. Hopefully, whatever vulnerabilities that were exploited will be patched, even if there is no public disclosure. (Word will get around when it needs to.) PS - I was more surprised by the case of identity data that was lost when a laptop was stolen. Why was something so valuable left in such a mobile form? http://informationweek.com/story/showArticle.jhtml?articleID=159907962 An example of following bad practices. Is the solution "more consultants?" ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
Re: Suggestions for failover/data-rate limiting
On Thursday, 26-May-2005 12:11, you wrote: > There's a lot of 'it depends' here. > - what are the loads of the links in a steady-state? Peer A typically runs at 80 Mbps. Peer B typically runs at 15 Mbps. Peer C (Internet2) typically runs at 15 Mbps, but frequently spikes to 60 Mbps for extended periods of time. > - how do you rate limit the 2nd link? The upstream currently has a rate limit (and so do we, just in case the provider fat-fingers something in a config), but we want to move away from that, since that would entail manual intervention. > - how are you balancing load among the three links? We aren't. I created the current route maps based on what they wanted (from a financial viewpoint). Based on those financial considerations, we will not load balance, at least not with the three providers we are currently using (and there are no plans to change providers in the near future). > I expect your answer will be in removing any rate limiting > configuration, and setting up some local-prefs on AS's to balance > traffic. Then your expensive 2nd link will take load (and incur > cost) upon failure of link 1. We currently have local prefs in place. They work fine, but we still have the data-rate problem: as long as we make the call to Peer B (or I can get to a computer fast enough to ssh into a router and drop the rate limits), no one complains Management is terrified of getting a huge bill from Peer B, so the rate limits (on both sides) will stay in place until we can find an "automated" solution. I gave up fighting that battle long ago Thanks.
Re: Route instability in the N.E. US this morning?
Granted, this was at about 5:00AM EST or so. So, it may have just been routine maintenance ;). Fergie (Paul Ferguson) wrote: Looked like a "routing tsunami" from down here in Austin. :-) Knocked us out for about a half-hour concur with the suspected origin. Given all the the discussion on the list regarding s*BGP, for a few minutes there I thought someone was just trying to teach us all a hard lesson by injecting massive instability into the DFZ. ;-) - ferg -- "Jonathan M. Slivko" <[EMAIL PROTECTED]> wrote: I saw *almost* 100% packet loss to Verio in Boca Raton, FL this morning, looks like it all started in Ashburn (it was about 80% after a few minutes of mtr running). Fergie (Paul Ferguson) wrote: Anyone know of any issues in the NE this morning? Lot's of routing instability - ferg -- Jonathan M. Slivko - [EMAIL PROTECTED] "Linux: The Choice for the GNU Generation" - http://www.linux.org/ - Don't fear the penguin. .^. /V\ /( )\ ^^-^^ He's here to help.
Re: Route instability in the N.E. US this morning?
Looked like a "routing tsunami" from down here in Austin. :-) Knocked us out for about a half-hour concur with the suspected origin. Given all the the discussion on the list regarding s*BGP, for a few minutes there I thought someone was just trying to teach us all a hard lesson by injecting massive instability into the DFZ. ;-) - ferg -- "Jonathan M. Slivko" <[EMAIL PROTECTED]> wrote: I saw *almost* 100% packet loss to Verio in Boca Raton, FL this morning, looks like it all started in Ashburn (it was about 80% after a few minutes of mtr running). Fergie (Paul Ferguson) wrote: > > Anyone know of any issues in the NE this morning? Lot's of > routing instability > > - ferg >
Re: Route instability in the N.E. US this morning?
I saw *almost* 100% packet loss to Verio in Boca Raton, FL this morning, looks like it all started in Ashburn (it was about 80% after a few minutes of mtr running). Fergie (Paul Ferguson) wrote: Anyone know of any issues in the NE this morning? Lot's of routing instability - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/ -- Jonathan M. Slivko - [EMAIL PROTECTED] "Linux: The Choice for the GNU Generation" - http://www.linux.org/ - Don't fear the penguin. .^. /V\ /( )\ ^^-^^ He's here to help.
Re: soBGP deployment
The thing we should keep in mind is that the problem set is really very limited. Although I acknowledge Tony's cockpit door analogy, we live in the world of today. The most significant problem is hijacking of IP address space for various purposes. That's it. Solve that in the SIMPLEST way possible, lets implement it (because everyone sees the problem) than we can either iteratively improve the solution or start working on the next solution. Steve's attitude (and mine) is pretty close to universal amongst operators. We don't need complexity to solve problems that aren't there. There has been a bit of a historic issue with vendors and IETF folks (congruent sets, yes), telling operators what their problems are and how to fix them. I won't enumerate the various "problems". Hijacked IP address space is a real problem. Simple solution please :) - Dan On 5/26/05 6:33 AM, "Todd Underwood" <[EMAIL PROTECTED]> wrote: > > steve, tony, all, > > just catching up. trying to ignore the TOS fest but the soBGP thread > actually is interesting. > > On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote: > >>> And yet, in the nine or so years I've been working on network >>> infrastructure stuff, spoofed BGP announcements have never been a major >>> cause of problems for me. >> >> That's what we can say so far. Do you really want to wait until we have >> a major problem? > > i want to agree with tony here. i find steve's attitude troubling and > unfortunately common. i hear about hijackings that cause *major* > problems on a regular basis (several times per month) and i hear a lot > of frustration from major *edge* ASes about the inability to do much > about it. in the past two years i've presented at least one, very > interesting, high-profile hijacking at some public event (NOTA peering > forum, S&D peering forum, LINX members meeting, nanog, etc) every 3 > months or so, and i'm not spending *any* time looking for them. > > i also hear a lot of nonchalance on the part of transit and SP ASes > about the problem. and i can understand that. because the current > tools don't give you many options and the current customers want > *cheap* and not *good*. depressing but true. > > i also hear steve's point about not making things work *less* well. > if we've learned anything from the md5 debacle it is that it is easy > to create a new vulnerability or attack vector while preventing a > non-problem. so it's prudent to be cautious. > > but i would suggest that doing anything that could *delay* a *new* > announcement on a *new* path is completely acceptable. it's already > happening now for edge ASes. you get new space. you contact your > providers and peers and tell them to accept it. they do the same > thing. and after a little while (usually more than a day but less > than a week) the advertisements reach some plausible imitation of the > "global" table and you call it good enough. > > so why not seriously consider options that don't impact existing > routes on existing paths, but make it more difficult to get a new > prefix working on a never-before-seen origination path pattern? > > like steve, i haven't yet formed an opnion on soBGP or sBGP (other > than the fact that they've obviously been around for a while and > obviously aren't being implemented by anyone yet). so my comments are > more general. > > t. -- Daniel Golding Network and Telecommunications Strategies Burton Group
Re: Stanford Hack Exposes 10,000
People are missing the point a bit. Most schools HAVE switched over to new numbering systems. Most student ID's have school-specific ID numbers. The problems are: 1) Older student records are indexed by SSN and they must be retained. 2) Some information is still indexed by SSN out of necessity - student financial aid for example That means you have a translation database somewhere, with all those SSNs and the new student index numbers. SSNs are already forbidden going forward at pretty much all school. For example, they can't be used to post grades. However, the need to retain them for backwards compatibility remains. Education institutions need a clear set of guidelines for handling sensitive data like that. A good start would be that such data can only be stored in an encrypted format in a physically secure facility. Yes, that seems obvious, but it doesn't happen. Considering the sort of free wheeling environment prevalent in University networks, you would think they would be a bastion of high security. Sadly, this isn't the case. - Dan On 5/26/05 6:10 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > >>> Around about whenever the US Federal Government gets the hint and >>> passes a bill which makes it illegal to use social security numbers >>> for any purpose other than the administration of social security. > > Wrong answer. Federal laws do not stop people from doing stupid > things and they do not stop people from doing illegal things. > > What we need is a Hollywood blockbuster in which some highschool > hackers wreak havoc by aquiring SSNs from gradesheets and using > mother's maiden names to steal lots of money and identities. > Then, pointy-haired bosses will ask their sysadmins to make sure > that it can't happen in their department. > > Hollywood movies change people's behavior. Federal laws do not. > > --Michael Dillon > -- Daniel Golding Network and Telecommunications Strategies Burton Group
Suggestions for failover/data-rate limiting
We currently have three BGP and MBGP peering sessions, one of which is an Internet2 peer. Our primary peering session (peer A) is a 100 Mbps connection. Our secondary connection (peer B) also is a 100 Mbps connection rate-limited to 19 Mbps (for financial reason). The Internet 2 connection (peer C) is a 100 Mbps connection. Through various route maps, the Internet2 connection has the highest priority. Should that peer go away, Internet2 traffic will then route through peer B. All non-Internet2 traffic takes the path through peer A except for traffic destined for ASs within peer B's network. I have been asked to find a solution which does the following. A. In the event of losing connectivity to peer A, bandwidth limit of 19 Mbps to peer B is automatically increased to 45 Mbps within 1 minute or less, and do this without any manual intervention (i.e., phone call to upstream to change the rate limit). B. The design will need to be resilient to failure (hardware redundant) or, in the case of failure, it should fail safely (do nothing but function as a dumb, pass-through device). All suggestions will be greatly appreciated. Thanks. Sargon
Re: Stanford Hack Exposes 10,000
On Thu, 26 May 2005 [EMAIL PROTECTED] wrote: > > > > Around about whenever the US Federal Government gets the hint and > > > passes a bill which makes it illegal to use social security numbers > > > for any purpose other than the administration of social security. > > Wrong answer. Federal laws do not stop people from doing stupid > things and they do not stop people from doing illegal things. > > What we need is a Hollywood blockbuster in which some highschool > hackers wreak havoc by aquiring SSNs from gradesheets and using Or for some private university to be bankrupted by a class action suit brought by the students who had their identities stolen when the student records db was compromised. How hard is it for a university to generate their own student "serial numbers" as students register? Personally, I'd like to see much harsher penalties for identity theft though (and I'm including simple credit card fraud / use of stolen credit card info in "identity theft"). This is happening so much, and is so often just brushed under the rug by the big credit card companies (banks), that kids do it with impunity, knowing that odds are they won't be looked for, much less caught. Last time one of my cards was "stolen" (from an online merchant I assume), I managed to social engineer the IP from which it was used from one of the online establishments where they used my card. It was a Linux box on DSL in California. Did anybody care? Not that I'm aware of. I filed complaints with the appropriate government agencies, and AFAIK, nothing happened. Put a few credit card frauders up in front of a firing squad, and see if things change. But that would require actually picking them up first, which LE doesn't seem to be motivated or have the time to do. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Route instability in the N.E. US this morning?
Anyone know of any issues in the NE this morning? Lot's of routing instability - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: BCP regarding TOS transparancy for internet traffic
> Overwriting the tos flags is not "best effort", it is "degraded service" So how do you propose to control the use of TOS flags within a network? If I have an application that receives specific treatment because of its TOS flags, I need to prevent non-compliant traffic from using this TOS flag at other ingress points. This requires either dropping that traffic or rewriting the flag.
Re: soBGP deployment
On Thu, 26 May 2005, Todd Underwood wrote: > the scalability problem, as i understand it (not at all an expert > here) is that routers won't currently handle such a list with regexps > very well. apparently, ciscos will not allow filtering advertisements > on a combination of prefix + as-path regexp at all and junipers will, > but the perception is that they will not scale to a list of 300-500K > (which is the union of routes in global tables without any > consolidation). if you could consolidate all equally originated > prefixes under their covering supernets and still adequately filter, > that number would be *much* smaller, obviously. Or if you could do it based on atoms rather than prefixes. But atoms have been looking like a trickier concept than I first thought, as we've started to look at them. -Bill
Re: soBGP deployment
On Thu, 26 May 2005, Todd Underwood wrote: > the list of all prefixes seen in the global table combined with all > origination patterns seen for the past 6 months or so is realively > easy to produce. This is something that we, or RIPE/RIS, or RouteViews, could produce and cryptographically sign immediately. Trivial script. We could have it up and available by https and updated once a day, in a matter of a day or two. If anybody feels like it would be solving a problem. -Bill
Re: Stanford Hack Exposes 10,000
On Wed, 25 May 2005, Jay R. Ashworth wrote: The major problem, as has been pointed out in Privacy and RISKS digests in the past dozens of times, is that people persist in using as authenticators things (like SSN's, Mother's Maiden Name, etc) which are patently not suitable for that. pre-existing sources of of unabigious uniqueness that map to people are hard to come by... fwiw, most universities that I'm aware of, have moved away from using ssn's as an authentication tool. joelja Cheers, -- jra -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: Stanford Hack Exposes 10,000
On Thu, May 26, 2005 at 11:10:08AM +0100, [EMAIL PROTECTED] wrote: > > > Around about whenever the US Federal Government gets the hint and > > > passes a bill which makes it illegal to use social security numbers > > > for any purpose other than the administration of social security. > > Wrong answer. Federal laws do not stop people from doing stupid > things and they do not stop people from doing illegal things. > > What we need is a Hollywood blockbuster in which some highschool > hackers wreak havoc by aquiring SSNs from gradesheets and using /// criminals > mother's maiden names to steal lots of money and identities. > Then, pointy-haired bosses will ask their sysadmins to make sure > that it can't happen in their department. > > Hollywood movies change people's behavior. Federal laws do not. "Mr President, did you see that movie about an Ebola outbreak in the US a couple of years ago?" "Yes...?" "The budget for that movie was quite a bit more then the total annual funding in the US to study Ebola and related viruses." Cheers, -- jr '' a -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth & AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: More on Moscow power failure( was RE: Moscow: global power outage)
Finally, a bit more info found in this Russian article http://www.comnews.ru/index.cfm?id=15645 According to the director of a well-known but unnamed Russian telecoms company, there were no diesel generators at MSK-IX. They had 3 external power feeds which all failed at once due to the cascading failure. UPS systems lasted from one-half to two hours. He says that they learned the lesson that they need to build a few distributed and technically independent exchanges even in the capital, Moscow. Some background on the power failure. It started with a fire in old equipment which caused a major power station to shed load and shut down in the middle of the night. As the sun rose and Moscow's power demands grew, this initiated a cascading failure which spread 200 kms south. However, it did not affect most of the northern half of the city. It did not affect the military who switched to their own generators. This is rather important considering that this "military" is responsible for roughly half of the serious nuclear weapons arsenal in the world. The military brought out their portable generators to support hospitals so it would appear that all hospitals did not have independent backup power. In Southern Moscow, much of the cellular telephone service also failed. In one of the regional towns a chemical factory released a cloud of nitrogen oxides which cause the population to panic and begin evacuation because in that town even the landlines had failed. After a lot of work, most power stations were back online this morning. There were only 400 apartment buildings with no power compared to thousands yesterday. The damaged station where the fire occurred is still not functioning and some backup power generation is still in place. The metro is running but some suburban electrical train lines are still shutdown. All in all, this was a remarkable event. The causes were identified so quickly. They recovered from the outage so quickly. The country's major Internet exchange was shown to be remarkably short-sighted. --Michael Dillon
Re: More on Moscow power failure( was RE: Moscow: global power outage)
The Russian media have lots of details about the power outage, but the general media hardly mentions the fact that there was a disruption of Internet service. The MSK-IX web page still has no news about the incident and no explanation as to why they shut down. Here is one Russian article that covers the shutdown http://www.webplanet.ru/news/internet/2005/5/25/shit_happens.html but they are scratching their heads as well. They say it is completely incomprehensible why MSK-IX was shut down because there should have been a reserve generator system in place. According to them, during normal times 80% of Russian Internet traffic passes through MSK-IX. Traffic did get rerouted to alternate international routes, however they became clogged up because the major international routes all rely on MSK-IX. Major Russian websites maintained power at their own data centres but that didn't help when most of their traffic goes through MSK-IX. The article summarizes by saying that the chief problem today is that there is not alternative internet exchange in Moscow and that means that it is easy to cut off Moscow from the Internet, even easier than one might have thought it would be. To that, I would add that Russia's entire telecomms infrastructure is still too highly centralized on Moscow. Even in a small country like England, we are moving away from centralizing everything through the capital city. Yet another lesson in how a single-point-of-failure is just plain bad design which *WILL* bite somebody in the end. --Michael Dillon
Re: soBGP deployment
steve, tony, all, just catching up. trying to ignore the TOS fest but the soBGP thread actually is interesting. On Wed, May 25, 2005 at 03:51:25PM -0700, Tony Li wrote: > > And yet, in the nine or so years I've been working on network > > infrastructure stuff, spoofed BGP announcements have never been a major > > cause of problems for me. > > That's what we can say so far. Do you really want to wait until we have > a major problem? i want to agree with tony here. i find steve's attitude troubling and unfortunately common. i hear about hijackings that cause *major* problems on a regular basis (several times per month) and i hear a lot of frustration from major *edge* ASes about the inability to do much about it. in the past two years i've presented at least one, very interesting, high-profile hijacking at some public event (NOTA peering forum, S&D peering forum, LINX members meeting, nanog, etc) every 3 months or so, and i'm not spending *any* time looking for them. i also hear a lot of nonchalance on the part of transit and SP ASes about the problem. and i can understand that. because the current tools don't give you many options and the current customers want *cheap* and not *good*. depressing but true. i also hear steve's point about not making things work *less* well. if we've learned anything from the md5 debacle it is that it is easy to create a new vulnerability or attack vector while preventing a non-problem. so it's prudent to be cautious. but i would suggest that doing anything that could *delay* a *new* announcement on a *new* path is completely acceptable. it's already happening now for edge ASes. you get new space. you contact your providers and peers and tell them to accept it. they do the same thing. and after a little while (usually more than a day but less than a week) the advertisements reach some plausible imitation of the "global" table and you call it good enough. so why not seriously consider options that don't impact existing routes on existing paths, but make it more difficult to get a new prefix working on a never-before-seen origination path pattern? like steve, i haven't yet formed an opnion on soBGP or sBGP (other than the fact that they've obviously been around for a while and obviously aren't being implemented by anyone yet). so my comments are more general. t. -- _ todd underwood director of operations & security renesys - interdomain intelligence [EMAIL PROTECTED] www.renesys.com
Re: soBGP deployment
On Thu, 26 May 2005, Jeroen Massar wrote: In short, you mean setting up, eg a Quagga box behind the existing core infra that one has, feeding it a full feed, which matches the current best paths one has in it's RIB and verifying the paths. This is somewhat similar how the detection of GRH (*1) works already for IPv6 tables, that is it nightly fetches the route6 objects from various registries(*1) and checks if a AS is registered to be allowed to announce a certain prefix, if not it marks it in the looking glass as being a bad route which is supposed to be routed from the registered AS. Now, if BGP would have some signature over the the path, one could verify this in the same method and have the exact thing happening above. GRH sends out mailings every day, though one could of course implement the above in realtime. If one would mirror the full table, one could even analyze the alternative paths to see if those are valid. What you mention, does indeed not break current operations and would be quite transparent. If I understand it right soBGP is kind of like that. In short different between SBGP and soBGP is that SBGP sends AS Path as signed data where as soBGP AS Path is separate and security is in a detached signatures which can optionally be sent along in bgp session as well. There also seem to be policy differences on how it is determined if path is good or bad, but overall the concept is not as bad as I originally thought. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: soBGP deployment
tony, all, On Wed, May 25, 2005 at 04:24:07PM -0700, Tony Li wrote: > Fundamentally, there is a serious scalability issue with doing > everything at configuration generation time. Since one cannot predict > with certainty what AS paths will be seen for which prefix, one would > have to authenticate each and every possible path and then encode the > authenticated paths in the configuration. but you don't really have to do this to solve a big chunk of the problem. wouldn't it be a good start to simply be able to authenticate originations? and by originations, i don't just mean the single AS, but i the set of length-2 paths that form the existing originations for a prefix. the list of all prefixes seen in the global table combined with all origination patterns seen for the past 6 months or so is realively easy to produce. the scalability problem, as i understand it (not at all an expert here) is that routers won't currently handle such a list with regexps very well. apparently, ciscos will not allow filtering advertisements on a combination of prefix + as-path regexp at all and junipers will, but the perception is that they will not scale to a list of 300-500K (which is the union of routes in global tables without any consolidation). if you could consolidate all equally originated prefixes under their covering supernets and still adequately filter, that number would be *much* smaller, obviously. t. -- _ todd underwood director of operations & security renesys - interdomain intelligence [EMAIL PROTECTED] www.renesys.com
Re: soBGP deployment
On Wed, 2005-05-25 at 16:24 -0700, Tony Li wrote: > For example, an operator can begin by enabling authentication on a BGP > speaker that is wholly outside of the traffic path. Instability of this > one speaker would have no effect on production traffic. Authentication > alarms generated by this speaker could be set up to do nothing more than > send a syslog message to operations personnel who would need to > intervene manually to actually change production BGP path selection. > For testing authentication, a host behind this speaker could monitor > reachability. In short, you mean setting up, eg a Quagga box behind the existing core infra that one has, feeding it a full feed, which matches the current best paths one has in it's RIB and verifying the paths. This is somewhat similar how the detection of GRH (*1) works already for IPv6 tables, that is it nightly fetches the route6 objects from various registries(*1) and checks if a AS is registered to be allowed to announce a certain prefix, if not it marks it in the looking glass as being a bad route which is supposed to be routed from the registered AS. Now, if BGP would have some signature over the the path, one could verify this in the same method and have the exact thing happening above. GRH sends out mailings every day, though one could of course implement the above in realtime. If one would mirror the full table, one could even analyze the alternative paths to see if those are valid. What you mention, does indeed not break current operations and would be quite transparent. Greets, Jeroen *1 = http://www.sixxs.net/tools/grh/ *2 = http://www.sixxs.net/tools/grh/how/ signature.asc Description: This is a digitally signed message part
Re: Stanford Hack Exposes 10,000
> > Around about whenever the US Federal Government gets the hint and > > passes a bill which makes it illegal to use social security numbers > > for any purpose other than the administration of social security. Wrong answer. Federal laws do not stop people from doing stupid things and they do not stop people from doing illegal things. What we need is a Hollywood blockbuster in which some highschool hackers wreak havoc by aquiring SSNs from gradesheets and using mother's maiden names to steal lots of money and identities. Then, pointy-haired bosses will ask their sysadmins to make sure that it can't happen in their department. Hollywood movies change people's behavior. Federal laws do not. --Michael Dillon
Re: More on Moscow power failure( was RE: Moscow: global power outage)
> More from MosNews: This is a publication run by right-wing ex-pat American business men with an ax to grind. > President Vladimir Putin has already blamed UES Chief Executive > Anatoly Chubais for the power cut which left much of the capital > without power, saying management had neglected the company?s > problems to concentrate on a restructuring plan. And Anatoly Chubais said: Here it is not possible to be of two minds, RAO "UES Russia" and I, personally as management, are responsible for the accident. All of this is on our conscience, nobody is going to shift the responsibility, but the basic actions are now directed towards restoration of service and on blocking the development more failures. Would the CEO of your company be as forthright, even in today's post-Enron, post-Worldcom world? The technical roots of the failure have been blamed on equipment dating from 1958-1962 timeframe which wasn't kept repaired and up-to-date. This is reminiscent of the Comair systems failure http://www.cio.com/archive/050105/comair.html and the 9-11 problems with emergency responder preparedness and the Challenger O-ring failure and the Columbia foam incident. How many old and forgotten devices and systems are doing mission critical jobs in your network? --Michael Dillon
Re: BCP regarding TOS transparancy for internet traffic
On Wed, 25 May 2005, Eric A. Hall wrote: Again, you are under no obligation to do anything with QoS flags from non-paying customers, and I'm not advocating for anybody to get a free ride here. Ignore the markings, but leave them alone too. Yes please. HOW? That is what I have been asking since the first post - how do you suggest honoring DSCP for paying customers AND ignoring them for non-paying customers (while leaving them alone) - WITHOUT putting the traffic onto "dedicated" networks (be it L2 or L3)? If you can answer that single question I'll shut up and run along to implement it. (And keep in mind not all providers have a full MPLS core, so let's stick to normal IP forwarding please). /leg
