As always, good research by renesys. http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml - Jared
On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote:
As always, good research by renesys.
What happens when an ASN is requested, and it's discovered that said ASN is already in use by an unauthorized network, and that some proportion of the Internet are accepting it due to a lack of appropriate routing policy? Is there a process to try and reclaim said ASN via persuasion, or some jurisdictionally-appropriate legal action, or peer pressure (pardon the pun), or . . . ? This is a different circumstance than either accidental or deliberate use of an already-assigned and -utilized ASN; has this situation occurred in the past, and if so, how was it resolved? If the situation isn't resolved in a timely manner, is the ASN in question considered 'poisoned' until a resolution is attained, and the next available ASN which isn't being utilized in a rogue fashion issued in its place? Apologies if this is a naive question; I've not run into this particular circumstance before, nor have I found any reference to it in any of the various list archives. I do believe that it may become a bit more common, given some of the confusion and drama regarding the operationalization of 4-byte ASNs. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
i believe john curran just posted the follow up to the list yesterday on this matter On Thu, Dec 10, 2009 at 10:51 AM, Dobbins, Roland <rdobbins@arbor.net>wrote:
On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote:
As always, good research by renesys.
What happens when an ASN is requested, and it's discovered that said ASN is already in use by an unauthorized network, and that some proportion of the Internet are accepting it due to a lack of appropriate routing policy? Is there a process to try and reclaim said ASN via persuasion, or some jurisdictionally-appropriate legal action, or peer pressure (pardon the pun), or . . . ?
This is a different circumstance than either accidental or deliberate use of an already-assigned and -utilized ASN; has this situation occurred in the past, and if so, how was it resolved? If the situation isn't resolved in a timely manner, is the ASN in question considered 'poisoned' until a resolution is attained, and the next available ASN which isn't being utilized in a rogue fashion issued in its place?
Apologies if this is a naive question; I've not run into this particular circumstance before, nor have I found any reference to it in any of the various list archives. I do believe that it may become a bit more common, given some of the confusion and drama regarding the operationalization of 4-byte ASNs.
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote:
As always, good research by renesys.
http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml
As already commented on the blog... ISC had a data entry error on an ASN for our site in Fiji. There was no RIR mixup, it was purely an error on our part. This was then further propogated when scripts we had generated routing registry objects and pushed them out. We're already down the path of fixing it, and the error will be corrected soon. We would like to thank Renesys for bringing it to our attention. While the ARIN / RIPE mixup in the 17xx range has caused a lot of people to go looking for a smoking gun I think Renesys has proved there is in fact no cause for alarm. 40,000+ ASN's in use and only two for which there is even a question. 0.005's of a percent error rate in a global system is quite good. To also answer one of the questions posed in the blog. It is only recently (I think about 4 months ago) ISC fully scripted it's routing registry updates, which is what caused the AS35686 to ISC entry in the RIPE DB. Prior to that there would have been no ISC entry anywhere, as it was not assigned to ISC; thus no other party would have checked it. I can't comment on if ISC checked if the ASN was in the APNIC database properly when they received it or not, but noting it was a data entry typo it is entirely likely the database was checked with the proper ASN, and then the data was miss-entered into internal systems. I would be very interested to know if something similar happened with AS3745. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Leo Bicknell wrote:
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote:
As always, good research by renesys.
http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml [...] I would be very interested to know if something similar happened with AS3745.
AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at whois.ripe.net is a user created object in the RIPE routing registry, not an assignment by RIPE NCC. The record in the ARIN database states: OrgName: Perot Systems OrgID: PEROTS-16 Address: 3800 Hamlin Road City: Auburn Hills StateProv: MI PostalCode: 48326 Country: US ASNumber: 3745 ASName: VWAG-AS ASHandle: AS3745 Comment: RegDate: 1994-08-01 Updated: 2001-03-29 RTechHandle: AP105-ARIN RTechName: Accounts Payable, Mr. E. Zeltzer RTechPhone: +1-248-754-5803 RTechEmail: domainmaster@vw.com Both the ASName and RTechEmail already point to Volkswagen (VW). Querying whois.arin.net for AP105-ARIN shows the full contact info: Name: Accounts Payable, Mr. E. Zeltzer Handle: AP105-ARIN Company: Volkswagen of America Address: Volkswagen of America Address: 3800 Hamlin Road City: Auburn Hills StateProv: MI PostalCode: 48326 Country: US Comment: RegDate: 1998-11-25 Updated: 2001-03-29 Phone: +1-248-754-5803 (Office) Email: domainmaster@vw.com So Perot Systems seems to have received this AS in 1994 for Volkswagen America. REX, RIPE NCC's prototype Resource EXplainer, shows AS3745 has been advertising 193.23.96.0/24 and 193.23.104.0/24 (both assigned to Volkswagen AG, Germany) as long as we have routing history from RIS. In 2001 and later years parts of 194.114/17 followed. See http://albatross.ripe.net/cgi-bin/rex.pl?res=AS3745&stime=2000-01-01&etime=2009-12-09&type=all The RIPE DB lists AS3745 as "Volkswagen AG, Wolfsburg, Germany". Although not consistent with the registration info in ARIN, you can at least see how, in the 1990s, the German parent company started to use the assignment made to its American subsidiary. The odd one in the current set of prefixes advertised by AS3745 appears to be 148.9.64.0/18 If you click on this prefix in the REX listing for AS3745 you see this announcement is in the routing tables since June 2008. The encompassing 148.9/16 was originated by AS5089 from January 2003 to January 2004 and by AS1294 for some short periods in 2000 and 2001. A next click on the "Resource Holder" (near the top of the page) shows the matching record in the ARIN database to be 148.9.0.0 - 148.9.255.255 a direct assignment to Perot Systems, Plano, TX Finally, a click on the "DNS and Reverse DNS" in REX removes any doubt the /18 is somehow related to Volkswagen: for November 2009 we found one reverse DNS entry in the CAIDA IPv4 DNS-names dataset[*] pointing to a domain under .gov In summary, AS3745 is indeed used by two different organizations, but it's the users not the RIRs who created this situation. -- Rene [*] http://www.caida.org/data/active/ipv4_dnsnames_dataset.xml
* Rene Wilhelm:
AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at whois.ripe.net is a user created object in the RIPE routing registry, not an assignment by RIPE NCC.
How can you tell one from the other? Is the lack of an org: attribute reliable? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
* Rene Wilhelm:
AS3745 is not a duplicate ASN assignment either. Like AS35868 the entry at whois.ripe.net is a user created object in the RIPE routing registry, not an assignment by RIPE NCC.
How can you tell one from the other? Is the lack of an org: attribute reliable?
The info is in the as-block object which whois.ripe.net returns in addition to the aut-num object when you do a default query for an AS number. For example for as43210 you get this: as-block: AS43008 - AS44031 descr: RIPE NCC ASN block remarks: These AS Numbers are further assigned to network remarks: operators in the RIPE NCC service region. AS remarks: assignment policy is documented in: remarks: <http://www.ripe.net/ripe/docs/asn-assignment.html> remarks: RIPE NCC members can request AS Numbers using the remarks: form available in the LIR Portal or at: remarks: <http://www.ripe.net/ripe/docs/asnrequestform.html> org: ORG-NCC1-RIPE admin-c: CREW-RIPE tech-c: RD132-RIPE mnt-by: RIPE-DBM-MNT mnt-lower: RIPE-NCC-HM-MNT source: RIPE # Filtered [...] Only AS numbers which are covered by "RIPE NCC ASN blocks" have been assigned by RIPE NCC or transferred to RIPE NCC (like AS1707). -- Rene
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch wrote:
As always, good research by renesys.
http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml
http://blog.isc.org/2010/01/asn-collisions-and-human-error.html -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
participants (6)
-
christian koch -
Dobbins, Roland -
Florian Weimer -
Jared Mauch -
Leo Bicknell -
Rene Wilhelm