CloudFlare issues?

[martijnschmidt at i3d.net (i3D.net - Martijn Schmidt)]

Hey Sandy,

At this time i3D.net is not able to fully implement RPKI for technical 
reasons: there are still some Brocade routers in our network which don't 
support it. We are making very good progress migrating the entire 
network over to Juniper routers which do support RPKI, and we will 
certainly deploy ROV when that is done, but with upwards of 40 
default-free backbone routers spread over six continents it's not a 
logistically trivial task.

That being said, a network doesn't need to use ROV to benefit from the 
routing security afforded by the RPKI protocol. Nearly all of the 
prefixes originated by AS49544 have been covered by RPKI ROAs for 
several years now. Those networks which have already deployed ROV are 
inoculated against route hijacks of i3D.net's IP space in scenarios 
where the bad paths would be marked as RPKI invalid. Considering that 
i3D.net was founded in The Netherlands and that a significant amount of 
our enterprise customers have businesses which are focused on the Dutch 
market, the fact that two of the major eyeball networks in the country 
(that'd be KPN & XS4ALL) are using ROV is already a huge win for 
everyone involved.

And, let's not forget that the degree of protection afforded by this 
relatively passive participation in RPKI is directly proportional to the 
use of a non-ARIN TAL. Real-world example: Mark Tinka's remark 
concerning Seacom's connection to Cloudflare's IP space being affected 
by the hijack due to the ARIN TAL problem, despite both involved parties 
fully deploying RPKI by both signing ROAs and implementing ROV.

Best regards,
Martijn

On 7/5/19 8:46 PM, Sandra Murphy wrote:
> Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV deployment.  Your message below hints that you may be using RPKI.  Are you doing ROV?  (You may be in the â??hundreds of othersâ?? category.)
>
> â??Sandy
>
> Begin forwarded message:
>
> From: Job Snijders <job at ntt.net>
> Subject: Re: CloudFlare issues?
> Date: July 4, 2019 at 11:33:57 AM EDT
> To: Francois Lecavalier <Francois.Lecavalier at mindgeek.com>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
>
> I believe at this point in time it is safe to accept valid and unknown
> (combined with an IRR filter), and reject RPKI invalid BGP announcements
> at your EBGP borders. Large examples of other organisations who already
> are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX,
> XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International,
> and hundreds of others.
>
>
>
>> On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG <nanog at nanog.org> wrote:
>>
>> So that means it's time for everyone to migrate their ARIN resources to a sane RIR that does allow normal access to and redistribution of its RPKI TAL? ;-)
>>
>> The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were both major reasons for us to bring our ARIN IPv4 address space to RIPE. Unfortunately we had to renumber our handful of IPv6 customers because ARIN doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain.
>>
>> Therefore, Cloudflare folks - when are you transferring your resources away from ARIN? :D
>>
>> Best regards,
>> Martijn
>>
>> On 7/4/19 11:46 AM, Mark Tinka wrote:
>>> I finally thought about this after I got off my beer high :-).
>>>
>>> Some of our customers complained about losing access to Cloudflare's resources during the Verizon debacle. Since we are doing ROV and dropping Invalids, this should not have happened, given most of Cloudflare's IPv4 and IPv6 routes are ROA'd.
>>>
>>> However, since we are not using the ARIN TAL (for known reasons), this explains why this also broke for us.
>>>
>>> Back to beer now :-)...
>>>
>>> Mark.