Re: More ASN collissions

[Leo Bicknell]

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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgplRS0fENoWR.pgp
Description: PGP signature

Re: More ASN collissions

[Rene Wilhelm]

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:
remarks:RIPE NCC members can request AS Numbers using the
remarks:form available in the LIR Portal or at:
remarks:
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

Re: More ASN collissions

[Florian Weimer]

* 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
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: More ASN collissions

[Rene Wilhelm]

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:  domainmas...@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:  domainmas...@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

Re: More ASN collissions

[Leo Bicknell]

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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpfdfIlRSdjm.pgp
Description: PGP signature

Re: More ASN collissions

[christian koch]

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 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  // 
>
>Injustice is relatively easy to bear; what stings is justice.
>
>-- H.L. Mencken
>
>
>
>
>

Re: More ASN collissions

[Dobbins, Roland]

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  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

More ASN collissions

[Jared Mauch]

As always, good research by renesys.

http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml

- Jared