Slashdot Mirror

Perhaps looking closer to the actual source would help your understanding? One of the instances was traffic from Denver, CO to Denver, CO ended up going through Iceland. While I can believe Denver might not have a peering point in the city, it seems rather unlikely the closest exchange would be in Iceland. This could possibly be explained being due to some network oddity, that still seems rather a bit odd.

Looks like Cuba's trying it.

Why does Slashdot keep linking to secondary sources, like Forbes.com, when the primary source is so easily available? Laziness would be my first guess.

Here is the much-better Renesys blog post: http://www.renesys.com/blog/2012/11/could-it-happen-in-your-countr.shtml

Questions about their methods of reasoning are the most interesting.

There may be 5 ISPs, each operating their own logical notwork, with their own IP space, servers, and everything--but they may all share the same physical fibre optic cable out of the country--especially if the country is an Island. New Zealand would be a good example of this: it is about 1500 km from Australia, and 1000 km from Fiji. There are only a few submarine fibre optic cables connecting to the rest of the world. Perhaps Southern Cross Cable and SPIN only?

The authors acknowledge they were mostly unable to analyse this, and had to guess about the number of physical conduits. They say they will have more to say about the limited physical connections in the future.

IP address ownership, sadly, doesn't prove anything. Anyone with a BGP connection can hijack any IP address for large parts of the world. And before you say "but surely Google can prevent this" :

Read this

I've been the admin on 3 networks which were IP hijacked now. In two cases it was accidental, in a third case it was not. The situation is bad in North America, seriously disappointing in Western Europe, and beyond outrageous everywhere else. Basically, outside of North America and Europe you can pretty much assume anyone can hijack anything they want. Inside "the West" you have to be a carrier, a transit provider with a few hundred customers. Which sounds good, until you realize there's over 500 such organizations in North America alone.

If you think you need to hack a router to redirect traffic on the internet, then you are wrong.

As an example:
http://www.renesys.com/blog/2010/11/chinas-18-minute-mystery.shtml

This is a large version, it obviously happends frequently on a small scale.

renesys: info about network
saturday's news: Syrian forces kill 6: protesters - Government eases internet stranglehold
current news: Syrian forces kill 35 in fresh crackdown: report

'Be patient Syria, the victory is written by the blood,'

There is a bigger picture involved.

During the Egyptian revolution the telecom companies, instead of supporting the people, complied with and acted upon the requests of a tyrannical leader to shut down internet access, in an attempt to silence the people. [1]

They also complied to send out pro-government, anti-democracy [2] mobile text messages [3].

Don't buy Vodafone's excuse, they abide to a mad man's "emergency laws", while the people and journalists risked life and limb to have their voice heard. Vodafone agreed to his terms, a guy who is now facing the death penalty under charge or premeditated murder against civilians[5], and need to grow a pair.

And do you know why?
"Its not clear who paid for the messages which could amount to hundred of thousands of dollars worth of messaging."

[1] http://english.aljazeera.net/news/middleeast/2011/01/2011128796164380.html
[2] http://www.businessday.co.za/articles/Content.aspx?id=133349
[3] http://liberalconspiracy.org/2011/02/03/unsolicited-pro-mubarak-text-messages-from-egypt/
[4] http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml
[5] http://www.reuters.com/article/2011/05/24/us-egypt-mubarak-idUSTRE74N3LG20110524

A pretty wide range of Algerian providers (Telecom Algeria, Wataniya Telecom Algeria, SPA Anwarnet, Smart Link, Orascom/Djezzy, etc.) have direct international connectivity, as seen in the BGP routing table. See here.

That makes it pretty hard for a tin-horn dictator to proxy all of these. (Algeria is not known as a great source of networking expertise).

I suspect it would be much easier to put up a dummy facebook server (honypot) and simply have it deny all log in attempts. A few dns entries at each ISP suckers in a lot of people.

The consensus in the networking community is that the Internet to / from Algeria has not been shut down. See the Renesys blog for more details.

The situation with regards to social media is more uncertain, with reports of both blockage and routine service.

WTF is the damn difference? What BS is this statement trying to make? Am I supposed to feel better about the pending 'Kill Switch'?

