[QUESTION] how-to do prefix whitelisting

[nskalis]

Hi,

If we consider as an example the following network RPKI invalid prefix 1.37.137.0/24 from AS4775.

In the network

> show route 1.37.137.0/24    

inet.0: 926935 destinations, 3236988 routes (912266 active, 2 holddown, 34383 hidden)
+ = Active Route, - = Last Active, * = Both

1.37.137.0/24      *[BGP/170] 5d 10:24:37, localpref 250
                      AS path: 7018 4775 I, validation-state: invalid
                    > to 213.46.190.198 via ae8.0

which agrees with the published ROAs

Now, taking advantage of the app's feature whitelisting

which updates slurm.json accordingly

$ more slurm.json 
{
  "slurmVersion": 1,
  "validationOutputFilters": {
    "prefixFilters": [],
    "bgpsecFilters": []
  },
  "locallyAddedAssertions": {
    "prefixAssertions": [
      {
        "asn": 4775,
        "prefix": "1.37.137.0/24",
        "maxPrefixLength": 24,
        "comment": "debug.."
      }
    ],
    "bgpsecAssertions": []
  }
}

It has the following effect in the web app, now it is depicted as valid

But, almost 1h later the router still sees it as RPKI invalid

> show validation database | match 1.37.137.0    

@us-chi01a-ri3> show route 1.37.137.0/24    

inet.0: 926998 destinations, 3238165 routes (912315 active, 19 holddown, 34344 hidden)
+ = Active Route, - = Last Active, * = Both

1.37.137.0/24      *[BGP/170] 5d 10:38:33, localpref 250
                      AS path: 7018 4775 I, validation-state: invalid
                    > to 213.46.190.198 via ae8.0

Should I see the above entry in the logs on the RTR server ?
(btw, it would help using grep on prefix= by decoding the prefix value, in which format it is encoded?)

Jul  1 11:02:05 nlamsproape01 rpki-rtr-server.sh: 2020-07-01 11:02:05.373  INFO 9203 --- [ntLoopGroup-3-2] n.ripe.rpki.rtr.adapter.netty.PduCodec   : writing IPv4PrefixPdu(protocolVersion=V0, flags=ANNOUNCEMENT, prefix=RtrPrefix(prefixLength=24, maxLength=24, prefix=[1, 37, 19, 0], asn=4775))
Jul  1 11:02:05 nlamsproape01 rpki-rtr-server.sh: 2020-07-01 11:02:05.373  INFO 9203 --- [ntLoopGroup-3-2] n.ripe.rpki.rtr.adapter.netty.PduCodec   : writing IPv4PrefixPdu(protocolVersion=V0, flags=ANNOUNCEMENT, prefix=RtrPrefix(prefixLength=24, maxLength=24, prefix=[1, 37, -70, 0], asn=4775))
Jul  1 11:02:05 nlamsproape01 rpki-rtr-server.sh: 2020-07-01 11:02:05.373  INFO 9203 --- [ntLoopGroup-3-2] n.ripe.rpki.rtr.adapter.netty.PduCodec   : writing IPv4PrefixPdu(protocolVersion=V0, flags=ANNOUNCEMENT, prefix=RtrPrefix(prefixLength=24, maxLength=24, prefix=[1, 37, -69, 0], asn=4775))

Would you be so kind to advise how I can achieve making 1.37.137.0/24 from AS4775 seem as valid or unknown ?
(when I don't own, I don't work in AS4775, but let's assume it is a customer of ours and temporarily I would like to whitelist that)

[Methionyl]

Hi

I think the fastest way if you want that prefix to be marked as "valid", create and use static ROA.

As I see you are using Juniper device which means you can create in this way:
[edit routing-options]

[edit routing-options]
validation {
                  static {
                       record destination {
                            maximum-length prefix-length {
                                    origin-autonomous-system as-number {
                                           validation-state (invalid | valid);
}
}
}
}

And I think the static is more prefered, its worth a try.

[nskalis]

thanks @Methionyl for looking into it, but if that prefix is learnt from many locations is not the most convenient method to do so.
I am interested in finding out why white-listing in RIPE's RPKI Validator doesn't work (at least to my perception).

[nskalis]

anyone? can you please advise on how to use RIPE's RPKI validator to whitelist a ROA? what is going wrong above?

[ties]

Hi,

I have tried to reproduce the situation above. I followed your steps (start validator, add whitelist entry, it is then present in slurm.json). I can not reproduce the situation.

Could you:

• Check if the prefix is present in the ROA export endpoint of the validator (http://localhost:9176/api/objecs/validated in my example)?
• And check the status of the rtr server (http://localhost:8081/cache in my example). This should be valid.

What do I see?

When I check the ROA export endpoint of the validator,

$ curl http://localhost:9176/api/objects/validated | grep 1.37.137 --after=2 --before=2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 12.2M    0 12.2M    0     0  20.0M      0 --:--:-- --:--:-- --:--:-- 20.0M
    }, {
      "asn" : "4775",
      "prefix" : "1.37.137.0/24",
      "maxLength" : 24
    } ],

I see that the whitelisted prefix is present. This is the endpoint that is fetched by rtr server. When I look at the RTR server, I see that:

$ curl http://localhost:8081/cache | jq '.'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   160    0   160    0     0  53333      0 --:--:-- --:--:-- --:--:-- 53333
{
  "data": {
    "ready": true,
    "sessionId": -4139,
    "serialNumber": 2,
    "announcementsCount": 146911,
    "deltas": [
      {
        "serialNumber": 1,
        "announcementsCount": 8,
        "withdrawalsCount": 1
      }
    ]
  }
}

Its cache is valid. When I connected rtr-client to that rtr server instance:

$ rtr_client -d --host localhost -p 8323
2020-07-07-095225: CONNECT localhost.8323
+
2020-07-07-095225: NEW SESSION ID 0
.
2020-07-07-095225: REFRESHED SESSION ID 0->61397
..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2020-07-07-095229: SESSION 61397 NEW SERIAL 0->1
2020-07-07-095232: DUMP ROUTES: session_id=61397 serial=1 announce=146904/withdraw=0
.^C
select wait: ^C

I get the currently valid ROAs (over time, this is very good for keeping history) dumped into a file. When I grep in that that:

$ cat data/2020-07/2020-07-07-095229.routes.00061397.00000001.json | grep 1.37.137 --before=2 --after=2
      },
      {
        "ip": "1.37.137.0/24",
        "asn": 4775
      },

I see the whitelisted prefix.