[routing-wg] RPKI validation problem

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 <nathalie at ripe.net> 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 <routing-wg at ripe.net <mailto:routing-wg at 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 at 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-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: marco at paesani.it <mailto:marco at paesani.it>
>>> 
>>> 
>>> 
>>> 
>>> Il giorno lun 16 dic 2019 alle ore 12:54 Gondim via routing-wg <routing-wg at ripe.net <mailto:routing-wg at 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)
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20191216/a972c905/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: </ripe/mail/archives/routing-wg/attachments/20191216/a972c905/attachment-0001.sig>