Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Alex Band]

Dear list,

> On 20 Mar 2021, at 23:40, Geoff Huston  wrote:
> 
>> I am not sure it is possible, but I would love to see some centralized site 
>> where all dropped ROV invalids would appear.  This way I can see if I have a 
>> problem as well as if someone tried to hijack my space but was thwarted by 
>> the drop.
> 
> Hi Hank,
> 
> https://stats.labs.apnic.net/roas is another resource you may find helpful. 
> Finding advertised invalids gets increasingly tricky as providers turn on 
> drop invalid. This report collects the BGP tables from all routeviews peers 
> and all ris peers in an effort to find invalids closer to source.

I added stats.labs.apnic.net to the RPKI Insights and Statistics list:

https://rpki.readthedocs.io/en/latest/rpki/resources.html

Please let me know (or submit a PR) if there are more initiatives that should 
be on this list.

-Alex

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Lukas Tribus]

Hello Nathalie,


On Thu, 18 Mar 2021 at 21:40, Job Snijders via routing-wg
 wrote:
> 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 AS 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.

I second this, let's not unnecessarily involve lawyers. Let's not pull
an "ARIN" here.

People in misconfigured networks will be unable to access any AS
services, regardless of whether they previously accepted specific T
or not, and this is no different then today, the only difference is
that this would now also include ROV.


I immagine lawyers did not check other possible routing mistakes
people may make, like trying to access AS services from
bogon/unallocated or hijacked IP space or wrong/spoofed/invalid AS
paths which intermediate networks or AS may drop.



thanks,
lukas

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Lukas Tribus]

Hi,

On Sun, 21 Mar 2021 at 13:48, Hank Nussbacher  wrote:
> > Monitoring ROV invalids in other people's networks (validators;
> > routers) is not possible and I doubt it ever will be.
> >
>
> We managed to create "Certificate Transparency" logs where all CAs send
> their certificates so with a little bit of IETF geekery I am sure an RFC
> can be designed so that everyone dumps their RPKI drops into some
> central stream/repository.  Yeah I know - I'm dreaming :-)

Logging dropped ROV invalids at the router is not comparable to CT
(which is about issuing certificates), but rather HPKP with reporting
enabled.

However there is no incentive to do this for the folks involved.
Browser vendors pushing to enhance WebPKI do that because their
business case is tied to that. Router vendors struggle to implement
basic RTR support without introducing major operational issues and
their business case does not depend on getting it right the first time
(actually it is quite the opposite), asking for additional features at
this point really is a "dream". There is no direct business case for
network operators either. So I would not say this is a realistic
endeavour.


cheers,
lukas

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Hank Nussbacher]

On 21/03/2021 13:43, Lukas Tribus wrote:

Hello,

On Sat, 20 Mar 2021 at 20:06, Hank Nussbacher  wrote:

I am not sure it is possible, but I would love to see some centralized
site where all dropped ROV invalids would appear.  This way I can see if
I have a problem as well as if someone tried to hijack my space but was
thwarted by the drop.


Monitoring ROV invalids in other people's networks (validators;
routers) is not possible and I doubt it ever will be.



We managed to create "Certificate Transparency" logs where all CAs send 
their certificates so with a little bit of IETF geekery I am sure an RFC 
can be designed so that everyone dumps their RPKI drops into some 
central stream/repository.  Yeah I know - I'm dreaming :-)


Regards,
Hank

Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Lukas Tribus]

Hello,

On Sat, 20 Mar 2021 at 20:06, Hank Nussbacher  wrote:
> I am not sure it is possible, but I would love to see some centralized
> site where all dropped ROV invalids would appear.  This way I can see if
> I have a problem as well as if someone tried to hijack my space but was
> thwarted by the drop.

Monitoring ROV invalids in other people's networks (validators;
routers) is not possible and I doubt it ever will be.

What you can do is monitor your IP space for hijacks (whether ROA's
exist or not) and generally ROV invalids. Like Randy mentioned,
bgpalerter is a great tool for this job.

If you roll your own custom CA, you should monitor it against
different validator instances.


But this is a valid point: I definitely believe that most operators
don't really monitor their validation instances for periodic
successful validation, their RTR servers for not serving stale data
and their RTR clients for not using stale data (for whatever reasons,
including bugs and misconfigurations). Just pinging your validator or
check for a SYN-ACK on the RTR port is not enough monitoring, I'm
afraid.

