====================================================================
New prefix for AS271 (Code: 60)
====================================================================
Detected new prefix:  f006:9000::/24
Update time:          2010-06-11 19:18 (UTC)
Detected by #peers:   4
Announced by:         AS271 (BCNET-AS - BCnet)
Upstream AS:          AS13768 (PEER1 - Peer 1 Network Inc.)
ASpath:               1280 174 3257 13768 271
Alert details:        http://bgpmon.net/alerts.php?details&alert_id=9019544
Add to my prefixes:   http://bgpmon.net/fp.php?aid=9019544

Looking at this message it seemed odd, although the prefix was very strange, the ASpaths seemed to make perfect sense. After some more digging I noticed that many other BGPmon.net users had also received an alert like this.

BGPmon.net keeps a list of bogon announcements, in this list you can seen many of the detected bogon announcements of yesterdat.
This list can be found here:
http://www.bgpmon.net/showbogons.php?inet=6

Looking at the large number of AS numbers, I found it hard to believe that all these ASn’s are actually announcing these prefixes. This would mean that about 100 networks at the same time decided to announce a bogon prefix, this is very unlikely so there must be something else.

Assuming that these prefixes are not originated by what seems to be the origin AS (based on ASpath), this would mean that the announcements are originated by another AS, which seems to spoof (AS prepends) the ASpath with these AS numbers.

More details
From what I can quickly see these ‘strange’ announcements are seen with at least about 100 different origin ASn’s.

Initially I though this was an issue with the BGPmon.net software, but after reviewing the data at the RIPE RIS website I see the same results.

These are some of examples of observed bogon prefixes:
0:1f00::/24
2800::/8
4000::/8
4800::/8
5810::/12
And many more

The announcements are detected by the following RIS peers at the AMS-IX – Amsterdam, Netherlands, MIX – Milan Internet Exchange and the PAIX – Palo Alto, United States.

Who announced this?
As the administrator of one these ASns I don’t believe these announcement really come from origin the AS as defined in the ASpath, i.e. the AS on the right hand side of the ASpath.
Looking more closely at all the ASpaths of all these bogon announcements, they all have 2 ASns in common,

174 3257 

Which are Cogent (174) & Tiscali (3257), so we should probably focus on those two.

Spoofed ASpath

All of these RIS peers above have a IPv6 relationship with Tiscali AS3257. It’s fair to assume that they also have an IPv6 peering with AS174 (Cogent) as that’s how they learned these announcements.

Because the RIS peers that detected this have a peering with both Cogent as well as Tiscali, it’s surprising that non of them reported a shorter path directly via AS3257. Instead the paths went through AS174 and then to AS3257.

Another observation is that AS3257 is a RIS peer, and as a result one of the peers that BGPmon.net uses to analyze data. However non of the bogon updates we’re detected by AS3257 (or more specifically, non were sent to the RIS collecter from AS3257).

Assuming that AS3257 never saw these updates, that would indicate that that is part of the spoofed AS path and makes 174 the source of these announcements.

Another possibly useful clue is that updates contain two AS174 communities.
174:21100 which according the the whois data means: peer route learned in EU
174:22005 no explanation available

What does this mean
Please note that the above are assumptions, as I have not had contact with either Tiscali or Cogent I can only report on the observations described earlier.
I have no idea what the purpose of these announcements were. In the past we’ve see ‘spoofed’ AS paths as part of a research project. But they have also been used in BGP man in the middle attacks.
Maybe one of you have an idea?

Duplicate announcements
If multiple networks announce the same prefix it might result in traffic being routed to the wrong network. This problem becomes even worse if someone else starts to announce a more specific of this network. Normally these ‘hijacks’ are not all that common, but with prefixes from this range it might be a bigger issue due to the nature of this prefix.
To try to quantify this I decided to take a look in the BGPmon.net database in which we have a complete collection of bogon announcements since May 2009. Any announcement in the 1.0.0.0/8 range in the last 9 months is recorded in this database.

In this 9 month period we detected 364 unique announcements for in prefix in the 1.0.0.0/8 range. If we group those announcements by origin AS and announced prefix we see 23 unique announcements.

