[RPKI] On entitlements and communications

[Tim Bruijnzeels]

Hi Aistis, list,


> On 10 Sep 2020, at 07:46, Aistis Zenkevičius via RPKI <rpki at lists.nlnetlabs.nl> wrote:
> 
> Hi list
> 
> Coule of questions regarding Krill in a context of it being a child for RIR CA:
> 	- is it possible to catch the certificate revocation from RIR end? Simply someone clicks on "Revoke" button in, for example, RIPE NCC's portal.

Not easily. But you would see errors in your log, and from 0.8 onwards (RC expected end of September) there will be improved 'status' reporting for the connection between Krill CAs an their parents (and repository for that matter).

It's hard to know whether an error in contacting a parent is due to a temporary issue at the parent, vs something like the parent no longer recognising krill as a child. There may be some more informed guessing that Krill can do (e.g. unreachable or 'internal error' vs a forbidden response etc) - but for now Krill assumes that if a parent is unavailable it will just come back later. So it will just try again later (10 minutes by default).

There is a similar issue wrt publication. However, if publication fails then Krill will reschedule publishing in 5 minutes, and keep trying until it works.

We are also thinking about prometheus gauges for monitoring this.


> According to Github, Krill used to "Log all RFC8181 and RFC6492 protocol messages. #143", then it started "Only save significant RFC6492 or RFC8181 exchanges #172", and at the moment, I'm not sure whether this is configurable at all. I did find a couple of messages under _data/rfc6492/<uuid>, but to be useful, they would need to be readable. 

The rfc* folders are mostly useful for debugging. The contain the raw CMS messages for the RFC 6492 (certificate entitlements, requests and revocations) and RFC 8181 (publication) protocols. Originally all exchanges were kept, but this resulted in a *lot* of data being saved. Especially when logging the requests for entitlements that Krill CAs send every 10 minutes. So, the code was updated to only save those exchanges where your CA requests a change (a new certificate, a key roll, or when it tries to publish) - or in case the parent / repo responds with an error. To enable this you need to set the "rfc6492_log_dir" and "rfc8181_log_dir" directives.


> 	- is it possible to catch entitlement changes? E.g. resource added/removed?

The full history of changes is kept. Intentions to make a change are recorded as 'commands' - regardless of whether they are initiated by an operator, e.g. create a ROA, or the system, e.g. request a new certificate because resource entitlements have changed.

The effect of a command is normally a list of changes, or 'events' as they are called here - or - an error in case the command could not be executed, e.g. you tried to create a duplicate ROA.

So all information is kept, but it is not that easy yet to access it. A start has been made, and you can look at your command history using the CLI. What is still missing though, is the ability to look at the effects of commands in more detail, better filtering and *importantly* inclusion in the UI.

If you want to play with this now, have look at the CLI:

root at krill-prod-master:~# krillc help history 
krillc-history 
Show full history of a CA.

USAGE:
    krillc history [FLAGS] [OPTIONS]

FLAGS:
        --api        Only show the API call and exit. Or set env: KRILL_CLI_API=1
        --full       Show history including publication.
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
        --after <<RFC 3339 DateTime>>     Show commands issued after date/time in RFC 3339 format, e.g. 2020-04-
                                          09T19:37:02Z
        --before <<RFC 3339 DateTime>>    Show commands issued after date/time in RFC 3339 format, e.g. 2020-04-
                                          09T19:37:02Z
    -c, --ca <name>                       The name of the CA you wish to control. Or set env: KRILL_CLI_MY_CA
    -f, --format <type>                   Report format: none|json|text (default). Or set env: KRILL_CLI_FORMAT
        --offset <<number>>               Number of results to skip
        --rows <<number>>                 Number of rows (max 250)
    -s, --server <URI>                    The full URI to the krill server. Or set env: KRILL_CLI_SERVER
    -t, --token <string>                  The secret token for the krill server. Or set env: KRILL_CLI_TOKEN


> In fact, has anyone experienced/tried entitlement changes with any of RIRs and has it worked properly? I had at least one case where certain IPv6 or ASN resource has been added after RPKI has been set up at ARIN side and it didn't show up in their management until we requested to regenerate certificate via support ticket. So I wonder how this looks with Krill.
> Unofficially (and without looking at code, since my Rust skills are rusty) I heard Krill follows RFC6492 and contacts parent CA every 10 minutes asking for entitlement changes and other things.
> 

Krill will check the entitlements every 10 minutes by default. Arguably this frequency could be lower, but 10 minutes does not seem to cause issues (yet). It will then request new certificates whenever there are resource changes, as well as when you are entitled to a certificate with a longer validity time.

This has been tested and should all work. If you find issues here I would be very interested to learn about them.

Thanks
Tim

> 
> 
> Thanks,
> Aistis
> 
> -- 
> RPKI mailing list
> RPKI at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/rpki