Also see:
https://labs.ripe.net/Members/lukas_tribus/rpki-rov-about-stale-rtr-servers-and-how-to-monitor-them
https://lists.nlnetlabs.nl/pipermail/rpki/2021-March/000275.html

Given the lack of discussions about the topic of properly monitoring
validation and RTR state, and the definitely non-zero amount of issues
with this exact issue, I think it's safe to assume that for the most
part proper monitoring in the production networks out there is not
happening today.


cheers,
lukas

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Geoff Huston]

> I am not sure it is possible, but I would love to see some centralized site 
> where all dropped ROV invalids would appear.  This way I can see if I have a 
> problem as well as if someone tried to hijack my space but was thwarted by 
> the drop.

Hi Hank,

https://stats.labs.apnic.net/roas is another resource you may find helpful. 
Finding advertised invalids gets increasingly tricky as providers turn on drop 
invalid. This report collects the BGP tables from all routeviews peers and all 
ris peers in an effort to find invalids closer to source.

Geoff 

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Randy Bush]

> I am not sure it is possible, but I would love to see some centralized
> site where all dropped ROV invalids would appear.

dropped by whom?  views and actions vary.

> This way I can see if I have a problem as well as if someone tried to
> hijack my space but was thwarted by the drop.

massimo's bgpalerter, https://github.com/nttgin/BGPalerter, rocks!

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Hank Nussbacher]

On 19/03/2021 10:06, Ben Maddison via routing-wg wrote:

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


I am not sure it is possible, but I would love to see some centralized 
site where all dropped ROV invalids would appear.  This way I can see if 
I have a problem as well as if someone tried to hijack my space but was 
thwarted by the drop.


Regards,
Hank

Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Leo Vegoda]

Hi Nathalie,

On Fri, Mar 19, 2021 at 4:24 AM Nathalie Trenaman  wrote:

[...]

> > 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.
>
> First of all, thanks for the warm support for ROV on AS. I’m reading all 
> mails and the discussion with great interest.
> Now, here Leo brings up a tricky point. If we would create such a website, 
> outside of our network, be would basically tell that other party to 
> never-ever do ROV themselves.
> I don’t think that we can (or should) demand that from another network.
> Also, other operational “back doors” are not a good idea, as we try to 
> equally protect the registry and the routing table. This will have 
> consequences. Operators who “locked themselves out” should use another 
> network to reach the LIR Portal.

I might not have been clear. Sorry. My intention was not for the RIPE
NCC to create a full-service LIR Portal on a network that doesn't use
RPKI. Instead, I was trying to suggest creating something like the
many DNSSEC validation checking websites that help you understand
where things have gone wrong. Being able to provide this analysis to
someone who has tripped over will allow you to provide them with
authoritative advice on the paths they could take to fix things.

> Apart from a big warning in the LIR Portal if they are about to do something 
> that can lock them out (as Gert mentioned) , there isn’t much we can do. And 
> from what I read here, there isn’t much more we should do.

This is definitely a good idea.

Kind regards,

Leo

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Nathalie Trenaman]

Hi all,


> Op 18 mrt. 2021, om 17:01 heeft Leo Vegoda  het volgende 
> geschreven:
> 
> Hi,
> 
> On Thu, Mar 18, 2021 at 8:03 AM Nathalie Trenaman  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.

First of all, thanks for the warm support for ROV on AS. I’m reading all 
mails and the discussion with great interest. 
Now, here Leo brings up a tricky point. If we would create such a website, 
outside of our network, be would basically tell that other party to never-ever 
do ROV themselves. 
I don’t think that we can (or should) demand that from another network. 
Also, other operational “back doors” are not a good idea, as we try to equally 
protect the registry and the routing table. This will have consequences. 
Operators who “locked themselves out” should use another network to reach the 
LIR Portal. 

Apart from a big warning in the LIR Portal if they are about to do something 
that can lock them out (as Gert mentioned) , there isn’t much we can do. And 
from what I read here, there isn’t much more we should do. 

Kind regards,
Nathalie Trenaman
RIPE NCC

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Ben Maddison via routing-wg]

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 AS. 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 AS?  This is the AS Number for the RIPE NCC’s main service
> network. It includes most of our *.ripe.net 
> websites, including the LIR Portal (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 AS, 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 AS
> 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

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


signature.asc
Description: PGP signature

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Mikael Abrahamsson via routing-wg]

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 Abrahamssonemail: swm...@swm.pp.se

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Job Snijders via routing-wg]

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 AS

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

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Melchior Aelmans]