It actually does make a difference, because it means that the Mubarak regime was able to keep each ISP scared enough to intimidate them into doing exactly what they said, even when that meant effectively cutting off their business. The timing of the calls -a little more than 13 minutes total- tells us that there was no hesitation from any of the ISPs. The only exception was the Noor group, who somehow managed to evade this order and remain online for days after the others had disappeared.

The fact that a government functionary can pick up the phone, say, "Shut down your network" and be complied with without the slightest hesitation doesn't say a thing about technology, but it teaches us a lot about the nature of government, and perhaps makes it a little clearer to those of us in the outside world just what the pro-democracy protesters were willing to risk their lives for.

Side note: It was James Cowie at Renesys who first posited this scenario within hours of the shutdown.

I wrote a much longer consideration of the effects of the Egyptian outage for my country's national daily. In a nutshell, the design of our physical networks makes them vulnerable to the kind of coercive pressure exerted by the Mubarak regime. And a some of the powers-that-be like it like that.

Renesys reports that the big four ISPs in Egypt have withdrawn approximately 3,500 individual BGP routes, leaving no valid paths by which to reach the rest of the world. One of the very few exceptions to this block has been Noor Group.

http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml

The Rensys blog has a similar, but more detailed, analysis of the withdrawal of Egyptian BGP announcements.

Like BGPMon, they note that the Noor Data group has not been shut off, and note that the "the Egyptian Stock Exchange (www.egyptse.com) is still alive at a Noor address." I have to suspect that this is not a coincidence.

One has to wonder what economic damage will be done by disconnecting a whole country from the Internet. Keeping the stock exchange on-line may not be enough.

According to renesys, all but one of the ISPs are offline - the one which carries the country's stock exchange: http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml

How long before the Iranian government lays all new fiber to a central military facility and then disable the now-current fiber links? The idea being total central control to turn off the internet connection entirely or by segments from one physical location.

What makes you think they don't route everything through a central location already?

Here's an analysis of the outage immediately following the presidential election. I'll let you draw your own conclusions.

Interesting articles about the general state of Iranian connectivity.

http://www.renesys.com/blog/2009/06/strange-changes-in-iranian-int.shtml
http://www.circleid.com/posts/20060617_iran_and_the_internet_uneasy_standoff/

Seems like Iran is well connected, but slashdotted since everyone is interested.

Renesys is a fairly neutral source for information about peering (as opposed to Cogent's press release, which is obviously their side of the story.) The Forbes article is good perspective, but it's from before Sprint dropped Cogent. BTW, Sprint and Cogent have only been peering for two years; before that Cogent had to pay to connect to them.

This one just came across on NANOG: Wrestling With the Zombie: Sprint Depeers Cogent, Internet Partitioned

http://www.renesys.com/blog/2008/10/wrestling-with-the-zombie-spri.shtml

This is a smaller amount than in past disputes where Cogent offered free GigabitEthernets to others. Someone else noticed that it's been exactly 2 years since they brought up a direct connection. Something smells fishy here.

http://www.renesys.com/blog/2006/11/sprint-and-cogent-peer.shtml

Cogent does not buy transit [0] , they've become Tier 1, my guess is Sprint isn't happy with how much traffic is flowing over some connections and wants money (think: paid peering).

[0] http://www.renesys.com/blog/2008/06/cogent-becomes-transitfree.shtml

A man-in-the-middle attack on BGP would require that you intercept and re-write BGP data. The only place to do that is if you can insert some hardware on the physical route between two BGP-speaking routers. That is, on the cable between two ISPs that are peering with each other or have a transit agreement. While the BGP protocol could, in theory, be routed across the internet, my understanding is that in practice it never is.

Add to that that to successfully perform such an attack, you would need appropriate (expensive) network interfaces and hardware capable of speaking fast enough, and this "attack" becomes something that needs a *lot* of resources to pull off. Sure, governments and big corporations can do it, maybe big organised crime could too, but yer average bedroom cracker couldn't.

And why would the big boys bother anyway, when they can just announce bogus routes?

Go read the thread on NANOG. Or read the timeline here: http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

The way this happened is the result of a fundamental weakness in BGP. A more specific prefix will trump a less specific one, so anyone who has a valid peer can advertise a more specific route and hijack IP space. This is frequently used by Cybercriminals to squat on unused IP space in larger netblocks.

There have been proposals to address this issue for some time. Maybe, now that a major site has fallen victim, something will actually be done about it.

Of course, we could solve the problem the way it was when the Internet was first designed: only allow trusted entities to connect at all. IMNSHO, if the Islamic world don't want to be in the 21st century, that's their choice, but they can't have their cake and eat it too. Unless and until they agree to the basic principles of the Internet: freedom of association and speech, they shouldn't be allowed to connect at all.

This was discussed yesterday, but somehow the mods didn't control the discussion degenerating into a debate about circumcision.

For those of you who actually want to know "How they did it?" posted from: Renesys Blog
which was found from Cydeweys which is updating as the story progresses. Both of those sites seem to be running a bit slow, so hesitate before clicking.

Full text of Reneysys: Pakistan hijacks YouTube.

A few hours ago, Pakistan Telecom (AS 17557) began advertising a small part of YouTube's (AS 36561) assigned network. This story is almost as old as BGP. Old hands will recognize this as, fundamentally, the same problem as the http://merit.edu/mail.archives/nanog/1997-04/msg00380.html">infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet's Christmas Eve gift 2005.

Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item) started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.

