Hi Nathalie, Too bad the RIPE NCC is still dragging their feed on the actual RPKI implementation in their own infrastructure.. Yes we want RPKI.. Yes we want the RIPE NCC to implement RPKI in their network and drop invalid ROA’s ... No we don’t care if there are members that lock themselves out of the LIR portal using an incorrect RPKI ROA if they are on that same IP space with their laptop … ( they can always use the wifi hotspot on their mobile to get to the RIPE NCC portal.. ) We can always look at every angle in this till infinity .. but as operators of a network we need to make these decisions as well … And it is best for the community that the ones that are having invalid ROA’s understand that they have invalid roa’s.. And have to deal with the consequences for having them .. I’m sure that the current Terms & Conditions also doesn’t state that the RIPE NCC are knowingly not taking active measurements against BGP Hijacks and while there are good ways of protecting the network against that kind of attacks, the RIPE NCC has decided that it wasn’t worth protecting us from .. I know that it is a bit over simplified, but we have all seen what the effects could be on bgp hijacks in the past .. I’m sure that that is a bigger issue than someone who shoots their selves in the foot. Sorry if I sound a bit annoyed on the tone of voice, but come on .. it is 2021 .. the policy to get all-inclusive on RPKI was in 2013 .. when this WG decided to accept RPKI Certification for non-members. Can we now also get the RIPE NCC to step into this ? .. pretty please .. ? Regards, Erik Bais From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Nathalie Trenaman <nathalie@ripe.net> Date: Thursday 18 March 2021 at 16:03 To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [routing-wg] RPKI Route Origin Validation and AS3333 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). 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. From an analysis we made on 10 February, there were 511 of such announcements from our members and End Users. 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. I welcome a respectful discussion and look forward to your advice and guidance. Kind regards, Nathalie Trenaman Routing Security Programme Manager RIPE NCC

Hello Nathalie, I am a bit puzzled. Isn't that bebavior exactly what we wanted? RIPE NCC depends on other networks/providers that implemted RPKI as desired, and it works! So what's the problem? Helping people that are on the "invalid" side of the network? No. please don't. They should raise their connectivity issue locally with their network provider that should fix the problem. I believe there is no action to RIPE NCC here. Regards, Kurt Am 18.03.21 um 16:03 schrieb Nathalie Trenaman:

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

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.  From an analysis we made on 10 February, there were 511 of such announcements from our members and End Users.

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. 

I welcome a respectful discussion and look forward to your advice and guidance.

Kind regards,

Nathalie Trenaman Routing Security Programme Manager RIPE NCC

Hi, On Thu, Mar 18, 2021 at 8:03 AM Nathalie Trenaman <nathalie@ripe.net> wrote: [...]

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.

[...]

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

If the goal is to do this in a customer friendly way, perhaps consider creating a website at something like: https://brokenrpki.ripe.net, on a network that does not validate RPKI, so that users can be provided with any analytical tools or step-by-step guides thought necessary. Kind regards, Leo

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

On Thu, 18 Mar 2021, Nathalie Trenaman wrote:

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.

Thanks for the outreach to the community. Indeed, as stated above, the more providers are enabling RPKI, the less consequential it is whether RIPE NCC is performing ROV or not. This, as the scales tip to "if you made a ROA mistake you can't talk to the Internet", it instead becomes important that RIPE NCC staff has deep knowledge in how the RPKI ecosystem works, including monitoring etc. That would be an upside to performing ROV and implementing all monitoring that should come with it. Then RIPE NCC will have staff with operational knowledge of all aspects of routing, ROV and RPKI. I believe this would be beneficial to RIPE NCC and the Internet as a whole. Thanks. -- Mikael Abrahamsson email: swmike@swm.pp.se