[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kent-bgpsec-threats) 00 01 02 03 04 05 06 07 08 09 RFC 7132

Secure Inter-Domain Routing                                      S. Kent
Internet-Draft                                                       BBN
Intended status: Standards Track
Expires: December 24, 2011
                                                           June 24, 2011


                  Threat Model for BGP Path Security
                 draft-ietf-sidr-bgpsec-threats-00.txt

Abstract

   This document describes a threat model for BGP path security
   (BGPSEC). BGPSEC is assumed to make use of the Resource Public Key
   Infrastructure (RPKI) already developed in the SIDR WG [I-D.ietf-
   sidr-arch], and thus threats and attacks against the RPKI are part of
   this model. The model assumes that BGP path security is achieved
   through the application of digital signatures to AS_Path Info. The
   document characterizes classes of potential adversaries that are
   considered to be threats, and examines classes of attacks that might
   be launched against BGPSEC. It concludes with brief discussion of
   residual vulnerabilities.

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 http://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 December 24, 2011.

Copyright Notice

   Copyright (c) 2011 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



Kent                     Expires December 24, 2011              [Page 1]

Internet-Draft               BGPSEC Threats                    June 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Threat Characterization  . . . . . . . . . . . . . . . . . . .  4
   4.  Attack Characterization  . . . . . . . . . . . . . . . . . . .  5
     4.1. Active wiretapping of links between routers . . . . . . . .  5
     4.2. Attacks on a BGP router . . . . . . . . . . . . . . . . . .  5
     4.3. Attacks on ISP management computers  (non-CA computers) . .  7
     4.4. Attacks on a repository publication point . . . . . . . . .  7
     4.5 Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . .   8
   5.  Residual Vulnerabilities . . . . . . . . . . . . . . . . . .  . 7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
























Kent                     Expires December 24, 2011              [Page 2]

Internet-Draft               BGPSEC Threats                    June 2011


1.  Introduction

   This document describes the security context in which BGPSEC is
   intended to operate. It discusses classes of potential adversaries
   that are considered to be threats, and classes of attacks that might
   be launched against BGPSEC. Because BGPSEC depends on the Resource
   Public Key Infrastructure (RPKI), threats and attacks against the
   RPKI also are discussed.

   The motivation for developing BGPSEC, 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 papers note that BGP does not include mechanisms that
   allow an Autonomous System (AS) to verify the legitimacy and
   authenticity of BGP route advertisements. (BGP now mandates support
   for mechanisms to secure peer-peer communication, i.e., for the links
   that connect BGP routers. There are several secure protocol options
   to addresses this security concern, e.g., IPsec [RFC4301] and 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 are addressed by BGPSEC.)

   RFC 4272 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.

   BGPSEC is intended to address the concerns cited above, to provide
   significantly improved path security, and to build upon the secure
   route origination foundation offered by use of the RPKI.
   Specifically, the RPKI enables relying parties (RPs) to determine of
   the origin AS for a path was authorized to advertise the prefix
   contained in a BGP update message. This security feature is enabled
   by the use of two types of digitally signed data: a PKI [I-D.sidr-
   res-certs] that associates one or more prefixes with the public
   key(s) of an address space holder, and Route Origination
   Authorizations (ROAs) [I-D.roa-format] that allows a prefix holder to



Kent                     Expires December 24, 2011              [Page 3]

Internet-Draft               BGPSEC Threats                    June 2011


   specify the AS(es) that are authorized to originate routes for a
   prefix.


   The security model adopted for BGPSEC 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 BGPSEC relies. It concludes with a brief
   review of residual vulnerabilities.


2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   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) 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 -  An AS is a set of one or more IP networks
   operated by a single administrative entity.

   AS Number (ANS) - An ASN is a 2 or 4 byte number issued by a registry
   to identify an AS in BGP.




Kent                     Expires December 24, 2011              [Page 4]