+----------------+----------+-----------------------------------------------------------------------------+
| prefix         | OriginAS | AS_name                                                                     |
+----------------+----------+-----------------------------------------------------------------------------+
| 1.0.0.0/9      | AS24785  | JOINTTRANSIT-AS Open Peering BV trading as Joint Transit                    |
| 1.1.0.0/16     | AS47377  | KPNBE T2 Belgium NV                                                         |
| 1.1.0.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   |
| 1.1.1.0/24     | AS8300   | Test-AS --  Swisscom Ltd                                                    |
| 1.1.1.0/24     | AS30733  | GLOBUS-AS GLOBUS-TELECOM Autonomous System                                  |
| 1.1.1.0/24     | AS6503   | Axtel, S.A.B. de C. V.                                                      |
| 1.1.1.0/24     | AS34695  | E4A-AS E4A Primary AS                                                       |
| 1.1.1.0/24     | AS8218   | NEO-ASN AS Confederation of Neotelecoms, euNetworks AG and Upstreamnet gmbh |
| 1.1.1.0/24     | AS3549   | GBLX Global Crossing Ltd.                                                   |
| 1.1.1.0/24     | AS45899  | VNPT-AS-VN VNPT Corp                                                        |
| 1.1.1.0/24     | AS16735  | Companhia de Telecomunicacoes do Brasil Central                             |
| 1.1.1.0/30     | AS38091  | HELLONET-AS-KR CJ-CABLENET                                                  |
| 1.1.1.0/31     | AS8359   | COMSTAR COMSTAR-Direct global network                                       |
| 1.1.1.1/32     | AS45400  | NICNET Korea Telecom-PUBNET                                                 |
| 1.1.1.10/31    | AS8359   | COMSTAR COMSTAR-Direct global network                                       |
| 1.1.2.0/30     | AS3313   | INET-AS I.NET S.p.A.                                                        |
| 1.1.88.0/24    | AS4645   | ASN-HKNET-AP HKNet Co. Ltd                                                  |
| 1.1.88.0/24    | AS39386  | STC-IGW-AS Saudi Telecom Company                                            |
| 1.120.0.0/13   | AS23148  | TERREMARK Terremark                                                         |
| 1.2.3.0/24     | AS19151  | WVFIBER-1 - WV FIBER                                                        |
| 1.20.23.178/32 | AS26592  | Dominio BR Consultoria em Informatica Ltda                                  |
| 1.40.0.0/13    | AS23148  | TERREMARK Terremark                                                         |
| 1.80.0.0/13    | AS23148  | TERREMARK Terremark                                                         |
+----------------+----------+-----------------------------------------------------------------------------+

A complete list of bogon announcements can be found here:
As you can see the 1.1.1.0/24 prefix is the most popular prefix, so we can only hope APNIC won’t allocate this prefix. Except maybe for a nice honeynet project.

Duplicate address usage
Duplicate announcements are not the only thing networks in the 1.0.0.0/8 prefix have to worry about. As it turns out a number of organizations have used this prefix as an alternative for the RFC1918 prefixes. With the reasoning that many people already use 192.168.0.0, 10.0.0.0 or 172.16.0.0 , so chances of collisions are reasonable. So these bright minds came up with the idea of using a unallocated prefix as an alternative, such as for example 1.0.0.0/8

AnoNet
AnoNet is a private friend-to-friend network built using VPNs and software BGP routers. anoNet works by making it difficult to learn the identities of others on the network allowing them to anonymously host content and IPv4 services. Also see http://en.wikipedia.org/wiki/AnoNet
The prefix they use for this network is 1.0.0.0/8.
Apparently AnoNet is planning to do the same for their IPv6 initiative, as according to their website:
“Services are gradually being migrated to dual-stack. It is all in the de00::/8 range”
de00::/8 is a unallocated range, just as 1.0.0.0/8 used to be….

WIANA
Wiana is The Wireless Internet Assigned Numbers Authority, provides IP addresses for wireless devices from the 1.0.0.0/8 prefix.
Ironical WIANA claims to have been formed to meet the that need network policies are upheld.
According to their FAQ the reason for this prefix is that several protocols used already utilize the 10.x.x.x network for unregistered addresses during handshaking. Another class A network was required. Unfortunately for WIANA (and the future legitimate holder of this prefix) soon, the prefix they choose will no longer be unqiue.

Receiving a prefix from the 1/8 range
The role of the RIRS is to make sure prefixes are allocated to one organization only and as a result should be unique. With prefixes from the 1.0.0.0/8 prefixes this can no longer be guaranteed. Not because of multiple allocations by the RIR, but in this case by other organizations that thought it would a smart idea to choose a random unallocated prefix.
In order to prevent issue’s with BGP announcements, looking at the bogon announcements it’s probably a good idea to (at least not yet) allocate prefixes in the 1.1.0.0/16 range as these seem to be leaked the most.

As Alain Durand mentioned on Nanog: “Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing.

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

.

As you will probably see, there’s quite a few strange IPv6 prefixes out there, looking like: a3c7:8800::/21 and a51e::/16 and many more. I’m not sure what this is, it’s not a bug in the BGPmon.net software as the same updates are seen by RIS (see here).  The announcements are very short, typically an announcement for these prefixes is followed by a withdraw just 1 second later. The (same) bogon prefixes are actually being announced by a number of origin AS’s looking a bit further shows that the one common thing is the rest of the AS path. So it could mean that somewhere in the transit path a faulty router is the cause of this. But that’s all guessing and if we go there we shouldn’t eliminate a bug in the RIS software. If anyone has any information about this, please leave a comment on this blog or sent me an email.

a few  weeks ago an interesting IPv6 prefix which caused my parser to start complaining. At first I thought it was a parser bug, but it’s not.  The prefix in question is 339:752f:14::/48  and is  seen by 35 RIS peers thus  seems to propagate fairly far.  Looking back in some old RIB files, it turns out that this prefix has been around for a while already, the first time somewhere in February, then it wasn’t visible for a while showing up in July/August again.  According to this IANA document, 0200::/7 used to be available for those who needed to map OSI NSAP to IPv6 [RFC4548]. However this is now obsoleted and declared historic.

This is probably is good moment to remember to check your IPv6 filters. And ask yourself, do I filter IPv6 announcements? Did you know that Gert Doering publishes some great resources for IPv6 filters? Please see: http://www.space.net/~gert/RIPE/ipv6-filters.html for IPv6 filter list recommendations.