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




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.

このドキュメントでは、外部ボーダーゲートウェイプロトコル(EBGP)パスセキュリティメカニズムが開発されるコンテキストの脅威モデルについて説明します。脅威モデルには、リソース公開鍵インフラストラクチャ(RPKI)の分析が含まれ、自律システム(AS)がBGP更新で受信したASパス情報の信頼性を検証する機能に焦点を当てています。 「PATHSEC」という用語は、RPKIを利用するすべてのBGPパスセキュリティ技術を指すために使用します。 PATHSECは、RPKIのAS間セキュリティに重点を置いたBGPを保護します。

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.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
1. はじめに

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.

このドキュメントでは、PATHSECが動作することを目的としたセキュリティコンテキストについて説明します。 「パスセキュリティ」という用語は(パスセキュリティの場合)、BGP更新メッセージ[RFC4271]で伝達されるAS_PATH属性の整合性と信頼性を維持するために使用される設計を指します。このドキュメント全体で使用されるセキュリティコンテキストは、Secure Inter-Domain Routing(SIDR)ワーキンググループチャーター[SIDR-CH]によって確立されています。憲章では、PATHSECを提供するソリューションがResource Public Key Infrastructure(RPKI)[RFC6480]を利用することを要求しています。また、受信したルートが問題の自律システム(AS)を通過したこと、およびルート内のネットワーク層到達可能性情報(NLRI)がアドバタイズされたものであることを確認するために必要な情報のみを保護することも求めています。

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.)

したがって、PATHSECの目的は、BGPスピーカーがこのパス属性に列挙されたASがNLRIが通過したASのシーケンスを表していることを確認できるようにすることです。したがって、「PATHSEC」という用語は、上記の目標と一致しています。 (他のSIDRドキュメントでは、特定の設計を指すために「BGPSEC」という用語を使用しています。ここではその用語の使用を避けています。)

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).

このドキュメントでは、脅威と見なされる潜在的な敵のクラスと、PATHSECに対して起動される可能性のある攻撃のクラスについて説明します。 PATHSECはRPKIに依存するため、RPKIに対する脅威と攻撃が含まれます。このモデルでは、PATHSECの使用によって有効になる攻撃のクラスも考慮されます(たとえば、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.)

PATHSECを開発する動機、つまりBGPの残留セキュリティ問題は、「BGPセキュリティ脆弱性分析」[RFC4272]や「セキュアボーダーゲートウェイプロトコル(S-BGP)の設計と分析」[Kent2000 ]。これらのドキュメントはすべて、BGPには、ASがBGPルートアドバタイズメントの正当性と信頼性を検証できるメカニズムが含まれていないことに注意しています。 (BGPは現在、ピアツーピア通信を保護するメカニズム、つまりBGPルーターを接続するリンクのサポートを義務付けています。このセキュリティ問題に対処するために、IPsec [RFC4301]やTCP認証オプション(TCP -AO)[RFC5925]。このドキュメントでは、BGPセキュリティのこの側面に対処する必要性について簡単に説明しますが、PATHSECで対処する必要があるアプリケーションレイヤーのBGPセキュリティ問題に焦点を当てています。

RFC 4272 [RFC4272] succinctly notes:

RFC 4272 [RFC4272]は簡潔に次のように述べています:

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.

BGPスピーカー自体は、他の正当なBGPスピーカーになりすまして、または無許可のルーティング情報を自分自身に配布することにより、偽のルーティング情報を注入できます。歴史的に、誤って設定された欠陥のあるルーターは、インターネットの広範囲にわたる混乱の原因でした。正当なBGPピアには、信頼できる偽のルーティング情報を生成するためのコンテキストと情報があるため、大きな損害を与える可能性があります。 [TCPMD5]の暗号保護と運用保護は、正当なピアから発生する偽の情報を除外することはできません。正当なBGPスピーカーによって引き起こされる混乱のリスクは現実のものであり、無視することはできません。

   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
   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
2. 用語

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.


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.

Man in the Middle(MITM):MITMは、通信パス上の2つ(またはそれ以上)のパーティ間のトラフィックを検査および変更できるエンティティです。

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.

公開鍵基盤(PKI):AN PKIは、デジタル証明書の作成、管理、配布、保存、および失効に使用されるハードウェア、ソフトウェア、人物、ポリシー、および手順の集まりです。

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.)

