[routing-wg] Proposed Service Criticality Form

[Nathalie Trenaman]

Dear Colleagues,

During RIPE 84 in May, we discussed the Service Criticality Framework. We 
mentioned that we would like the Routing Working Group's input on the 
criticality rating for the RPKI service.

Thank you to the Co-chairs for asking the working group for input in June with 
the original form: 
https://www.ripe.net/ripe/mail/archives/routing-wg/2022-June/004582.html

Since we did not receive much feedback so far, we hereby share our proposed 
completed form with you (see attached PDF). We hope to receive your feedback by 
23 December. 

Kind regards
Nathalie Trenaman
RIPE NCC



RPKI SC Form.pdf
Description: Adobe PDF document
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] RPKI Quarterly Planning Q1 2023

[Nathalie Trenaman]

Dear colleagues,

We have now published the quarterly planning for Q1 2023 for RPKI:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
 
<https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>
This quarter, we’ll continue with the implementation of the “Publish in Parent” 
RFC 8181 support and building an audit framework for RPKI among other work 
items.

The goal of our quarterly planning is to communicate the work we’re doing for 
the coming months, get your input and start a discussion on other developments 
we should work on.
 
If you have any comments or questions, we hope you'll discuss with us on the 
list or, if you prefer, you can always contact the team directly at 
r...@ripe.net <mailto:r...@ripe.net> .

Kind regards,

Nathalie Trenaman
RIPE NCC

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RPKI Service Criticality Questionnaire

[Nathalie Trenaman]

Dear all,

I want to thank Mike and Randy for their input so far. It is important for us 
at the RIPE NCC to learn what the Routing Working Group thinks about the nine 
questions in relation to the service criticality. So if you haven’t yet, please 
provide us with your thoughts.

This will help us decide on many things in relation to RPKI, including service 
level objectives, security controls, as well as how we use cloud services in 
relation to RPKI. More information on the overall project is at:
https://labs.ripe.net/author/razvano/service-criticality-framework/ 
<https://labs.ripe.net/author/razvano/service-criticality-framework/>

As Job said, you can provide your input free form or you can follow the 
template. The most important thing is that we do get your input :)

Many thanks,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

> On 27 Jun 2022, at 17:58, Job Snijders via routing-wg  
> wrote:
> 
> Dear all,
> 
> RIPE NCC has asked the Routing WG Chairs to facilitate a working group
> conversation on framing RIPE NCC's RPKI services subcomponents in terms
> of criticality. 
> 
> At the bottom of this email is a form that focusses on three components:
> confidentiality, integrity and availability. Each component is split
> into three questions (a, b, and c), a total of 9 questions are being put
> forward to the working group. We envision this process to be a public
> consultation: WG participants can submit (free-form) responses, and also
> chime in by replying to each other's responses; hopefully bringing us to
> a degree of consensus in the coming weeks.
> 
> I believe this is an unique opportunity to help RIPE NCC! Investing our
> time - in turn - will help ourselves rely on and integrate RIPE NCC's
> RPKI services in our production environments. The goal is to help
> RIPE NCC develop a deeper understanding of how the moving parts fit
> together, which in turn helps decide where and how to invest resources.
> 
>>>> Your feedback is much appreciated! <<<
> 
> NOTE: if you are *NOT* a RIPE NCC member, and use the RIPE NCC Trust
> Anchor (e.g. as Relying Party to make informed routing decisions, inside
> and outside the RIPE region), your feedback *also* is much appreciated.
> 
> Kind regards,
> 
> Job, Ignas, Paul
> Routing WG co-chairs
> 
> --- FORM STARTS BELOW ---
> 
> Service Criticality Questionnaire Form - RPKI
> =
> 
> Introduction
> 
> 
> This form is used to gather input from the community on the service
> criticality of the RPKI Service from RIPE NCC. The framework is
> detailed in: 
> https://labs.ripe.net/author/razvano/service-criticality-framework/
> 
> The service criticality has three components:
> 
> * Confidentiality: What is the highest possible impact of a data
>   confidentiality-related incident (e.g. data leak)?
> 
> * Integrity:   What is the highest possible impact of a data
>   integrity-related incident (e.g. hacking)?
> 
> * Availability:What is the highest possible impact of a service
>  availability-related incident (e.g. outage)? (All RIPE NCC
>  services are designed with at least 99% availability, so
>   please consider outages of up to 22 hours.)
> 
> Service purpose
> ---
> 
> The RIPE NCC RPKI Service is the RPKI Trust Anchor (TA) for the RIPE NCC
> service region, comprised of:
>* RPKI Dashboard (in the LIR portal)
>* Repositories (rsync/RRDP)
>* Certification Authorities (CAs)
>* RPKI Management API
>* Hardware Security Modules (HSMs)
>* Datasets
> 
> Service Criticality
> ---
> 
> Please review the following three areas.
> 
> ## (1) Global Routing
> 
> Incident Serverity
>* Low(No / negligible impact)
>* Medium (One or a few ASes are unavailable)
>* High   (Many ASes in a region are unavailable)
>* Very High  (Global Internet routing disruptions)
> 
> Please rate the incident serverity (Low to Very High) in the following
> three areas. Please explain why.
> 
> (a) Confidentiality (Impact level of incidents such as data leaks)
> 
> Answer 1a:
> 
> (b) Integrity (Impact level of incidents such as hack attempts)
> 
> Answer 1b:
> 
> (c) Availability (Impact level of service outage incidents, up to 22 hours 
> per quarter)
> 
> Answer 1c:
> 
> ## (2) IP addresses and AS Numbers
> 
> Incident Serverity
>* Low   (No / negligible impact)
>* Medium(Local disruptions (registration information not being
> available for so

[routing-wg] RPKI Quarterly Planning Q3 2022

[Nathalie Trenaman]

Dear colleagues,

The quarterly planning for Q3 2022 for RPKI has now been published:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
 
<https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>
Recently, we published a page for the different components of RPKI which can be 
accessed at:
https://status.ripe.net <https://status.ripe.net/>
We’re still carrying on with the activities started in Q1 2022 such as 
implementing "Publish in Parent" RFC 8181 support and creating multiple 
parallel internal test environments for RPKI. We’ll announce here on the list 
when these have finished. 
Also, we’re currently starting the process for the purchase of the new HSMs, 
which we will start to use as soon as we can. 

The goal of our quarterly planning is to communicate the work we’re doing for 
the coming months, get your input and start a discussion on other developments 
we should work on.
 
If you have any comments or questions, we hope you'll discuss with us on the 
list or, if you prefer, you can always contact the team directly at 
r...@ripe.net <mailto:r...@ripe.net> .

Kind regards,
Nathalie Trenaman 
Routing Security Programme Manager
RIPE NCC

-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] Follow up: RIPE NCC Open House - RPKI Data

[Nathalie Trenaman]

Dear colleagues,

Last week, on Wednesday 4 May 2022, 14:00 UTC, we held a RIPE NCC Open House on 
the topic of RPKI Data.
You can find the recording here: 
https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-rpki-data
 
<https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-rpki-data>

Thank you to all who participated, I thought it was a useful session and I 
enjoyed the discussion and feedback we received.
During the session I promised to send an e-mail to this list with a summary of 
all data and visualisations we currently have public for RPKI:

Visualisations:

https://certification-stats.ripe.net/ <https://certification-stats.ripe.net/>
-Generated from the RIR Trust Anchor Statistics https://ftp.ripe.net/rpki/ 
<https://ftp.ripe.net/rpki/>

https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html
 
<https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html>
-Generated from "delegated stats” in combination with BGP data from RIS
-No IPv6 

Data:

https://ftp.ripe.net/rpki/ <https://ftp.ripe.net/rpki/>
-Documented on 
https://github.com/RIPE-NCC/internet-dataset-descriptions/blob/main/rpki-repo-archive.md
 
<https://github.com/RIPE-NCC/internet-dataset-descriptions/blob/main/rpki-repo-archive.md>
-Daily data per Trust Anchor per 2011

Public tools:

https://rpki-validator.ripe.net/ui/ <https://rpki-validator.ripe.net/ui/>
-User interface for Relying Party software

https://stat.ripe.net/widget/rpki-by-trust-anchor 
<https://stat.ripe.net/widget/rpki-by-trust-anchor>
-Generated from https://ftp.ripe.net/rpki/ <https://ftp.ripe.net/rpki/>

https://stat.ripe.net/app/use-cases/asn/rpki-check/S1__C16e 
<https://stat.ripe.net/app/use-cases/asn/rpki-check/S1__C16e> (example)
-Shows the RPKI validity state for a combination of prefix and Autonomous 
System.
-Generated from https://rpki-validator.ripe.net/ui/ 
<https://rpki-validator.ripe.net/ui/>

https://stat.ripe.net/docs/02.data-api/rpki-history.html 
<https://stat.ripe.net/docs/02.data-api/rpki-history.html>
-API call returns a timeseries with the count of VRPs (Validated ROA Payload) 
for the requested resource.  
-Generated from https://ftp.ripe.net/rpki/ <https://ftp.ripe.net/rpki/>


My key take aways from the session:

-Ruediger Volk asked for an inventory of our current data, visualisations and 
tools. I started by this e-mail to the Working Group and I’m still considering 
how to make them easier to find on our website. 
-Randy Bush noted that experiments will/might pollute our data. Ties suggested 
to add known experiments to the GitHub dataset description.
-Mingwei Zhang mentioned that he is currently working with Emile Aben and 
Agustin Formoso on “when did a VRP appear/disappear” feature for RIPEstat. This 
will be a very valuable addition for trouble shooting. 
-John Kristoff would like to see statistics on the time it takes from the 
moment someone hits “submit” in the LIR portal for a ROA, to the moment the VRP 
is visible in the repository and when it is seen picked up by routers. 
-Job Snijders mentioned that it would be beneficial to have ftp.ripe.net/rpki 
<http://ftp.ripe.net/rpki> data available as rsync://ftp.ripe.net/rpki 

-Amreesh Phokeer suggested a more granular data set for Trust Anchor data. This 
is currently a daily dump. We are interested to hear how granular would be 
useful. Also Amreesh would be interested in statistics about revoked ROAs. 
-Ruediger Volk added that he would be interested in data that shows how 
frequent CRLs are used. Job Snijders provided insight in his mail to the WG: 
https://www.ripe.net/ripe/mail/archives/routing-wg/2022-May/004566.html 
<https://www.ripe.net/ripe/mail/archives/routing-wg/2022-May/004566.html>
-Sacha mentioned that it would be useful to have a tool that would show how a 
ROA would impact a route, without actually creating that ROA, or for a prefix 
that you don’t have holdership of.  
-Nathalie said that she would like to get rid of the world map, as it is now 
well-known and does not include IPv6. A better alternative, that includes IPv6 
can be found on: https://rpki-maps.nlnetlabs.nl/ui/world.html 
<https://rpki-maps.nlnetlabs.nl/ui/world.html>

We’re looking into all your suggestions and where possible implement them. Stay 
tuned :)