Thanks Nathalie for all your efforts trying to get this done while also
maneuvering between technical (im)possibilities and (legal) barriers. I'm
glad to see you seem to have the full picture and are trying to take into
account all parties interests.
I'm confident you will succeed in bringing this home in a way that works
for everybody. It seems to me you only need some more time to get all the
interests aligned.

Thanks for all your effort.
Cheers,
Melchior

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[James Rice]

On Thu, 18 Mar 2021, Erik Bais wrote:

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


Indeed, this is just like accidentally deleting your route: objects and 
finding that your upstreams no longer route your prefixes. You then need 
to find a different prefix to go and create your new route: objects from.


This bootstraping problem is not specific to RPKI.

Cheers
James

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Gert Doering]

Hi,

On Thu, Mar 18, 2021 at 05:13:06PM +0100, Kurt Kayser wrote:
> but you are assuming that the person trying to access RIPE NCC Service
> is the SAME that is responsible for messing/clearing it up?
> 
> That is for me not necessarily the same person.

Well, this is the case that is relevant here: someone in a given
network cannot access the LIR portal anymore, because of invalid ROA
for their very network, and to *fix* the ROA, this access is needed.  

Catch-22.

Any other sort of "someone messed up routing for someone else, for
some reason" is indeed nothing the RIPE NCC needs to concern themselves
over - but the case above is something that needs consideration and then
a well-communicated decision.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


smime.p7s
Description: S/MIME cryptographic signature

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Kurt Kayser]

Gert,

but you are assuming that the person trying to access RIPE NCC Service
is the SAME that is responsible for messing/clearing it up?

That is for me not necessarily the same person.

regards, Kurt

Am 18.03.21 um 17:08 schrieb Gert Doering:
> Hi,
>
> On Thu, Mar 18, 2021 at 04:56:22PM +0100, Kurt Kayser wrote:
>> They should raise their connectivity issue locally with their network
>> provider that should fix the problem.
> Uh, no...  if someone has a bad ROA, and the NCC does RPKI ROV, that user
> has no way to talk *to the NCC portal* anymore.  And that is what would
> be needed to actually "fix the problem".
>
> OTOH I'm with Erik here - if someone messes up their ROAs, they will
> need to find an Internet cafe or a LTE hotspot to hook their laptop to,
> and then they can access the portal again to fix it.  So I wouldn't
> worry too much about that situation.
>
> Maybe the portal can have a double check added ("you connect from 
> IP 2001:db8::1234, AS 65003, do you really really want to add a ROA
> for this network and AS 12345?  It will kick you out of the portal!").
>
> Gert Doering
> -- NetMaster



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Gert Doering]

Hi,

On Thu, Mar 18, 2021 at 04:56:22PM +0100, Kurt Kayser wrote:
> They should raise their connectivity issue locally with their network
> provider that should fix the problem.

Uh, no...  if someone has a bad ROA, and the NCC does RPKI ROV, that user
has no way to talk *to the NCC portal* anymore.  And that is what would
be needed to actually "fix the problem".

OTOH I'm with Erik here - if someone messes up their ROAs, they will
need to find an Internet cafe or a LTE hotspot to hook their laptop to,
and then they can access the portal again to fix it.  So I wouldn't
worry too much about that situation.

Maybe the portal can have a double check added ("you connect from 
IP 2001:db8::1234, AS 65003, do you really really want to add a ROA
for this network and AS 12345?  It will kick you out of the portal!").

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Leo Vegoda]

Hi,

On Thu, Mar 18, 2021 at 8:03 AM Nathalie Trenaman  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

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Kurt Kayser]

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 AS. 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 AS?
> This is the AS Number for the RIPE NCC’s main service network. It
> includes most of our *.ripe.net websites, including
> the LIR Portal (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 AS, 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 AS
> 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

Re: [routing-wg] RPKI Route Origin Validation and AS3333

[Erik Bais]

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  on behalf of Nathalie Trenaman 

Date: Thursday 18 March 2021 at 16:03
To: "routing-wg@ripe.net" 
Subject: [routing-wg] RPKI Route Origin Validation and AS

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 
AS. 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 AS?
This is the AS Number for the RIPE NCC’s main service network. It includes most 
of our *.ripe.net websites, including the LIR Portal 
(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 AS, 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 AS 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