8.8.8.0/24 is the prefix that serves one of Google’s Open DNS servers, which is available at 8.8.8.8.
A few hours ago 8.8.8.0/24 was announced by AS30890 (EVOLVA Evolva Telecom s.r.l.), a provider from Romania.

This ‘Hijack’ lasted for about 7 minutes, and was detected by 14 RIS peers in 4 unique countries. The majority of these networks learned this announcement through AS6939.

This is the second time in a month that Google is affected by a hijack. Last month on July 9th, AS42473 (ANEXIA) a provider from Austria announced a more specific of one of Google’s prefixes.
The prefix 74.125.127.0/24 was announced by AS42473. This is a more specific of 74.125.126.0/23, a prefix that hosts many of Google’s public services.
This announcement was later identified as a copy paste mistake, and quickly resolved after the engineers of AS42473 detected the mistake.

This is yet another example of how easy it is to ‘accidentally’ mess with the reachability of prefixes. There’s not a lot we can do about this today, except for strict filtering on the edges and monitoring using services such as BGPmon.net.
Luckily there’s some good progress being made on the Resource Certificate Public Key Infrastructure (RPKI) initiative.
Hopefully RPKI related tools will become available soon, so that it will be easy for operators to deploy this. And although this will not be a full proof mechanism for preventing BGP hijacks, it will prevent us from most of the ‘fat finger’ incidents we see on regular basis.

Although it seems they have leaked a whole table, only about 10% of these prefixes propagated outside of the Chinese network. These include prefixes for popular websites such as dell.com, cnn.com, www.amazon.de, www.rapidshare.com and www.geocities.jp.
A large number of networks impacted this morning were actually Chinese networks. These include some popular Chinese website such as
www.joy.cn , www.pconline.com.cn , www.huanqiu.com, www.tianya.cn and www.chinaz.com
A list of all prefixes that were announced/hijacked can be found here

The event has been detected globally by peers in The Netherland, UK, Rusia, Italy, Sweded USA, Japan and Brazil. However not all individual prefix ‘hijacks’ were detected globally, many only by a few peers, in one or 2 countries, but some by more.

Some details
All announcement had part of the AS path in common. The common part in the ASpath is (note the prepend).
4134 23724 23724

Which are:
AS4134 CHINANET-BACKBONE No.31,Jin-rong Street
AS23724 CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation

ASns peering with AS4134 seem to have picked this up and propagated that to their customers.
Some of these ASns include:
AS9002 RETN-AS ReTN.net Autonomous System
AS12956 TELEFONICA Telefonica Backbone Autonomous System
AS209 ASN-QWEST – Qwest Communications Company, LLC
AS3320 DTAG Deutsche Telekom AG
AS3356 LEVEL3 Level 3 Communications
AS7018 ATT-INTERNET4 – AT&T WorldNet Services

All RIS peers that detected this where behind (transit/peer) one of those ANS’s.

AS2914 NTT-COMMUNICATIONS-2914 – NTT America, Inc. customers
Looking at more routing information it seems that AS2914 saw more then just the 10% mentioned above. So the impact for NTT America customers might have been bigger.

Impact
28% of the RIS collectors used by BGPmon.net have detected these events. This means that quite a number of networks were impacted by this. The first announcement was detected at 2010-04-08 17:54:31 (UTC), the last ‘hijack’ announcement was at 2010-04-08 18:10:14.
Most ‘alerts’ have now been cleared, they typically lasted a few minutes.

Probably more then the 51 peers mention above would have detected the prefix, but not have chosen this as the best path. Most likely due to the ASpath length or other policies. I believe it’s fair to assume that the impact in China and probably Asia was far bigger then the rest of the world.

Possible Cause
I have not spoken with engineers from AS23724, so I can only speculate. Given the large number of prefixes and short interval I don’t believe this is an intentional hijack.
Most likely it’s because of configuration issue, i.e. fat fingers. But again, this is just speculation.

Prefix distribution
Most prefixes impacted by this were prefixes from the US and China. Below you’ll find the top countries impacted:

Country => number of prefixes hijacked by AS23724
US => 10547
CN => 10298
KR => 2857
AU => 1650
MX => 885
IN => 719
JP => 604
BR => 592
FR => 508
RU => 471
CA => 425
TH => 372
ID => 369
IT => 338
CO => 328
GB => 322
CL => 302
SE => 281
HK => 276
EC => 272
DE => 227

