It's not just AS1712. AS1707 - AS1726 appear to all have been
allocated to Renater. AS1707 was ERX'd to RIPE on Sep 9, 2002, but it
appears that AS1708-AS1726 were missed and have subsequently been
reallocated by ARIN (between Aug 18 and Aug 21, 2009)
this failure is one of the joys of per-rir trust anchors
I don't see operators jumping at the idea of central trust anchor
myself, no more than I see everyone ready to sign the root zone.
Not everyone gets to sign the IANA root zone.
I see some gTLD and ccTLD operators ready, but not all gTLD and ccTLD
operators want it signed. There is perhaps the same issue here.
I'm looking at the registry service requests for .museum, .org, .com/.net/.name, .biz, and writing .cat's.
What gTLD operators are you looking at?
What ccTLD operators are you looking at?
In all seriousness though, how does this get fixed? and... who has to
renumber?
luckily, it's not a renumber in the ip address sense. but some router
jock[ette]s are gonna be even more overworked than usual.
hope for their sake it's just 1 router and 2 transits ... if they
have internal bgp setup (more than one router in their peering/transit
edge) it's going to cause them some pain
(at least with only 1 router and 2 bgp peers you could hope to static
route around the maintenance event)
how to detect if there are more instances?
o Should some form of 'scrape routeviews before assignment' happen at
the RIR? (if you don't like o RV, pick another 2-3 sources of data)
o How do you make sure each RIR does this act?
o Should the customer check public data sources before acceptance?
o Is there a 30 day revoke/return dance for Number Resources?
how to prevent new instances, both asn and ip?
See above ... It seems sensible to check existing data sources, if
that can be automated easily enough?
Checking "global BGP" only works if the ASN is being announced at that instant. That ought to be one of the due diligence steps, but so should checking the various RIR whois servers. Lots of ASNs have been assigned but aren't visible in the global table.
o Should some form of 'scrape routeviews before assignment' happen at
the RIR? (if you don't like o RV, pick another 2-3 sources of data)
o How do you make sure each RIR does this act?
o Should the customer check public data sources before acceptance?
o Is there a 30 day revoke/return dance for Number Resources?
Checking "global BGP" only works if the ASN is being announced at that
instant. That ought to be one of the due diligence steps, but so should
checking the various RIR whois servers. Lots of ASNs have been assigned but
aren't visible in the global table.
sure, pick 2-3 ways to check was my point... I ain't writin' RIR
policy in nanog maillist traffic I presume also there's some '80%
check is good enough' standard that's applied along the way because I
doubt you'll ever get 100% certainty in this sort of thing, sadly.
o Should some form of 'scrape routeviews before assignment' happen at
the RIR? (if you don't like o RV, pick another 2-3 sources of data)
o How do you make sure each RIR does this act?
o Should the customer check public data sources before acceptance?
o Is there a 30 day revoke/return dance for Number Resources?
how to prevent new instances, both asn and ip?
See above ... It seems sensible to check existing data sources, if
that can be automated easily enough?
owned resources may not be announced or visible universally.
existing data sources deeply suck. rir source data are in different
formats, owner identies are not even unique in one rir (how many names
does goog have in arin?), let alone coordinated across rirs, much
historical data is missing, ...
dual ownership is needed for transfer. so i am thinking along the lines
of an aged report of cert conflicts. maybe "bob and alice have both
owned 42.666.0.0/15 for 77 days."
of course this begs the issue of irs not having unique single IDs for
bob and alice.
The whole value of the RIR is to guarantee this uniqueness. This
problem should not have happened.
Indeed. It is a big blunder from the RIR system. I have reported it to
RIPE-NCC (ticket NCC#2009116087) but not to ARIN (I'm not used to
interact with them, if someone wants to relay the information...)
There are links at the bottom for explanations and a link at the top for asking
different questions. Note again that this is not a production service, it is raw data
that needs interpretation and a nicer presentation is coming soon.
In all seriousness though, how does this get fixed?
AS number translation, perhaps?
But more seriously, in general, it is impossible to tell if a conflict
between RIPE and ARIN is real, or is the result of lack of updates
after mergers and acquisitions on one of the sides. A good example in
this area is 53.0.0.0/8, which has a rather interesting history.
Another one is AS702.
Lots of ASNs have been assigned but aren't visible in the global table.
And not all global networks (needing unique numbering) connect to the global "public" internet.
Yes, very good idea. And to check the BGP public routing table also
(belts and suspenders...)
That's a good check, but not sufficient. When last we fixed an ASN registration, the check showed that other ASN's we had were not seen in that table. We just mentioned "they are used on another inter-network" and passed.
Kinda like "belts and suspenders" but let's make sure the fly is shut too.
owned resources may not be announced or visible universally.
Right...or maybe in a different universe.
existing data sources deeply suck. rir source data are in different
formats, owner identies are not even unique in one rir (how many names
does goog have in arin?), let alone coordinated across rirs, much
historical data is missing, ...
This is why an inter-registry database inspection tool is needed. The traditional one is WhoIs - which as Randy mentions is too vague in content. (The WhoIs spec only says something about TCP to port 43...and nothing about the query/response formats.) A tool like IRIS is on the shelf that could be a platform from which to build something better.
Checking the global public internet tables is a good first step, but that's not all that is needed. Such a step only gives credence to uniqueness, but it doesn't guarantee it.
It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present.
The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as “assigned by ARIN” with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726).
We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause.
Yes. I also saw the presentation at IETF in Hiroshima on this.
The issue of zone signing is going to be interesting as some nation-states (ccTLD) have been known to speak-up about their issues with the signing of the zone.
I'm not saying these things will never happen, just they won't happen on a timescale that some would prefer (or would have preferred, eg: last summer or earlier).
In all seriousness though, how does this get fixed?
It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders. Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present.
The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but had not actually been assigned until very recently. (ARIN did a reconciliation in July 2009 of all ASNs marked as �assigned by ARIN� with our own internal records to find out whether any holes existed, and began assigning such ASNs in August 2009, including AS numbers in the range 1708 thru 1726).
We're working with RIPE to determine how these numbers were put into usage via the RIPE DB, and will come up with appropriate steps to prevent recurrence once we fully understand the root cause.
/John
John Curran
President and CEO
ARIN
FWIW,
I searched for any historical registrations from this block
in the RADB and found a number of routes with an origin
of AS1717. They date from 1995 and were registered for the
Universit� Pierre et Marie Curie by Renater. They have long
since been removed from the RADB.
Here's an example --
route: 132.166.0.0/15
descr: RENATER_CIDR
descr: Universite Pierre et Marie Curie
descr: 4 place Jussieu 75252 PARIS CEDEX 05
descr: FRANCE
origin: AS1717
advisory: AS690 1:1800 2:1239(144) 3:1133 4:1674
comm-list: COMM_NSFNET
mnt-by: MAINT-AS1717
changed: rensvp@renater.fr 950510
source: RADB
Of course if it was already assigned when IANA said that (no dates on the link above) then maybe the fault is more IANA's for telling another RIR that they could allocate an ASN that another RIR already allocated. Who knows. It should be an interesting one to watch play out though.
Of course if it was already assigned when IANA said that (no dates on
the link above) then maybe the fault is more IANA's for telling another
RIR that they could allocate an ASN that another RIR already allocated.
i suspect that, in the erx project, there may have been more than one
case of the iana saying "ok, X now manages this block, excpet of course
for those pieces already allocated by Y and Z." and the latter were not
always well defined or easily learnable, and were not registered
directly with the iana, but other rirs.
<rant>
and the data are all buried in whois, which is not well-defined, stats
files, which are not defined, etc. the rirs, in the thrall of nih (you
did know that ripe/ncc invented the bicycle), spent decades not agreeing
on common formats, protocols, or code. this is one result thereof.
testosterone kills, and the community gets the collateral damage.