Internet-Draft               BGPSEC Threats                    June 2011


   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 autonomous systems, in support of
   inter-domain routing.

   False (Route) Origination - If an ISP originates a route for a prefix
   that the ISP does not hold (and that it 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,
   ISPs).

   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

   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.

   Relying Parties (RPs) - An RP is an entity that makes use of signed
   products from a PKI, i.e., relies on signed data that is verified
   using certificates, and CRLs from a PKI.

   RPKI Repository System - The RPKI repository system consists of a
   distributed set of loosely synchronized databases




Kent                     Expires December 24, 2011              [Page 5]

Internet-Draft               BGPSEC Threats                    June 2011


   Resource PKI (RPKI) - A PKI operated by the entities that manage
   INRs, and that issues X509 certificates (and CRLs) that attest to the
   holdings of INRs.

   RPKI Signed Object - An RPKI signed object is a Cryptographic Message
   Syntax (CMS)-encapsulated data object complying with the format and
   semantics defined in [draft-ietf-sidr-signed-object-02.txt].

   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.

   Route leak - A route leak is said to occur when AS-A advertises
   routes that it has received from an AS-B to AS-A's neighbors, 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.



























Kent                     Expires December 24, 2011              [Page 6]

Internet-Draft               BGPSEC Threats                    June 2011


3. Threat Characterization

   The following classes of threats are addressed in this document.

   BGP speakers - A BGP speaker, e.g., an ISP or a multi-homed non-ISP
   subscriber, may be a threat. (For simplicity, the remainder of this
   document refers to BGP speakers as ISPs.) An ISP may be motivated to
   cause BGP routers controlled by the ISP to emit update messages with
   inaccurate routing info. Such updates might cause traffic to flow via
   paths that would otherwise be rejected as less advantageous by other
   ISPs. Because the ISP controls the BGP routers that it operates, it
   is in a position to modify their operation. Routers operated by the
   ISP are vehicles for mounting MITM attacks on both control and data
   plane traffic. If the ISP participates in the RPKI, it will have at
   least 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 BGPSEC, it will have the ability
   to issue certificates for its routers, and to sign updates in a
   fashion that will be recognized by BGPSEC-enabled ISP neighbors.

   Hackers - Hackers are considered a threat. Hackers might assume
   control of network management computers and routers operated by ISPs,
   including ISPs that implement BGPSEC. In such cases, hackers would be
   able to act as a rogue ISP (see above). It is assumed that hackers
   generally do not have the capability to effect MITM attacks on most
   links between ISPs. Hackers might be recruited, without their
   knowledge, by criminals or by nations, to act on their behalf.

   Criminals - Criminals may be a threat. Criminals might persuade (via
   threats or extortion) an ISP to act as rogue ISP (see above), and
   thus be able to effect a wide range of attacks. Criminals might
   persuade telecom staff to enable MITM attacks on links between
   routers. The motivation for criminals may include the ability to
   extort money from other ISPs or ISP clients, e.g., by adversely
   affecting routing for these ISPs or clients. They may wish to
   manipulate routing to conceal the sources of spam or of DoS attacks.

   Registries - Any registry in the RPKI could be a threat. Staff at the
   registry are capable of manipulating repository content or
   mismanaging RPKI certificates. These actions could adversely affect
   the operation of an ISP or a client of an ISP. The staff could be
   motivated to do this based on political pressure from the nation in
   which it operates (see below).

   Nations - A nation may be a threat. A nation may control one or more
   ISPs that operate in the nation, and thus can cause them to act as
   rogue ISPs. A nation may have a technical active wiretapping



Kent                     Expires December 24, 2011              [Page 7]

Internet-Draft               BGPSEC Threats                    June 2011


   capability (e.g., within its territory) that enables it to effect
   MITM attacks on inter-ISP traffic. It may have an ability to attack
   and take control of routers or management network computers of ISPs
   in other countries. A nation may control a registry that operates
   within its territory, and might force the registry to act as 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).
   A manifest associated with a CA's repository publication point
   contains a list of:

4. Attacks

   This section describes classes of attacks that may be effected
   against Internet routing. Attacks are classified based on the target
   of the attack, as an element of the routing system, or the routing
   security infrastructure on which BGPSEC relies. In general, attacks
   of interest are ones that attempt to violate the integrity or
   authenticity of BGP traffic, or which violate the authorizations
   associated with entities participating in the RPKI. Attacks that
   violate the implied confidentiality of routing traffic are not
   considered significant (see 4.1 below).

4.1. Active wiretapping of links between routers

   An adversary may attack the links that connect BGP routers. Passive
   attacks are not considered, because it is assumed that most of the
   info carried by BGP will otherwise be accessible to adversaries.
   Several classes of adversaries are assumed to be capable of MITM
   effecting attacks against the control plane traffic. MITM attacks may
   be directed against BGP, BGPSEC, or against TCP or IP. Such attacks
   include replay of selected BGP messages, selective modification of
   BGP messages, and DoS attacks against BGP routers.


4.2. Attacks on a BGP router

   An adversary may attack a BGP router, whether it implements BGPSEC or
   not. 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
   BGPSEC 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



Kent                     Expires December 24, 2011              [Page 8]

Internet-Draft               BGPSEC Threats                    June 2011


   is not publicly disclosed. As a result, they are not considered
   attacks.)

        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.

        Secure Path Downgrade: A router might remove signatures from a
        BGPSEC update that it receives, when forwarding this update to a
        BGPSEC-enabled neighbor. This behavior violates the BGPSEC spec
        and thus is considered an attack.

        Invalid Signature Insertion: A router might emit a signed update
        with a "bad" signature, i.e., a signature that cannot be
        validated by other BGPSEC routers. (This might occur due to use
        of a revoked or expired certificate, a computational error, or a
        syntactic error.) This behavior violates the BGPSEC spec and
        thus is considered an attack.

        Stale Path Announcement: An announcement may be propagated with
        an origination signature segment expiry value that is not
        current. This behavior violates the BGPSEC spec and is
        considered a possible replay attack.

        Premature Path Announcement Expiration: A router might emit a
        signed update with an origin expiry time that is very short. The
        BGPSEC protocol specification does not mandate a minimum expiry
        time. However, an immediate neighbor of a route originator
        should expect to see an expiry time that not substantially less
        than XX in the future. Later routers along a path generally
        cannot determine if a shorter expiry time is "suspicious" since
        they cannot know how long a route may have been held by an
        earlier AS, prior to being released. Thus this consideration
        applies only to an immediate neighbor of a route originator.

        MITM Attack: A cryptographic key used for point-to-point
        security (e.g., TCP-AO 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.

        Compromised Private Key: The private key associated with an RPKI
        EE certificate issued to a router might be compromised by an



Kent                     Expires December 24, 2011              [Page 9]

Internet-Draft               BGPSEC Threats                    June 2011


        attack against the router. An adversary with access to this key
        would be able to generate updates that appear to be from this
        router (or from any routers that share this key and
        certificate). If the adversary controlled another ISP, it could
        use this key to forge signatures that appear to come from the
        router(s) in question, thus making it appear that those routers
        were misbehaving.

        Replay Attack: An update may be signed and announced, and later
        withdrawn. The adversary controlling intermediate routers does
        not propagate the withdrawal but instead re-announces (i.e.,
        replays) the previous announcement within its expiry time if it
        has not yet expired.

4.3. Attacks on ISP management computers (non-CA computers)

   An adversary may choose to attack computers used by an ISP to manage
   its network, especially its routers. Such attacks might be effected
   by an adversary that has compromised the security of these computers.
   This might be effected via remote attacks, extortion of selected ISP
   staff, etc. If an adversary compromises NOC computers, it can execute
   any management function that authorized ISP staff would have
   performed. Thus the adversary could modify local routing policy to
   change preferences, to black-hole certain routes, etc. This type of
   behavior cannot be externally detected as an attack.

   If the ISP participates in the RPKI, the 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 ISP to view valid routes as not
   validated, which could alter its routing behavior.

   If the adversary invoked the tool used to manage the repository
   publication point for this ISP, 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 ISP (e.g., by deleting their
   CA certificates).

   An attacker 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 ISP, but also any ISPs that receive allocations/assignments
   from it, e.g., because their CA certificates were revoked.

   It the ISP is BGPSEC-enabled, an attack of this sort could cause the
   affected ISP to be viewed as not BGPSEC-enabled, possibly making
   routes it emits be less preferred.



Kent                     Expires December 24, 2011             [Page 10]

Internet-Draft               BGPSEC Threats                    June 2011


   If an adversary invoked a tool used to request ROAs, it could
   effectively re-allocate some of the prefixes allocated/assigned to
   the ISP (e.g., by modifying the origin AS in ROAs). This might cause
   other BGPSEC-enabled ISPs, and other RPKI-enabled ISPs, to view the
   ISP as no longer originating routes for these prefixes. Multi-homed
   subscribers of this ISP who received a PA allocation from the ISP
   might find their traffic was now routed via other connections.

   If the ISP is BGPSEC-enabled, and the adversary invoked a tool used
   to request certificates, it could replace valid certificates for
   routers with ones that might be rejected by BGPSEC-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 inside 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. Attacks that delete signed
   products, that insert products with "bad" signatures, that tamper
   with object signatures, or that replace newer objects with older
   (valid) ones, can be detected by RPs (with a few exceptions). RPs are
   expected to make use of the cached repository data until attacks that
   violate the integrity of publication points (and which are detected)
   are resolved. Thus the impact of such attacks is mitigated in part by
   the design of the repository system.

   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, and cause RPs to not accept
   it. This is equivalent to deleting the object, on many respects.

   If an adversary deletes one or more CA certificates, ROAs or the CA's



Kent                     Expires December 24, 2011             [Page 11]

Internet-Draft               BGPSEC Threats                    June 2011


   CRL at a publication point, the manifest for that publication point
   will allow an RP to detect this attack. (The RP would be very unhappy
   if there is no CRL for the CA instance anyway.) 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), that is detectable by an RP, and should result in
   the CA being notified of the problem. 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 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 [ietf-
   sidr-manifest]). This alerts an RP that there may be a problem, and,
   hopefully, the CA responsible for the publication point will be asked
   to remedy the problem (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.

   If a CA revokes a CA certificate or a ROA (via deleting the
   corresponding 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, and so
   it would use the cached instances of the affected objects. Here too
   one hopes that the CA will be notified of the problem and will
   attempt to 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 be detect the
   attack. Thus it behooves CAs to select CRL/manifest lifetimes (the
   two are linked) that represent an acceptable tradeoff 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.


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



Kent                     Expires December 24, 2011             [Page 12]

Internet-Draft               BGPSEC Threats                    June 2011


   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 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 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 CA as adversary vs. CA as an attack victim is important. Only
   in the latter case should one expect the CA to remedy problems caused
   by a attack once the attack has been detected. 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 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
   as valid any ROAs or signed updates based on these certificates,
   which would make routes dependent on them to be 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 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



Kent                     Expires December 24, 2011             [Page 13]

Internet-Draft               BGPSEC Threats                    June 2011


   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 have 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 as valid any ROAs issued under the affected CA
   certificate, and updates based on router certificates issued by the
   affected CA would be rejected. This would make routes dependent on
   these signed products to be less preferred. However, the constraints
   imposed by the use of RFC 3779 [RFC3779] extensions do 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 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
   that controls the private key in question as the legitimate INR
   holder. Again the constraints imposed by the use of RFC 3779
   extensions do 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 (as first noted by Pogo). For
   example, a CA might fail to replace its own certificate in a timely



Kent                     Expires December 24, 2011             [Page 14]

Internet-Draft               BGPSEC Threats                    June 2011


   fashion (well before it expires). If 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. An ISP 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 example of
   mismanagement could adversely affect RPs, despite the absence of
   malicious intent.


   5. Residual Vulnerabilities

   The RPKI, upon which BGPSEC relies, has several residual
   vulnerabilities that were been discussed in the preceding text
   (Sections 4.4 and 4.5). These vulnerabilities are of two principle
   forms:

        - the RPKI repository system may be attacked in ways that make
        its contents unavailable, or not current. It is anticipated that
        RPs will cope with this vulnerability through local caching of
        repository data, and through local settings that tolerate
        expired or stale repository data.

        - any CA in the RPKI may misbehave within the bounds of the
        resources allocated to it, e.g., it may issue certificates with
        duplicate resource allocations or revoke certificates
        inappropriately. This vulnerability is intrinsic in any PKI. It
        is anticipated that RPs will deal with this through


    BGPSEC has a separate set of residual vulnerabilities:

        - BGPSEC is not able to prevent what is usually referred to as
        route leaks, because BGP itself does not distinguish between
        transit and non-transit ASes- BGPSEC signatures do not protect
        all attributes associated with an AS_path. Some of these
        attributes are employed as inputs to routing decisions. Thus
        attacks that modify (or strip) these other attributes are not
        detected by BGPSEC.

6.  Security Considerations

   A threat model is, by definition, a security-centric document. Unlike
   a protocol description, a threat model does not create security



Kent                     Expires December 24, 2011             [Page 15]

Internet-Draft               BGPSEC Threats                    June 2011


   problems nor 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 BGPSEC, including
   on the RPKI on which BGPSEC relies.


7.  IANA Considerations

   [Note to IANA, to be removed prior to publication: there are no IANA
   considerations stated in this version of the document.]


8.  Acknowledgements

   The author wishes to thank . . .


9.  References

9.1.  Normative References


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



9.2.  Informative References

   [RFC4272]
       Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272,
       June 2006

   [RFC4301]
       Kent, S. and Seo, K., "Security Architecture for the Internet
       Protocol", RFC 4301, December, 2005.

   [RFC3779]
       Lynn, C., Kent, S., Seo, K., X.509 Extensions for IP Addresses
       and AS Identifiers, RFC 3779, June 2004.

   [Kent2000]
       Kent, S., Lynn, C., and Seo, K., "Design and Analysis of the
       Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX Conference,
       June, 2000.




Kent                     Expires December 24, 2011             [Page 16]

Internet-Draft               BGPSEC Threats                    June 2011


   [RFC5925]
       Touch, J., et al., "The TCP Authentication Option",
       RFC 5925, June 2010.

   [I-D.ietf-sidr-arch]
       Lepinski, M. and S. Kent, "An Infrastructure to Support
       Secure Internet Routing", draft-ietf-sidr-arch-11.txt
       (work in progress), September 2010.

   [I-D.sidr.signed-object]
       Lepinski, M, Chi, A., and Kent, S., "Signed Object Template for
       the Resource Public Key Infrastructure", draft-ietf-sidr-signed-
       object-01.txt, (work in progress), December 2010.

   [I-D.sidr-res-certs]
       Huston, G., Michaelson, G., and Loomans, R. "A Profile for X.509
       PKIX Resource Certificates", draft-ietf-sidr-res-certs-21.txt
       (work in progress), December 2010.

   [I-D.roa-format]
       Lepinski, M., Kent, S., and Kong, D., "A Profile for Route Origin
       Authorizations (ROAs)", draft-ietf-sidr-roa-format-09.txt,
       (work in progress), November 2010.




























Kent                     Expires December 24, 2011             [Page 17]

Internet-Draft               BGPSEC Threats                    June 2011


   Author's Address

   Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA  02138 USA

   Email: kent@bbn.com














































Kent                     Expires December 24, 2011                     [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/