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> 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
In message <CAA=nHSKbOHc7vSk5O+oPQ8459HyCk=t8pY8CZbHx+yhBE1tFkQ@mail.gmail.com> George Michaelson <ggm@apnic.net> 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.
Sounds good to me! Could it be made to happen, um, yesterday? Regards, rfg 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? Also, could this scenario have been replicated if the origin AS had been registered in/by ARIN, APNIC, LACNIC, or AFRINIC, rather than RIPE? If so, then a proper sort of fix will necessarily involve all five RiRs, no?
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".
If so, then a proper sort of fix will necessarily involve all five RiRs, no?
Correct. George Michaelson is from APNIC, so "they are aware", and I'm fairly sure the other RIRs are being informed. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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/
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
In message <545FDE27.7030702@velea.eu>, Elvis Daniel Velea <elvis@velea.eu> wrote:
*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...
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.
Can anyone speak to this? What resources in what registries cannot currently be covered by RPKI? If the answer is "none", then there is no problem with requiring that right now, correct? I confess that as a relative outsider to all these matters, I am more than a little mystified by the suggestion, here in late 2014, that RPKI might be unavailable for certain resources in certain registries. I say that because I read this: http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ which suggests that RPKI was rolled out by all five RiRs sometime during 2011 (or even earlier, in the case of APNIC). So if the infrastructure really is all there already, then what's the problem?
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.
Cart, horse. Firstly, it appears that RIPE NCC may need some guidance about the set of conditions which should cause them to ``consider to be rogue'' a particular AS or other number resource. Deletion could only follow recognition. And if the comment made here yesterday is true, i.e. that RIPE NCC has already had a ticket open on AS201640 for two full months already, then it would seem to that RIPE NCC may not yet consider this thing to be ``rogue'', either according to their formal operating procedures, or perhaps even in any other sense. So that would appear to be the first order problem.
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.
Ummm... yea. I was kind-of wondering about that myself. In fact, that's the reason I came here, to this mailing list, i.e. to find out either what has been done about this, or what is being done about this, or what could yet be done about this.
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?
I have been working, in my own way, to rid the Internet of spammers since about 1995. Given that, and the fact that there is now abundant proof that the IP space associated with some of these routes has been used, and indeed most probably is being used, as we speak, for, at the very least, spamming, I think that everyone should easily be able to infer which way I would vote on this question, if asked. But in case not, I will be plain: I would fervently like to see these route announcements not just killed but annihilated, with extreme prejudice, and not merely immediately, but yesterday. (I understand that RIPE NCC cannot directly affect either the announcements or their propagation, but they certainly can affect the data which appears to validate the announcements.) Regards, rfg
Hello, On 11/09/2014 11:35 PM, Elvis Daniel Velea wrote:
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 am also wondering why their upstreams still have peers and other interconnects after this. Isn't this what peer pressure is about? Yours, -- Aleksi Suhonen
participants (6)
-
Aleksi Suhonen -
Elvis Daniel Velea -
George Michaelson -
Gert Doering -
Rene Wilhelm -
Ronald F. Guilmette