If I missed something, or if you want to share your thoughts, have suggestions, 
please send an e-mail to the list or directly to us on r...@ripe.net 
<mailto:r...@ripe.net>

Kind regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC





-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RPKI vulnerable?

[Nathalie Trenaman]

Dear Hank,

> On 18 Feb 2022, at 14:34, Hank Nussbacher  wrote:
> 
> On 18/02/2022 10:54, Nathalie Trenaman wrote:
>> Hi Nick,
>>> On 18 Feb 2022, at 09:53, Nick Hilliard  wrote:
>>> 
>>> Hank Nussbacher wrote on 18/02/2022 07:39:
>>>> We are working with large network providers and registrars on mitigating 
>>>> the vulnerabilities in RPKI deployments.
>>> 
>>> Has anyone from the RIPE NCC been in contact with this group?
>>> 
>>> Nick
>> No, we haven’t. This also sparked our curiosity, so we’re trying to contact 
>> them.
> 
> Haya posted on her Linkedin posting (3 hours ago) "RIPE NCC is on our list" 
> in response to Ivo Dijkhuis asking "Dear Haya, we would certainly appreciate 
> an invitation to that workshop."
> 
> So I guess RIPE NCC needs to find out who within the NCC has been getting 
> Haya's emails.

As I stated this morning, no-one within the RIPE NCC has received Haya’s 
e-mails, or any e-mails from this research group regarding this research. This 
is why our Senior Security Officer Ivo Dijkhuis posted that message.  

Kind regards,
Nathalie Trenaman
RIPE NCC
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] RPKI vulnerable?

[Nathalie Trenaman]

Hi Nick,

> On 18 Feb 2022, at 09:53, Nick Hilliard  wrote:
> 
> Hank Nussbacher wrote on 18/02/2022 07:39:
>> We are working with large network providers and registrars on mitigating the 
>> vulnerabilities in RPKI deployments.
> 
> Has anyone from the RIPE NCC been in contact with this group?
> 
> Nick

No, we haven’t. This also sparked our curiosity, so we’re trying to contact 
them.

Kind regards,
Nathalie Trenaman
RIPE NCC
-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

[routing-wg] RPKI Quarterly Planning Q1 2022

[Nathalie Trenaman]

Dear colleagues,

We have now published our quarterly planning for Q1 2022 for RPKI: 
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
 
<https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>

We’re still working on finishing some loose ends from Q4 2021, for example open 
sourcing the RPKI core code and finishing the final step for the HSM migration 
and we’ll announce here on the list when this has finished. 
 
Our goals are to make it clear what we are working on in the coming months, and 
also to get discussion around those plans so we can make developments based on 
community input.
If you have comments or questions around this, we hope you'll discuss with us 
on the list or you can always contact the team directly at r...@ripe.net 
<mailto:r...@ripe.net>.

Kind regards,
Nathalie Trenaman 
Routing Security Programme Manager
RIPE NCC-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/routing-wg

Re: [routing-wg] Add BGPsec support to Hosted RPKI?

[Nathalie Trenaman]

Hi all,

Please forgive me for top-posting (and trimming the recipients list).
There seems to be support for both BGPsec in Hosted RPKI and for “Publish in 
Parent" - RFC8181. 
As I’m currently working on the roadmap for Q1 2022, I will discuss with the 
team what needs to be done in order to implement both proposals, possible 
dependencies and other work.
In order to implement BGPsec for hosted RPKI for example, we also need to keep 
in mind UI work on the RPKI Dashboard to make this easy to use (and easy to 
understand).

Kind regards,
Nathalie Trenaman
RIPE NCC



> Op 11 okt. 2021, om 12:36 heeft Job Snijders via routing-wg 
>  het volgende geschreven:
> 
> On Mon, Oct 11, 2021 at 11:33:40AM +0200, Tim Bruijnzeels wrote:
>> Why now?
> 
> There are published RFC and running code. Time for the next step.
> 
>> RIPE NCC may have substantial resources, but they are applied
>> sequentially. Perhaps RIPE NCC can shed a light on the effort
>> involved, but I suspect it's more than we might think. 
> 
> It is not clear to me what you mean with "more than we might think".
> I think a standard PKCS#10 / PKCS#7 exchange is less involved than
> implementing support for an entirely new Signed Object profile?
> 
> Additionally, to implement BGPsec support in the hosted environment, the
> developers can take inspiration from prior-art. For ASPA no examples
> exist yet.
> 
>> In that context, I am not against BGPSec as such, there are just
>> things that I would like to see first:
> 
> Thank you for sharing your personal wishlist. The above 'context' seems
> to depend on an assumption that work progresses sequentially.
> 
>> 1. Publication Service
>> 
>> I think this has immediate applicability to anyone considering running a 
>> delegated
>> CA. It's also in the interest of the ecosystem to limit the excessive growth 
>> in the
>> number of repositories.
>> 
>> 2. ASPA
>> 
>> This is in draft status, but so were ROAs when the production system 
>> launched in
>> January 2011.
> 
> I'll with the working group a brief overview of where ASPA is, which
> should help understand why ASPA probably is more of a 2022/2023 project.
> I'm personally involved as co-author of the ASPA specification.
> 
>* ASPA is 2 drafts, 0 RFCs:
>  
> https://datatracker.ietf.org/doc/search/?name=aspa=on=on
>  This means that ASPA has not yet received review from the wider
>  IETF community.
> 
>* As of yet no codepoints have been assigned to ASPA
>  https://www.iana.org/assignments/rpki/rpki.xhtml
> 
>* No RPKI-to-Router protocol extension has been proposed for ASPA.
> 
>* At the IETF 111 SIDROPS meeting it was suggested to first
>  construct a testbed before moving ASPA forward. See slids 11 and
>  onwards: 
> https://datatracker.ietf.org/meeting/111/materials/slides-111-sidrops-running-code-sidrops-00
>  The testbed does not exist yet: https://github.com/SIDROPS/ASPA-testbed
> 
>* ASPA's running code status page still is empty
>  https://trac.ietf.org/trac/sidrops/wiki ("AspaImplementations?" is a
>  non-existing wiki page)
> 
>* Only a few months ago an issue was discovered in the ASPA
>  verification algorithm in relationship to IX Route Servers. This
>  has since been resolved (in -07 of the draft). To me it is an
>  indicator that ASPA's specification still is in flux.
> 
> All in all ASPA undeniably is making progress, I would love for a
> RPKI-based routing policy signaling mechanism to exist, but there is a
> lot of work yet to be done.
> 
> I would suggest to start a discussion about adding ASPA to the RPKI
> Quarterly planning as soon as passed at least "IETF Working Group Last
> Call".
> 
> Kind regards,
> 
> Job
> 

[routing-wg] RPKI Quarterly Planning Q4 2021

[Nathalie Trenaman]

Dear colleagues,

We have now published our Q4 planning for RPKI:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
 
<https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap>
This is the second quarterly plan we have published. The previous plan for Q3 
is also available so you can see how we progressed and see what was completed 
and what will continue in Q4:
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap/archived-plans

If you have comments or questions around our plans, we hope you'll discuss with 
us on the list or you can always contact us directly at .

Kind regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC 

Re: [routing-wg] Support for "Publish in Parent" [RPKI RFC 8181]?

[Nathalie Trenaman]

Dear Job,

