Invalid Prefix get through as valid

[ghost]

Hi,
while testing the validator we noticed that prefixes created by us as invalid reach our network as valid. This was tested with a Juniper router.

Our problem cannot be replicated in the current environment

After consultation with Nathalie(RIPE), we open this issue here, since this is probably not known.

[lolepezy]

Hi,

Could you please elaborate? What exactly you are doing, where did you create the prefixes, what did you expect and what happened instead?

[ghost]

Hi,

We tested it, by setting up a validation session between our juniper-routerA in the lab and the rtr-server, while we had another juniper-routerB to create BGP-Sessions to routerA, so we could throw prefixes at it. The routing-policy we tested it with, would first drop invalids, then accept valids with a localpref of 300 and unknowns with a localpref of 200, so we could see to which term it would hit. The test was first made with our second asn as208559 that we used to send a valid prefix 2a02:f28:23::/48 first, which was received and marked as valid with a localpref of 300, then we tried it with 2a02:f28:24::/48, which is clearly invalid, but it was also received and marked as valid and got a localpref of 300. We also simulated sessions in the lab with other as, where we knew, which prefixes are unknown or invalid and all the prefixes were marked as valid. So we switched the test-setup to octo-rpki and go-rtr, tested the same prefixes again and they all got the right validation this time.

Actually we would like to contribute to the developement, since we would rather like to use this tool compared to cloudflare. Unfortunatly we don't have the setup anymore, so we can't test it right now or it would be at least timecomsuming, which is a bit diffficult at the moment but maybe this helps you a bit.

[FvDxxx]

You didn't capture the rv cache on the Juniper at the time of testing for the prefixes in question, did you? (show validation database record )?

[ghost]

Unfortunatly not, like we wrote before, we can maybe set it up again to test it, but it will take some time right now. The original tests we ran at the beginning of september with version 3.1.

[lolepezy]

Hi,

It is pretty hard to say anything without reproducing the problem, but if you would like to keep using the validator and if you see something fishy in the setup, you can check the validator's view of the world here https://rpki-validator.ripe.net/bgp-preview. If you just type in prefix or ASN in the search box, it shows what it thinks about validity of an announcement. You can do the same with your local installation of course. If you find errors there, it's definitely a bug.

I can see that 2a02:f28:24::/48 is (right now, 6 days later) valid with the AS20647. Is it expected? Could that be that the validator just hadn't get the updates at that moment? It can take up to tens of minutes to propagate updates you make in RPKI dashboard (or your own delegated CA) to every validator.

There are two components in the validator: rpki-validator and rpki-rtr-server, the second one accepts connections from routers and get updates from rpki-validator using an HTTP API. So another way to do that is to check what is going on is to see what rpki-validator feeds to rpki-rtr-server, using "http://localhost:8080/api/objects/validated", it will give you the full dump of what is valid according to rpki-validator.

Hope that helps, if not -- don't hesitate to ask.

[ghost]

Hi,

we already decided that we will test the validator again, just not right now, because we are really under a heavy load of other things, that need to be done. I guess in two or three weeks we can get to test that again.

The network 2a02:f28:24::/48 is valid for as20647 as there is an existent ROA for 2a02:f28::/32, so that is ok. What we tested was, that we annnounced that /48 with as208559 as origin to our router with the validation-session and there it was accepted as valid, which shouldn't have happened. I should add, that we checked it on the webgui of our installation and in there it was actually correctly marked as invalid. So the problem seems to be at the rtr-server or maybe at the connection between rtr and validator, since the rtr-server gave us the wrong validations for all the routes that we tested.

Well, we will test it again and we will defenitly let you know the outcome.

[omuravskiy]

The rtr-server does not decide on the validity of the announcements, it is done by the router itself.
The rtr-server sends to the router all VRPs – validated ROA payloads, and they are validated from the crypto point of view, not from the BGP point of view. So in the situation you describe I could only think about one reason when rtr-server could be responsible for a wrong decision – when it would send your router a VRP for a ROA that authorises as208559 to announce your /48.
I would say this is quite unlikely.