We already check that the fileList isn't excessively large. A bit later we
also check that the list contains a CRL, as required by RFC 9286. However,
between these two checks a zero-sized allocation may happen, which is now
avoided. sk_num() is one of those gifts that keep on giving, but it seems
that this is the only occurrence in rpki-client that can be problematic.
ok job
On accept(2), httpd(8) sets the timeout based on ip:port. Once we have
parsed the http headers we can find the name-based server block and
apply its request timeout.
Problem identified and fix from Nick Owens, thanks!
OK tb
In some cases, following a fallback from RRDP to RSYNC, files are
moved to the wrong place. With this change, only rsync repositories
are considered when looking up where to move DIR_TEMP files.
repo.c requires more study, this fix might be a bandaid for a problem
not fully understood.
"put it in" claudio@ OK tb@
The RPKI ecosystem suffers from a partially unmitigated risk related to
long-lived Trust Anchor certificate issuances.
Issues could arise when a on-path attackers (or, operational errors such
as restoring a super old backup of a webserver) bring back into
circulation old (but still valid) TA certificate. Older certificates
remain valid for the duration of their validity period, because TA
certificates - being top of the chain - cannot be revoked.
Real world examples of old potential replayable certificates that today
still would pass validation are here:
https://mailarchive.ietf.org/arch/msg/sidrops/NxzvSFH0sPXEmyfOS99cLApFKqM/
The trouble with these replayable TA certificates is that when an
on-path entity ends up presenting such an outdated-but-still-valid
certificate to the RP, accepting such a cert will damage the RP's local
validated cache. Parts of the validated output will disappear, in an
unpredictably manner.
Periodic reissuance of TA certs is important because TA certificates are
not entirely static, which of course is why replay might even be an issue
in the first place!. There are 3 'dynamic' fields in TA certificates:
- the validity period (notBefore, notAfter)
- the SubjectInfoAccess (where can the RP find the first repository?)
- the extensions for IP addresses & AS identifiers (RFC 3779 INRs)
(the RFC 3779 extensions are of critical importance to the
RPKI's chain validation algorithm)
RIRs will want RPs to validate using the 'latest' issuance of the TA
certificate, because a TA cert from 10 years ago obviously will be 10
years behind on operational decisions, potential SIA migrations,
resource transfers, new IANA assignments, or any other updates to the
RIR's current holdings.
How to repair this situation?
The plan to overcome this risk has three steps:
step 1) RPs to prefer shorter-lived Trust Anchor certificates over
longer-lived ones. (rpki-client already implemented this)
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebreaker
step 2) RPs ship with scheduled future refusal of ultra long-lived Trust
Anchor certificates (that's the below diff).
step 3) Consequently, RIRs have to reissue shorter-lived TA certificates
to avoid being rejected by RPs.
The end result is that after anno 2026 / 2027, if 100 year or 10 year
certs somehow be brought back into circulation, RPs will simply refuse
such long-lived certs, despite them technically being 'valid'.
Why this works:
The ta-tiebreaker mechanism provides an incentive for TA operators to
reissue with reasonable (1 or 2 year) validity periods, as those certs
will be preferred. In turn, RPs scheduling refusal of long-lived certs
at a predetermined future point in time, relieves TA operators from
worrying about previously issued certs with ultra long lifetimes. It is
a win win for everyone in the ecosystem.
Scheduling details:
- February 2nd 2026 for phase 1, because 02-02-2026 is an unambiguous
date both in the US and elsewhere.
- March 3rd 2027 for phase 2, because 03-03-2027 also is unambiguous and
visually is very distinct from the phase 1 date.
The hope is that with this schedule global coordination less will be less
error-prone, and everyone should get adequate preparation time.
Discussed with various RIRs
with & OK tb@
This is an extension to graceful restart and requires graceful restart to
be enabled to work. The NOTIFICATION bits are implemented as specified but
a much more strict stand was taken as to when send a graceful reset.
bgpd only sends graceful notifications for a few cease cases (same as in
the RFC) and for the holdtimer and sendholdtimer errors. Everything else
is a hard error because the other side is not trustworthy.
OK tb@
INTERVAL_SESSION_DOWN (3600) seconds.
Rebuilding the Adj-RIB-Out is a lot of work while keeping the RIB in sync
is reasonably trivial. So avoid the work for the case that a session
was just quickly reset. This only works if the same peer settings are
used in the old and new session.
For this introduce a IMSG_SESSION_DELETE that tells the RDE to remove the
peer and split peer_down into a part that takes the session down (and
clears the Adj-RIB-In) and a part the frees the peer (peer_delete).
The SE now sends an IMSG_SESSION_ADD command on first connect and skips
that imsg on later connects unless IMSG_SESSION_DELETE was called before.
During config reload the IMSG_SESSION_ADD calls only need to happen when
the RDE actually has that information.
OK tb@
prefixes to the update / withdraw queue if the peer is up.
For updates the Adj-RIB-Out is already updated and nothing more needs to happen.
For withdraws the prefix is unlinked and needs to be destroyed if the peer is
not up. For this to work correctly make the prefix as dead.
Right now this is a no-op since the functions are only called if the peer
is up.
OK tb@
and is stopped when the session comes up (ESTABLISHED state).
Right now it is used to remove cloned sessions. For that the SessionDownTimer
is also started when a clone is created.
OK tb@
The pointer passed to pt_writebuf() is bad and there is no reason to limp
further. Someone else will trip over this at a later stage so better to
do it now.
OK tb@
Rename the upcall and done callbacks:
- rde_up_adjout_force_upcall() to peer_blast_upcall() and same for done
- rde_up_dump_upcall() to peer_dump_upcall() and same for done
Introduce peer_blast() which blasts out the Adj-RIB-Out including all
the route refresh messages (BEGIN_RR, EOR and END_RR) needed.
peer_dump() now always throttles the peer before starting the table walk to
fill the Adj-RIB-Out and calls peer_blast() in all cases (either directly or
via the peer_dump_done() call.
OK tb@
This extends the maximum message size of BGP from 4096 to 65535.
This mostly follows rfc8654 with the following differences:
- NOTIFICATIONS are always truncated to fit in 4096 bytes.
- There is no message reduction using "attribute discard" in case of overflow.
- Large messages are only sent if both sides announced extended message support.
OK tb@
If a bt(5) script uses the same probe multiple times (like interval:hz),
btrace(8) has currently no knowledge of which rule to execute when it
parses events read from the kernel.
Disable the funcitonnality until someone in need of such feature comes
up with a nice implementation.
From Christian Ludwig.
libraries was changed. Before @tag we used to execute programs directly
as part of many updates (rebuilding desktop databases, icon cache, etc)
but those are now usually deferred until the end of the run, leaving
some executables not able to be run until pkg_add finishes.
From espie.
Adj-RIB-Out and in that case set F_CTL_ADJ_OUT on the request.
With this 'bgpctl show rib out' and 'bgpctl show rib table Adj-RIB-Out'
return the same results.
OK tb@
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@