> Op 20 sep. 2021, om 13:26 heeft Job Snijders via routing-wg 
>  het volgende geschreven:
> 
> Hi working group,
> 
> In recent mail threads the concepts of "Hosted RPKI" and "Delegated
> RPKI" came up, but as mentioned by Tim and Rubens, another flavor also
> exists! A "hybrid" between Delegated and Hosted, informally known as
> "publish in parent" (aka RFC 8181 compliant Publication Services).
> 
> There are multiple benefits to the general RPKI ecosystem when RIRs and
> NIRs support RFC 8181:
> 
>* Resource Holders are relieved from the responsibility to operate
>  always online RSYNC and RRDP servers.
> 
>* Reducing the number of Publication servers reduces overall
>  resource consumption for Relying Parties. Consolidation of
>  Publication Servers improves efficiency and is generally
>  considered advantageous.
> 
>* Helps avoid "reinventing the wheel": it might be better to have a
>  small group of experts build a globally performant and resillient
>  infrastructure that serves everyone, rather than everyone building
>  the 'same' infrastructure.
> 
> Other RIRs and NIRs are also working on RFC 8181 support. RFC 8181 is
> relatively new so it'll take some time before we see universal
> availability.
> 
>NIC.BR (available): https://registro.br/tecnologia/numeracao/rpki/
>APNIC (available): 
> https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-parent-self-hosted-rpki/
>ARIN (planned): 
> https://www.arin.net/participate/community/acsp/suggestions/2020/2020-1/
> 
> Is implementing RFC 8181 support something RIPE NCC should add to the
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap
>  ?
> 
> What do others think?
> 
> Kind regards,
> 
> Job
> 
> Relevant documentation:
> https://datatracker.ietf.org/doc/html/rfc8181

Thanks for bringing this up. 
Please be aware that the roadmap you mentioned just shows the roadmap for the 
current quarter and not for a longer period. 
If you see something missing there, it does not mean that we don’t intend to 
work on it, just (probably) not in the current quarter, unless it is urgent of 
course. The reason why we chose to publish a quarterly roadmap, is to 
facilitate discussions on our priorities with this working group. 
This is exactly why I’m very pleased that you brought up this topic (potential 
work item). We can always add new functionality to future roadmaps. In about a 
week, we will publish our roadmap for Q4. 

In the past, RFC8181 support (Hybrid RPKI, publish in parent, 
repo-as-a-service) has been asked from RIPE NCC by a few community members, for 
example by Benno Overeinder at RIPE82 in the routing-wg 
session:https://ripe82.ripe.net/archives/steno/47/ 
<https://ripe82.ripe.net/archives/steno/47/> 

I look forward to seeing a discussion here on this topic to find out if there 
is a broader interest.

Kind regards,

Nathalie Trenaman
RIPE NCC

[routing-wg] A Changing User Interface for rpki-validator.ripe.net

[Nathalie Trenaman]

Dear colleagues, 

As we have already announced, we have ended support for our RPKI Validator. 
We have still been running our Validator 3 on http://rpki-validator.ripe.net 
<http://rpki-validator.ripe.net/>  as an informational service to the 
community. 
However, we will be replacing our validator with Routinator on Thursday 16 
September. 
Routinator has a new User Interface, so this migration will change the look and 
feel of http://rpki-validator.ripe.net <http://rpki-validator.ripe.net/>. 
In order to prepare for this change, you can try out the new UI that Routinator 
will use at https://routinator.nlnetlabs.nl <https://routinator.nlnetlabs.nl/>

More details are in our RIPE Labs article at 
https://labs.ripe.net/author/nathalie-trenaman/a-changing-user-interface-for-rpki-validatorripenet/
 
<https://labs.ripe.net/author/nathalie-trenaman/a-changing-user-interface-for-rpki-validatorripenet/>

Best regards,
Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

Re: [routing-wg] RPKI Quarterly Planning

[Nathalie Trenaman]

Hi Hank,

> Op 13 jul. 2021, om 14:46 heeft Hank Nussbacher  het 
> volgende geschreven:
> 
> On 13/07/2021 14:08, Job Snijders via routing-wg wrote:
>> On Tue, Jul 13, 2021 at 05:25:11AM +0200, Daniel Karrenberg wrote:
>>> It might also be that the operational community has chosen other fora to
>>> discuss because this working group is not working.
>> What a strange thing to say. Of course there are other fora to discuss
>> RPKI, one of the most important ones is IETF's SIDROPS working group
>> (which is quite active!).
>> As for the road map - RIPE NCC indicated feedback can be shared with the
>> routing-wg@ or with r...@ripe.net. I myself opted to try the latter
>> route to re-iterate a request for publish dashboards and graphs about
>> the RPKI service which resulted in 'RPKI-2021-#01' being added to the
>> roadmap.
>> The motivation behind RPKI-2021-#01 is that many IXPs offer publicly
>> accessible graphs ala:
>> https://www.ams-ix.net/ams/documentation/total-stats
>> https://portal.linx.net/
>> https://www.jpnap.net/ix/traffic.html
>> https://www.netnod.se/ix/statistics
>> https://de-cix.net/en/locations/frankfurt/statistics
>> When incidents happen, these graphs enable the IX participants to
>> quickly understand whether 'something is wrong', because humans are
>> really good at pattern recognition.
>> I imagine that developing more insight into the RIPE NCC RPKI service
>> will offer the community similar benefits as what the community gleans
>> from these public IX stats, hence the ask for RPKI-2021-#01.
>> Kind regards,
>> Job
> 
> Tool missing that I would like to see:
> 
> Breakdown by country - unknowns + invalid ROAs.  Listed as a table of prefix 
> + ASN.  Best I have found is https://stats.labs.apnic.net/roas which lists 
> totals but doesn't provide a breakdown by specific prefix and ASN per 
> country.  Maybe I'm missing it.
> 
> Regards,
> Hank
> 

Is this of any help? Romain Fontugne launched this tool this week:
https://ihr.iijlab.net/ihr/en-us/rov <https://ihr.iijlab.net/ihr/en-us/rov>  
(worldwide)
https://ihr.iijlab.net/ihr/en-us/countries/FR 
<https://ihr.iijlab.net/ihr/en-us/countries/FR> (per country)
https://ihr.iijlab.net/ihr/en-us/networks/AS7922 
<https://ihr.iijlab.net/ihr/en-us/networks/AS7922> (per ASN)

Kind regards,
Nathalie Trenaman
RIPE NCC

[routing-wg] Fwd: Update on upcoming maintenance to ARIN’s RPKI infrastructure

[Nathalie Trenaman]

Hi all,

Since this is also relevant for operators in our region, sharing ARINs 
announcement here as well:

ARIN will be conducting a maintenance of their RPKI infrastructure on July 20th 
14:00 UTC for 30 minutes.

- Forwarded message from Brad Gorman mailto:bgor...@arin.net>> -

Date: Tue, 22 Jun 2021 20:51:34 +
From: Brad Gorman mailto:bgor...@arin.net>>
To: "arin-tech-disc...@arin.net <mailto:arin-tech-disc...@arin.net>" 
mailto:arin-tech-disc...@arin.net>>
Subject: [arin-tech-discuss] Update on upcoming maintenance to ARIN’s RPKI 
infrastructure

ARIN previously announced an upcoming maintenance to our RPKI infrastructure.   
https://www.arin.net/announcements/20210602-rpki/ 
<https://www.arin.net/announcements/20210602-rpki/>

We are updating the notice of this upcoming maintenance with the following 
additional information:


- July 20th is the date scheduled for this activity  

- We anticipate that the maintenance will take place starting at 10:00 
AM ET for a period of 30 minutes

- During the 30-minute window, customers will not be able to reach the 
ARIN RPKI repository, but ARIN will NOT be
  taking any action that impacts the integrity of the data contained in 
the repository


Sincerely,

Brad Gorman
Senior Product Owner, Routing Security
American Registry for Internet Numbers (ARIN)

___
arin-tech-discuss mailing list
arin-tech-disc...@arin.net <mailto:arin-tech-disc...@arin.net>
https://lists.arin.net/mailman/listinfo/arin-tech-discuss 
<https://lists.arin.net/mailman/listinfo/arin-tech-discuss>

----- End forwarded message ——

Kind regards,
Nathalie Trenaman
RIPE NCC

[routing-wg] RPKI Quarterly Planning

[Nathalie Trenaman]

Dear colleagues,

We are now publishing our quarterly planning for RPKI: 
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-planning-and-roadmap

Our goals here are to make it clear what we are working on in the coming 
months, and also to get discussion around those plans so we can make 
developments based on community input.
If you have comments or questions around this, we hope you'll discuss with us 
on the list or you can always contact the team directly at r...@ripe.net.
 
Kind regards,
Nathalie Trenaman 
Routing Security Programme Manager
RIPE NCC

[routing-wg] Ending Support for the RIPE NCC RPKI Validator

[Nathalie Trenaman]

Dear colleagues,

This is a reminder that on Thursday, 1 July 2021, we will stop supporting the 
RIPE NCC RPKI Validator. This will have no impact on any of our core activities 
around the Resource Public Key Infrastructure (RPKI).

After discussions we had with members and the wider community at this mailing 
list and at the last two RIPE Meetings, we agreed that this approach will allow 
us to focus on the core of RPKI and maintain a secure, stable and resilient 
RPKI Certificate Authority.

We strongly recommend that any network operators still running our RPKI 
Validator switch to an alternative Relying Party software [1] before 1 July. 
Alternatives include: 
•   Routinator
•   RPKI-client
•   Fort
•   OctoRPKI
•   Prover


It is important to note that continuing to use the RIPE NCC RPKI Validator 
after 1 July 2021 may lead to security incidents, as we will no longer be 
making updates to the software.

If you have any questions, please get in touch with me.

Best regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

[1] https://rpki.readthedocs.io/en/latest/ops/tools.html 
<https://rpki.readthedocs.io/en/latest/ops/tools.html>

