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.

Sure to be some.

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.