I became interested in this immediately as I was concerned that I wouldn't be able to spend my evening watching imbecilic videos of cats doing foolish things (even for a cat). Then, I started to examine our mountains of BGP data and quickly noticed that the correct AS path ("Will the real YouTube please stand up?") was getting restored to most of our peers.

The data points identified below are culled from over 250 peering sessions with 170 unique ASNs. While it is hard to describe exactly how widely this hijacked prefix was seen, we estimate that it was seen by a bit more than two-thirds of the Internet.

This table shows the timing of the event and how quickly the route propagated (this is actually a fairly normal propagation pattern). The ASNs seeing the prefix were mostly transit ASNs below, so this means that these routes were distributed broadly across the Internet. Almost all of the default free zone (DFZ) carried the hijacked route at least briefly.

18:47:00uninterrupted videos of exploding jello

18:47:45first evidence of hijacked route propagating in Asia, AS path 3491 17557

18:48:00several big trans-Pacific providers carrying hijacked route (9 ASNs)

18:48:30several DFZ providers now carrying the bad route (and 47 ASNs)

18:49:00most of the DFZ now carrying the bad route (and 93 ASNs)

18:49:30all providers who will carry the hijacked route have it (total 97 ASNs)

20:07:25YouTube, AS 36561 advertises the /24 that has been hijacked to its providers

20:07:30several DFZ providers stop carrying the erroneous route

20:08:00many downstream providers also drop the bad route

20:08:30and a total of 40 some-odd providers have stopped using the hijacked route

20:18:43and now, two more specific /25 routes are first seen from 36561

20:19:3725 more providers prefer the /25 routes from 36561

20:28:12peers of 36561 start seeing the routes that were advertised to transit at 20:07

20:50:59evidence of attempted prepending, AS path was 3491 17557 17557

20:59:39hijacked prefix is withdrawn by 3491,

For those of you who actually want to know "How they did it?" posted from: Renesys Blog
which was found from Cydeweys which is updating as the story progresses. Both of those sites seem to be running a bit slow, so hesitate before clicking.

Full text of Reneysys: Pakistan hijacks YouTube.

A few hours ago, Pakistan Telecom (AS 17557) began advertising a small part of YouTube's (AS 36561) assigned network. This story is almost as old as BGP. Old hands will recognize this as, fundamentally, the same problem as the http://merit.edu/mail.archives/nanog/1997-04/msg00380.html">infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet's Christmas Eve gift 2005.

Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item) started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.

I became interested in this immediately as I was concerned that I wouldn't be able to spend my evening watching imbecilic videos of cats doing foolish things (even for a cat). Then, I started to examine our mountains of BGP data and quickly noticed that the correct AS path ("Will the real YouTube please stand up?") was getting restored to most of our peers.