Example alert message

====================================================================
Possible Prefix Hijack (Code: 10)
====================================================================
Your prefix: 203.190.56.0/21:
Prefix Description: www.infoseek.co.jp
Update time: 2010-04-08 16:09 (UTC)
Detected by #peers: 4
Detected prefix: 203.190.56.0/21
Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation)
Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street)
ASpath: 8331 9002 9002 4134 23724 23724
Alert details: http://bgpmon.net/alerts.php?details&alert_id=6617721
Mark as false alert: http://bgpmon.net/fp.php?aid=6617721

Many of you have received alert messages for this event, informing you of the ‘possible hijack’.  I would like to take a bit of time explaining how to interpreted these message so it’s easy to determine the impact of such an event.
The first thing to look for is the number of peers that detected this prefix. In this case the event was detected by 2 peers, this gives you an indication that this event did not have a significant widespread impact.
The next thing to do is to login to BGPmon and check the details of this alert, a direct link to this the detailed info page is now included in the email messages.
Here you’ll quickly see again the number of peers that detected this as well as the geographic location of these peers. In this case both peers were located in Italy, indicating that it’s a fairly local event.  The global impact is also visible on the world map, making it easy to determine the geographical impact.

The same detailed info page also shows the BGP messages that are relevant for this alert. This will give you some more detailed information about the exact BGP announcements. In case the alarm is cleared you will see the exact time this happened. An alarm is cleared when the peer that detected this alert saw  a new valid update for this prefix or a withdrawal. It will also display the exact duration of the event per peer.

BGPmon notification time
BGPmon alert messages are normally sent out a few minutes (<5min average) after we received the updates from the RIPE RIS collectors.
Yesterday, some of you, received the alert messages later then usual.  I apologize for this and am currently working on a solution for this in order to prevent the delay in notification in cases of ‘mass hijacks/leaks’ like we saw yesterday.  A significant part of the solution is  to upgrade some of the hardware components of the  BGPmon.net server.   If you or your company would like to support this project, please consider making a donation. For more information please see this page.

Looking at the raw BGP data from routeviews4 it seems that:
AS13214 leaked a full table (~266294 prefixes) with 13214  as OriginAS to AS48285 which is a routeviews4 peer. Routeviews4 saw these announcements as:
ASpath 48285 13214.

It seems to  have happened twice:
~ 11:03:45 GMT to 12:16:31 GMT (here AS48285 start announcing a valid path to routeviews again).
then a few seconds later again:
~ 12:16:36 GMT to 12:18:14 GMT
After that AS48285 announced ‘normal’ ASpath to routeviews again.

So looks like it wasn’t a global hijack, it was only seen by one routeview peer.  This is a very similar event as the one we saw in November 2008:  Prefix hijack by AS16735 or (Brazil Leak: If a tree falls in the rainforest).

This again shows that it’s hard to determine if an event is a ‘real’ hijack or not. Some will say it’s irrelevant some want to be notified in all cases. Based on received feedback regarding the November 11 event, BGPmon.net implemented peer thresholds.

IPv6 is also fully supported in the auto discovery feature for both prefix discovery as well as the regular expression generator.

I hope you, BGPmon users, are happy with this new functionality and will use it. As always if you have any feedback please let me know

Monitoring IPv6 prefix with BGPmon

.

The reason that you received multiple email is that your prefix was detected as hijacked multiple times in 75 minutes. Multiple alarms in a 5 minutes interval are aggregated in one notification email. If the updates are detected after that 5 minutes another notification email is generated, this email possibly can have multiple  updates as well.  BGPmon tries not to sent to many notification by aggregating notifications, but at the same time we try to be sub-real time, i.e. 5 minutes interval. Hope that explains a bit about more about the notification email interval.

Example email as sent out earlier today:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:

http://bgpmon.net/showupdates.php

====================
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix 142.231.0.0/16:
Update details: 2008-11-11 01:58 (UTC)
142.231.0.0/16
Announced by: AS16735 (Companhia de Telecomunicacoes do Brasil Central)
Transit AS: 22548 (Comite Gestor da Internet no Brasil)
ASpath: 22548 16735
====================