ルート:インターネットでは、ルートはプレフィックスであり、プレフィックスに向かうトラフィックを転送できるパスを示すASNの関連シーケンスです。 (ルートには発信元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
3. 脅威の特徴付け

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

ネットワークオペレーター:ネットワークオペレーターは脅威となる可能性があります。オペレーターは、それが制御するBGPルーターに不正確なルーティング情報を含む更新メッセージを送信させ、例えば、オペレーターにとって経済的に有利なパスを経由してトラフィックを流そうとする動機を持っている場合があります。このような更新により、他のネットワークオペレーターによる利点が少ないとして拒否されるパスを介してトラフィックが流れる可能性があります。オペレーターはネットワーク内のBGPルーターを制御するため、任意の方法で操作を変更することができます。ネットワークオペレーターが管理するルーターは、コントロールプレーントラフィックとデータプレーントラフィックの両方にMITM攻撃を仕掛ける手段です。オペレーターがRPKIに参加する場合、オペレーターには少なくとも1つのCAリソース証明書があり、任意の数の下位CA証明書とROAを生成できる場合があります。独自のリポジトリ公開ポイントを設定する(ホストすることもできる)ことが承認されます。 PATHSECを実装している場合、およびPATHSECがルーターまたはASに関連付けられている証明書を使用している場合、PATHSECはそれ自体にそのような証明書を発行することができます。 PATHSECが更新にデジタル署名する場合、PATHSEC対応のネイバーが受け入れる方法で署名を行うことができます。

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 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).

国:国は脅威かもしれません。国は、国内で運営されている1つまたは複数のネットワークオペレータを制御している可能性があるため、不正なネットワークオペレータとして機能する可能性があります。国には、ネットワークトラフィックへのMITM攻撃を可能にする技術的なアクティブな盗聴機能(たとえば、その領域内)がある場合があります。 (この機能は、国内で動作する電気通信プロバイダーに対する制御または影響によって促進される場合があります。)他の国のネットワークオペレーターのルーターまたは管理ネットワークコンピューターを攻撃および制御する機能を持っている可能性があります。国は、その領土内で動作するレジストリ(RIRなど)を制御し、そのレジストリに不正な機能で動作するように強制する場合があります。国の脅威の動機には、国への/国からのトラフィックのフローを制御したい、または他の国に向けられたトラフィックを迂回したいという欲求が含まれます(DoSを含む受動的または能動的な盗聴)

4. Attack Characterization
4. 攻撃の特徴付け

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
4.1. ルーター間のセッションのアクティブな盗聴

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

攻撃者は、BGPスピーカーのペアを接続するBGP(TCP)セッションを攻撃する可能性があります。 BGP(TCP)セッションに対するアクティブな攻撃は、トラフィックをリモートポイントからBGPスピーカーに転送するか、BGPセッショントラフィックを伝送するリンク上にMITMとして配置することで実行できます。リモート攻撃は、任意の敵から影響を受ける可能性があります。 MITM攻撃には、リンクへのアクセスが必要です。最新のトランスポートネットワークは、AS間リンクにそれらを利用するパケットネットワークと同じくらい複雑な場合があります。したがって、これらのトランスポートネットワークは、重大な攻撃対象となる可能性があります。それにもかかわらず、BGPセッションに対するMITM攻撃が可能であると想定されるのは、一部のクラスの敵のみです。 MITM攻撃は、BGPおよびPATHSECで保護されたBGP、あるいはTCPまたはIPに対して向けられる可能性があります。このような攻撃には、選択したBGPメッセージの再生、BGPメッセージの選択的な変更、およびBGPルーターに対するDoS攻撃が含まれます。 [RFC4272]は、このような攻撃に対するいくつかの対策を説明しているため、このドキュメントでは、このような攻撃については取り上げません。

4.2. Attacks on a BGP Router
4.2. BGPルーターへの攻撃

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.)