The data points identified below are culled from over 250 peering sessions with 170 unique ASNs. While it is hard to describe exactly how widely this hijacked prefix was seen, we estimate that it was seen by a bit more than two-thirds of the Internet.

This table shows the timing of the event and how quickly the route propagated (this is actually a fairly normal propagation pattern). The ASNs seeing the prefix were mostly transit ASNs below, so this means that these routes were distributed broadly across the Internet. Almost all of the default free zone (DFZ) carried the hijacked route at least briefly.

18:47:00uninterrupted videos of exploding jello

18:47:45first evidence of hijacked route propagating in Asia, AS path 3491 17557

18:48:00several big trans-Pacific providers carrying hijacked route (9 ASNs)

18:48:30several DFZ providers now carrying the bad route (and 47 ASNs)

18:49:00most of the DFZ now carrying the bad route (and 93 ASNs)

18:49:30all providers who will carry the hijacked route have it (total 97 ASNs)

20:07:25YouTube, AS 36561 advertises the /24 that has been hijacked to its providers

20:07:30several DFZ providers stop carrying the erroneous route

20:08:00many downstream providers also drop the bad route

20:08:30and a total of 40 some-odd providers have stopped using the hijacked route

20:18:43and now, two more specific /25 routes are first seen from 36561

20:19:3725 more providers prefer the /25 routes from 36561

20:28:12peers of 36561 start seeing the routes that were advertised to transit at 20:07

20:50:59evidence of attempted prepending, AS path was 3491 17557 17557

20:59:39hijacked prefix is withdrawn by 3491,

For those of you who actually want to know "How they did it?" posted from: Renesys Blog
which was found from Cydeweys which is updating as the story progresses. Both of those sites seem to be running a bit slow, so hesitate before clicking.

Full text of Reneysys: Pakistan hijacks YouTube.

A few hours ago, Pakistan Telecom (AS 17557) began advertising a small part of YouTube's (AS 36561) assigned network. This story is almost as old as BGP. Old hands will recognize this as, fundamentally, the same problem as the http://merit.edu/mail.archives/nanog/1997-04/msg00380.html">infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet's Christmas Eve gift 2005.

Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item) started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.

I became interested in this immediately as I was concerned that I wouldn't be able to spend my evening watching imbecilic videos of cats doing foolish things (even for a cat). Then, I started to examine our mountains of BGP data and quickly noticed that the correct AS path ("Will the real YouTube please stand up?") was getting restored to most of our peers.

The data points identified below are culled from over 250 peering sessions with 170 unique ASNs. While it is hard to describe exactly how widely this hijacked prefix was seen, we estimate that it was seen by a bit more than two-thirds of the Internet.

This table shows the timing of the event and how quickly the route propagated (this is actually a fairly normal propagation pattern). The ASNs seeing the prefix were mostly transit ASNs below, so this means that these routes were distributed broadly across the Internet. Almost all of the default free zone (DFZ) carried the hijacked route at least briefly.

18:47:00uninterrupted videos of exploding jello

18:47:45first evidence of hijacked route propagating in Asia, AS path 3491 17557

18:48:00several big trans-Pacific providers carrying hijacked route (9 ASNs)

18:48:30several DFZ providers now carrying the bad route (and 47 ASNs)

18:49:00most of the DFZ now carrying the bad route (and 93 ASNs)

18:49:30all providers who will carry the hijacked route have it (total 97 ASNs)

20:07:25YouTube, AS 36561 advertises the /24 that has been hijacked to its providers

20:07:30several DFZ providers stop carrying the erroneous route

20:08:00many downstream providers also drop the bad route

20:08:30and a total of 40 some-odd providers have stopped using the hijacked route

20:18:43and now, two more specific /25 routes are first seen from 36561

20:19:3725 more providers prefer the /25 routes from 36561

20:28:12peers of 36561 start seeing the routes that were advertised to transit at 20:07

20:50:59evidence of attempted prepending, AS path was 3491 17557 17557

20:59:39hijacked prefix is withdrawn by 3491,

