endpoint for VRPs of all the CAs

[ties]

As a user I want an (unauthenticated) endpoint that outputs all VRPs in the JSON format that RPs use to exchange VRPs in order to be able to monitor that my VRPs show up in RPs.

Using a JSON endpoint in this format, together with rtrmon a user can monitor that VRPs show up in RPs and thus have full-circle visibility in their ROAs working.

This enables the setup for VRPs described in https://www.ripe.net/ripe/mail/archives/routing-wg/2021-October/004476.html (the published objects endpoint would require a different endpoint, or could take rrdp from a (hidden) krill instance as source of truth if that is guaranteed to reflect the database state).

[timbru]

Sounds reasonable. Given that this is all public (published) information I see no reason to enforce authentication.

Do you see specific requirements from your end regarding the format?

From my end I want to be specific about the difference between configured VRPs - i.e. the authorisations that users put into krill as opposed to the actual ROA objects. Bear in mind that:

• a single VRP may appear on multiple ROAs if the CA has the same prefix under multiple parents.
• multiple VRPs for the same ASN may be combined in a single ROA (default 100 VRP threshold)
• a configured VRP may still be present for a CA if they lost a resource, but it won't be published (preventing an overclaiming ROA is a feature)

I think that for monitoring purposes a structure like this could work:

/stats/vrps/all.json

[
   {
      "prefix": "10.0.0.0/24",
      "max_length": 24,
      "asn": 65001,
      "ca": "ca-name",
    },
   ...
]

I could use "maxLength" instead, if it's important.. but because this is not really the idiomatic rust way I would prefer if I don't need to.. I think it would be good to always include this field, defaulting to the prefix length - since that is also what you would expect in rtr.

I don't want to do the work now in the context of this issue, but when this is added we can extend the json in future to include additional information - such as.. whether the VRP is for a prefix no longer held by the CA.

[ties]

Sounds reasonable. Given that this is all public (published) information I see no reason to enforce authentication.

Do you see specific requirements from your end regarding the format?

To use rtrmon - like I have setup to monitor another CA, it makes sense to use the pseudo-standard json-vrp format such as used by routinator etc. Another format that makes some sense (but would not be useful with rtrmon) is SLURM (where you assert everything set by krill).

From my end I want to be specific about the difference between configured VRPs - i.e. the authorisations that users put into krill as opposed to the actual ROA objects. Bear in mind that:

• a single VRP may appear on multiple ROAs if the CA has the same prefix under multiple parents.
• multiple VRPs for the same ASN may be combined in a single ROA (default 100 VRP threshold)
• a configured VRP may still be present for a CA if they lost a resource, but it won't be published (preventing an overclaiming ROA is a feature)

I think that an extended option that includes configured VRPs that are no longer held by the CA makes sense as well. You could use that to, for example, make sure that all the VRPs you intended to have are present (during migrations etc).

I am not sure if this endpoint makes more sense for the aggregate of all CAs or per-CA.

I think that for monitoring purposes a structure like this could work:

/stats/vrps/all.json

[
   {
      "prefix": "10.0.0.0/24",
      "max_length": 24,
      "asn": 65001,
      "ca": "ca-name",
    },
   ...
]

I could use "maxLength" instead, if it's important.. but because this is not really the idiomatic rust way I would prefer if I don't need to.. I think it would be good to always include this field, defaulting to the prefix length - since that is also what you would expect in rtr.

To interop with other tools maxLength would be needed. And I agree with defaulting to the prefix length there.