攻撃者は、PATHSECを実装しているかどうかに関係なく、BGPルーターを攻撃する可能性があります。ルーターを正当に制御する、またはルーターの制御を引き継ぐことができる攻撃者は、以下に説明する種類の攻撃に影響を与えることができると想定されます。ローカルルーティングポリシーの決定に起因する可能性があるルーターの動作は、攻撃とは見なされないことに注意してください。これは、このような動作がローカルポリシー設定の結果として説明される可能性があり、PATHSECが無許可の動作として検出できる範囲を超えているためです。したがって、たとえば、ルーターが一部またはすべてのルートの撤回を伝達できなかったり、「ルートリーク」を引き起こしたりすることがあります。 (これらの動作はBGPの仕様によって除外されておらず、公開されていないローカルポリシーの結果である可能性があります。その結果、それらは攻撃とは見なされません。詳細については、セクション5を参照してください。)

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].

False(ルート)発信:ルーターが表すASがそのプレフィックスのルートの発信を許可されていない場合、ルーターはプレフィックスのルートを発信する可能性があります。これは攻撃ですが、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.


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.

早期パスアナウンスの有効期限:PATHSECで保護されたアナウンスに有効期限が関連付けられている場合、ルーターは有効期間が非常に短いPATHSECで保護されたアナウンスを発行する可能性があります。 PATHSECプロト​​コル仕様で最小有効期限が指定されていない限り、これは攻撃ではありません。ただし、そのような時間が義務付けられている場合、この動作は攻撃になります。パスに沿ったBGPスピーカーは、リリースされる前にルートが以前のASによって保持されていた期間を知ることができないため、通常、有効期限が「疑わしいほど短い」かどうかを判断できません。

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.

MITM攻撃:2つのBGPルーター間のポイントツーポイントセキュリティ(TCP-AO、TLS、IPsecなど)に使用される暗号化キーが(ルーターからの抽出などにより)侵害される可能性があります。これにより、攻撃者はキーが使用されているリンクに対してMITM攻撃を行うことができます。 AS間のルーター間リンクを保護するための特定のセキュリティメカニズムの使用は、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.)

侵害されたルーター秘密鍵:PATHSECメカニズムが公開鍵暗号化を採用している場合(たとえば、更新でデータにデジタル署名する場合)、ルーターまたはASに関連付けられた秘密鍵は、ルーターに対する攻撃によって危険にさらされる可能性があります。このキーにアクセスできる攻撃者は、このルーターが表すASを通過したように見える更新を生成することができます。そのような更新は、そのリンクが敵にアクセス可能である場合、侵害されたルーターとその近隣の間のリンクに注入される可能性があります。攻撃者が別のネットワークを制御している場合、このキーを使用して、問題のASまたはルーターからのように見える署名を偽造して、いくつかの制約を課すことができます。したがって、たとえば、別のASを制御する攻撃者は、侵入されたルーター/ ASキーを使用して、ターゲットのルーター/ ASを含むPATHSEC署名付きデータを発行する可能性があります。 (敵のASの近隣者は、ターゲットのASから直接発信することを意図したルートを受け入れるべきではありません。したがって、攻撃者は、侵害されたASを通過する正当な保護されたルートを取得し、自身をネクストホップとして追加し、次に転送することができます。ネイバーへのルートが生成されます。)

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).

撤回抑制攻撃:PATHSECで保護されたアップデートは、署名および発表され、後で撤回される場合があります。攻撃者が中間ルーターを制御すると、撤回の伝達に失敗する可能性があります。 BGPはすでにこの種の動作に対して脆弱であるため、離脱抑制は、このモードのベースとなる想定(つまり、オラクルがない)での攻撃として特徴付けられません。

4.3. Attacks on Network Operator Management Computers (Non-CA Computers)

4.3. ネットワークオペレーター管理コンピューター(非CAコンピューター)への攻撃

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.)

