New Release

[smlng]

Any plans on making a new release after >1 year of development since the last one in 2016?

[timbru]

Hi,

Actually we have been working on a new version of this software for a while now. It's not ready for public release yet, but if you want to have a peek at the work in progress you can have a look here: https://github.com/RIPE-NCC/rpki-validator-3

For this version we are still planing a small release now that APNIC is using a single Trust Anchor instead of 5 distinct ones, and there is a possible issue we're investigating w.r.t. duplicate 'Validated Roa Prefixes' in RPKI-RTR if the same prefix is found in different Trust Anchors.

[smlng]

there is a possible issue we're investigating w.r.t. duplicate 'Validated Roa Prefixes' in RPKI-RTR if the same prefix is found in different Trust Anchors.

That's why I'm asking, because we use your validator as a backend to our @rtrlib and it currently reports an error because of an duplicate announcement for 2001:1890::/29 which has two ROAs in ARIN. I saw there is a fix for that in master, but we use "latest" release with version 2.23 in our deployment.

[timbru]

We are working on a new release right now.

[timbru]

Version 2.24 has been released and is available here: https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources

[smlng]

Great, many thanks (on behalf of the @rtrlib team) for tackling this so quickly!

[smlng]

Just tried the release, but there is one problem. There are lots of ._ files in various directories (I think they come from macOS somehow), specifically those under conf/ are problematic as the app parses all files in those subdirectories which seems to be confused by those ._* files.

[smlng]

further, the issue of duplicate announcements persists, see http://rpki.inet.haw-hamburg.de:9090/api/v1/validity/AS7018/2001:1890::/29

which runs on latest version 2.24. The problem is that currently there are two ROAs for IPV6 prefix 2001:1890::/29, the first is valid until February 1st, 2018 and the second is valid from January 1st, 2018. So they are overlapping to avoid regression, but overall both are valid and hence the prefix should be two. According to RFC 6810 (https://tools.ietf.org/html/rfc6810#section-5.6) the RTR server MUST ensure to send only one entry (or PDU) per prefix. Even if multiple ROAs exists.

[timbru]

Oops..

The first issue happened because I repackaged the .tar.gz file on my Mac when I found that test Trust Anchors were accidentally included.

The second issue should have been fixed. We got it reported fixed. We also have had a test (since 2011) that checks that we exclude duplicates..

I am afraid that this will need some more debugging on our side tomorrow. For the moment, can you work around the issue temporarily by including that prefix in the "Ignore Filter" and adding it once only to the whitelist entries?

[smlng]

Hi again,

to clarify a bit more: it seems that the duplicates are not present when using the RTR protocol to receive prefix data - at least our RTRlib test applications all work with the 2.24 release, but hang with 2.23. They only seem to be shown on the REST API as linked in my previous comment.

[timbru]

Hi,

Okay, we exclude it in RPKI-RTR because the spec says we MUST - I believe that this MUST exists mainly as a warning in case duplicates are found in deltas - this would indicate an out-of-sync issue between the client router and RPKI validator.

The API returns both because both exist. Why is this a problem for you?

It doesn't impact validity of the route. As long as there is at least one VRP that makes the announcement valid it is valid. What we probably should do, is extend the API (in the new validator when we get to this point) to also include a link to the ROA object where the VRP was found. Others have asked for this as well.

A single ROA can have duplicate prefixes. There is nothing I found in RFC6482 that says you MUST not have exact duplicates. There is text in RFC6482 that RECOMMENDs not have pseudo-duplicates where there is an entry of the same prefix - with different max length (the higher max length value would 'eclipse' the other entry in this case). That said, having exact duplicates does not make any sense. In theory we could filter these out on the ROA object validation level without any impact on route validity (just ignore them). But... I believe that it's the correct thing to do that we show that they are technically there.

So, I will close this issue again for now, but let us know if there is a good reason that I am overlooking with regards to duplicates listed in the API, and we may re-open or choose to do things differently in v3.

[smlng]

Sorry for the noise,

The API returns both because both exist. Why is this a problem for you?

not exactly, but first I thought if duplicates are visible via the REST API they are in the RTR session as well - they are not as I saw later on.

also include a link to the ROA object where the VRP was found

that sounds reasonable, and a nice-to-have feature! At the moment, the REST API returns two identical entries in the VRP which only increases the data volume but not information. I'm aware that a prefix can have multiple ROAs, e.g. when a ROA is close to expiration. However, from a RPKI client perspective (IMHO) the validation state matters only, which is derived from all ROAs for each prefix. Thus there is no exact value in showing identical/matching ROAs for a certain state (valid, invalid, not found).

TL;DR: no direct issue with duplicates via REST API response, as long as the RTR part is standard conform 😉

---

looking forward to version 3!