Network Working Group R. Austein Internet-Draft Arrcus Intended status: Standards Track September 18, 2018 Expires: March 22, 2019 RPKI Cantilever: Fixing the BGPsec Downgrade Attack draft-austein-sidr-rpki-cantilever-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 22, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Austein Expires March 22, 2019 [Page 1] Internet-Draft RPKI Cantilever September 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Suggested Reading . . . . . . . . . . . . . . . . . . . . 2 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 2. The Cantilever Object . . . . . . . . . . . . . . . . . . . . 3 2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 3 3. RPKI Cache Behavior . . . . . . . . . . . . . . . . . . . . . 4 4. BGPsec-aware Router Behavior . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This note describes a new RPKI object type which BGPsec implementations can use to fix a known downgrade attack on the BGPsec protocol. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Suggested Reading The reader is assumed to understand BGP [RFC4271], BGPsec [RFC8205], the RPKI [RFC6480], and Route Origin Authorizations (ROAs) [RFC6482]. 1.3. Problem Statement 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 Austein Expires March 22, 2019 [Page 2] Internet-Draft RPKI Cantilever September 2018 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. 2. The Cantilever Object 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 [RFC6488]. 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). 2.1. ASN.1 Module Austein Expires March 22, 2019 [Page 3] Internet-Draft RPKI Cantilever September 2018 RPKI-CANTILEVER { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) modules(0) TBD } DEFINITIONS EXPLICIT TAGS ::= BEGIN id-ct-rpkiCantilever OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-ct(1) TBD } Cantilever ::= SEQUENCE { version [0] INTEGER DEFAULT 0, signer ASID, target ASID } ASID ::= INTEGER END 3. RPKI Cache Behavior 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 [RFC8210] 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 pair of Autonomous System Numbers. 4. BGPsec-aware Router Behavior 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 Austein Expires March 22, 2019 [Page 4] Internet-Draft RPKI Cantilever September 2018 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. 5. IANA Considerations 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. 6. Security Considerations Sure to be some. 7. Acknowledgements The author would like to thank: o Alexander Azimov, for accidentally triggering the chain of thought that led to this mechanism; o 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. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. Austein Expires March 22, 2019 [Page 5] Internet-Draft RPKI Cantilever September 2018 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, May 2017. [RFC8205] Lepinski, M. and K. Sriram, "BGPsec Protocol Specification", RFC 8205, September 2017. 8.2. Informative References [RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, September 2017. Author's Address Rob Austein Arrcus Email: sra@hactrn.net Austein Expires March 22, 2019 [Page 6]