doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7132.txt b/doc/rfc/rfc7132.txt
new file mode 100644
index 0000000..d21ae3b
--- /dev/null
+++ b/doc/rfc/rfc7132.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Kent
+Request for Comments: 7132                                           BBN
+Category: Informational                                           A. Chi
+ISSN: 2070-1721                                                   UNC-CH
+                                                           February 2014
+
+
+                   Threat Model for BGP Path Security
+
+Abstract
+
+   This document describes a threat model for the context in which
+   External Border Gateway Protocol (EBGP) path security mechanisms will
+   be developed.  The threat model includes an analysis of the Resource
+   Public Key Infrastructure (RPKI) and focuses on the ability of an
+   Autonomous System (AS) to verify the authenticity of the AS path info
+   received in a BGP update.  We use the term "PATHSEC" to refer to any
+   BGP path security technology that makes use of the RPKI.  PATHSEC
+   will secure BGP, consistent with the inter-AS security focus of the
+   RPKI.
+
+   The document characterizes classes of potential adversaries that are
+   considered to be threats and examines classes of attacks that might
+   be launched against PATHSEC.  It does not revisit attacks against
+   unprotected BGP, as that topic has already been addressed in the
+   BGP-4 standard.  It concludes with a brief discussion of residual
+   vulnerabilities.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7132.
+
+
+
+
+
+
+
+
+Kent & Chi                    Informational                     [Page 1]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   (http://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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Threat Characterization . . . . . . . . . . . . . . . . . . .   6
+   4.  Attack Characterization . . . . . . . . . . . . . . . . . . .   8
+     4.1.  Active Wiretapping of Sessions between Routers  . . . . .   8
+     4.2.  Attacks on a BGP Router . . . . . . . . . . . . . . . . .   9
+     4.3.  Attacks on Network Operator Management Computers (Non-CA
+           Computers)  . . . . . . . . . . . . . . . . . . . . . . .  11
+     4.4.  Attacks on a Repository Publication Point . . . . . . . .  12
+     4.5.  Attacks on an RPKI CA . . . . . . . . . . . . . . . . . .  14
+   5.  Residual Vulnerabilities  . . . . . . . . . . . . . . . . . .  16
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
+   8.  Informative References  . . . . . . . . . . . . . . . . . . .  18
+
+1.  Introduction
+
+   This document describes the security context in which PATHSEC is
+   intended to operate.  The term "PATHSEC" (for path security) refers
+   to any design used to preserve the integrity and authenticity of the
+   AS_PATH attribute carried in a BGP update message [RFC4271].  The
+   security context used throughout this document is established by the
+   Secure Inter-Domain Routing (SIDR) working group charter [SIDR-CH].
+   The charter requires that solutions that afford PATHSEC make use of
+   the Resource Public Key Infrastructure (RPKI) [RFC6480].  It also
+   calls for protecting only the information required to verify that a
+   received route traversed the Autonomous Systems (ASes) in question,
+   and that the Network Layer Reachability Information (NLRI) in the
+   route is what was advertised.
+
+
+
+
+
+Kent & Chi                    Informational                     [Page 2]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   Thus, the goal of PATHSEC is to enable a BGP speaker to verify that
+   the ASes enumerated in this path attribute represent the sequence of
+   ASes that the NLRI traversed.  The term "PATHSEC" is thus consistent
+   with the goal described above.  (Other SIDR documents use the term
+   "BGPSEC" to refer to a specific design; we avoid use of that term
+   here.)
+
+   This document discusses classes of potential adversaries that are
+   considered to be threats, and classes of attacks that might be
+   launched against PATHSEC.  Because PATHSEC will rely on the RPKI,
+   threats and attacks against the RPKI are included.  This model also
+   takes into consideration classes of attacks that are enabled by the
+   use of PATHSEC (e.g., based on use of the RPKI).
+
+   The motivation for developing PATHSEC, i.e., residual security
+   concerns for BGP, is well described in several documents, including
+   "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and
+   Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000].
+   All of these documents note that BGP does not include mechanisms that
+   allow an AS to verify the legitimacy and authenticity of BGP route
+   advertisements.  (BGP now mandates support for mechanisms to secure
+   peer-to-peer communication, i.e., for the links that connect BGP
+   routers.  There are several secure protocol options to address this
+   security concern, e.g., IPsec [RFC4301] and TCP Authentication Option
+   (TCP-AO) [RFC5925].  This document briefly notes the need to address
+   this aspect of BGP security, but focuses on application layer BGP
+   security issues that must be addressed by PATHSEC.)
+
+   RFC 4272 [RFC4272] succinctly notes:
+
+      BGP speakers themselves can inject bogus routing information,
+      either by masquerading as any other legitimate BGP speaker, or by
+      distributing unauthorized routing information as themselves.
+      Historically, misconfigured and faulty routers have been
+      responsible for widespread disruptions in the Internet.  The
+      legitimate BGP peers have the context and information to produce
+      believable, yet bogus, routing information, and therefore have the
+      opportunity to cause great damage.  The cryptographic protections
+      of [TCPMD5] and operational protections cannot exclude the bogus
+      information arising from a legitimate peer.  The risk of
+      disruptions caused by legitimate BGP speakers is real and cannot
+      be ignored.
+
+   PATHSEC is intended to address the concerns cited above, to provide
+   significantly improved path security, which builds upon the route
+   origination validation capability offered by use of the RPKI
+   [RFC6810].  Specifically, the RPKI enables relying parties (RPs) to
+   determine if the origin AS for a path was authorized to advertise the
+
+
+
+Kent & Chi                    Informational                     [Page 3]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   prefix contained in a BGP update message.  This security feature is
+   enabled by the use of two types of digitally signed data: a PKI
+   [RFC6487] that associates one or more prefixes with the public key(s)
+   of an address space holder, and Route Origin Authorizations (ROAs)
+   [RFC6482] that allow a prefix holder to specify one or more ASes that
+   are authorized to originate routes for a prefix.
+
+   The security model adopted for PATHSEC does not assume an "oracle"
+   that can see all of the BGP inputs and outputs associated with every
+   AS or every BGP router.  Instead, the model is based on a local
+   notion of what constitutes legitimate, authorized behavior by the BGP
+   routers associated with an AS.  This is an AS-centric model of secure
+   operation, consistent with the AS-centric model that BGP employs for
+   routing.  This model forms the basis for the discussion that follows.
+
+   This document begins with a brief set of definitions relevant to the
+   subsequent sections.  It then discusses classes of adversaries that
+   are perceived as viable threats against routing in the public
+   Internet.  It continues to explore a range of attacks that might be
+   effected by these adversaries against both path security and the
+   infrastructure upon which PATHSEC relies.  It concludes with a brief
+   review of residual vulnerabilities, i.e., vulnerabilities that are
+   not addressed by use of the RPKI and that appear likely to be outside
+   the scope of PATHSEC mechanisms.
+
+2.  Terminology
+
+   The following security and routing terminology definitions are
+   employed in this document.
+
+   Adversary:  An adversary is an entity (e.g., a person or an
+      organization) that is perceived as malicious, relative to the
+      security policy of a system.  The decision to characterize an
+      entity as an adversary is made by those responsible for the
+      security of a system.  Often, one describes classes of adversaries
+      with similar capabilities or motivations rather than specific
+      individuals or organizations.
+
+   Attack:  An attack is an action that attempts to violate the security
+      policy of a system, e.g., by exploiting a vulnerability.  There is
+      often a many-to-one mapping of attacks to vulnerabilities because
+      many different attacks may be used to exploit a vulnerability.
+
+   Autonomous System (AS):  An AS is a set of one or more IP networks
+      operated by a single administrative entity.
+
+   AS Number (ASN):  An ASN is a 2- or 4-byte number issued by a
+      registry to identify an AS in BGP.
+
+
+
+Kent & Chi                    Informational                     [Page 4]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   Certification Authority (CA):  An entity that issues digital
+      certificates (e.g., X.509 certificates) and vouches for the
+      binding between the data items in a certificate.
+
+   Countermeasure:  A countermeasure is a procedure or technique that
+      thwarts an attack, preventing it from being successful.  Often,
+      countermeasures are specific to attacks or classes of attacks.
+
+   Border Gateway Protocol (BGP):  A path vector protocol used to convey
+      "reachability" information among ASes in support of inter-domain
+      routing.
+
+   False (Route) Origination:  If a network operator originates a route
+      for a prefix that the operator does not hold (and that has not
+      been authorized to originate by the prefix holder), this is termed
+      false route origination.
+
+   Internet Service Provider (ISP):  An organization managing (and
+      typically selling) Internet services to other organizations or
+      individuals.
+
+   Internet Number Resources (INRs):  IPv4 or IPv6 address space and
+      ASNs.
+
+   Internet Registry:  An organization that manages the allocation or
+      distribution of INRs.  This encompasses the Internet Assigned
+      Number Authority (IANA), Regional Internet Registries (RIRs),
+      National Internet Registries (NIRs), and Local Internet Registries
+      (LIRs) (network operators).
+
+   Man in the Middle (MITM):  A MITM is an entity that is able to
+      examine and modify traffic between two (or more) parties on a
+      communication path.
+
+   Network Operator:  An entity that manages an AS and thus emits (E)BGP
+      updates, e.g., an ISP.
+
+   Network Operations Center (NOC):  A network operator employs a set of
+      equipment and a staff to manage a network, typically on a 24/7
+      basis.  The equipment and staff are often referred to as the NOC
+      for the network.
+
+   Prefix:  A prefix is an IP address and a mask used to specify a set
+      of addresses that are grouped together for purposes of routing.
+
+   Public Key Infrastructure (PKI):  A PKI is a collection of hardware,
+      software, people, policies, and procedures used to create, manage,
+      distribute, store, and revoke digital certificates.
+
+
+
+Kent & Chi                    Informational                     [Page 5]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   Relying Parties (RPs):  An RP is an entity that makes use of signed
+      products from a PKI, i.e., it relies on signed data that is
+      verified using certificates and Certificate Revocation Lists
+      (CRLs) from a PKI.
+
+   RPKI Repository System:  The RPKI repository system consists of a
+      distributed set of loosely synchronized databases.
+
+   Resource PKI (RPKI):  A PKI operated by the entities that manage INRs
+      and that issue X.509 certificates (and CRLs) that attest to the
+      holdings of INRs.
+
+   RPKI Signed Object:  An RPKI signed object is a data object
+      encapsulated with Cryptographic Message Syntax (CMS) that complies
+      with the format and semantics defined in [RFC6488].
+
+   Route:  In the Internet, a route is a prefix and an associated
+      sequence of ASNs that indicates a path via which traffic destined
+      for the prefix can be directed.  (The route includes the origin
+      AS.)
+
+   Route Leak:  A route leak is said to occur when AS-A advertises
+      routes that it has received from AS-B to the neighbors of AS-A,
+      but AS-A is not viewed as a transit provider for the prefixes in
+      the route.
+
+   Threat:  A threat is a motivated, capable adversary.  An adversary
+      that is not motivated to launch an attack is not a threat.  An
+      adversary that is motivated but not capable of launching an attack
+      also is not a threat.
+
+   Vulnerability:  A vulnerability is a flaw or weakness in a system's
+      design, implementation, or operation and management that could be
+      exploited to violate the security policy of a system.
+
+3.  Threat Characterization
+
+   As noted in Section 2 above, a threat is defined as a motivated,
+   capable adversary.  The following classes of threats represent
+   classes of adversaries viewed as relevant to this environment.
+
+      Network Operators: A network operator may be a threat.  An
+      operator may be motivated to cause BGP routers it controls to emit
+      update messages with inaccurate routing info, e.g., to cause
+      traffic to flow via paths that are economically advantageous for
+      the operator.  Such updates might cause traffic to flow via paths
+      that would otherwise be rejected as less advantageous by other
+      network operators.  Because an operator controls the BGP routers
+
+
+
+Kent & Chi                    Informational                     [Page 6]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+      in its network, it is in a position to modify their operation in
+      arbitrary ways.  Routers managed by a network operator are
+      vehicles for mounting MITM attacks on both control and data plane
+      traffic.  If an operator participates in the RPKI, it will have at
+      least one CA resource certificate and may be able to generate an
+      arbitrary number of subordinate CA certificates and ROAs.  It will
+      be authorized to populate (and may even host) its own repository
+      publication point.  If it implements PATHSEC, and if PATHSEC makes
+      use of certificates associated with routers or ASes, it will have
+      the ability to issue such certificates for itself.  If PATHSEC
+      digitally signs updates, it will be able to do so in a fashion
+      that will be accepted by PATHSEC-enabled neighbors.
+
+      Hackers: Hackers are considered a threat.  A hacker might assume
+      control of network management computers and routers controlled by
+      operators, including operators that implement PATHSEC.  In such
+      cases, hackers would be able to act as rogue network operators
+      (see above).  It is assumed that hackers generally do not have the
+      capability to effect MITM attacks on most links between networks
+      (links used to transmit BGP and subscriber traffic).  A hacker
+      might be recruited, without his/her knowledge, by criminals or by
+      nations, to act on their behalf.  Hackers may be motivated by a
+      desire for "bragging rights", for profit, or to express support
+      for a cause ("hacktivists" [Sam04]).  We view hackers as possibly
+      distinct from criminals in that the former are presumed to effect
+      attacks only remotely (not via a physical presence associated with
+      a target) and not necessarily for monetary gain.  Some hackers may
+      commit criminal acts (depending on the jurisdiction), and thus
+      there is a potential for overlap between this adversary group and
+      criminals.
+
+      Criminals: Criminals may be a threat.  Criminals might persuade
+      (via threats or extortion) a network operator to act as a rogue
+      operator (see above) and thus be able to effect a wide range of
+      attacks.  Criminals might persuade the staff of a
+      telecommunications provider to enable MITM attacks on links
+      between routers.  Motivations for criminals may include the
+      ability to extort money from network operators or network operator
+      clients, e.g., by adversely affecting routing for these network
+      operators or their clients.  Criminals also may wish to manipulate
+      routing to conceal the sources of spam, DoS attacks, or other
+      criminal activities.
+
+      Registries: Any registry in the RPKI could be a threat.  Staff at
+      the registry are capable of manipulating repository content or
+      mismanaging the RPKI certificates that they issue.  These actions
+      could adversely affect a network operator or a client of a network
+
+
+
+
+Kent & Chi                    Informational                     [Page 7]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+      operator.  The staff could be motivated to do this based on
+      political pressure from the nation in which the registry operates
+      (see below) or due to criminal influence (see above).
+
+      Nations: A nation may be a threat.  A nation may control one or
+      more network operators that operate in the nation, and thus can
+      cause them to act as rogue network operators.  A nation may have a
+      technical active wiretapping capability (e.g., within its
+      territory) that enables it to effect MITM attacks on inter-network
+      traffic.  (This capability may be facilitated by control or
+      influence over a telecommunications provider operating within the
+      nation.)  It may have an ability to attack and take control of
+      routers or management network computers of network operators in
+      other countries.  A nation may control a registry (e.g., an RIR)
+      that operates within its territory and might force that registry
+      to act in a rogue capacity.  National threat motivations include
+      the desire to control the flow of traffic to/from the nation or to
+      divert traffic destined for other nations (for passive or active
+      wiretapping, including DoS).
+
+4.  Attack Characterization
+
+   This section describes classes of attacks that may be effected
+   against Internet routing (relative to the context described in
+   Section 1).  Attacks are classified based on the target of the
+   attack, an element of the routing system, or the routing security
+   infrastructure on which PATHSEC relies.  In general, attacks of
+   interest are ones that attempt to violate the integrity or
+   authenticity of BGP traffic or that violate the authorizations
+   associated with entities participating in the RPKI.  Attacks that
+   violate the implied confidentiality of routing traffic, e.g., passive
+   wiretapping attacks, are not considered a requirement for BGP
+   security (see [RFC4272]).
+
+4.1.  Active Wiretapping of Sessions between Routers
+
+   An adversary may attack the BGP (TCP) session that connects a pair of
+   BGP speakers.  An active attack against a BGP (TCP) session can be
+   effected by directing traffic to a BGP speaker from some remote
+   point, or by being positioned as a MITM on the link that carries BGP
+   session traffic.  Remote attacks can be effected by any adversary.  A
+   MITM attack requires access to the link.  Modern transport networks
+   may be as complex as the packet networks that utilize them for inter-
+   AS links.  Thus, these transport networks may present significant
+   attack surfaces.  Nonetheless, only some classes of adversaries are
+   assumed to be capable of MITM attacks against a BGP session.  MITM
+   attacks may be directed against BGP and PATHSEC-protected BGP, or
+   against TCP or IP.  Such attacks include replay of selected BGP
+
+
+
+Kent & Chi                    Informational                     [Page 8]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   messages, selective modification of BGP messages, and DoS attacks
+   against BGP routers.  [RFC4272] describes several countermeasures for
+   such attacks, and thus this document does not further address such
+   attacks.
+
+4.2.  Attacks on a BGP Router
+
+   An adversary may attack a BGP router, whether or not it implements
+   PATHSEC.  Any adversary that controls routers legitimately, or that
+   can assume control of a router, is assumed to be able to effect the
+   types of attacks described below.  Note that any router behavior that
+   can be ascribed to a local routing policy decision is not considered
+   to be an attack.  This is because such behavior could be explained as
+   a result of local policy settings and thus is beyond the scope of
+   what PATHSEC can detect as unauthorized behavior.  Thus, for example,
+   a router may fail to propagate some or all route withdrawals or
+   effect "route leaks".  (These behaviors are not precluded by the
+   specification for BGP and might be the result of a local policy that
+   is not publicly disclosed.  As a result, they are not considered
+   attacks.  See Section 5 for additional discussion.)
+
+   Attacks on a router are equivalent to active wiretapping attacks (in
+   the most general sense) that manipulate (forge, tamper with, or
+   suppress) data contained in BGP updates.  The list below illustrates
+   attacks of this type.
+
+      AS Insertion: A router might insert one or more ASNs, other than
+      its own ASN, into an update message.  This violates the BGP spec
+      and thus is considered an attack.
+
+      False (Route) Origination: A router might originate a route for a
+      prefix when the AS that the router represents is not authorized to
+      originate routes for that prefix.  This is an attack, but it is
+      addressed by the use of the RPKI [RFC6480].
+
+      Secure Path Downgrade: A router might remove AS_PATH data from a
+      PATHSEC-protected update that it receives when forwarding this
+      update to a PATHSEC-enabled neighbor.  This behavior violates the
+      PATHSEC security goals and thus is considered an attack.
+
+      Invalid AS_PATH Data Insertion: A router might emit a PATHSEC-
+      protected update with "bad" data (such as a signature), i.e.,
+      PATHSEC data that cannot be validated by other PATHSEC routers.
+      Such behavior is assumed to violate the PATHSEC goals and thus is
+      considered an attack.
+
+
+
+
+
+
+Kent & Chi                    Informational                     [Page 9]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+      Stale Path Announcement: If PATHSEC-secured announcements can
+      expire, such an announcement may be propagated with PATHSEC data
+      that is "expired".  This behavior would violate the PATHSEC goals
+      and is considered a type of replay attack.
+
+      Premature Path Announcement Expiration: If a PATHSEC-secured
+      announcement has an associated expiration time, a router might
+      emit a PATHSEC-secured announcement with an expiry time that is
+      very short.  Unless the PATHSEC protocol specification mandates a
+      minimum expiry time, this is not an attack.  However, if such a
+      time is mandated, this behavior becomes an attack.  BGP speakers
+      along a path generally cannot determine if an expiry time is
+      "suspiciously short" since they cannot know how long a route may
+      have been held by an earlier AS, prior to being released.
+
+      MITM Attack: A cryptographic key used for point-to-point security
+      (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be
+      compromised (e.g., by extraction from a router).  This would
+      enable an adversary to effect MITM attacks on the link(s) where
+      the key is used.  Use of specific security mechanisms to protect
+      inter-router links between ASes is outside the scope of PATHSEC.
+
+      Compromised Router Private Key: If PATHSEC mechanisms employ
+      public key cryptography, e.g., to digitally sign data in an
+      update, then a private key associated with a router or an AS might
+      be compromised by an attack against the router.  An adversary with
+      access to this key would be able to generate updates that appear
+      to have passed through the AS that this router represents.  Such
+      updates might be injected on a link between the compromised router
+      and its neighbors if that link is accessible to the adversary.  If
+      the adversary controls another network, it could use this key to
+      forge signatures that appear to come from the AS or router(s) in
+      question, with some constraints.  So, for example, an adversary
+      that controls another AS could use a compromised router/AS key to
+      issue PATHSEC-signed data that includes the targeted router/AS.
+      (Neighbors of the adversary's AS ought not accept a route that
+      purports to emanate directly from the targeted AS.  So, an
+      adversary could take a legitimate, protected route that passes
+      through the compromised AS, add itself as the next hop, and then
+      forward the resulting route to neighbors.)
+
+      Withdrawal Suppression Attack: A PATHSEC-protected update may be
+      signed and announced, and later withdrawn.  An adversary
+      controlling intermediate routers could fail to propagate the
+      withdrawal.  BGP is already vulnerable to behavior of this sort,
+      so withdrawal suppression is not characterized as an attack under
+      the assumptions upon which this mode is based (i.e., no oracle).
+
+
+
+
+Kent & Chi                    Informational                    [Page 10]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+4.3.  Attacks on Network Operator Management Computers (Non-CA
+      Computers)
+
+   An adversary may choose to attack computers used by a network
+   operator to manage its network, especially its routers.  Such attacks
+   might be effected by an adversary who has compromised the security of
+   these computers.  This might be effected via remote attacks,
+   extortion of network operations staff, etc.  If an adversary
+   compromises NOC computers, he can execute any management function
+   that authorized network operations the staff would have performed.
+   Thus, the adversary could modify the local routing policy to change
+   preferences, to black-hole certain routes, etc.  This type of
+   behavior cannot be externally detected as an attack.  Externally,
+   this appears as a form of rogue operator behavior.  (Such behavior
+   might be perceived as accidental or malicious by other operators.)
+
+   If a network operator participates in the RPKI, an adversary could
+   manipulate the RP tools that extract data from the RPKI, causing the
+   output of these tools to be corrupted in various ways.  For example,
+   an attack of this sort could cause the operator to view valid routes
+   as not validated, which could alter its routing behavior.
+
+   If an adversary invoked the tool used to manage the repository
+   publication point for this operator, it could delete any objects
+   stored there (certificates, CRLs, manifests, ROAs, or subordinate CA
+   certificates).  This could affect the routing status of entities that
+   have allocations/assignments from this network operator (e.g., by
+   deleting their CA certificates).
+
+   An adversary could invoke the tool used to request certificate
+   revocation, causing router certificates, ROAs, or subordinate CA
+   certificates to be revoked.  An attack of this sort could affect not
+   only this operator but also any operators that receive allocations/
+   assignments from it, e.g., because their CA certificates were
+   revoked.
+
+   If an operator is PATHSEC-enabled, an attack of this sort could cause
+   the affected operator to be viewed as not PATHSEC-enabled, possibly
+   making routes it emits less preferable to other operators.
+
+   If an adversary invoked a tool used to request ROAs, it could
+   effectively reallocate some of the prefixes allocated/assigned to the
+   network operator (e.g., by modifying the origin AS in ROAs).  This
+   might cause other PATHSEC-enabled networks to view the affected
+   network as no longer originating routes for these prefixes.  Multi-
+   homed subscribers of this operator who received an allocation from
+   the operator might find that their traffic was routed via other
+   connections.
+
+
+
+Kent & Chi                    Informational                    [Page 11]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   If the network operator is PATHSEC-enabled, and makes use of
+   certificates associated with routers/ASes, an adversary could invoke
+   a tool used to request such certificates.  The adversary could then
+   replace valid certificates for routers/ASes with ones that might be
+   rejected by PATHSEC-enabled neighbors.
+
+4.4.  Attacks on a Repository Publication Point
+
+   A critical element of the RPKI is the repository system.  An
+   adversary might attack a repository, or a publication point within a
+   repository, to adversely affect routing.
+
+   This section considers only those attacks that can be launched by any
+   adversary who controls a computer hosting one or more repository
+   publication points, without access to the cryptographic keys needed
+   to generate valid RPKI-signed products.  Such attacks might be
+   effected by an insider or an external threat.  Because all repository
+   objects are digitally signed, attacks of this sort translate into DoS
+   attacks against the RPKI RPs.  There are a few distinct forms of such
+   attacks, as described below.
+
+   Note first that the RPKI calls for RPs to cache the data they acquire
+   and verify from the repository system [RFC6480][RFC6481].  Attacks
+   that delete signed products, insert products with "bad" signatures,
+   tamper with object signatures, or replace newer objects with older
+   (valid) ones, can be detected by RPs (with a few exceptions).  RPs
+   are expected to make use of local caches.  If repository publication
+   points are unavailable or the retrieved data is corrupted, an RP can
+   revert to using the cached data.  This behavior helps insulate RPs
+   from the immediate effects of DoS attacks on publication points.
+
+   Each RPKI data object has an associated date on which it expires or
+   is considered stale (certificates expire and CRLs become stale).
+   When an RP uses cached data, how to deal with stale or expired data
+   is a local decision.  It is common in PKIs to make use of stale
+   certificate revocation status data when fresher data is not
+   available.  Use of expired certificates is less common, although not
+   unknown.  Each RP will decide, locally, whether to continue to make
+   use of or ignore cached RPKI objects that are stale or expired.
+
+   If an adversary inserts an object into a publication point, and the
+   object has a "bad" signature, the object will not be accepted and
+   used by RPs.
+
+   If an adversary modifies any signed product at a publication point,
+   the signature on the product will fail, causing RPs to not accept it.
+   This is equivalent to deleting the object, in many respects.
+
+
+
+
+Kent & Chi                    Informational                    [Page 12]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   If an adversary deletes one or more CA certificates, ROAs, or the CRL
+   for a publication point, the manifest for that publication point will
+   allow an RP to detect this attack.  An RP can continue to use the
+   last valid instance of the deleted object (as a local policy option),
+   thus minimizing the impact of such an attack.
+
+   If an adversary deletes a manifest (and does not replace it with an
+   older instance), RPs are able to detect this action.  Such behavior
+   should result in the CA (or publication point maintainer) being
+   notified of the problem.  An RP can continue to use the last valid
+   instance of the deleted manifest (a local policy option), thus
+   minimizing the impact of such an attack.
+
+   If an adversary deletes newly added CA certificates or ROAs, and
+   replaces the current manifest with the previous manifest, the
+   manifest (and the CRL that it matches) will be "stale" (see
+   [RFC6486]).  This alerts an RP that there may be a problem.  The RP
+   should use the information from a Ghostbuster Record [RFC6493] to
+   contact the entity responsible for the publication point and request
+   a remedy to the problem (e.g., republish the missing CA certificates
+   and/or ROAs).  An RP cannot know the content of the new certificates
+   or ROAs that are not present, but it can continue to use what it has
+   cached.  An attack of this sort will, at least temporarily, cause RPs
+   to be unaware of the newly published objects.  INRs associated with
+   these objects will be treated as unauthenticated.
+
+   If a CA revokes a CA certificate or a ROA (via deleting the
+   corresponding End Entity (EE) certificate), and the adversary tries
+   to reinstate that CA certificate or ROA, the adversary would have to
+   rollback the CRL and the manifest to undo this action by the CA.  As
+   above, this would make the CRL and manifest stale, and this is
+   detectable by RPs.  An RP cannot know which CA certificates or ROAs
+   were deleted.  Depending on local policy, the RP might use the cached
+   instances of the affected objects and thus be tricked into making
+   decisions based on these revoked objects.  Here too, the goal is that
+   the CA will be notified of the problem (by RPs) and will remedy the
+   error.
+
+   In the attack scenarios above, when a CRL or manifest is described as
+   stale, this means that the next issue date for the CRL or manifest
+   has passed.  Until the next issue date, an RP will not detect the
+   attack.  Thus, it behooves CAs to select CRL/manifest lifetimes (the
+   two are linked) that represent an acceptable trade-off between risk
+   and operational burdens.
+
+   Attacks effected by adversaries that are legitimate managers of
+   publication points can have much greater effects and are discussed
+   below under attacks on or by CAs.
+
+
+
+Kent & Chi                    Informational                    [Page 13]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+4.5.  Attacks on an RPKI CA
+
+   Every entity to which INRs have been allocated/assigned is a CA in
+   the RPKI.  Each CA is nominally responsible for managing the
+   repository publication point for the set of signed products that it
+   generates.  (An INR holder may choose to outsource the operation of
+   the RPKI CA function and the associated publication point.  In such
+   cases, the organization operating on behalf of the INR holder becomes
+   the CA from an operational and security perspective.  The following
+   discussion does not distinguish such outsourced CA operations.)
+
+   Note that attacks attributable to a CA may be the result of malice by
+   the CA (i.e., the CA is the adversary), or they may result from a
+   compromise of the CA.
+
+   All of the adversaries listed in Section 2 are presumed to be capable
+   of launching attacks against the computers used to perform CA
+   functions.  Some adversaries might effect an attack on a CA by
+   violating personnel or physical security controls as well.  The
+   distinction between the CA as an adversary versus the CA as an attack
+   victim is important.  Only in the latter case should one expect the
+   CA to remedy problems caused by an attack once the attack has been
+   detected.  (If a CA does not take such action, the effects are the
+   same as if the CA is an adversary.)
+
+   Note that most of the attacks described below do not require
+   disclosure of a CA's private key to an adversary.  If the adversary
+   can gain control of the computer used to issue certificates, it can
+   effect these attacks, even though the private key for the CA remains
+   "secure" (i.e., not disclosed to unauthorized parties).  However, if
+   the CA is not the adversary, and if the CA's private key is not
+   compromised, then recovery from these attacks is much easier.  This
+   motivates use of hardware security modules to protect CA keys, at
+   least for higher tiers in the RPKI.
+
+   An attack by a CA can result in revocation or replacement of any of
+   the certificates that the CA has issued.  Revocation of a certificate
+   should cause RPs to delete the (formerly) valid certificate (and
+   associated signed object, in the case of a revoked EE certificate)
+   that they have cached.  This would cause repository objects (e.g., CA
+   certificates and ROAs) that are verified under that certificate to be
+   considered invalid, transitively.  As a result, RPs would not
+   consider any ROAs or PATHSEC-protected updates to be valid based on
+   these certificates, which would make routes dependent on them less
+   preferred.  Because a CA that revokes a certificate is authorized to
+   do so, this sort of attack cannot be detected, intrinsically, by most
+   RPs.  However, the entities affected by the revocation or replacement
+   of CA certificates can be expected to detect the attack and contact
+
+
+
+Kent & Chi                    Informational                    [Page 14]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   the CA to effect remediation.  If the CA was not the adversary, it
+   should be able to issue new certificates and restore the publication
+   point.
+
+   An adversary that controls the CA for a publication point can publish
+   signed products that create more subtle types of DoS attacks against
+   RPs.  For example, such an attacker could create subordinate CA
+   certificates with Subject Information Access (SIA) pointers that lead
+   RPs on a "wild goose chase" looking for additional publication points
+   and signed products.  An attacker could publish certificates with
+   very brief validity intervals or CRLs and manifests that become
+   "stale" very quickly.  This sort of attack would cause RPs to access
+   repositories more frequently, and that might interfere with
+   legitimate accesses by other RPs.
+
+   An attacker with this capability could create very large numbers of
+   ROAs to be processed (with prefixes that are consistent with the
+   allocation for the CA) and correspondingly large manifests.  An
+   attacker could create very deep subtrees with many ROAs per
+   publication point, etc.  All of these types of DoS attacks against
+   RPs are feasible within the syntactic and semantic constraints
+   established for RPKI certificates, CRLs, and signed objects.
+
+   An attack that results in revocation and replacement (e.g., key
+   rollover or certificate renewal) of a CA certificate would cause RPs
+   to replace the old, valid certificate with the new one.  This new
+   certificate might contain a public key that does not correspond to
+   the private key held by the certificate subject.  That would cause
+   objects signed by that subject to be rejected as invalid, and prevent
+   the affected subject from being able to sign new objects.  As above,
+   RPs would not consider any ROAs issued under the affected CA
+   certificate to be valid, and updates based on router certificates
+   issued by the affected CA would be rejected.  This would make routes
+   dependent on these signed products less preferred.  However, the
+   constraints imposed by the use of extensions detailed in [RFC3779]
+   prevent a compromised CA from issuing (valid) certificates with INRs
+   outside the scope of the CA, thus limiting the impact of the attack.
+
+   An adversary that controls a CA could issue CA certificates with
+   overlapping INRs to different entities when no transfer of INRs is
+   intended.  This could cause confusion for RPs as conflicting ROAs
+   could be issued by the distinct (subordinate) CAs.
+
+   An adversary could replace a CA certificate, use the corresponding
+   private key to issue new signed products, and then publish them at a
+   publication point controlled by the attacker.  This would effectively
+   transfer the affected INRs to the adversary or to a third party of
+   his choosing.  The result would be to cause RPs to view the entity
+
+
+
+Kent & Chi                    Informational                    [Page 15]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   that controls the private key in question as the legitimate INR
+   holder.  Again, the constraints imposed by the use of the extensions
+   in RFC 3779 prevent a compromised CA from issuing (valid)
+   certificates with INRs outside the scope of the CA, thus limiting the
+   impact of the attack.
+
+   Finally, an entity that manages a repository publication point can
+   inadvertently act as an attacker (an example of Walt Kelly's most
+   famous "Pogo" quote [Kelly70]).  For example, a CA might fail to
+   replace its own certificate in a timely fashion (well before it
+   expires).  It might fail to issue its CRL and manifest prior to
+   expiration, creating stale instances of these products that cause
+   concern for RPs.  A CA with many subordinate CAs (e.g., an RIR or
+   NIR) might fail to distribute the expiration times for the CA
+   certificates that it issues.  A network with many ROAs might do the
+   same for the EE certificates associated with the ROAs it generates.
+   A CA could rollover its key but fail to reissue subordinate CA
+   certificates under its new key.  Poor planning with regard to rekey
+   intervals for managed CAs could impose undue burdens for RPs, despite
+   a lack of malicious intent.  All of these examples of mismanagement
+   could adversely affect RPs, despite the absence of malicious intent.
+
+5.  Residual Vulnerabilities
+
+   The RPKI, upon which PATHSEC relies, has several residual
+   vulnerabilities that were discussed in the preceding text (Sections
+   4.4 and 4.5).  These vulnerabilities are of two principle forms:
+
+   o  The RPKI repository system may be attacked in ways that make its
+      contents unavailable, not current, or inconsistent.  The principle
+      defense against most forms of DoS attacks is the use of a local
+      cache by each RP.  The local cache ensures availability of
+      previously acquired RPKI data in the event that a repository is
+      inaccessible or if the repository contents are deleted
+      (maliciously).  Nonetheless, the system cannot ensure that every
+      RP will always have access to up-to-date RPKI data.  An RP, when
+      it detects a problem with acquired repository data, has two
+      options:
+
+      1.  The RP may choose to make use of its local cache, employing
+          local configuration settings that tolerate expired or stale
+          objects.  (Such behavior is, nominally, always within the
+          purview of an RP in PKI.)  Using cached, expired, or stale
+          data subjects the RP to attacks that take advantage of the
+          RP's ignorance of changes to this data.
+
+
+
+
+
+
+Kent & Chi                    Informational                    [Page 16]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+      2.  The RP may chose to purge expired objects.  Purging expired
+          objects removes the security information associated with the
+          real-world INRs to which the objects refer.  This is
+          equivalent to the affected INRs not having been afforded
+          protection via the RPKI.  Since use of the RPKI (and PATHSEC)
+          is voluntary, there may always be a set of INRs that are not
+          protected by these mechanisms.  Thus, purging moves the
+          affected INRs to the set of non-participating INR holders.
+          This more conservative response enables an attacker to move
+          INRs from the protected set to the unprotected set.
+
+   o  Any CA in the RPKI may misbehave within the bounds of the INRs
+      allocated to it, e.g., it may issue certificates with duplicate
+      resource allocations or revoke certificates inappropriately.  This
+      vulnerability is intrinsic in any PKI, but its impact is limited
+      in the RPKI because of the use of extensions in RFC 3779.  It is
+      anticipated that RPs will deal with such misbehavior through
+      administrative means once it is detected.
+
+   PATHSEC has a separate set of residual vulnerabilities:
+
+   o  It has been stated that "route leaks" are viewed as a routing
+      security problem by many operators.  However, BGP itself does not
+      include semantics that preclude what many perceive as route leaks,
+      and there is no definition of the term in any RFC.  This makes it
+      inappropriate to address route leaks in this document.
+      Additionally, route leaks are outside the scope of PATHSEC,
+      consistent with the security context noted in Section 1 of this
+      document.  If, at a later time, the SIDR security context is
+      revised to include route leaks, and an appropriate definition
+      exists, this document should be revised.
+
+   o  PATHSEC is not required to protect all attributes associated with
+      an AS_PATH, even though some of these attributes may be employed
+      as inputs to routing decisions.  Thus, attacks that modify (or
+      strip) these other attributes are not prevented/detected by
+      PATHSEC.  As noted in Section 1, the SIDR security context calls
+      for protecting only the information needed to verify that a
+      received route traversed the ASes in question, and that the NLRI
+      in the route is what was advertised.  (The AS_PATH data also may
+      have traversed ASes within a confederation that are not
+      represented.  However, these ASes are not externally visible and
+      thus do not influence route selection, so their omission in this
+      context is not a security concern.)  Thus, protection of other
+      attributes is outside the scope of this document, as described in
+      Section 1.  If, at a later time, the SIDR security context is
+      revised to include protection of additional BGP attributes, this
+      document should be revised.
+
+
+
+Kent & Chi                    Informational                    [Page 17]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   o  PATHSEC cannot ensure that an AS will withdraw a route when the AS
+      no longer has a route for a prefix, as noted in Section 4.2.
+      PATHSEC may incorporate features to limit the lifetime of an
+      advertisement.  Such lifetime limits provide an upper bound on the
+      time that the failure to withdraw a route will remain effective.
+
+6.  Security Considerations
+
+   A threat model is, by definition, a security-centric document.
+   Unlike a protocol description, a threat model does not create
+   security problems nor does it purport to address security problems.
+   This model postulates a set of threats (i.e., motivated, capable
+   adversaries) and examines classes of attacks that these threats are
+   capable of effecting, based on the motivations ascribed to the
+   threats.  It describes the impact of these types of attacks on
+   PATHSEC, including the RPKI on which PATHSEC relies.  It describes
+   how the design of the RPKI (and the PATHSEC design goals) address
+   classes of attacks, where applicable.  It also notes residual
+   vulnerabilities.
+
+7.  Acknowledgements
+
+   The authors with to thank the members of the SIDR working group for
+   the extensive feedback provided during the development of this
+   document.
+
+8.  Informative References
+
+   [Kelly70]  Kelly, W., "We Have Met The Enemy and He Is Us: Pogo Earth
+              Day Poster", April 1970.
+
+   [Kent2000]
+              Kent, S., Lynn, C., and K. Seo, "Design and Analysis of
+              the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX
+              Conference, June 2000.
+
+   [RFC3779]  Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+              Addresses and AS Identifiers", RFC 3779, June 2004.
+
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
+              4272, January 2006.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+
+
+
+Kent & Chi                    Informational                    [Page 18]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, June 2010.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, February 2012.
+
+   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
+              Resource Certificate Repository Structure", RFC 6481,
+              February 2012.
+
+   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+              Origin Authorizations (ROAs)", RFC 6482, February 2012.
+
+   [RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
+              "Manifests for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6486, February 2012.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487, February
+              2012.
+
+   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
+              Template for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6488, February 2012.
+
+   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
+              Ghostbusters Record", RFC 6493, February 2012.
+
+   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
+              Infrastructure (RPKI) to Router Protocol", RFC 6810,
+              January 2013.
+
+   [SIDR-CH]  "Secure Inter-Domain Routing: Charter for Working Group",
+              September 2013, <http://tools.ietf.org/wg/sidr/
+              charters?item=charter-sidr-2013-09-20.txt>.
+
+   [Sam04]    Samuel, A., "Hacktivism and the Future of Political
+              Participation", Ph.D. dissertation, Harvard University,
+              September 2004, <http://www.alexandrasamuel.com/
+              dissertation/pdfs/Samuel-Hacktivism-entire.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+Kent & Chi                    Informational                    [Page 19]
+
+RFC 7132           Threat Model for BGP Path Security      February 2014
+
+
+Authors' Addresses
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton St.
+   Cambridge, MA  02138
+   USA
+
+   EMail: kent@bbn.com
+
+
+   Andrew Chi
+   University of North Carolina - Chapel Hill
+   c/o Department of Computer Science
+   CB 3175, Sitterson Hall
+   Chapel Hill, NC  27599
+   USA
+
+   EMail: achi@cs.unc.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Chi                    Informational                    [Page 20]
+