[routing-wg] Security & Compliance reports for RPKI

[Nathalie Trenaman]

Dear colleagues,

Security is always high on our list of priorities for RPKI. Every year, we ask 
an external party to carry out a security audit of our RPKI systems. This is 
the first year that we are publishing the security report, in an effort to 
increase transparency and trust in the RPKI system. 

Please note that the report also listed several recommendations that should be 
included in a penetration test. These recommendations have been redacted from 
the original report, as we will include them in the penetration test scheduled 
for June 2021. Also, some comments about the proprietary software for the 
Hardware Security Module have been redacted. 

On 
https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/security-and-compliance
 you will now find the RFC compliance report written by Radically Open Security 
in 2020 and our response to their findings. 

We hope you will find these reports useful, and we look forward to your 
feedback.

Kind regards,
Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

Re: [routing-wg] request to enable ICMP echo-reply on rpki.ripe.net?

[Nathalie Trenaman]

Hi Job,

Our ops team just enabled ICMP echo-reply on rpki.ripe.net 
<http://rpki.ripe.net/>.

Kind regards,
Nathalie Trenaman
RIPE NCC

> Op 5 mei 2021, om 12:23 heeft Job Snijders via routing-wg 
>  het volgende geschreven:
> 
> Hi RIPE NCC, hi all,
> 
> In today's troubleshooting adventure, an operator experienced difficulty
> pinpointing where exactly a connectivity issue between them and
> rpki.ripe.net (193.0.6.138 + 2001:67c:2e8:22::c100:68a) resided.
> 
> It would be helpful if RIPE NCC reverted disabling responding to ICMP
> echo requests originating from the Internet. Would it be possible to
> adjust the firewall settings to accomodate troubleshooting and
> monitoring?
> 
> Right now connectivity testing has to be performed directly against the
> rsync daemon's internet-exposed TCP port (873) - but it would be much
> cheaper and faster for both the tester and the service hoster if instead
> ICMP echo requests could be used as an early warning system (rather than
> the rsync service itself).
> 
>$ ping -c 6 rpki.ripe.net
>PING rpki.ripe.net (193.0.6.138): 56 data bytes
> 
>--- rpki.ripe.net ping statistics ---
>6 packets transmitted, 0 packets received, 100.0% packet loss
> 
> The above test result differs compared to sending echo requests to
> molamola.ripe.net or manus.authdns.ripe.net.
> 
> Kind regards,
> 
> Job
> 

[routing-wg] RPKI Route Origin Validation on RIPE NCC Network

[Nathalie Trenaman]

Dear colleagues,

(My colleagues are drafting a reply on the rsync issue)

Following up on my previous email and the discussion we had in this mailing 
last about enabling Route Origin Validation (ROV) invalid == reject on the RIPE 
NCC’s network, AS, I am happy to inform you that we will be going ahead on 
Monday, 19 April. 

I have written a RIPE Labs article with more information, which you can find at:
https://labs.ripe.net/author/nathalie_nathalie/rpki-and-as-or-how-we-eat-our-own-dogfood/

Thank you very much for your contributions, discussion and support.

Kind Regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

[routing-wg] Issue affecting rsync RPKI repository fetching

[Nathalie Trenaman]

Dear colleagues,

We have been made aware of an issue that may affect some users who use RPKI 
relying party (RP) software that uses rsync. Please note that by default, only 
rpki-client reads from rsync; the rest of the RPs prefer the RPKI Repository 
Delta Protocol (RRDP). 

The issue appears to create some inconsistency between the RPKI repository and 
rsync clients. In more detail, an RRDP client reads a complete state for a 
specific “serial” from the repository. In contrast, an rsync client syncs the 
state in multiple steps. First, a list of files is copied, followed by updates 
for files that have been copied. In an affected scenario, a certificate is 
added and one of the other files (the manifest) is modified after the file list 
has been sent. By reading the new manifest, but not copying the new file (it is 
not on the rsync file list), the repository copied by the rsync client contains 
an invalid manifest (a file is missing) and the RP software rejects it.

We are planning on changing our publication infrastructure and using the same 
"revisions" RRDP uses for the content of the rsync repository. Rsync is an 
officially supported distribution protocol for RPKI repository data, and it is 
one of our highest priorities that the data published is atomic and consistent. 
We plan to release the new publication infrastructure in Q2/Q3 2021. Part of 
this work will mitigate these non-repeatable-reads for clients using rsync.

We will update you on our progress during RIPE 82, taking place online from 
17-21 May 2021.

Kind regards,

Nathalie Trenaman
RIPE NCC

Re: [routing-wg] RPKI Invalid == Reject policies on the AS 3333 EBGP border

[Nathalie Trenaman]

Dear chairs, all,

> Op 26 mrt. 2021, om 16:46 heeft Paul Hoogsteder  het volgende 
> geschreven:
> 
> Dear RIPE Routing WG and RIPE NCC,
> 
> after having gone through all responses on the mailing list there seems to
> be unanimous support for RIPE NCC to proceed with the deployment of "RPKI
> Invalid == Reject" policies on the AS  EBGP border.
> 
> Kind regards,
> 
> Job Snijders & Paul Hoogsteder
> 
> 

Many thanks for all your input, we will proceed accordingly. 
Expect a message from us soon!

Kind regards,
Nathalie Trenaman
RIPE NCC

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

[routing-wg] RPKI Route Origin Validation and AS3333

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

[routing-wg] Join the RIPE NCC Open House: Hosted vs. Delegated RPKI

[Nathalie Trenaman]

Dear colleagues,

We’re hosting a RIPE NCC Open House this Friday, 19 March (09:00 UTC), on the 
differences between hosted and delegated RPKI, and their use cases.

Alex Band, Director of Product Development for NLNetLabs and I will discuss 
different scenarios in which hosted and delegated RPKI could be useful, and 
will give a short demo on how to use Krill as a software solution.

Event details and registration can be found at:
https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-hosted-vs-delegated-rpki
 
<https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-hosted-vs-delegated-rpki>

Hope to see you there!

Kind regards,
Nathalie Trenaman
RIPE NCC

Re: [routing-wg] Improving operations at RIPE NCC TA (Was: Delay in publishing RPKI objects)

[Nathalie Trenaman]

Hi Daniel,

> Op 19 feb. 2021, om 09:33 heeft Daniel Suchy via routing-wg 
>  het volgende geschreven:
> 
> Hi Nathalie,
> 
> On 2/19/21 9:15 AM, Nathalie Trenaman wrote:
>> We can do many things but our main concern is to implement what is
>> needed in a way that we can manage effectively and with input from all
>> the relevant stakeholders. You've provided a big list here and some of
>> these are already on our roadmap. For example, ROV in AS, we are
>> working on this, and we expect to come with an announcement soon.
> 
> Can you share your roadmap? I think also plans and timeline should be open. 
> As these plans exists, you can just publish such document(s) for those who're 
> interested.
> I think community should be informed in advance about plans - not just 
> ex-post by "marketing" announcements about done things.

I shared the RPKI roadmap on RIPE Labs last year: 
https://labs.ripe.net/Members/nathalie_nathalie/where-were-at-with-rpki-resiliency
 
<https://labs.ripe.net/Members/nathalie_nathalie/where-were-at-with-rpki-resiliency>
and the work plan for this year has recently been finalised and will first be 
presented to the Executive Board in March. After that, I will publish another 
RIPE Labs article with the work plan for this year and announce it in this 
working group as well. 


