[routing-wg] RPKI Route Origin Validation and AS3333

Dear RIPE NCC,

On Thu, Mar 18, 2021 at 04:03:16PM +0100, Nathalie Trenaman wrote:
> From the network operations perspective, there are no obstacles to
> enable ROV on AS3333

Excellent news!

> 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. 

Another scenario where a member can't reach RIPE NCC is when the
Member's network is not connected directly or indirectly to RIPE NCC's
network. There are many many scenarios in which this can happen.

Imagine RIPE NCC purchases IP transit from Transit_X, and the member
purchases IP transit from Transit_Y, but Transit_X and Transit_Y for one
reason or another don't peer with each other. In such a network topology
there no exchange of IP traffic is possible between RIPE NCC and the
Member.

The Internet is a 'mostly' connected graph of nodes, the default-free
zone is always in flux. Not everyone can reach everyone all the time.
Sometimes an operator has to walk to the local teahouse or jump on the
wifi network of their neighbor to help fix the connectivity issue.

There never is ANY guarantee all Members or End Users can exchange IP
traffic with RIPE NCC servers at all times. For this specific reason I
applaude the fact that the RIPE NCC 'member sign-up process' can be
executed online and ALSO via postal service. End-to-end Internet
connectivity is not a requirement to do business with RIPE NCC.

> From an analysis we made on 10 February, there were 511 of such
> announcements from our members and End Users.

quick side-note: Did your team check how many of those route
announcements are covered by less-specific 'valid' or 'not-found' route
announcements? or even by a default route? To me or this group the
answer is not that relevant, but I raise this comment to point out that
what matters most in service delivery is the end-to-end data-plane
connectivity, and rejecting a few RPKI invalid routes in and of itself
doesn't necessarily lead to loss of connectivity.

> 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.

And indeed, the RPKI terms and conditions SHOULD NOT mention anything of
such nature. As Relying Parties we can never know what people actually
intended to publish in the RPKI. All any Relying Party knows is that the
holder of the private keys of a CA with a set of subordinate resources
managed to produce a cryptographicly valid object validating according
the RPKI CP (RFC 6484) and there is a valid chain towards the locally
present Trust Anchor Locator.

It is always laudable to try to stop children from running around with
scissors, but RIPE NCC can't really stop operators from hurting their
network presence. The best RIPE NCC can do is to try to design good User
Interfaces, and provide accurate documentation.

> 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. 

I challenge the above assertion as I do not believe the legal team has
to update anything.

The RIPE NCC network is connected to the Internet as 'best effort'.

Whether a specific individual IP packets originating from RIPE NCC's
servers arrive at the the final destination or not is not relevant on a
case-by-case basis.

An IP packet might be dropped because of ethernet port congestion, a
routing partitioning gap in the BGP DFZ because of a peering dispute, a
submarine cable cut, a software defect, a member misconfiguring a RPKI
ROA, a local wifi problem, or any other reason...  it doesn't matter.

All we hope for is that when Internet outages occur, someone somewhere
is working on it. :-)

Kind regards,

Job