攻撃者は、ネットワークオペレーターがネットワーク、特にルーターを管理するために使用するコンピューターを攻撃する可能性があります。このような攻撃は、これらのコンピューターのセキュリティを侵害した攻撃者によって影響を受ける可能性があります。これは、リモート攻撃、ネットワーク運用スタッフの強要などによって影響を受ける可能性があります。敵対者がNOCコンピュータを危険にさらした場合、彼は、スタッフが実行したであろうネットワーク操作を許可する管理機能を実行できます。したがって、攻撃者はローカルルーティングポリシーを変更して、設定を変更したり、特定のルートをブラックホール化したりすることができます。このタイプの動作は、外部から攻撃として検出することはできません。外部的には、これは不正なオペレーターの行動の1つの形として現れます。 (このような動作は、他のオペレーターによって偶発的または悪意のあるものとして認識される場合があります。)

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.


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.

ネットワークオペレーターがPATHSEC対応であり、ルーター/ ASに関連付けられた証明書を利用している場合、攻撃者はそのような証明書を要求するために使用されるツールを呼び出す可能性があります。その後、攻撃者はルーター/ ASの有効な証明書を、PATHSEC対応のネイバーによって拒否される可能性のある証明書に置き換えることができます。

4.4. Attacks on a Repository Publication Point
4.4. リポジトリ公開ポイントへの攻撃

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.

このセクションでは、有効なRPKI署名付き製品を生成するために必要な暗号化キーにアクセスせずに、1つ以上のリポジトリ公開ポイントをホストするコンピューターを制御する攻撃者が実行できる攻撃のみを考慮します。このような攻撃は、内部関係者または外部の脅威の影響を受ける可能性があります。すべてのリポジトリオブジェクトはデジタル署名されているため、この種の攻撃はRPKI RPに対するDoS攻撃に変換されます。以下に説明するように、このような攻撃にはいくつかの異なる形式があります。

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.

最初に、RPKIはRPが取得し、リポジトリシステムから確認および検証するデータをキャッシュすることを要求することに注意してください[RFC6480] [RFC6481]。署名された製品を削除する、「悪い」署名のある製品を挿入する、オブジェクト署名を改ざんする、または新しいオブジェクトを古い(有効な)オブジェクトで置き換える攻撃は、RPで検出できます(いくつかの例外があります)。 RPはローカルキャッシュを利用することが期待されています。リポジトリ公開ポイントが利用できない場合、または取得したデータが破損している場合、RPはキャッシュされたデータの使用に戻ることができます。この動作は、公開ポイントに対するDoS攻撃の直接的な影響からRPを隔離するのに役立ちます。

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.

各RPKIデータオブジェクトには、有効期限が切れるか、古くなったと見なされる日付が関連付けられています(証明書が期限切れになり、CRLが古くなる)。 RPがキャッシュされたデータを使用する場合、古いデータまたは期限切れのデータを処理する方法はローカルの決定です。より新しいデータが利用できない場合、PKIでは古い証明書失効ステータスデータを利用するのが一般的です。有効期限が切れた証明書の使用はあまり知られていませんが、あまり一般的ではありません。各RPは、古くなっているか期限切れのキャッシュされたRPKIオブジェクトを引き続き使用するか無視するかをローカルで決定します。

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.


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.

攻撃者が公開ポイントの1つ以上のCA証明書、ROA、またはCRLを削除した場合、その公開ポイントのマニフェストにより、RPはこの攻撃を検出できます。 RPは、削除されたオブジェクトの最後の有効なインスタンスを(ローカルポリシーオプションとして)引き続き使用できるため、このような攻撃の影響を最小限に抑えることができます。

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.

攻撃者がマニフェストを削除した場合(かつそれを古いインスタンスに置き換えない場合)、RPはこのアクションを検出できます。このような動作により、CA(または公開ポイントの管理者)に問題が通知されます。 RPは、削除されたマニフェストの最後の有効なインスタンス(ローカルポリシーオプション)を引き続き使用できるため、このような攻撃の影響を最小限に抑えることができます。

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.