> 
>> Also, open-sourcing the RPKI core is on our roadmap, but this will take
>> a bit longer.
> 
> Can you explain in detail, where's problem with opensourcing RPKI core 
> (publishing it's code)? Are there some legal reasons or there's something 
> else blocking publishing code you're using? As above, how long we have to 
> wait? I think (open) community review is important also from security 
> perspective for this critical part of internet infrastructure.
> 

I agree that open sourcing the RPKI core is important, and so are many other 
things that we are working on. Please be assured that this is on our radar and 
we’ll move forward with this as soon as we can. 

> - Daniel
> 

Kind regards,
Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

Re: [routing-wg] Improving operations at RIPE NCC TA (Was: Delay in publishing RPKI objects)

[Nathalie Trenaman]

Hi Job,

See my responses inline in your final section...

> Op 17 feb. 2021, om 16:58 heeft Job Snijders via routing-wg 
>  het volgende geschreven:
> 
> Dear RIPE NCC,
> 
> On Wed, Feb 17, 2021 at 11:28:32AM +0100, Nathalie Trenaman wrote:
>>> The multitude of RPKI service impacting events as a result from
>>> maloperation of the RIPE NCC trust anchor are starting to give me
>>> cause for concern.
>> 
>> I’m sorry to hear this. Transparency is key for us, this means that we
>> report any event. In this case, we were not compliant with our CPS and
>> this non-publishing period had operational impact.
> 
> From the previous email there might be a misunderstanding about what
> rpki-client and Routinator do. Both utilities help Relying Parties
> validate X.509 signed CMS objects and transform the validated content
> into authorizations and attestations. Neither utility is a SLA or CPS
> compliance monitor. RIPE NCC - as CA operator - needs different tools.
> 
> Neither utility has been designed to interpret the Certification
> Practise Policy (written in a natural language) and subsequently
> programmatically transform the described 'Service Level' into metrics
> suitable for monitoring.
> 
> A relying party can never tell the difference between a publication
> pipeline being empty because CAs didn't issue new objects, or a
> publication pipeline being empty because of a malfunction in one of RIPE
> NCC's RPKI subsystems.
> 
> More examples of 'out of scope' functionality for Relying Party
> software: validators don't monitor whether lirportal.ripe.net is
> functional, whether RIPE NCC's BPKI API endpoints are operational, or
> whether LIRs paid their invoices, the list is quite long. The validators
> by themselves are the wrong tool for RPKI CPS/SLA monitoring.
> 
> You state "transparency is key for us", but I fear ad-hoc low-quality
> a-posteriori reports are not the appropriate mechanism to impress and
> reassure this community regarding 'transparency'.
> 
> I have some tangible suggestions to RIPE NCC that will improve the
> reliability of the Trust Anchor and potentially help rebuild trust:
> 
> A need for Certificate Transparency
> ---
> 
> RIPE NCC should set up a Certificate Transparency project which publicly
> shows which certificates (fingerprints) were issued when, and store such
> information in immutable logs, accessible to all.
> 
> How can anyone trust a Trust Anchor which does not offer transparency
> about its issuance process?
> 
> Lack of transparency to signer software
> ---
> 
> The RIPE NCC WHOIS database software is open source, as is most of the
> software for RIPE Atlas, K-ROOT, and other efforts RIPE NCC has
> undertaken over the years.
> 
> Why has the signer source code still not open sourced? Why can't members
> review the code related to scheduled changes? Why is an organisation
> proclaiming 'transparency' being opaque about how the RPKI certificates
> are issued?
> 
> Lack of Public status dashboard
> ---
> 
> RIPE NCC should set up a website like https://rpki-status.ripe.net/
> which shows dashboards with graphs and traffic lights related to each
> (best effort) commitment listed in the CPS. RIPE NCC should continuously
> publish & revoke & delete objects and verify whether those activities
> are visible externally, and then automatically report whether any
> potential delays observed are within the Service Levels outlined in the
> CPS.
> 
> Metrics that come to mind:
> 
> * delta between last certificate issuance & successful publication
> * Object count in the repository, repo size (and graphs)
> * Time-To-Keyroll (and graphs on duration & frequency)
> * Resource utilisation of various RPKI subsystems
> * aggregate bandwidth consumption for RPKI endpoints (including rrdp, API, 
> rsync)
> * Graphs & logs of overlap between INRs listed on EE certificates under
>  the RIPE TA and other commonly used TAs, matched against known
>  transfers. This will help detect compromises as well as understand
>  whether transfers are successful or not.
> * Unique client IP count for RSYNC & RRDP for last hour/day/week
> * Number of CS/hostmaster tickets mentioning RPKI
> 
> There is are plenty of aspects to monitor, perhaps some notes should be
> copied from how the DNS root is monitored.
> 
> Lack of operational experience with BGP ROV at RIPE NCC
> ---
> 
> I believe the number of potential future incidents related to the RIPE
> NCC Trust Anchor can be prevented (or remediation time

Re: [routing-wg] Delay in publishing RPKI objects

[Nathalie Trenaman]

Hi Nick,

> Op 17 feb. 2021, om 15:25 heeft Nathalie Trenaman  het 
> volgende geschreven:
> 
> Hi Nick,
> 
>> Op 17 feb. 2021, om 13:54 heeft Nick Hilliard  het volgende 
>> geschreven:
>> 
>> Hi Nathalie
>> 
>> do any of the other RIRs run any components of the software stack that the 
>> RIPE NCC developed for managing its RPKI CA functionality?  I.e. how much 
>> exposure to production environments does this software get outside the RIPE 
>> NCC?
>> 
>> Nick
> 
> In the past APNIC used some fork of our publication server code, but I’m not 
> aware how far this diverted from our code. I’m not aware of any of the other 
> RIRs using our software stack. 
> 
> Kind regards,
> Nathalie
> 
> 

I stand corrected. Tim pointed out to me that APNIC has their own code base, 
always had and is actually older than the RIPE NCC code.
AFRINIC runs a fork from APNIC.
ARIN used our code base around 2010 for their pilot, but implemented their own 
code base from scratch. 
LACNIC uses the RPKI object library but has their own CA and publication stack. 

Sorry for the confusion and thanks for the correction Tim.

Kind regards,
Nathalie

Re: [routing-wg] Delay in publishing RPKI objects

[Nathalie Trenaman]

Dear Job,

Please find my answers in line below:

> Op 16 feb. 2021, om 19:22 heeft Job Snijders via routing-wg 
>  het volgende geschreven:
> 
> Dear RIPE NCC,
> 
> On Tue, Feb 16, 2021 at 04:56:31PM +0100, Nathalie Trenaman wrote:
>> On Monday, 15 February we encountered an issue with our RPKI software.
>> This issue prevented us from publishing RPKI object updates from
>> 08:07-18:06 (UTC). 
>> 
>> During this period, Certificate Authority activation and Route Origin
>> Authorization configuration updates were delayed and therefore not
>> visible in the RPKI repository.
> 
> It appears Certificate Authority revocation was also delayed.

Indeed, all modifications, creations and deletions were delayed. 

> 
>> The updates were published after we restarted the system at 17:45
>> (UTC), with full recovery completed by 18:06 (UTC).  Since this
>> non-publishing period is shorter than our default RPKI object validity
>> period, set to 8 hours, existing objects that are not updated were
>> still valid. No data was lost during this period. 
> 
> Can the following phrase "default RPKI object validty period, set to 8
> hours" please be clarified?
> 
> For objects produced in the RIPE-hosted RPKI environment I observe the
> following validity periods are commonly used:
> 
> Object type| validity duration after issuance
> ---+-
> CRLs   | 24 hours
> ROA EE certs   | 18 months
> Manifest eContent  | 24 hours
> Manifest EE certs  |  7 days
> CAs| 18 months
> 
> I'm just guessing, is the '8 hour' period a reference to RIPE-751
> section 2.3?
> 
>"A certificate will be published within eight hours of being issued (or 
> deleted)."

Yes, the eight hours referred to this section in the CPS but also in 4.3.1:
"The Production CA and the ACA, as well as hosted CAs, make all subordinate 
certificates and objects available for publication. While the system will make 
a best effort to publish these materials as soon as possible, publication 
should happen no later than eight hours after issuance (as described in Section 
2.3.)”

The validity periods are all longer than eight hours, and we can confirm that 
none of the RIPE hosted objects expired within the non-publishing time frame. 

> 
> The RIPE-751 CPS also states in section 4.9.8 ("Maximum latency for
> CRLs"): CRLs will be published to the repository system within one hour
> of their generation. 
> 
> As the outage appears to have exceeded both the 1 hour revocation window
> and 8 hour object publication window, RIPE NCC was not compliant with
> its own CPS.

Correct.

> 
> The multitude of RPKI service impacting events as a result from
> maloperation of the RIPE NCC trust anchor are starting to give me me
> cause for concern.

I’m sorry to hear this. Transparency is key for us, this means that we report 
any event. In this case, we were not compliant with our CPS and this 
non-publishing period had operational impact. 
However, not all relying party software discovered this non-publishing period, 
for example, rpki-client. Routinator logs these warnings. Is this something all 
relying party software should log? Maybe this should be discussed in the 
SIDROPS wg at the IETF.

Kind regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

[routing-wg] Delay in publishing RPKI objects

[Nathalie Trenaman]

Dear colleagues,

On Monday, 15 February we encountered an issue with our RPKI software. This 
issue prevented us from publishing RPKI object updates from 08:07-18:06 (UTC). 

During this period, Certificate Authority activation and Route Origin 
Authorization configuration updates were delayed and therefore not visible in 
the RPKI repository. The updates were published after we restarted the system 
at 17:45 (UTC), with full recovery completed by 18:06 (UTC).
Since this non-publishing period is shorter than our default RPKI object 
validity period, set to 8 hours, existing objects that are not updated were 
still valid. No data was lost during this period. 

We are still investigating the reason that caused this delay and will follow up 
once we have identified the root cause. 

Kind regards, 
Nathalie Trenaman 
Routing Security Programme Manager 
RIPE NCC

[routing-wg] Invitation: RPKI Open House

[Nathalie Trenaman]

Dear all,

The RIPE NCC is hosting an Open House on Routing Security and RPKI next week to 
discuss developments, uptake, and future plans of RPKI.

The RIPE NCC Open House will take place on Wednesday, 20 January at 11:00 UTC 
and it's a free, ninety-minute remote session for RIPE NCC staff, community 
members and industry experts to initiate discussions, and share insights and 
feedback on:

·RPKI trends and statistics

·RIPE NCC's plans for the future of RPKI

·Deprecating the RIPE NCC Validator

·Discussion on the future of Routing Security

To register and find more information about the event, check this page: 
https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-the-future-of-rpki
 
<https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-the-future-of-rpki>

See you there.

Cheers,

Nathalie Trenaman
RIPE NCC

[routing-wg] RPKI Outage Post-Mortem

[Nathalie Trenaman]

Summary: 
Yesterday, on 7 January 2021, an issue with our RPKI software caused an 
inconsistent certificate to be published from 15:29-16:20 (UTC+1). This may 
have resulted in outages. We strongly recommend network operators update their 
Relying Party software to the latest version.

Details: 
At 15:06 (UTC+1) yesterday, we processed an outgoing transfer of IP resources 
to another RIR service region. This caused our system to update the 
corresponding RPKI certificates in our Certificate Authority (CA). 

Unfortunately, our RPKI software published the updated parent certificate 
(production CA) ahead of its child certificate (member CA). As a result, in the 
period immediately after the updated parent was published, the child 
certificate (updated later) contained resources that were no longer on the 
updated parent, and the child certificate over-claimed. This was resolved once 
the child certificate was updated.

Currently we have three separate processes:
* One that updates the resources in the registry in RPKI (every 15min) 
* One that updates the resources of the RIPE production CA (parent of all 
member CA) from the registry (1h, takes ~5 min) 
* One that updates the resources for member CAs from the registry (1h, takes 
~40 min)

If there is an outgoing transfer and the member CA update runs before the 
production CA update, the situation with over-claiming occurs. The update of 
the member CA needs to happen at the same time (i.e. same RRDP delta), or 
before the production CA resources are reduced. This does not happen the other 
way around (and so is not an issue with incoming resources). 

Some older Relying Parties had applied a strict manifest handling 
interpretation in their validator software. This meant that they were 
configured to reject all certificates in the manifest if a single entry was 
invalid. As a consequence, all RPKI certificates covering RIPE resources were 
rejected by these validators during this period.

Based on our access logs, we estimate that 327 instances of Relying Party 
software were impacted.

On Monday 11 January, we will implement a fix so that every time a RIPE NCC 
certificate changes, we will look at all members to see if their certificates 
are over-claiming and force an immediate re-issue if so. This approach does not 
give us a 100% bullet-proof fix to the problem, but it reduces the period of 
over-claiming from an hour to a couple of minutes. 
We will work on reducing this time to less than a minute, to further reduce the 
potential for inconsistency. In the longer term, we will work on implementing 
atomic publishing of data for this type of situation. 

In the meantime, we strongly recommend that network operators update their RPKI 
Relying Party software to the latest version: 
* Routinator 0.8.2 
* rpki-client 6.8p1 
* FORT 1.4.2 
* octorpki 1.2.2 
* RIPE NCC 3.2-2020.12.10.13.57

Best regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

Re: [routing-wg] 2021.01.07 RPKI certificate issue?

[Nathalie Trenaman]

Hi Job,

It was a very similar issue as we experienced on 9 December 2020:
https://www.ripe.net/support/service-announcements/invalid-rpki-certificate-published
 
<https://www.ripe.net/support/service-announcements/invalid-rpki-certificate-published>

Of course we will send a more elaborate post-mortem to this working group later 
today.

Kind regards,
Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

> Op 7 jan. 2021, om 23:03 heeft Job Snijders  het volgende 
> geschreven:
> 
> Hi,
> 
> I saw 
> https://www.ripe.net/support/service-announcements/rpki-planned-downtime-3
> 
> Are more details available?
> 
> Kind regards,
> 
> Job
> 

[routing-wg] Planned Downtime for the RPKI service

[Nathalie Trenaman]

Dear colleagues,

On Monday, 30 November at 08:30 (UTC), we plan to upgrade the infrastructure 
supporting the Resource Public Key Infrastructure (RPKI) service. This will 
involve 
up to one hour of downtime.

You will not be able to access the RPKI dashboard or RPKI API during this 
period. 
There will be no interruption to the rsync and RRDP repositories.

Best regards, 

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

[routing-wg] New on RIPE Labs: Lifecycle of the RIPE NCC RPKI Validator

[Nathalie Trenaman]

Dear colleagues,

We made some important decisions with regards to the future of the RIPE NCC 
RPKI Validator. In this RIPE Labs article, I provide an overview and a time 
line. 

https://labs.ripe.net/Members/nathalie_nathalie/life-cycle-of-the-ripe-ncc-rpki-validator-1
 
<https://labs.ripe.net/Members/nathalie_nathalie/life-cycle-of-the-ripe-ncc-rpki-validator-1>

Kind regards,

Nathalie Trenaman
RIPE NCC

[routing-wg] From Zero to RPKI Hero: Live Demo

[Nathalie Trenaman]

Hi all,

The community has teamed up to bring something very exiting to network 
operators around the world!
This Friday, from 17:00 CEST, we are doing a live demo “From Zero to RPKI Hero” 
where we will show how to create ROAs, set up Routinator, RIPE NCC Validator, 
configure Juniper, Arista, Nokia and Cisco routers to perform RPKI Origin 
Validation. This has never been done before! And it will be live!  People can 
join over Zoom: https://arista.zoom.us/s/93051476697 
<https://arista.zoom.us/s/93051476697> <https://arista.zoom.us/s/93051476697 
<https://arista.zoom.us/s/93051476697>> or join the Facebook live stream: 
https://www.facebook.com/events/183972346373123/186010836169274/ 
<https://www.facebook.com/events/183972346373123/186010836169274/> Later on, 
this will be uploaded to YouTube. 

Please note: This is not an event organised by any of the vendors, nor is it a 
commercial event. Just a bunch of techies (Ties de Kock, Florian Hibler, Greg 
Hankins, Jeff Tantsura, Orhan Ergun, Melchior Aelmans, Alex Band and Nathalie 
Trenaman)  coming together to show “how it’s done”

Best regards,
Nathalie Trenaman

[routing-wg] RPKI Outage Post-Mortem

[Nathalie Trenaman]

Dear colleagues,

From Saturday 22 February at 08:24 (CET), any newly created, modified, or 
deleted ROAs (176 in total) could not be added to our publication server due to 
a disk problem. From that moment on, all the data was stored on the database, 
but the publication did not happen. The disk did not report any problems and, 
therefore, no engineer was alerted of this incident.

Due to the disk problem, starting from Sunday 23 February at 09:10 (CET), our 
CRL expired and our repository could not be properly updated. This was reported 
to us on Monday 24 February at 11:44 (CET). Immediately, our engineers fixed 
the disk problem, however, since the CRL expired, all underlying objects also 
expired. Depending on the Relying Party software an operator used, this 
abnormal behaviour appeared differently.

Initially, our engineers tried to do a full re-population of the RPKI 
repository, but unfortunately, this did not update the CRL in the validation 
tree. At 15:03 (CET), we performed a full CA key-roll, which was completed at 
21:02 (CET) and resolved the problem. At 19:58 (CET), all objects in the 
backlog were published.

We apologise for any inconvenience this may have caused and we are taking all 
the necessary steps to ensure this incident does not appear again in the future.

Kind regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC


signature.asc
Description: Message signed with OpenPGP

[routing-wg] Looking for recommendations

[Nathalie Trenaman]

Dear colleagues,

As presented at the last Routing WG meeting at RIPE 79, the RIPE NCC is 
planning on carrying out
an extensive technical and procedural audit on RPKI throughout this year.

We are currently looking for an organisation that can help us with this 
exercise.
Particularly, we are looking for an organisation that is familiar with the RPKI 
audit frameworks and ,ideally, has extensive knowledge on BGP routing and 
cryptography.

We are planning on starting the consultation in two weeks and are looking 
forward to your recommendations.

Kind regards,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC


signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] RPKI validation problem

[Nathalie Trenaman]

Hi all,

We have just released fixed versions of our Validator 3.

You can find them here:

Centos7 - 
https://ftp.ripe.net/tools/rpki/validator3/prod/centos7/repo/rpki-validator-3.1-2019.12.16.15.18.18.noarch.rpm
Debian - 
https://ftp.ripe.net/tools/rpki/validator3/prod/deb/rpki-validator-3.1-2019.12.16.15.18.18.deb
Generic build - 
https://ftp.ripe.net/tools/rpki/validator3/prod/generic/rpki-validator-3.1-2019.12.16.15.18.18-dist.tar.gz
 
<https://ftp.ripe.net/tools/rpki/validator3/prod/generic/rpki-validator-3.1-2019.12.16.15.18.18-dist.tar.gz>

If you have yum repository configured, "yum install rpki-validator" will do the 
job.

This was an interesting bug - We always relied on the idea that serial numbers 
of manifest objects increase --- apparently all the Trust Anchors so far 
(except for some of the sub-repositories under APNIC) generated increasing 
serial numbers and it always worked. It looks like Krill doesn't do it, that's 
why Validator 3 doesn't always pick up the latest manifest and can use stale 
data. According to the RFC serial numbers don't have to increase, they just 
need to be different (the Krill implementation follows that RFC), so it was a 
bug on our side that is now fixed.

Thanks for bringing this up.

Nathalie Trenaman
RIPE NCC



> Op 16 dec. 2019, om 15:22 heeft Nathalie Trenaman  het 
> volgende geschreven:
> 
> Hi all,
> 
> It seems that Validator 3.x (the one you see on 
> https://rpki-validator.ripe.net/bgp-preview 
> <https://rpki-validator.ripe.net/bgp-preview>) has been hanging and not 
> fetching new information from the repositories. All the other Validators 
> (2.x, Routinator, OctoRPKI, RPKIclient, FORT) don’t have this problem, so it 
> depends on what validator you are running, which result you see. Our RPKI 
> team is currently looking into this. Meanwhile, if you are running Validator 
> 3.x and you see 170.79.184.0/22 appearing as “unknown”, a reboot will help.
> We have just rebooted  https://rpki-validator.ripe.net/ 
> <https://rpki-validator.ripe.net/> and as you can see, 170.79.184.0/22  now 
> appears as “valid”.
> Stay tuned, as soon as we have more information, I will report back.
> 
> Thanks,
> Nathalie Trenaman
> RIPE NCC
> 
> 
>> Op 16 dec. 2019, om 13:36 heeft Gondim via routing-wg > <mailto:routing-wg@ripe.net>> het volgende geschreven:
>> 
>> Hi Marco,
>> 
>> Em 16/12/2019 10:28, Marco Paesani escreveu:
>>> Marcelo,
>>> the route  170.79.184.0/22 <http://170.79.184.0/22> is not present on 
>>> validator.
>>> 
>>> m.paesani@MX960-MIX-RE0# run show route 170.79.184.0/22 
>>> <http://170.79.184.0/22> exact active-path
>>> 
>>> inet.0: 782165 destinations, 5177202 routes (777291 active, 0 holddown, 
>>> 20504 hidden)
>>> + = Active Route, - = Last Active, * = Both
>>> 
>>> 170.79.184.0/22 <http://170.79.184.0/22>*[BGP/170] 3d 14:13:33, MED 
>>> 500, localpref 100
>>>   AS path: 6762 53181 53135 I, validation-state: unknown
>>> > to 93.186.128.48 via xe-8/0/3.100
>> The strange thing is that it is being validated elsewhere. What I do not 
>> understand is why in some it appears as valid and others as unknown when 
>> everyone should be seeing the same information. Or am I mistaken?
>> 
>> # whois -h whois.bgpmon.net <http://whois.bgpmon.net/> " --roa 53135 
>> 170.79.184.0/22"
>> 0 - Valid
>> 
>> ROA Details
>> 
>> Origin ASN:   AS53135
>> Not valid Before: 2019-12-13 19:24:16
>> Not valid After:  2020-12-13 19:29:16  Expires in 363d6h55m11s
>> Trust Anchor: rpki-repo.registro.br <http://rpki-repo.registro.br/>
>> Prefixes: 170.79.184.0/22 (max length /24)
>> 
>> 
>> 
>> # whois -h whois.bgpmon.net <http://whois.bgpmon.net/> 170.79.184.0/22
>> % This is the BGPmon.net <http://bgpmon.net/> whois Service
>> % You can use this whois gateway to retrieve information
>> % about an IP adress or prefix
>> % We support both IPv4 and IPv6 address.
>> %
>> % For more information visit:
>> % https://portal.bgpmon.net/bgpmonapi.php 
>> <https://portal.bgpmon.net/bgpmonapi.php>
>> 
>> Prefix:  170.79.184.0/22
>> Prefix description:  Nettel Telecomunicacoes Ltda
>> Country code:BR
>> Origin AS:   53135
>> Origin AS Name:  Nettel Telecomunica��es Ltda., BR
>> RPKI status: ROA validation successful
>> First seen:  2017-03-0

Re: [routing-wg] RPKI validation problem

[Nathalie Trenaman]

Hi all,

It seems that Validator 3.x (the one you see on 
https://rpki-validator.ripe.net/bgp-preview 
<https://rpki-validator.ripe.net/bgp-preview>) has been hanging and not 
fetching new information from the repositories. All the other Validators (2.x, 
Routinator, OctoRPKI, RPKIclient, FORT) don’t have this problem, so it depends 
on what validator you are running, which result you see. Our RPKI team is 
currently looking into this. Meanwhile, if you are running Validator 3.x and 
you see 170.79.184.0/22 appearing as “unknown”, a reboot will help.
We have just rebooted  https://rpki-validator.ripe.net/ 
<https://rpki-validator.ripe.net/> and as you can see, 170.79.184.0/22  now 
appears as “valid”.
Stay tuned, as soon as we have more information, I will report back.

Thanks,
Nathalie Trenaman
RIPE NCC


> Op 16 dec. 2019, om 13:36 heeft Gondim via routing-wg  
> het volgende geschreven:
> 
> Hi Marco,
> 
> Em 16/12/2019 10:28, Marco Paesani escreveu:
>> Marcelo,
>> the route  170.79.184.0/22 <http://170.79.184.0/22> is not present on 
>> validator.
>> 
>> m.paesani@MX960-MIX-RE0# run show route 170.79.184.0/22 
>> <http://170.79.184.0/22> exact active-path
>> 
>> inet.0: 782165 destinations, 5177202 routes (777291 active, 0 holddown, 
>> 20504 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> 170.79.184.0/22 <http://170.79.184.0/22>*[BGP/170] 3d 14:13:33, MED 500, 
>> localpref 100
>>   AS path: 6762 53181 53135 I, validation-state: unknown
>> > to 93.186.128.48 via xe-8/0/3.100
> The strange thing is that it is being validated elsewhere. What I do not 
> understand is why in some it appears as valid and others as unknown when 
> everyone should be seeing the same information. Or am I mistaken?
> 
> # whois -h whois.bgpmon.net " --roa 53135 170.79.184.0/22"
> 0 - Valid
> 
> ROA Details
> 
> Origin ASN:   AS53135
> Not valid Before: 2019-12-13 19:24:16
> Not valid After:  2020-12-13 19:29:16  Expires in 363d6h55m11s
> Trust Anchor: rpki-repo.registro.br
> Prefixes: 170.79.184.0/22 (max length /24)
> 
> 
> 
> # whois -h whois.bgpmon.net 170.79.184.0/22
> % This is the BGPmon.net whois Service
> % You can use this whois gateway to retrieve information
> % about an IP adress or prefix
> % We support both IPv4 and IPv6 address.
> %
> % For more information visit:
> % https://portal.bgpmon.net/bgpmonapi.php 
> <https://portal.bgpmon.net/bgpmonapi.php>
> 
> Prefix:  170.79.184.0/22
> Prefix description:  Nettel Telecomunicacoes Ltda
> Country code:BR
> Origin AS:   53135
> Origin AS Name:  Nettel Telecomunica��es Ltda., BR
> RPKI status: ROA validation successful
> First seen:  2017-03-02
> Last seen:   2019-12-14
> Seen by #peers:  65
> 
> 
> 
>> 
>> 
>> Marco Paesani
>> 
>> 
>> Skype: mpaesani
>> Mobile: +39 348 6019349
>> Success depends on the right choice !
>> Email: ma...@paesani.it <mailto:ma...@paesani.it>
>> 
>> 
>> 
>> 
>> Il giorno lun 16 dic 2019 alle ore 12:54 Gondim via routing-wg 
>> mailto:routing-wg@ripe.net>> ha scritto:
>> Hi Matthias,
>> 
>> Em 16/12/2019 08:43, Matthias Waehlisch escreveu:
>> > [1] and [2] use different Trust Anchors.
>> >
>> > which prefix do you check?
>> 
>> For example 170.79.184.0/22 <http://170.79.184.0/22>
>> 
>> Other Autonomous Systems that I consulted also experienced this problem.
>> 
>> >
>> > Cheers
>> >   matthias
>> >
>> > On Mon, 16 Dec 2019, Gondim via routing-wg wrote:
>> >
>> >> Dear all,
>> >>
>> >> Friday, here in Brazil, the RPKI was enabled. We have published our ROAs
>> >> and are being validated in several places but we found a divergence.
>> >> When we query our AS on this link [1] it appears to be valid but when we
>> >> query our AS on this link [2], it appears as unknown.
>> >>
>> >> Is there any difference between the tools that might be causing this?
>> >>
>> >> [1] http://localcert.ripe.net:8088/bgp-preview 
>> >> <http://localcert.ripe.net:8088/bgp-preview>
>> >>
>> >> [2] https://rpki-validator.ripe.net/bgp-preview 
>> >> <https://rpki-validator.ripe.net/bgp-preview>
>> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀  Marcelo Gondim
>   ⣾⠁⢠⠒⠀⣿⡁  Sysadmin - https://www.linuxinfo.com.br 
> <https://www.linuxinfo.com.br/>
>   ⢿⡄⠘⠷⠚⠋   DA04 922E 78B3 44A5 3C8D 23D0 8DB5 571E E151 4E19
>   ⠈⠳⣄  Logic will get you from A to B. Imagination will take you 
> everywhere. (Albert Einstein)



signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] RIS dumps, 0.0.0.0/0 routes and RPKI validator 3

[Nathalie Trenaman]

Hi nusenu,

> Op 17 mrt. 2019, om 09:23 heeft nusenu  het volgende 
> geschreven:
> 
> Randy Bush:
>>> Are 0.0.0.0/0 routes filtered by RIPEstat but
>>> included in RIS dumps?
>>> Should rpki-validator filter them out?
>> 
>> as the rirs each have a cert for 0/0, shouldn't the validator should be
>> prepared to evaluate 0/0?
> 
> just to clarify: I didn't mean to say that validtor 3 isn't
> prepared to evaluate 0/0.
> The strange results originated from my tools that did not
> expect 0/0 routes in validator's BGP preview - but I will fix my side.
> 
> And to clarify "strange results": I'm regularly looking at
> how we are doing with RPKI misconfigurations (RPKI Observatory) and the
> last output suggested that we are down to 0 unreachable
> RPKI IP address space because _every_ INVALID announcement
> had an alternative path via 0/0 from AS15576 which is obviously not correct.

The data in the validator is consistent with the data in RIS:
https://stat.ripe.net/widget/announced-prefixes#w.resource=15576 

You can see 0.0.0.0/0 (and ::/0 by the way) there.
Out of curiosity, did you ping them about these mis-announcements already?

Nathalie



signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] RPKI Validator 3: RIS dump downloads - still plain HTTP

[Nathalie Trenaman]

Hi nusenu, all,

I can confirm that the RIS dumps now work (by default) through HTTPS in the 
validator. Please make sure you have the latest build: 387.

Thanks,
Nathalie Trenaman
RIPE NCC

> Op 15 feb. 2019, om 23:40 heeft nusenu  het volgende 
> geschreven:
> 
> Nathalie Trenaman:
>> Hi nusenu,
>> 
>> First of all, my apologies that the issue you raised fell a bit
>> through the cracks and it took so long to get resolved. We do see the
>> importance to offer RIS dumps through HTTPS and to configure our RPKI
>> validator to fetch the RIS dumps via HTTPS. At the moment the RIS
>> team is working on making HTTPS available and as soon as this is done
>> (they told me it will happen soon), we will make the change to the
>> validator. Overall, we need a few more weeks for this, but we will
>> reply here as well as soon as it is done. We will open the issue
>> again and only close it when it is resolved.
> 
> Thanks for your reply, it is appreciated.
> 
> 
> 
> --
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
> 



signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] New on RIPE Labs: RIS Live BGP Message Stream

[Nathalie Trenaman]

Hi nusenu,

> Op 24 feb. 2019, om 00:14 heeft nusenu  het volgende 
> geschreven:
> 
> Mirjam Kuehne:
>> We are launching a prototype called RIS Live, a feed that offers BGP
>> messages in real time. It collects information from the RIS Route
>> Collectors (RRCs) and uses a WebSocket JSON API to monitor and detect
>> routing events around the world.
>> 
>> Please find more details on RIPE Labs:
>> 
>> https://labs.ripe.net/Members/chris_amin/ris-live-bgp-message-stream
> 
> Thanks a lot for creating and providing this service!
> 
> Are there any plans to make use of this data source in rpki-validator as an
> opt-in real-time BGP data source instead of using the RIS dumps that happen 
> every
> 8 hours?
> 
> kind regards,
> nusenu
> 

At the moment we don’t have this on our roadmap, but we will investigate if we 
can have riswhois.ripe.net  (where this data comes 
from)
work with 'near-real-time’ data behind the looking-glass for the validator. Not 
any time soon though, I’m afraid.

Thanks,
Nathalie





signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] RPKI Validator 3: RIS dump downloads - still plain HTTP

