RPKI Cantilever: Fixing the BGPsec Downgrade Attack
Arrcus
sra@hactrn.net
RPKI
This note describes a new RPKI object type which provides the
data necessary for a BGPsec-aware router to distinguish
downgrade attacks from update messages which really should be
unsigned.
This note describes a new RPKI object type which BGPsec
implementations can use to fix a known downgrade attack on the
BGPsec protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.
The reader is assumed to understand
BGP ,
BGPsec ,
the RPKI ,
and Route Origin Authorizations (ROAs) .
BGPsec's security guarantees depend on the ability to
construct an unbroken signature path starting from a ROA and
continuing through each ASN which issued a legitimate
advertisement for the prefixes in question. Given this
signed path and a supporting collection of certificates and
other objects published in the RPKI, a BGPsec-aware router
can determine whether a BGP UPDATE message is "Valid".
However, until and unless BGPsec achieves universal
deployment, a BGPsec-aware router can't assume that it will
only receive BGPsec UPDATE messages, so BGPsec-aware routers
are allowed and in some cases required to "strip" BGPsec
attributes out of the messages they send to their neighbors,
converting BGPsec_PATH attributes into plain AS_PATH
attributes.
Unfortunately, in the absence of other data, it is not
possible for a BGPsec-aware router further along a path to
determine whether the BGPsec signatures should have been
stripped or not: stripping is a downgrade from BGPsec to
plain BGP, and since the validating router doesn't know why
the signatures were stripped, it can't tell the difference
between signatures that were properly stripped as a path
exited an "island of security" and signatures that were
stripped as a downgrade attack.
This note defines a new RPKI object type which provides the
information needed to avoid this form of downgrade attack.
Our solution to the downgrade attack follows directly from the
problem statement: we need a way for a BGPsec-aware router to
determine whether BGP UPDATE data it receives for a particular
path should have been signed. For simplicity, we do not
attempt to determine this for individual prefixes or
individual pairs of adjacent routers, only for entire
Autonomous Systems.
The Cantilever object is an attestation that a particular
Autonomous System ("signer") uses BGPsec for all UPDATEs it
sends to a second particular Autonomous System ("target").
The object is signed by a private key corresponding to an RPKI
certificate containing the signer's Autonomous System Number
in its ASIdentifiers SEQUENCE.
Cantilever objects are RPKI signed objects as specified in
.
The eContentType for a Cantilever object is defined as
id-ct-rpkiCantilever and has the numerical value
1.2.840.113549.1.9.16.1.TBD.
The content of a Cantilever object is ASN.1 encoded using the
Distinguished Encoding Rules (DER).
RPKI relying parties validate Cantilever objects in much the
same way as they do other RPKI leaf objects such as ROAs. The
validation engine MUST follow all the usual rules for checking
RPKI signed objects, with the additional constraint that the
ASN from the signer field of the Cantilever object MUST appear
in the ASIdentifiers extension of the associated EE certificate.
A future update of the RPKI-Router protocol
will include support for the
payload of the Cantilever object. In any case, once the cache
has performed the usual RPKI relying party checking, the only
portion of the payload needed by the router is the <signer,
target> pair of Autonomous System Numbers.
A BGPsec-aware router which uses the Cantilever mechanism MUST
check the validated Cantilever data for records naming its ASN
as the target. The signer fields in these records tell the
router the list of ASNs from which it should expect to receive
BGPsec UPDATEs instead of plain BGP UPDATEs.
Behavior of neighboring BGPsec-aware routers is
straightforward, but the more interesting question is what
other BGPsec-aware routers should do: in particular, how can a
BGPsec-aware router several hops away detect a malicious
downgrade?
One possibility would be to decree that the existence of any
Cantilever objects for a given signing AS indicates that there
will be Cantilever objects pointing from that AS to ALL of the
neighboring Autonomous Systems with which it peers, but, as
stated, this wouldn't work, because we can't require that all
of a particular Autonomous System's neighbors speak BGPsec.
We could, however, add a boolean field to the Cantilever
object, indicating whether the AS signing the Cantilever
object signs towards this target AS or not.
We'll need OIDs for the RPKI-CANTILEVER module and the
id-ct-rpkiCantilever eContentType.
We may also need a MIME type in order to allocate filename
extension (".can" ?) for Cantilever object files.
The author would like to thank:
Alexander Azimov, for accidentally triggering the chain of
thought that led to this mechanism;
Randy Bush, Russ Housley, and Steve Bellovin, for
confirming that the basic semantics here make sense;
and anybody else who helped along the way but whose name the
author has temporarily forgotten.