For those of you who actually want to know "How they did it?" posted from: Renesys Blog
which was found from Cydeweys which is updating as the story progresses. Both of those sites seem to be running a bit slow, so hesitate before clicking.

Full text of Reneysys: Pakistan hijacks YouTube.

A few hours ago, Pakistan Telecom (AS 17557) began advertising a small part of YouTube's (AS 36561) assigned network. This story is almost as old as BGP. Old hands will recognize this as, fundamentally, the same problem as the http://merit.edu/mail.archives/nanog/1997-04/msg00380.html">infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet's Christmas Eve gift 2005.

Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item) started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.

I became interested in this immediately as I was concerned that I wouldn't be able to spend my evening watching imbecilic videos of cats doing foolish things (even for a cat). Then, I started to examine our mountains of BGP data and quickly noticed that the correct AS path ("Will the real YouTube please stand up?") was getting restored to most of our peers.

The data points identified below are culled from over 250 peering sessions with 170 unique ASNs. While it is hard to describe exactly how widely this hijacked prefix was seen, we estimate that it was seen by a bit more than two-thirds of the Internet.

This table shows the timing of the event and how quickly the route propagated (this is actually a fairly normal propagation pattern). The ASNs seeing the prefix were mostly transit ASNs below, so this means that these routes were distributed broadly across the Internet. Almost all of the default free zone (DFZ) carried the hijacked route at least briefly.

18:47:00uninterrupted videos of exploding jello

18:47:45first evidence of hijacked route propagating in Asia, AS path 3491 17557

18:48:00several big trans-Pacific providers carrying hijacked route (9 ASNs)

18:48:30several DFZ providers now carrying the bad route (and 47 ASNs)

18:49:00most of the DFZ now carrying the bad route (and 93 ASNs)

18:49:30all providers who will carry the hijacked route have it (total 97 ASNs)

20:07:25YouTube, AS 36561 advertises the /24 that has been hijacked to its providers

20:07:30several DFZ providers stop carrying the erroneous route

20:08:00many downstream providers also drop the bad route

20:08:30and a total of 40 some-odd providers have stopped using the hijacked route

20:18:43and now, two more specific /25 routes are first seen from 36561

20:19:3725 more providers prefer the /25 routes from 36561

20:28:12peers of 36561 start seeing the routes that were advertised to transit at 20:07

20:50:59evidence of attempted prepending, AS path was 3491 17557 17557

20:59:39hijacked prefix is withdrawn by 3491,

The claim "It took about 80 minutes for YouTube to inform its providers that the route had been hijacked." is neither true nor relevant. YouTube's own providers are pretty much irrelevant to hijacking of YouTube space.

The Renesys link is good, and the cydeweys blog has good comments.

No sources support your claim of inaction on YouTube's part.

Better technical explanations of the event are available from the Renesys blog and Data Center Knowledge. The erroneous IP assignments spread across the net within 1 minute, 45 seconds of its announcement by Pakistan Telecom, according to a timeline by Renesys. It took about 80 minutes for YouTube to inform its providers that the route had been hijacked. YouTube says it is "investigating and working with others in the Internet community to prevent this from happening again."

http://www.iust.ac.ir/
IP: 194.225.230.89
Machine Location: Tehran, Iran

http://www.mfa.gov.ir/
IP: 217.172.99.41
Machine Location: Tehran, Iran

http://www.cbi.ir/
IP: 217.218.174.178
Machine Location: Tehran, Iran

http://www.renesys.com/blog/2008/02/attention_iran_is_not_disconne_1.shtml

These people think he's wrong:
Iran is not Disconnected

That being said, there have been a number of Earthquakes undersea lately.

Here's an Accurate Description of what's going on. Linkey
I love how all the conspiracy theroists are here on /. Paranoia is good for systems administration, and bad for foreign policy. It's a nice idea and maybe the GCC is getting a clear cut message, however the internet is a U.S. invention, sadly pandora's box cannot be closed.

Let's get a bit of perspective here.

The internet Health Report shows that connectivity to Iran is down. It's Really only showing connectivity to a single Router is down.
http://www.internettrafficreport.com/asia.htm
As of this time it's also showing Indonesia is down.

