Detect BGPsec Router Key corruption in JSON input

[job]

Although the SKI field in BGPSec Router Keys appears to be redundant, its presence can perhaps be used to detect data corruption in the pipeline.

Given the following example:

"bgpsec_keys": [
  { "asn": 15562, "ski": "5D4250E2D81D4448D8A29EFCE91D29FF075EC9E2", "pubkey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgFcjQ/g//LAQerAH2Mpp+GucoDAGBbhIqD33wNPsXxnAGb+mtZ7XQrVO9DQ6UlAShtig5+QfEKpTtFgiqfiAFQ==", "ta": "ripe", "expires": 1699105676 }
]

The SKI can be confirmed by calculating the SHA-1 hash of the BIT STRING present in the base64-encoded DER-encoded SPKI.

$ echo MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEgFcjQ/g//LAQerAH2Mpp+GucoDAGBbhIqD33wNPsXxnAGb+mtZ7XQrVO9DQ6UlAShtig5+QfEKpTtFgiqfiAFQ== \
  | base64 -d \
  | dd bs=1 skip=26 2>/dev/zero # skip the ASN1 tags \
  | openssl sha1
(stdin)= 5d4250e2d81d4448d8a29efce91d29ff075ec9e2

Perhaps it is robust behavior to log a warning and ignore the Router Key entry if there is a mismatch between the calculated SKI and the listed SKI?

[ties]

The json is not fully standardised is it? The ski field feels redundant.

Wish there was a better spec for this. Might make sheets on it. Mostly because there also is a nice way to get multiple rtr servers in sync for the same session if the session and serial-within-that-session are in the json.

[benjojo]

I'm not a huge fan of the idea of validating ASN.1 payloads inside a RTR demon, In terms of scope creep on a RTR demon, and the scope for bugs as a result of dealing directly with ASN.1 payloads

Message ID: @.***>

[job]

The JSON format indeed does not follow a standard. For BGPsec Router Keys I attempted to mimic the layout of the RTR PDUs to make Ben’s life easier.