攻撃者が新しく追加されたCA証明書またはROAを削除し、現在のマニフェストを以前のマニフェストに置き換えると、マニフェスト(および一致するCRL)は「古くなります」([RFC6486]を参照)。これは、問題がある可能性があることをRPに警告します。 RPは、ゴーストバスターレコード[RFC6493]からの情報を使用して、公開ポイントの責任者に連絡し、問題の解決策を要求する必要があります(たとえば、不足しているCA証明書やROAを再公開します)。 RPは、存在しない新しい証明書またはROAの内容を認識できませんが、キャッシュしたものを引き続き使用できます。この種の攻撃は、少なくとも一時的には、RPが新しく公開されたオブジェクトを認識しないようにします。これらのオブジェクトに関連付けられているINRは、認証されていないものとして扱われます。

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.

CAが(対応するEnd Entity(EE)証明書を削除することにより)CA証明書またはROAを取り消し、攻撃者がそのCA証明書またはROAを復元しようとした場合、攻撃者はCRLおよびマニフェストをロールバックしてこのアクションを取り消す必要があります。 CAによって。上記のように、これはCRLとマニフェストを陳腐化させ、これはRPによって検出可能です。 RPは、削除されたCA証明書またはROAを認識できません。ローカルポリシーに応じて、RPは影響を受けるオブジェクトのキャッシュされたインスタンスを使用する可能性があるため、これらの取り消されたオブジェクトに基づいて判断を下すように騙される可能性があります。ここでも、目標はCAに(RPによって)問題が通知され、エラーが修正されることです。

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.

上記の攻撃シナリオで、CRLまたはマニフェストが古いと記述されている場合、これはCRLまたはマニフェストの次の発行日が過ぎたことを意味します。次の発行日まで、RPは攻撃を検出しません。したがって、CAは、リスクと運用上の負担の間の許容できるトレードオフを表すCRL /マニフェストライフタイム(2つはリンクされている)を選択する必要があります。

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
4.5. 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.)

INRが割り当てられているエンティティはすべて、RPKIのCAです。各CAは、名目上、生成する一連の署名付き製品のリポジトリ公開ポイントを管理する責任があります。 (INR保有者は、RPKI CA機能および関連する公開ポイントの運用を外部委託することを選択できます。そのような場合、INR保有者に代わって活動する組織は、運用およびセキュリティの観点からCAになります。以下の説明では、このような外部委託されたCAの運用。)

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.)

セクション2にリストされているすべての敵は、CA機能を実行するために使用されるコンピューターに対して攻撃を仕掛けることができると想定されています。一部の敵対者は、人員や物理的なセキュリティコントロールにも違反することにより、CAへの攻撃に影響を与える可能性があります。攻撃者としてのCAと攻撃の被害者としてのCAの違いは重要です。後者の場合にのみ、攻撃が検出された後、CAが攻撃によって引き起こされた問題を修復することを期待できます。 (CAがそのような行動を取らない場合、その影響はCAが敵対者である場合と同じです。)

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

CAによる攻撃により、CAが発行した証明書が失効または置き換えられる可能性があります。証明書を取り消すと、RPはキャッシュしていた(以前の)有効な証明書(および取り消されたEE証明書の場合は、関連付けられた署名付きオブジェクト)を削除します。これにより、その証明書の下で検証されたリポジトリオブジェクト(CA証明書やROAなど)が一時的に無効と見なされます。その結果、RPは、ROAまたはPATHSECで保護された更新がこれらの証明書に基づいて有効であるとは見なさないため、それらに依存するルートの優先度が低くなります。証明書を取り消すCAはそうすることが許可されているため、この種の攻撃は本質的にほとんどのRPで検出できません。ただし、CA証明書の失効または置き換えの影響を受けるエンティティは、攻撃を検出し、CAに連絡して修復を行うことが期待できます。 CAが敵対者ではなかった場合、新しい証明書を発行し、公開ポイントを復元できるはずです。

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

攻撃者はCA証明書を置き換え、対応する秘密キーを使用して新しい署名付き製品を発行し、攻撃者が制御する公開ポイントでそれらを公開する可能性があります。これにより、影響を受けるINRが効果的に敵対者または選択した第三者に転送されます。その結果、RPは、問題の秘密鍵を制御するエンティティを正当なINR保有者と見なします。この場合も、RFC 3779の拡張機能の使用によって課せられる制約により、侵害されたCAがCAの範囲外のINRで(有効な)証明書を発行することを防ぎ、攻撃の影響を制限します。

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.

