AS0 TALs represent unmitigated operational risks: what if the RIR by
accident marks some IP space as 'unassigned'?
APNIC notes in their limitation of liability statement:
"""
Depending on router configuration, errors in the AS0 ROA could
cause unintended interruption to routing with other networks.
For this reason, it is strongly recommended that the AS0 ROA is
used for advisory and/ or alerting purposes only, and not for
automatic filtering of BGP routes.
"""
https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/
Guard usage of AS0 TALs behind new '-0' option
OK deraadt@ tb@
Having a single letter to distinguish a length from a pointer is error
prone. This results in binary change only in validate.c and cert.c due
to a line wrap resulting in line number changes and in cert.c there's in
addition two asserts that change.
checked with/ok job
It is helpful for network operators, publication point operators, and CA
operators to have more insight into whether the RP noticed an issuance
gap between two versions of a given manifest.
* high number of gaps all the time might be an indication the RP is not
refreshing often enough
* the CA is trying to issue manifests more than once a second
* the RFC 8181 publication server's ingress API endpoint has issues
* the RFC 8181 publication client has trouble reaching the server
* the CA's private keys (RPKI + BPKI) are used on a second (cloned) system
* the CA's issuance database is broken
Correlation opportunity: detection of a gap means some of the CA's
intermediate states were occluded from the RP; the RP operator might
want to correlate this to traffic shifts in BGP or publication point
reachability issues.
Going forward, emit a warning per manifest, adds metrics to the
openmetrics output, and displays a summary at the end of the run about
issuance gaps.
OK tb@
The CRL number draft clarified what ignoring means and it includes checking
that the CRL number is well-formed again. So do this but continue to ignore
the value for any other purpose. This refactors x509_convert_seqnum() into
a couple of helpers. There's some duplication between crl_check_crl_number()
and crl_parse_crl_number() which could be removed if anyone cares.
tweaks/ok job
It is technically possible for a series of RRDP deltas and a snapshot
to diverge. An RRDP server could distribute files via Deltas and then
forget about those files, causing copies to remain stuck in the caches
of RRDP clients. Resetting RRDP sessions once every few weeks helps with
garbage collection.
In week 0 the probability of triggering re-initialization is ~0.025% and
doubles every week, in week 11 its 50% and always after week 12. Thus,
RPs will reinitialize at least once every 3 months.
OK tb@ claudio@
Only trigger a duplicate error if a valid filepath is revisted. It is
possible that a bad CA references somebody else's files and if that
happens first it would block the valid access.
To make this work, pass the ok flag to filepath_add() and only set the
talmask bit if the file was ok. Since we need to do the duplicate check
before processing the entity introduce filepath_valid() which checks
if the path is in the tree and has its talmask bit set.
In repo_move_valid() handle conflicts more gracefully. When both a valid
and temporary file are present assume that one of the files was never ok
(talmask == 0) and silently remove that file from the filepath tree.
OK tb@
This is a simple wrapper around X509_check_policy(cert, -1, 0) that
doesn't need an explanatory comment in the caller.
The reason for having to do this is that various OpenSSL API calls rely
on having extension information cached. As an unsurprising consequence of
OpenSSL's characteristic API misdesign these calls can't report errors,
so they call the extension caching without error checking and the result
is that they may report nonsense.
To work around this, cache the extensions up front so a second call can't
fail and thus API calls such as X509_check_ca(), X509_get_key_usage() and
X509_cmp() work reliably.
ok job
Per RFC 6487, the subject and issuer fields of a certificate and the issuer
field of a CRL are subject to the same restrictions: only a commonName and
an optional serialNumber may be present and the commonName must be an ASN.1
printable string.
So far we've only checked the subject of certificates, which covers almost
everything by relying on the verifier to check that the issuer's subject is
identical to the subject's issuer, also for CRLs per X509_V_FLAG_CRL_CHECK.
The only thing missing this way is the TA's issuer.
Since the check is cheap and simple, we're better off doing it ourselves:
Refactor the x509_vaild_subject() helper to take an X509_NAME (which is of
course the appropriate name for a type representing an X.501 distinguished
name). This checks the details of RFC 6487, section 4.4, except that we
still can't check for a printable string since afrinic has ~3000 EE certs
that don't follow the spec, which would knock out ~45% of their ROAs. We're
told that this is going to be fixed this year.
looks good to claudio
ok job
There is no benefit in parsing the CRLNumber in the RPKI. It is redundant
with other mechanisms, notably the requirements on manifests. rpki-client
never did anything with the CRL number anyway so stop parsing it in the
main process.
Move CRL AKI and CRL number handling from x509.c to crl.c, slightly improve
error checking for X509_CRL_get_ext_d2i() and only check well-formedness of
the CRL number: check it's there and non-critical. Avoid double warnings.
Add some checks for the well-formedness of the list of revoked certs.
Due to bugs in rpki-rs and Krill we can't reject empty lists (because
~15% of CRL's have this). And some people still use CRLs revoking certs
at the time they expire. This latter point might change mid-2025.
Add a hook for printing CRL numbers in file mode and warn about ill-formed
numbers (negative and overlong ones).
ok claudio job
The certificate SKI is not strictly unique so using it as a unique id is
problematic. It is also not really needed to do that since in theory we
already know the path (but this got lost in the privsep communication).
So add a cert id and pass this id back and forth between main process and
the parser. With this id we can lookup the authentication chain in the
parser and this even works with multiple paths to the same resource.
Since we no longer lookup by SKI the valid_aki_ski function is replaced
by find_issuer() which does the lookup by certid.
The loop protection is now extended to allow each TAL to reach each file
once but still triggers if a file is reaccessed by the tree of a TAL.
In filemode the lookup now uses an AIA uri based lookup tree. Again this
replaces the SKI based lookups from before.
Done together with tb@
OK tb@ job@
The previous approach introduced a cap, but it might not always be hit as
intended (I missed this on review). Fix this to check the cap after merging
an ASPA into an already existing VAP. Also free the list of providers since
nothing should be looking at it anymore.
Count VAPs that hit the limit with a new overflowed counter. There are
still a few aspects of the accounting that probably aren't entirely right.
This will be fixed at another point. It's just statistics after all.
with/ok claudio, ok job
The number of providers in a single ASPA object already was limited to
MAX_ASPA_PROVIDERS, now also impose a limit on the total number of providers
across multiple ASPA objects. If the MAX_ASPA_PROVIDERS limit is hit, omit
the Customer ASID's entry from OpenBGPD and JSON output.
OK tb@
Parent is confusing and issuer is the appropriate terminology. This is
a mechanical diff. The only remaining uses of 'parent' in this code
base now mean 'parent process'.
discussed with beck and job
ok job
Signed Prefix List are a CMS protected content type for use with the
RPKI to carry the complete list of prefixes which an Autonomous System
may originate to all or any of its routing peers. The validation of a
Signed Prefix List confirms that the holder of the listed ASN produced
the object, and that this list is a current, accurate and complete
description of address prefixes that may be announced into the routing
system originated by this AS.
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-prefixlist
with and OK claudio@ tb@
Fix their indent in extern.h, move the X509_TIME_* macros to main.c since
they aren't (and can't really be) used elsewhere, document the meaning of
the magic numbers. Also move get_current_time() out of the middle of entity
handlers.
ok claudio job
OBJ_nid2* can return NULL if the gloriously consistent objects.txt
database doesn't specify a long or a short name. So try the long name
first, fall back to the short name, and if both fail, use "unknown".
Always include the nid as a decimal.
ok claudio
Newly issued manifests should not only have a higher manifestNumber,
their issuance time should also be later. Add corresponding checks
and warnings when comparing a newly fetched manifest to a manifest
from the cache.
ok job (who noticed that such a check was missing)
Unify the printing of warnings about AS numbers and IP address blocks to
use a call to as_warn() and ip_warn(). Fix a bug in the latter where the
upper bound of an IP range didn't take the RFC 3779 encoding into account
and passed the address directly to inet_pton() rather than filling the
missing bits with 1. Switch the argument order to match the warnings and
tweak some warning messages.
ok claudio job
Picked 100 bytes as a minimum, to accommodate future signature schemes
(such as the smaller P-256) and small files like empty CRLs.
With and OK claudio@ tb@
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@
