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