最後に、リポジトリ公開ポイントを管理するエンティティが不注意で攻撃者として振る舞う可能性があります(ウォルトケリーの最も有名な「Pogo」の引用[Kelly70]の例)。たとえば、CAは自身の証明書を適時に(期限切れになる前に)置き換えられない場合があります。有効期限が切れる前にCRLとマニフェストを発行できず、RPに問題を引き起こすこれらの製品の古いインスタンスが作成される可能性があります。多くの下位CA(RIRやNIRなど)を持つCAは、発行するCA証明書の有効期限を配布できない場合があります。多くのROAを持つネットワークは、生成するROAに関連付けられたEE証明書に対して同じことを行う場合があります。 CAはそのキーをロールオーバーできますが、新しいキーの下で下位CA証明書を再発行できません。管理されたCAのキー更新間隔に関する計画が不十分な場合、悪意のある意図がなくても、RPに過度の負担がかかる可能性があります。悪意のある意図がなくても、これらの誤管理の例はすべてRPに悪影響を与える可能性があります。

5. Residual Vulnerabilities
5. 残りの脆弱性

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:

o RPKIリポジトリシステムは、そのコンテンツが利用できない、最新ではない、または一貫性がないようにする方法で攻撃される可能性があります。ほとんどの形式のDoS攻撃に対する基本的な防御策は、各RPによるローカルキャッシュの使用です。ローカルキャッシュは、リポジトリにアクセスできない場合、またはリポジトリのコンテンツが(悪意を持って)削除された場合に、以前に取得したRPKIデータの可用性を保証します。それにもかかわらず、システムはすべてのRPが常に最新のRPKIデータにアクセスできることを保証できません。 RPは、取得したリポジトリデータの問題を検出すると、2つのオプションがあります。

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.

1. RPは、期限切れのオブジェクトや古いオブジェクトを許容するローカル構成設定を使用して、ローカルキャッシュを利用することを選択できます。 (そのような動作は、名目上、常にPKIのRPの範囲内です。)キャッシュされた、期限切れの、または古いデータを使用すると、RPがこのデータの変更を知らないことを利用する攻撃を受けます。

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.

2. RPは、期限切れのオブジェクトをパージすることを選択できます。期限切れのオブジェクトをパージすると、オブジェクトが参照する実際のINRに関連付けられているセキュリティ情報が削除されます。これは、影響を受けるINRがRPKIを通じて保護されていなかったのと同じです。 RPKI(およびPATHSEC)の使用は任意であるため、これらのメカニズムによって保護されていないINRのセットが常に存在する場合があります。したがって、パージすると、影響を受けるINRが一連の非参加INR保有者に移動します。このより保守的な応答により、攻撃者は保護されたセットから保護されていないセットにINRを移動できます。

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.

o RPKI内のCAは、それに割り当てられたINRの範囲内で誤動作する可能性があります。たとえば、リソース割り当てが重複する証明書を発行したり、証明書を不適切に失効させたりする可能性があります。この脆弱性はどのPKIにも内在していますが、RFC 3779で拡張機能を使用しているため、RPKIでの影響は限定的です。RPがこのような不正行為を検出すると、管理手段を通じて対処することが予想されます。

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 「ルートリーク」は、多くのオペレーターにとってルーティングセキュリティの問題と見なされていると述べられています。ただし、BGP自体には、ルートリークとして多くの人が認識するものを排除するセマンティクスが含まれておらず、RFCにはこの用語の定義はありません。このため、このドキュメントでルートリークに対処することは不適切です。さらに、ルートリークはPATHSECの範囲外であり、このドキュメントのセクション1に記載されているセキュリティコンテキストと一致しています。後で、SIDRセキュリティコンテキストがルートリークを含むように改訂され、適切な定義が存在する場合、このドキュメントを改訂する必要があります。

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.