This site has a great writeup from the past several days regarding the cable break
http://www.renesys.com/blog/

Tin Foils hats are appropriate at times. I'm not sure this is one of those times.
Of course.. I thought the first plane was an accident..............

I'm also somewhat skeptical that Iran has "dropped off the net" -- see http://www.renesys.com/blog/2008/02/attention_iran_is_not_disconne_1.shtml which actually cites a Slashdot post as evidence of how the lie goes round the world before the truth gets it's boots on... just because ITR shows no response from a single router in .ir, that doesn't mean there's no connectivity.

And for the conspiracy theorists, why would cutting cables (with massive collateral damage to all those US and EU businesses that are using Indian call centres and outsourced dev firms) be a precursor to a military attack? Not only would it give the Iranians a completely obvious early warning of incoming trouble, it gives no military advantage at all that I can think of. Presumably the Iranian military do not communicate through IM or blogs...

I'm also somewhat skeptical that Iran has "dropped off the net" -- see http://www.renesys.com/blog/2008/02/attention_iran_is_not_disconne_1.shtml which actually cites a Slashdot post as evidence of how the lie goes round the world before the truth gets it's boots on... just because ITR shows no response from a single router in .ir, that doesn't mean there's no connectivity.

And for the conspiracy theorists, why would cutting cables (with massive collateral damage to all those US and EU businesses that are using Indian call centres and outsourced dev firms) be a precursor to a military attack? Not only would it give the Iranians a completely obvious early warning of incoming trouble, it gives no military advantage at all that I can think of. Presumably the Iranian military do not communicate through IM or blogs...