[Nathalie Trenaman]

Hi nusenu,

First of all, my apologies that the issue you raised fell a bit through the 
cracks and it took so long to get resolved.
We do see the importance to offer RIS dumps through HTTPS and to configure our 
RPKI validator to fetch the RIS dumps via HTTPS.
At the moment the RIS team is working on making HTTPS available and as soon as 
this is done (they told me it will happen soon), we will
make the change to the validator. Overall, we need a few more weeks for this, 
but we will reply here as well as soon as it is done.
We will open the issue again and only close it when it is resolved.

Thanks,

Nathalie Trenaman
Routing Security Programme Manager
RIPE NCC

> Op 12 feb. 2019, om 23:28 heeft nusenu  het volgende 
> geschreven:
> 
> Hi,
> 
> back in September I opened an issue on github [1]
> about RPKI Validator 3 fetching RIS dumps via plain HTTP
> connections, two weeks ago the issue got closed.
> 
> First I was glad since I assumed the issue got closed because it is fixed
> but then I noticed that the issue still persists in
> rpki-validator-3.0-377
> so I'm wondering why the issue got closed?
> 
> thanks,
> nusenu
> 
> 
> [1] https://github.com/RIPE-NCC/rpki-validator-3/issues/50
> 
> --
> https://twitter.com/nusenu_
> https://mastodon.social/@nusenu
> 



signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] RPKI Validator 3 Disk Space Requirement

[Nathalie Trenaman]

Hi nusenu,

> Op 8 okt. 2018, om 10:54 heeft nusenu  het volgende 
> geschreven:
> 
> Hi,
> 
> the wiki page [1] states:
>> The repository objects are stored in a file based database, rather
>> than in memory - we recommend at least 10GB of available disk space
>> (under /var/lib/rpki-validator-3/db for the RPM).
> 
> the rpki-validator.h2.mv.db file is already >22GB in size, I assume there
> is no way to reduce the disk usage requirements via a configuration change?
> 
> How big will the db file become?

There is a config setting regulating how often the validator will remove the 
"garbage", i.e. unused objects that it still stores but they are not really 
used but kept just in case (no connectivity to download updated records, broken 
manifests, CRLs, etc.). The setting is called 
"rpki.validator.rpki.object.cleanup.grace.duration" and by default it is set to 
"P7D", i.e. a period of 7 days, which is pretty conservative. You can set it to 
much smaller periods, 1-2 day or 12 hours and still have reasonable behaviour.
There is another parameter 
“rpki.validator.validation.run.cleanup.grace.duration" with the similar 
meaning, but it's less crucial when it comes to storage space.
Also Validator version 3 is lighter than 2 in a sense that it consumes less 
memory, but it can only do it by storing more data on the disk.