o PATHSECは、AS_PATHに関連付けられたすべての属性を保護する必要はありませんが、これらの属性の一部はルーティング決定への入力として使用できます。したがって、これらの他の属性を変更(または除去)する攻撃は、PATHSECによって防止/検出されません。セクション1で述べたように、SIDRセキュリティコンテキストは、受信したルートが問題のASを通過し、ルートのNLRIがアドバタイズされたものであることを確認するために必要な情報のみを保護することを要求します。 (AS_PATHデータは、コンフェデレーション内で表されないASを通過することもあります。ただし、これらのASは外部からは見えないため、ルート選択に影響を与えないため、このコンテキストでのASの省略はセキュリティ上の問題ではありません。)したがって、セクション1で説明されているように、他の属性はこのドキュメントの範囲外です。後で、SIDRセキュリティコンテキストが改訂され、追加のBGP属性の保護が含まれる場合は、このドキュメントを改訂する必要があります。

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.

o セクション4.2に記載されているように、PATHSECは、ASにプレフィックスのルートがなくなったときに、ASがルートを取り消すことを保証できません。 PATHSECには、広告の有効期間を制限する機能が組み込まれている場合があります。このようなライフタイム制限は、ルートの撤回の失敗が有効なままである時間の上限を提供します。

6. Security Considerations
6. セキュリティに関する考慮事項

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.

脅威モデルは、定義上、セキュリティ中心のドキュメントです。プロトコルの説明とは異なり、脅威モデルはセキュリティの問題を引き起こさず、セキュリティの問題に対処する意図もありません。このモデルは、一連の脅威(つまり、動機付けされた有能な敵)を想定し、脅威に起因する動機に基づいて、これらの脅威がもたらすことができる攻撃のクラスを調べます。 PATHSECが依存するRPKIを含む、PATHSECに対するこれらのタイプの攻撃の影響について説明します。該当する場合、RPKIの設計(およびPATHSEC設計目標)が攻撃のクラスにどのように対処するかについて説明します。また、残りの脆弱性についても説明します。

7. Acknowledgements
7. 謝辞

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
8. 参考引用

[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.

[Kent2000] Kent、S.、Lynn、C。、およびK. Seo、「Secure Border Gateway Protocol(S-BGP)の設計と分析」、IEEE DISCEX会議、2000年6月。

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

[RFC3779] Lynn、C.、Kent、S.、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.

[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4(BGP-4)」、RFC 4271、2006年1月。

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

[RFC4272]マーフィーS。、「BGPセキュリティ脆弱性分析」、RFC 4272、2006年1月。

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

[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.

[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6481] Huston、G.、Loomans、R。、およびG. Michaelson、「リソース証明書リポジトリ構造のプロファイル」、RFC 6481、2012年2月。

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6482] Lepinski、M.、Kent、S.、D。Kong、「A Route for Route Origin Authorizations(ROAs)」、RFC 6482、2012年2月。

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.

[RFC6486] Austein、R.、Huston、G.、Kent、S。、および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.

[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

[RFC6488] Lepinski、M.、Chi、A。、およびS. Kent、「Resource Public Key Infrastructure(RPKI)の署名付きオブジェクトテンプレート」、RFC 6488、2012年2月。

[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.

[RFC6493] Bush、R。、「The Resource Public Key Infrastructure(RPKI)Ghostbusters Record」、RFC 6493、2012年2月。

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013.

[RFC6810] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure(RPKI)to Router Protocol」、RFC 6810、2013年1月。

[SIDR-CH] "Secure Inter-Domain Routing: Charter for Working Group", September 2013, < charters?item=charter-sidr-2013-09-20.txt>.

[SIDR-CH]「安全なドメイン間ルーティング:ワーキンググループのチャーター」、2013年9月、<。 txt>。

[Sam04] Samuel, A., "Hacktivism and the Future of Political Participation", Ph.D. dissertation, Harvard University, September 2004, < dissertation/pdfs/Samuel-Hacktivism-entire.pdf>.


Authors' Addresses


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

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


Andrew Chi University of North Carolina - Chapel Hill c/o Department of Computer Science CB 3175, Sitterson Hall Chapel Hill, NC 27599 USA

アンドリューチーノースカロライナ大学-Chapel Hill c / o Department of Computer Science CB 3175、Sitterson Hall Chapel Hill、NC 27599 USA