[routing-wg] RPKI Route Origin Validation and AS3333

Hi Nathalie,

On 03/18, Nathalie Trenaman wrote:
> Dear Colleagues, Working Group,
> 
> As discussed previously in this mailing list, some community members
> expressed that they would like to see the RIPE NCC perform Route
> Origin Validation on AS3333. We decided to ask the community for
> advice and guidance on how we should proceed. 
> 
> What is Route Origin Validation?  Route Origin Validation is a
> mechanism by which route advertisements can be authenticated as
> originating from an expected autonomous system (AS).  The best current
> practice is to drop RPKI invalid BGP announcements. These are
> announcements that conflict with the statement as described in a Route
> Origin Authorization (ROA).
> 
I believe that you have hit the nail on the head here: dropping ROV
Invalids has (IMO) now become the best practice for operators of all
sizes. It is no longer some experimental technique for academics and
people that live at the bleeding edge.

We wouldn't have the same debate about dropping martians, right?

> What is AS3333?  This is the AS Number for the RIPE NCC’s main service
> network. It includes most of our *.ripe.net <http://ripe.net/>
> websites, including the LIR Portal (my.ripe.net <http://my.ripe.net/>)
> and the RIPE Database. 
> 
> What is the Problem?  Currently, some of our upstream providers
> already perform ROV. This means that some of our members that
> potentially misconfigured their ROA or members who have lost control
> of creation and modification of their ROAs cannot reach our services
> via those peers. 
> 
> On the other hand, some of our upstream providers do not perform ROV,
> and if a member’s prefix is being announced by a hijacker, they cannot
> access our services. We already received a report about this.This is
> also not an ideal situation. 
> 
> From the network operations perspective, there are no obstacles to
> enable  ROV on AS3333, however, we have to consider that members or
> End Users who announce something different in BGP than their ROA
> claims, will be dropped and lose access to our services from their
> network. This includes the RPKI Dashboard where they can make changes
> to their ROAs. This is specially relevant when members operate
> certificate generation in hosted mode which is the current operation
> mode for almost all for our members. 
> 
Your explanation seems to suggest that the above scenarios are similar.
I would suggest that they are actually opposites of one-another:

If a network cannot access RIPE's online services because they broke
their routing, including through creating a conflicting ROA, the blame
lies with the operator of that network.

On the other hand, if a network cannot access those services because
RIPE's routers are selecting a route towards it that is identifiably
bogus using best current practices, including RPKI ROV, then the fault
lies with the RIPE NCC.

Again, no one would be wringing their hands because someone was unable
to get to the LIR portal from 10/8, right?

> From an analysis we made on 10 February, there were 511 of such
> announcements from our members and End Users.
> 
ROV is well deployed today. Either these routes are covered by Valid
aggregates, or these members are already experiencing widespread routing
issues.

In the later case, whilst that is unfortunate for those operators and
their customers in the short term, experiencing some inconvenience is
likely the only possible incentive for the problematic objects to get
cleaned up.

I don't think that RIPE or it's members should be expected to sit around
and wait for that to happen by magic.

> Our current RPKI Terms and Conditions do not mention that a Member or
> End User ROA should match their routing intentions, or any
> implications it may have if the ROA does not match their BGP
> announcement. If the community decides it is important that AS3333
> performs ROV, our legal team needs to update the RPKI Terms and
> Conditions to reflect the potential impact. 
> 
As others have already indicated, I don't think that this has any place
in those Ts&Cs.

I'm sure that if RIPE were ever to be subject to a claim arising from a
member kicking themselves out of the LIR portal, you would find no
shortage of expert witnesses on this list queuing up to help have it
laughed out of court.

> I welcome a respectful discussion and look forward to your advice and
> guidance.
> 
I think that the feedback you have received in the last 24 hours is
quite unambiguous.

I hope we'll see some swift action in response.

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </ripe/mail/archives/routing-wg/attachments/20210319/3d83a130/attachment.sig>