-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect BGPsec Router Key corruption in JSON input #95
Comments
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. |
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: ***@***.***>
|
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. |
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:
The SKI can be confirmed by calculating the SHA-1 hash of the BIT STRING present in the base64-encoded DER-encoded SPKI.
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?
The text was updated successfully, but these errors were encountered: