The ability to constrain a RPKI Trust Anchor's effective signing
authority to a limited set of Internet Number Resources allows
Relying Parties to enjoy the potential benefits of assuming trust,
within a bounded scope.
Some examples: ARIN does not support inter-RIR IPv6 transfers, so
it wouldn't make any sense to see a ROA subordinate to ARIN's trust
anchor covering RIPE-managed IPv6 space. Conversely, it wouldn't
make sense to observe a ROA covering ARIN-managed IPv6 space under
APNIC's, LACNIC's, or RIPE's trust anchor - even if a derived trust
arc (a cryptographically valid certificate path) existed. Along these
same lines, AFRINIC doesn't support inter-RIR transfers of any kind,
and none of the RIRs have authority over private resources like
10.0.0.0/8 and 2001:db8::/32.
For more background see:
https://datatracker.ietf.org/doc/draft-snijders-constraining-rpki-trust-anchors/https://mailman.nanog.org/pipermail/nanog/2023-September/223354.html
With and OK tb@, OK claudio@
An upcoming diff requires the ability to convert ASIdentifiers and
IpAddrBlocks into rpki-client's internal structures. Accordingly,
split already existing code into dedicated parsing functions . The
original functions now only extract the extension-specific data from
the X509_EXTENSION.
input/ok claudio
This will be needed by an upcoming feature where we will need to know
what trust anchor a given cert chains to. This doesn't change anything
except the size of the diff.
ok claudio job
Convert all cryptowarnx() and cryptoerrx() to appropriate versions of
warn() and err{,x}(). Neither users nor developers benefit from them.
If we need better errors, we need to do some thinking. libcrypto won't
do that for us.
suggested by claudio
ok job
Through draft-ietf-sidrops-aspa-profile-15, the ASPA profile was
made AFI-agnostic. This represents a simplification for both operators
and implementers in both the RPKI and BGP layers of the stack.
This update changes the JSON structure.
No effort was made to simultaneously support ASPA v0 and v1 objects.
OK tb@ claudio@
According to RFC 8182, a given session_id and serial number represent an
immutable record of the state of the Repository Server at a certain
point in time.
Add a check to the RRDP notification file processing to compare whether
the delta hashes associated to previously seen serials are different in
newly fetched notification files. Fall back to a snapshot if a difference
is detected, because such a mutation is a strong desynchronization
indicator.
Idea from Ties de Kock (RIPE NCC).
Based on a diff by job@
With and OK job@ tb@
In the RSYNC protocol a file's last modification time and its size are
used to determine whether sending a (partial) copy over the wire is needed.
Previously, when RRDP data structures are serialized to disk, the mtime of
files in DIR_VALID ended up being UTIME_NOW.
Thus, the mtimes of files obtained through RRDP will never match the mtimes
of the same files available through RSYNC - causing each and every file to
be added to the file transfer list.
Instead, use the internal timestamps of RPKI files as the last modified
timestamp. Specifically, for Signed Objects (ROAs, MFTs, GBRs, TAKs, ASPAs)
the CMS signing-time, for .cer files the X.509 notBefore, and for .crl files
the CRL lastUpdate. This results in a surprising optimization for the number
files which have to be transfered.
OK claudio@
Make rpki-client choose the verification time of the time it is invoked
rather than always getting the current system time for every certificate
verification. This will result in output that is not variable on run-time.
Using the time of invocation does not work well with fast publishing CAs. It
can take a few minutes to reach a repo and that CA may have issued certificates
that are not yet valid if that startup time of rpki-client is used to validate.
This still keeps the -P option to specify a fixed validation time.
OK beck@ job@ tb@
The generally rather poor quality RFC 3779 code in libcrypto also performs
abysmally. Flame graphs show that nearly 20% of the parser process is spent
in addr_contains() alone. There is room for improvement in addr_contains()
itself - the containment check for prefixes could be optimized quite a bit.
We can avoid a lot of the most expensive work for certificates with tons of
resources close to the TA by using the verifier's partial chains flag.
More precisely, in the tree of already validated certs look for the first
one that has no inherited RFC 3779 resources and use that as 'trust anchor'
for our chains via the X509_V_FLAG_PARTIAL_CHAIN flag. This way we can be
sure that a leaf's delegated resources are properly covered and at the same
time significantly shorten most paths validated.
Job's and my testing indicates that this avoids 30-50% of overhead and works
equally well with LibreSSL and OpenSSL >= 1.1. The main bottlenecks in the
parser process now appear to be SHA-2 and RSA/BIGNUM, two well-known pain
points in libcrypto.
This is based on a hint by beck and was discussed extensively with beck,
claudio and job during and after m2k23.
ok claudio job
rather than always getting the current system time for every certificate
verification. This will result in output that is not variable on run-time.
ok tb@ claudio@
This fixes some wrong accounting for repositories that are referenced
from more than one TAL. It changes the ometric lable output a little bit
since there are repository metrics that no longer include the 'name' label.
OK tb@
Unify common code paths which find the exact expiry moment into a new
helper function. Additionally, the new helper offers more accuracy by
checking more applicable CRLs whether their 'nextupdate' is 'sooner'.
tb@ noted: The helper adds a multiplier of log(#crls), but that's
certainly acceptable as it is still very cheap.
OK tb@
Change the way the validated ASPA tree is built since OpenBGPD config
follows more the ASPA profile and puts the optional AFI to each provider
ASnum instead of duplicated everything into an IPv4 and IPv6 tree.
The JSON output of ASPA is still the same.
The inclusion of the aspa-set can currently be disabled by the -A flag.
OK tb@
RFC 8182 requires the session_id to be a version 4 random UUID (using
variant 1). Now checking the version and variant is currently disabled
because there is at least one CA with a session_id that is all random
and therefor the version check triggers there.
Joint work with job@. OK job@, tb@
Many statistic values are now accounted by repository via repo_stat_inc()
At end of the run sum_stats() accumulates these stats per TAL and globally.
The new output file metrics is written when the -m output flag is specified.
The metrics file is written in OpenMetrics format (with a few tweaks to
allow node_exporter to parse the file as well). The ometric code is a copy
from bgpctl(8) and should be kept in sync.
OK tb@
RFC 9092 describes a scheme in which an authenticator is appended to a
geofeed (RFC 8805) file. It is a digest of the main body of the file
signed by the private key of the relevant RPKI certificate for a covering
address range. The authenticator is a detached CMS signature.
with and OK tb@
Unfortunately we can't yet error out when accessMethods other than
signedObject are encountered in the SubjectInformationAccess extension
because there is pollution in the ecosystem.
OK tb@
Add support validation of Signed Objects containing Trust Anchor Keys
(TAKs - aka 'Signed TALs'). Signed TALs provide a mechanism for RIRs
to distribute and sign the next Trust Anchor with the current Trust
Anchor. This might be an improvement over visiting RIR websites and
copy+pasting TAL data by hand.
OK tb@
Unify conformance checking of Trust Anchors, ROAs, ASPAs, RSCs - none of which
may have any 'inherit' elements in the RFC 3779 IP/AS Resources extension of
the X509 certificate.
OK tb@
The abort is done in a way that waits for any inflight files or http
requests to finish before removing the rrdp state and before sending
the rrdp done message indicating failure.
OK tb@ and benno@
ASPA objects are published in the RPKI and can be used to detect and
mitigate BGP route leaks. Validated ASPA Payloads are visible through
filemode (-f) and the JSON output format (-j).
With feedback from tb@
OK claudio@ tb@
The resources delegated in the RFC 3779 extensions of the EE cert for
ROAs or RSCs can be a subset of the resources in the auth chain. So far
we compared that the resources of ROAs and RSCs are covered by the auth
chain, which is not entirely correct. Extract the necessary data from
the EE cert into rpki-client's own data structures, then verify that
the EE cert's resources cover the ones claimed in the ROA or RSC.
Do this as part or ROA and RSC parsing, that the EE cert's resources are
covered by the auth chain is checked in valid_x509() later on.
All this is a bit more annoying and intrusive than it should be...
ok claudio job
