Hi George, everyone, (long e-mail incoming, both on the future process but also on what should we do _today_ with the case of AS201640) *Regarding the future process:** * I do not think it will be that easy to come up with a process. RPKI may not be available for legacy (or independent) resources in all the regions. I think this means the RIRs will first need to speed up the deployment of RPKI for all the resources in their registries for George's idea to work. Still, it may just work... In a first step, a quick fix would be to reject the creation of a rogue route object in (for example) the RIPE Database if the other RIR has a valid registered ROA. But we should not reject the registration if the ROA is not valid; not yet, not before all the resources can be covered by RPKI. We will still have to discuss what should happen with the objects already created. For example, an AS assigned by an other RIR can be registered in the RIPE Database by anyone, even if they are not the legitimate holder of that resource. One question here, would be: how could an AS holder from an other RIR demonstrate the legitimate holdership of the resource in order to request the RIPE NCC to delete the 'rogue' object from the RIPE NCC? Can this be done by using a certificate? (note: not allowing an AS holder from an other region to register a copy in the RIPE IRR will probably be contested by quite a few large organisations) An other question we need to find an answer to is: what would happen if the ROA would be registered/changed/deleted in one RIR system and a route object would become invalid, should all the other RIRs automatically delete any invalid object from their databases? Or only upon request? - if the first option is possible and accepted, it would fix the time limit question raised by George - if the latter, what should be do with all the 'junk' in the RIR Databases and IRRs? Finally, The RIPE NCC will need a clear mandate from us, the community on the process they should follow in order to forcefully delete objects considered to be rogue. *Regarding **AS201640 and the reason why we are now talking about this:** * Right now, we should all note that AS201640 still hijacks or has route objects registered for prefixes from: AfriNIC: a) 105.154.248.0/21 registered to Maroc Telecom, b) 41.198.224.0/20 and 41.198.80.0/20 registered to IWAY Africa, c) 41.92.206.0/23 registered to Ringo, S.A, APNIC a) 119.227.224.0/19 registered to SIFYNET/IN, b) 202.39.112.0/20 registered to Taiwan Network Information Center c) 210.57.0.0/19 and 210.57.192.0/20 registered to Telstra Global Internet Services Network Blocks d) 61.242.128.0/19 registered to China United Network Communications Corporation Limited e) 36.0.56.0/21 registered to CHINANET Guangdong province f) 27.112.32.0/19 registered to TianJin LongChina Network S&T Co.,Ltd g) 123.29.96.0/19 registered to Vietnam Posts and Telecommunications(VNPT) LACNIC: a) 187.189.158.0/23 registered to Iusacell PCS de Mexico, S.A. de C.V. b) 177.46.48.0/22 registered to ASSOCIA??O NACIONAL PARA INCLUS?O DIGITAL - ANID c) 177.22.117.0/24 registered to Tobias Freitas de Souza - these are only 13 prefixes which have been hijacked in the past 2 weeks. In total 43 prefixes have been hijacked since 26/08/2014 from all the regions. Note: for 6 of these prefixes, they still have objects registered in RADB but some are missing from any IRR - meaning their upstream accepts anything anyway. I personally find it difficult to understand how come that a 'company' can hijack 43 prefixes from various RIRs and still operate after more than two and a half months. I think the e-mail coming from Daniel was asking what should be do now.. and not in the next few months. Rene was asking in the e-mail forwarded by Daniel to this wg whether this community can request the RIPE NCC to remove the route objects from the RIPE NCC; or whether the RIPE NCC could take such actions now.. If it would be just for me, I would ask the RIPE NCC to delete _today_ the route objects and the aut-num object. But, it's not just me, what does the rest of the wg say? my two cents, elvis (sorry for the long e-mail) On 09/11/14 17:57, George Michaelson wrote:
the easy to use solution is to require external data to be signed by RPKI certificates from another RIR's system.
1) its time limited: all signed objects have a lifetime 2) its secure (as secure as PKI) 3) it doesn't require massive effort to implement: a well formed object can be specified by anyone, and then signed by the prime resource holder using a certificate covering the resources. The receiving side can validate it directly.
Thats pretty much what I said to the microphone of the routing wg meeting.
On 9 November 2014 08:42, Sander Steffann <sander@steffann.nl <mailto:sander@steffann.nl>> wrote:
Hi Ronald,
>> Having IP addresses is not a requirement for getting an ASN. There are >> many legitimate cases where an ASN may be used to announce address space >> belonging to someone else. For example an ISP announcing address space >> belonging to its customer. Or a transit provider. > > OK, that's a good point. But I'm not sure that it fully negates the > possible value of my question. > > Everybody is _supposed_ to have working e-mail address contacts in their > IP allocation records within the WHOIS data bases of the various RiRs, > yes? So suppose that there had been a protocol in place that required > an affirmative e-mail response from at least one legitimate IP address > block registrant (in some/any region) before the allocation of an AS > number would proceed. Such a protocol would have forestalled the > situation that we now see with AS201640, would it not?
It is a possible implementation but one that only has a one-time check. It wouldn't keep track of changes to resources in other regions. The working group asked the RIPE NCC to look into the possibilities and report back to the working group. Let's see if there is a easy to use solution that makes sure we don't import data into our database that then end up being invalid or outdated.
Cheers, Sander