I hope this helps.

Kind regards,

Nathalie Trenaman
RIPE NCC


signature.asc
Description: Message signed with OpenPGP

Re: [routing-wg] [db-wg] The Ongoing Summer of Hijacks: MNT-SERVERSGET / dnsget.top

[Nathalie Trenaman]

Hi Håvard,

Please see my comments below.

> Op 15 aug. 2018, om 10:21 heeft Havard Eidnes via db-wg  het 
> volgende geschreven:
> 
> Hi,
> 
> following up on a particular point (only), dropping the
> anti-abuse WG, but keeping the other two because it relates to
> database authorization and the IRR:
> 
>> More to the point, since when has it become a routine part of "day
>> to day operations" to have RIPE members flooding the RIPE data base
>> with blatant bovine excrement?
> 
> I guess one important reason is that in some specific cases it's
> difficult to automate the distinction between what you refer to
> as "bovine excrement" and legitimate route objects.
> 
> (This refers to your substantiated claim that fraudulent route
> objects have been and are being registered in the IRR part of the
> RIPE database.)
> 
> Looking at the description of the route object in the RIPE DB:
> 
>  
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-5-description-of-the-route-object
> 
> and the authorization requirements at
> 
>  
> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-7-protection-of-route-6-object-space
> 
> my understanding is that it describes that when "route" objects
> are created which cover in-region address space, authorization is
> requied from both the maintainer of the AS object as well as from
> the maintainer of the address space, so registering in-region
> route objects without the consent of the address space holder is
> more or less prevented.

Indeed, but this is about to change. The RIPE DB Working Group has decided to 
remove AS authentication for ROUTE(6) objects. This will come into effect on 
the 4th of September 2018. 
From then, only a prefix holder can create a ROUTE(6) object and can reference 
any AS number. 


> 
> However, if the address space is out-of-region, the authorization
> checks for the address space is dropped / ignored, and only the
> authorization for the AS object is used, allowing the
> registration of route objects without the consent of the address
> space holder.  I suspect it is this loop-hole which is being
> abused to register the route objects you are mentioning.

Exactly, and part of the NWI-5 implementation is that from the 4th of 
September, it will not be possible anymore to create new out-of-region ROUTE(6) 
objects and AUTNUMs in the RIPE IRR. 
This loophole will then be closed. All the out-of-region objects will remain in 
the RIPE IRR, but with a different “source:” attribute: RIPE-NONAUTH. Holders 
can still update and delete these objects, but not create new ones. 
We have communicated these changes to all out-of-region object holders and the 
RIPE DB WG. Also we have communicated this to all other RIRs (most of them 
wrote articles about these upcoming changes and informed their members.
You can read the full implementation plan here:
https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
 
<https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation>


> 
> I suspect that out-of-region route objects in the RIPE DB are an
> operational requirement for other reasons.

Well, the WG decided it was time to move on and fixing the loophole was more 
important. 

> 
> One way to close this loop-hole would be for the RIRs to agree on
> a uniform authorization model, and share the authorization
> information (and data) between themselves.  I suspect this is no
> small task.
> Best regards,
> 
> - Håvard
> 

Best regards,

Nathalie Trenaman
Product Manager 
RIPE NCC

[routing-wg] Calling for Beta-testers for RPKI Validator 3.0

[Nathalie Trenaman]

Dear colleagues,

We’re happy to announce the beta-release of the RIPE NCC RPKI Validator 3.0, 
first mentioned during the Open Source Working Group at RIPE76. 

We are testing this release ourselves as well, but we would really value if you 
are able to test in your own different environments and provide feedback. 
You can report issues on GitHub or email certificat...@ripe.net 
<mailto:certificat...@ripe.net>. 
A confirmation that everything works as expected is also very welcome. 

The main features of the new RIPE NCC RPKI Validator 3.0 are:

-ROA validation, export compatible with version 2.x
-Re-written in Java to ensure maintainability
-Supports incremental updates to routers through the rpki-rtr protocol
-Allows running multiple rtr-servers for redundancy
-Supports overrides by local filters and white lists 
-Requires 2GB of server memory
-Requires 10GB of disk space for the embedded database for large objects
-Open Source BSD Licence and available on GitHub

We set up a wiki with all the information about the installation sources and 
options, documentation and example configurations in the GitHub project:
https://github.com/RIPE-NCC/rpki-validator-3/wiki 
<https://github.com/RIPE-NCC/rpki-validator-3/wiki>

Best regards,

Nathalie Trenaman
Product Manager
RIPE NCC