"Is BGP safe yet?" test

Tue Apr 21 07:52:08 UTC 2020

> On 21 Apr 2020, at 08:51, Matt Corallo via NANOG <nanog at nanog.org> wrote:
> 
> I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up.
> 
> Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates.

The RIPE NCC has an IRR that is tightly coupled to the resource holder. With many networks requiring a route object to be published in the IRR for them to accept your announcement, the RPKI scenario that you describe has basically existed for the RIPE Database IRR since forever. This tight coupling doesn’t exist for the RADB and ARIN and as a result it is full of incorrect data, which is one of the reasons RPKI exists in the first place.

Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline.

> Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.

ARIN has taken pretty drastic nonrepudiation measures:
https://www.arin.net/resources/manage/rpki/faq/#why-must-i-create-a-key-pair-to-use-rpki

With Delegated RPKI you can take matters into your own hands:
https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html#delegated-rpki

-Alex

> By no means am I suggesting we should stop the RPKI train (and AS397444 happily drops invalids and has ROAs for all prefixes), but there’s a very cost here that doesn’t appear to have gotten much love, let alone mitigation effort. In the context of RIPE having to ask for permission to keep receiving payments from several Iranian LIRs, this isn’t completely inconceivable.
> By way of an example, something like a waiting period for RIRs to add new ROAs replacing removed ROAs (which would imply some kind of signed replacement, but you get the point). At least ARIN already has a several-month quieting period after yanking resources for non-payment, why not use that to give operators time to think about whether they mind talking to Iran?
> 
> /ducks
> 
> Matt
> 
>> On Apr 20, 2020, at 08:10, Andrey Kostin <ankost at podolsk.ru> wrote:
>> 
>> Hi Nanog list,
>> 
>> Would be interesting to hear your opinion on this:
>> https://isbgpsafeyet.com/
>> 
>> We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses.
>> IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
>> 
>> Kind regards,
>> Andrey