[routing-wg] discussion about rogue database objects

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 at steffann.nl 
> <mailto:sander at 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
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/routing-wg/attachments/20141109/616fcc22/attachment.html>