Renesys (who really know what it's doing in this space) has posted a refutation to this exact story, explaining that while Iran did suffer from the cut cables the same as the rest of the middle east, it did not go offline, and looking at why TFA may have thought it did. It goes quite in-depth.

http://www.renesys.com/blog/2008/02/attention_iran_is_not_disconne_1.shtml

Iran is not disconnected, according to a company that monitors routing tables.

A lot more information is available from the Renesys Blog.

It was both the Flag Telecom and SEA-ME-WEA 4 cables outside of Alexandria, Egypt. The SEA-ME-WEA 3 cable is apparently OK.

In long distance telecommunications, you really need another path going "the other way around" to be safe. For example, many of the large companies with back-offices in India pay for routes both over the Atlantic to the Middle East to India (which might have been broken by this) and also West Coast to Pacific to Singapore to India (which would not have been).

At AmericaFree.TV, the steady Egyptian audience went to zero yesterday, presumably because of the break, while the audience in Iran, Iraq, the GCC, Pakistan and India did not seem to be affected.

They're a small network compared to the other global players. Even if you add up their SBC+ATT operations it's still not as big as other players in the market.

no.

that makes no sense. first of all, i see no evidence of AS3549 (global crossing) as a provider to netvision. second of all, even if they were and uunet and gblx both set a null route, traffic would still have come in via telia and btn.

the fact that the slashdot crowd seems not to know who btn (as3491) or telia (as1299) are, doesn't really matter. telia are one of the 10 or 15 largest networks in the world, depending on how you count. btn are top-25.

i'm going to go write this up with some details so that the network-clue-impaired can understand it. i doubt i'll succeed but i'll put results up over at the renesys blog later.

Sigh.

This is, annoyingly, the *exact* same topic as the Verizon post earlier today and it is the exact same, terribly old news that people (including me have been discussing since back in November, when SBC chair Whitacre made comments to business week about forcing google to pay to access their network.

Don't get me wrong, this is an interesting topic. I'm in favor of continuing to discuss it. But the Businessweek, the nation and several other sources get it totally wrong by ignoring the technical realities (as I tried to explain earlier today).

There is already a two-tier network, people. There are legitimate questions about how much further (and in exactly what ways) it should be extended, but people who opine about these matters unhindered by data would do better to read and think a bit first.

This is the exact same issue (from the exact same source) as the interview with SBC Chairman Whitacre last fall. I covered the dispute in my blog last month. It doesn't seem to die.

The issue is clouded by fuzzy-headed thinking. Cable companies already do this. They "reserve bandwidth" (i.e. channels, frequencies, capacity) for their video content and only make a small amount of space available for Internet. The idea that ILECs would do the same when they roll out IPTV or other video-over-packet strategies, is so shockingly unremarkable as to not be news.

The only interesting issue here is whether VZ or SBC or others will restrict or degrade their existing Internet service in the process. I seriously doubt they will--the market would punish them for that. But if they were to, that would be interesting.

This is the exact same issue (from the exact same source) as the interview with SBC Chairman Whitacre last fall. I covered the dispute in my blog last month. It doesn't seem to die.

The issue is clouded by fuzzy-headed thinking. Cable companies already do this. They "reserve bandwidth" (i.e. channels, frequencies, capacity) for their video content and only make a small amount of space available for Internet. The idea that ILECs would do the same when they roll out IPTV or other video-over-packet strategies, is so shockingly unremarkable as to not be news.

The only interesting issue here is whether VZ or SBC or others will restrict or degrade their existing Internet service in the process. I seriously doubt they will--the market would punish them for that. But if they were to, that would be interesting.

...And why doesn't the gov't just buy the Whole Earth Porn Map from Alexa? As has already been observed elsewhere, the relevant data are commercially available today. As web services. Updated daily. With a "porn" tag to differentiate porn from nonporn, yet.

The data they present indicates that the blackout had a severe regional impact. I see nothing that shows that there was a significant global impact (meaning that I can't get data from AS 12374 to AS 553, for example).

That's correct. In fact, our data showed that it clearly did _not_ have global impact. (Compare with various worm events, which do generally have global impact: http://www.renesys.com/projects/bgp_instability/in dex.html
cod red ii and nimda report)

The WTC collapse probably had more impact on global routing (some large carriers had primary and backup equipment in both basements).

Actually, it did not. It did affect some regions outside the US that had trans-Atlantic connectivity straight into NYC, but otherwise it was geographically well localized. This report (PDF slides) compares it to Code Red and Nimda:
http://www.renesys.com/projects/911/renesy s-030502 -NRC-911.pdf
9/11 report

The data they present indicates that the blackout had a severe regional impact. I see nothing that shows that there was a significant global impact (meaning that I can't get data from AS 12374 to AS 553, for example).

That's correct. In fact, our data showed that it clearly did _not_ have global impact. (Compare with various worm events, which do generally have global impact: http://www.renesys.com/projects/bgp_instability/in dex.html
cod red ii and nimda report)

The WTC collapse probably had more impact on global routing (some large carriers had primary and backup equipment in both basements).

Actually, it did not. It did affect some regions outside the US that had trans-Atlantic connectivity straight into NYC, but otherwise it was geographically well localized. This report (PDF slides) compares it to Code Red and Nimda:
http://www.renesys.com/projects/911/renesy s-030502 -NRC-911.pdf
9/11 report

Code Red and Nimda actually did a bit more than that. See this report on global router instabilities during the Code Red and Nimda peak activity periods.

I'm not really thrilled with how that report words things, but then I don't really understand BGP and global routing. The interesting conclusion:

We speculate that, although most of the traffic in the Internet continued to flow normally through the small fraction of links that make up the global backbones, most of the links at the Internet edge had serious performance problems during the worms' probing and propagation phases. A complete list of reasons still needs to be documented, but we suspect i) congestion-induced failures of BGP sessions due to timeouts; ii) flow-diversity induced failures of BGP sesions due to router CPU overloads; iii) proactive disconnection of certain networks; and iv) failures of other equipment at the Internet edge such as DSL routers and other devices.

Once MSFT does dominate the Internet 100% we can expect this sort of thing to happen all the time:

• A computing monoculture will allow 100% susceptiblity to whatever exploit-of-the-day comes around. For Code Red, only about 30% of all web servers were susceptible.
• MSFT does protocol design very poorly, and documents it in even worse fashion. BGP is publicly documented, and it still has weird beard problems with tons of traffic. Imagine what some hacked-out, irregular piece of crap protocol like CIFS might do.
• Security information will go back to living only in the shady underground. "Responsible disclosure", as advocated by MSFT toadies, will keep any and all security bugs from public knowledge.