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/