On 11/9/14, 8:59 PM, Gert Doering wrote:
Hi,
>
> On Sun, Nov 09, 2014 at 11:48:36AM -0800, Ronald F. Guilmette wrote:
>> P.S. I'm still a bit befuddled by what happened in this case.
>> Would it be a fair characterization to say that what AS201640 has
>> done in this case is to exploit a kind of loophole which is
>> uniquely present only when the hijacker/squatter AS is registered
>> in one RiR and the IP blocks that are being hijacked/squatted are
>> registered in a different RiR?
>
> Yes.
>
>> Also, could this scenario have been replicated if the origin AS had
>> been registered in/by ARIN, APNIC, LACNIC, or AFRINIC, rather than
>> RIPE?
>
> I'm not sure how the access control in other regions' IRR DBs work -
> but at least ARIN's database is based on RIPE code, so "it might
> be".
>
Both APNIC and AFRINIC ensure the address range and AS number are within
theirrespective resource ranges before a route object can be registered;
see [1] and [2].In these two regions it is not possible to register
routes for which eitherprefix or origin AS has been issued by another RIR.
The ARIN routing registry on the other hand does not enforce authorization
against inetnum or inet6num objects [3]. As a result rr.arin.net also hosts
routeobjects which relate to address space allocated by the RIPE NCC.
And the origin ASlisted with those routes doesn't have to be the same
as the one recored in theRIPE routing registry. For example:
$ whois -h rr.arin.net 212.100.0.0/19
route: 212.100.0.0/19
descr: VeriSign Customer Route
origin: AS26415
mnt-by: MNT-VIO-2
source: ARIN # Filtered
vs.
$ whois -h whois.ripe.net 212.100.0.0/19
inetnum: 212.100.0.0 - 212.100.31.255
descr: mipex.net
org: ORG-mA19-RIPE
netname: EU-MIPEX-981002
country: EU
admin-c: DH815-RIPE
admin-c: PJB-RIPE
tech-c: PJB-RIPE
tech-c: AJ686-RIPE
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: UKPO-RIPE-MNT
mnt-routes: UKPO-RIPE-MNT
source: RIPE # Filtered
organisation: ORG-mA19-RIPE
org-name: mipex.net
org-type: LIR
phone: +441633814000
fax-no: +441633814514
admin-c: AJ686-RIPE
admin-c: MDE15-RIPE
admin-c: PJB-RIPE
mnt-ref: UKPO-RIPE-MNT
mnt-ref: RIPE-NCC-HM-MNT
mnt-by: RIPE-NCC-HM-MNT
source: RIPE # Filtered
abuse-c: AR15071-RIPE
address: The Patent Office
address: Concept House
address: Cardiff Road
address: NP10 8QQ Newport
address: UNITED KINGDOM
[...]
% Information related to '212.100.0.0/19AS9011'
route: 212.100.0.0/19
descr: UK Patents Office
origin: AS9011
mnt-by: UKPO-RIPE-MNT
source: RIPE # Filtered
I can only assume that from a local (VeriSign's) perspective the entry in
the ARINrouting registry makes sense, but it does confuse applications
and users whoon a global scale try to deduce a route's authorized origin
from routingregistry entries.
-- Rene
[1] https://www.apnic.net/services/services-apnic-provides/routing-registry
[2] http://afrinic.net/en/services/afrinic-irr
[3] https://www.arin.net/resources/routing/
