[routing-wg] access control in other regions' IRR DB [was: Re: AS201640]

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/