[要約] RFC 7353は、BGPパスの検証のためのセキュリティ要件を定義しています。その目的は、BGPルーティングプロトコルのセキュリティを向上させ、不正な経路の伝播を防ぐことです。
Internet Engineering Task Force (IETF) S. Bellovin
Request for Comments: 7353 Columbia University
Category: Informational R. Bush
ISSN: 2070-1721 Internet Initiative Japan
D. Ward
Cisco Systems
August 2014
Security Requirements for BGP Path Validation
BGPパス検証のセキュリティ要件
Abstract
概要
This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.
このドキュメントでは、発信元の自律システム（AS）がプレフィックスをアナウンスし、アナウンスのASパスを保証する権利を持っていることを暗号で保証するためのBGPセキュリティプロトコル設計の要件について説明します。
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 http://www.rfc-editor.org/info/rfc7353.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7353で入手できます。
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Recommended Reading . . . . . . . . . . . . . . . . . . . . . 2
3. General Requirements . . . . . . . . . . . . . . . . . . . . 3
4. BGP UPDATE Security Requirements . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Origin validation based on Resource Public Key Infrastructure (RPKI) [RFC6811] provides a measure of resilience to accidental mis-origination of prefixes; however, it provides neither cryptographic assurance (announcements are not signed) nor assurance of the AS Path of the announcement.
Resource Public Key Infrastructure（RPKI）[RFC6811]に基づくオリジン検証は、プレフィックスの誤った誤発信に対する回復力の尺度を提供します。ただし、暗号化による保証（アナウンスは署名されていません）も、アナウンスのASパスの保証も提供しません。
This document describes requirements to be placed on a BGP security protocol, herein termed "BGPsec", intended to rectify these gaps.
このドキュメントでは、これらのギャップを修正することを目的とした、ここでは「BGPsec」と呼ばれるBGPセキュリティプロトコルに課せられる要件について説明します。
The threat model assumed here is documented in [RFC4593] and [RFC7132].
ここで想定されている脅威モデルは、[RFC4593]と[RFC7132]で文書化されています。
As noted in the threat model [RFC7132], this work is limited to threats to the BGP protocol. Issues of business relationship conformance, while quite important to operators, are not security issues per se and are outside the scope of this document. It is hoped that these issues will be better understood in the future.
脅威モデル[RFC7132]で述べられているように、この作業はBGPプロトコルに対する脅威に限定されています。ビジネス関係の適合性の問題は、事業者にとって非常に重要ですが、それ自体はセキュリティの問題ではなく、このドキュメントの範囲外です。これらの問題が将来よりよく理解されることが望まれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case, without normative meaning.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は解釈されますRFC 2119 [RFC2119]で説明されているように、すべて大文字で表記されている場合のみ。それらは、標準的な意味なしに、小文字または大文字と小文字が混在して表示される場合もあります。
This document assumes knowledge of the RPKI [RFC6480] and the RPKI Repository Structure [RFC6481].
このドキュメントは、RPKI [RFC6480]およびRPKIリポジトリ構造[RFC6481]の知識があることを前提としています。
This document assumes ongoing incremental deployment of Route Origin Authorizations (ROAs) [RFC6482], the RPKI to the Router Protocol [RFC6810], and RPKI-based Prefix Validation [RFC6811].
このドキュメントは、Route Origin Authorizations（ROA）[RFC6482]、ルータープロトコルへのRPKI [RFC6810]、およびRPKIベースのプレフィックス検証[RFC6811]の継続的な増分展開を想定しています。
And, of course, a knowledge of BGP [RFC4271] is required.
そしてもちろん、BGP [RFC4271]の知識が必要です。
The following are general requirements for a BGPsec protocol:
BGPsecプロトコルの一般的な要件は次のとおりです。
3.1 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the originating AS in the received PATH attribute possessed the authority to announce the prefix.
3.1 BGPsec設計では、BGPアナウンスの受信者が、受信したPATH属性内の発信元ASがプレフィックスをアナウンスする権限を持っていることを確実に判断できるようにする必要があります。
3.2 A BGPsec design MUST allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of External BGP (eBGP) exchanges that propagated the prefix from the origin AS to the receiver, particularly if an AS has added or deleted any AS number other than its own in the PATH attribute. This includes modification to the number of AS prepends.
3.2 BGPsec設計では、BGPアナウンスの受信者が、受信したPATH属性が、発信元ASから受信者にプレフィックスを伝播した外部BGP（eBGP）交換のシーケンスを正確に表すことを、確実に判断できるようにする必要があります（特に）。 ASが、PATH属性で自身以外のAS番号を追加または削除した場合。これには、ASプリペンド数の変更が含まれます。
3.3 BGP attributes other than the AS_PATH are used only locally, or have meaning only between immediate neighbors, may be modified by intermediate systems and figure less prominently in the decision process. Consequently, it is not appropriate to try to protect such attributes in a BGPsec design.
3.3 AS_PATH以外のBGP属性は、ローカルでのみ使用されるか、または隣接する隣接間でのみ意味があり、中間システムによって変更され、決定プロセスであまり目立たなくなる場合があります。したがって、BGPsec設計でそのような属性を保護することは適切ではありません。
3.4 A BGPsec design MUST be amenable to incremental deployment. This implies that incompatible protocol capabilities MUST be negotiated.
3.4 BGPsec設計は、段階的な展開に対応できる必要があります。これは、互換性のないプロトコル機能をネゴシエートする必要があることを意味します。
3.5 A BGPsec design MUST provide analysis of the operational considerations for deployment and particularly of incremental deployment, e.g., contiguous islands, non-contiguous islands, universal deployment, etc.
3.5 BGPsec設計は、展開の運用上の考慮事項、特に連続的なアイランド、非連続的なアイランド、ユニバーサルな展開などの増分展開の分析を提供する必要があります。
3.6 As proofs of possession and authentication may require cryptographic payloads and/or storage and computation, likely increasing processing and memory requirements on routers, a BGPsec design MAY require use of new hardware. That is, compatibility with current hardware abilities is not a requirement that this document imposes on a solution.
3.6 所有証明および認証には暗号化ペイロードおよび/またはストレージと計算が必要になる可能性があり、ルーターの処理要件とメモリ要件が増加する可能性があるため、BGPsec設計では新しいハードウェアの使用が必要になる場合があります。つまり、現在のハードウェア機能との互換性は、このドキュメントがソリューションに課す要件ではありません。
3.7 A BGPsec design need not prevent attacks on data-plane traffic. It need not provide assurance that the data plane even follows the control plane.
3.7 BGPsec設計では、データプレーントラフィックへの攻撃を防ぐ必要はありません。データプレーンがコントロールプレーンに続くことさえ保証する必要はありません。
3.8 A BGPsec design MUST resist attacks by an enemy who has access to the inter-router link layer, per Section 3.1.1.2 of [RFC4593]. In particular, such a design MUST provide mechanisms for authentication of all data, including protecting against message insertion, deletion, modification, or replay. Mechanisms that suffice include TCP sessions authenticated with the TCP Authentication Option (TCP-AO) [RFC5925], IPsec [RFC4301], or Transport Layer Security (TLS) [RFC5246].
3.8 [RFC4593]のセクション3.1.1.2に従い、BGPsec設計は、ルーター間リンクレイヤーにアクセスできる敵による攻撃に抵抗する必要があります。特に、そのような設計は、メッセージの挿入、削除、変更、または再生に対する保護を含む、すべてのデータの認証のためのメカニズムを提供する必要があります。十分なメカニズムには、TCP認証オプション（TCP-AO）[RFC5925]、IPsec [RFC4301]、またはトランスポート層セキュリティ（TLS）[RFC5246]で認証されたTCPセッションが含まれます。
3.9 It is assumed that a BGPsec design will require information about holdings of address space and Autonomous System Numbers (ASNs), and assertions about binding of address space to ASNs. A BGPsec design MAY make use of a security infrastructure (e.g., a PKI) to distribute such authenticated data.
3.9 BGPsec設計では、アドレススペースと自律システム番号（ASN）の保持に関する情報、およびアドレススペースのASNへのバインドに関するアサーションが必要であると想定されています。 BGPsecの設計では、セキュリティインフラストラクチャ（PKIなど）を利用して、そのような認証済みデータを配布することができます（MAY）。
3.10 It is entirely OPTIONAL to secure AS SETs and prefix aggregation. The long-range solution to this is the deprecation of AS_SETs; see [RFC6472].
3.10 AS SETとプレフィックス集約を保護することは完全にオプションです。これに対する長期的な解決策は、AS_SETの廃止です。 [RFC6472]を参照してください。
3.11 If a BGPsec design uses signed prefixes, given the difficulty of splitting a signed message while preserving the signature, it need not handle multiple prefixes in a single UPDATE PDU.
3.11 BGPsec設計が署名付きプレフィックスを使用する場合、署名を保持しながら署名付きメッセージを分割することが難しいため、1つのUPDATE PDUで複数のプレフィックスを処理する必要はありません。
3.12 A BGPsec design MUST enable each BGPsec speaker to configure use of the security mechanism on a per-peer basis.
3.12 BGPsec設計では、各BGPsecスピーカーがセキュリティメカニズムの使用をピアごとに構成できるようにする必要があります。
3.13 A BGPsec design MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible manner.
3.13 BGPsec設計は、混合セキュリティ環境を介して伝送されるルーティング情報のメッセージのフォーマット、送信、および処理に下位互換性を提供する必要があります。完全に保護された環境でのメッセージのフォーマットは、下位互換性のない方法で処理される場合があります。
3.14 While the formal validity of a routing announcement should be determined by the BGPsec protocol, local routing policy MUST be the final arbiter of the best path and other routing decisions.
3.14 ルーティングアナウンスの正式な有効性はBGPsecプロトコルによって決定される必要がありますが、ローカルルーティングポリシーは、最適なパスと他のルーティング決定の最終的なアービターである必要があります。
3.15 A BGPsec design MUST support 'transparent' route servers, meaning that the AS of the route server is not counted in downstream BGP AS-path-length tie-breaking decisions.
3.15 BGPsec設計は、「透過的な」ルートサーバーをサポートする必要があります。つまり、ルートサーバーのASは、ダウンストリームBGP AS-path-lengthのタイブレイク決定ではカウントされません。
3.16 A BGPsec design MUST support AS aliasing. This technique is not well defined or universally implemented but is being documented in [AS-MIGRATION]. A BGPsec design SHOULD accommodate AS 'migration' techniques such as common proprietary and non-standard methods that allow a router to have two AS identities, without lengthening the effective AS Path.
3.16 BGPsec設計はASエイリアスをサポートする必要があります。この手法は明確に定義されておらず、一般的にも実装されていませんが、[AS-MIGRATION]で文書化されています。 BGPsec設計は、有効なASパスを長くすることなく、ルーターが2つのAS IDを持つことを可能にする一般的な独自の方法や非標準的な方法などのAS「移行」手法に対応する必要があります（SHOULD）。
3.17 If a BGPsec design makes use of a security infrastructure, that infrastructure SHOULD enable each network operator to select the entities it will trust when authenticating data in the security infrastructure. See, for example, [LTA-USE-CASES].
3.17 BGPsec設計でセキュリティインフラストラクチャを利用する場合、そのインフラストラクチャは、各ネットワークオペレーターがセキュリティインフラストラクチャでデータを認証するときに信頼するエンティティを選択できるようにする必要があります（SHOULD）。たとえば、[LTA-USE-CASES]を参照してください。
3.18 A BGPsec design MUST NOT require operators to reveal more than is currently revealed in the operational inter-domain routing environment, other than the inclusion of necessary security credentials to allow others to ascertain for themselves the necessary degree of assurance regarding the validity of Network Layer Reachability Information (NLRI) received via BGPsec. This includes peering, customer/provider relationships, an ISP's internal infrastructure, etc. It is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc., today.
3.18 BGPsec設計では、ネットワークレイヤー到達可能性の有効性に関する必要な保証を他者が確認できるようにするために必要なセキュリティ資格情報を含めることを除き、運用中のドメイン間ルーティング環境で現在明らかにされている以上のものを明らかにすることをオペレーターに要求してはなりませんBGPsec経由で受信した情報（NLRI）。これには、ピアリング、顧客/プロバイダーの関係、ISPの内部インフラストラクチャなどが含まれます。一部のデータは、今日のBGP、tracerouteなどによって、精通したシーカーに明らかにされていることがわかります。
3.19 A BGPsec design MUST signal (e.g., via logging or SNMP) security exceptions that are significant to the operator. The specific data to be signaled are an implementation matter.
3.19 BGPsec設計は、オペレーターにとって重要なセキュリティ例外を（ロギングやSNMPなどを介して）通知する必要があります。通知される特定のデータは実装の問題です。
3.20 Any routing information database MUST be re-authenticated periodically or in an event-driven manner, especially in response to events such as, for example, PKI updates.
3.20 ルーティング情報データベースは、特にPKI更新などのイベントに応答して、定期的に、またはイベント駆動方式で再認証する必要があります。
3.21 Any inter-AS use of cryptographic hashes or signatures MUST provide mechanisms for algorithm agility. For a discussion, see [ALG-AGILITY].
3.21 暗号ハッシュまたは署名のAS間使用は、アルゴリズムの俊敏性のためのメカニズムを提供する必要があります。議論については、[ALG-AGILITY]を参照してください。
3.22 A BGPsec design SHOULD NOT presume to know the intent of the originator of a NLRI, nor that of any AS on the AS Path, other than that they intend to pass it to the next AS in the path.
3.22 BGPsec設計では、NLRIの発信者の意図も、パスの次のASに渡すつもりでない限り、ASパス上のASの意図も知っているべきではありません（SHOULD NOT）。
3.23 A BGPsec listener SHOULD NOT trust non-BGPsec markings, such as communities, across trust boundaries.
3.23 BGPsecリスナーは、信頼境界を越えて、コミュニティなどの非BGPsecマーキングを信頼してはいけません（SHOULD NOT）。
The following requirements MUST be met in the processing of BGP UPDATE messages:
BGP UPDATEメッセージの処理では、次の要件を満たす必要があります。
4.1 A BGPsec design MUST enable each recipient of an UPDATE to formally validate that the origin AS in the message is authorized to originate a route to the prefix(es) in the message.
4.1 BGPsec設計では、UPDATEの各受信者が、メッセージ内の発信元ASがメッセージ内のプレフィックスへのルートを発信することを承認されていることを正式に検証できるようにする必要があります。
4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the NLRI has traversed the AS Path indicated in the UPDATE. Note that this is more stringent than showing that the path is merely not impossible.
4.2 BGPsec設計では、UPDATEの受信者が、NLRIがUPDATEに示されたASパスを通過したことを正式に判断できるようにする必要があります。これは、パスが単に不可能ではないことを示すよりも厳しいことに注意してください。
4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks.
4.3 BGP UPDATEメッセージのリプレイを完全に防止する必要はありませんが、BGPsec設計は、リプレイ攻撃にさらされるウィンドウを制御するメカニズムを提供する必要があります（SHOULD）。
4.4 A BGPsec design SHOULD provide some level of assurance that the origin of a prefix is still 'alive', i.e., that a monkey in the middle has not withheld a WITHDRAW message or the effects thereof.
4.4 BGPsec設計は、接頭辞の起点がまだ「生きている」こと、つまり、途中の猿がWITHDRAWメッセージまたはその影響を差し控えていないことをある程度保証します（SHOULD）。
4.5 The AS Path of an UPDATE message SHOULD be able to be authenticated as the message is processed.
4.5 UPDATEメッセージのASパスは、メッセージが処理されるときに認証できる必要があります（SHOULD）。
4.6 Normal sanity checks of received announcements MUST be done, e.g., verification that the first element of the AS_PATH list corresponds to the locally configured AS of the peer from which the UPDATE was received.
4.6 受信したアナウンスの通常の健全性チェックを実行する必要があります。たとえば、AS_PATHリストの最初の要素が、UPDATEを受信したピアのローカルに構成されたASに対応していることを確認します。
4.7 The output of a router applying BGPsec validation to a received UPDATE MUST be unequivocal and conform to a fully specified state in the design.
4.7 受信したUPDATEにBGPsec検証を適用するルーターの出力は、明確であり、設計で完全に指定された状態に準拠している必要があります。
If an external "security infrastructure" is used, as mentioned in Section 3, paragraphs 9 and 17 above, the authenticity and integrity of the data of such an infrastructure MUST be assured. In addition, the integrity of those data MUST be assured when they are used by BGPsec, e.g., in transport.
上記のセクション3、パラグラフ9および17で述べたように、外部の「セキュリティインフラストラクチャ」を使用する場合、そのようなインフラストラクチャのデータの信頼性と完全性を保証する必要があります。さらに、それらのデータの完全性は、それらがBGPsecによって、たとえばトランスポートで使用されるときに保証される必要があります。
The requirement of backward compatibility to BGP4 may open an avenue to downgrade attacks.
BGP4への下位互換性の要件は、ダウングレード攻撃への道を開くかもしれません。
The data plane might not follow the path signaled by the control plane.
データプレーンは、コントロールプレーンから通知されたパスをたどらない場合があります。
Security for subscriber traffic is outside the scope of this document and of BGP security in general. IETF standards for payload data security should be employed. While adoption of BGP security measures may ameliorate some classes of attacks on traffic, these measures are not a substitute for use of subscriber-based security.
加入者トラフィックのセキュリティは、このドキュメントおよびBGPセキュリティ一般の範囲外です。ペイロードデータセキュリティのIETF標準を採用する必要があります。 BGPセキュリティ対策を採用すると、トラフィックに対するいくつかのクラスの攻撃が改善される可能性がありますが、これらの対策は、加入者ベースのセキュリティの使用に代わるものではありません。
The authors wish to thank the authors of [BGP-SECURITY] from whom we liberally stole, Roque Gagliano, Russ Housley, Geoff Huston, Steve Kent, Sandy Murphy, Eric Osterweil, John Scudder, Kotikalapudi Sriram, Sam Weiler, and a number of others.
著者は、私たちが自由に盗んだ[BGP-SECURITY]の著者、Roque Gagliano、Russ Housley、Geoff Huston、Steve Kent、Sandy Murphy、Eric Osterweil、John Scudder、Kotikalapudi Sriram、Sam Weiler、および多数の著者に感謝します。その他。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[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月。
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014.
[RFC7132] Kent、S。およびA. Chi、「BGPパスセキュリティの脅威モデル」、RFC 7132、2014年2月。
[ALG-AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility", Work in Progress, June 2014.
[ALG-AGILITY] Housley、R。、「Cryptographic Algorithm Agilityのガイドライン」、Work in Progress、2014年6月。
[AS-MIGRATION] George, W. and S. Amante, "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Work in Progress, January 2014.
[AS-MIGRATION]ジョージW.およびS.アマンテ、「自律システム（AS）の移行機能とBGP AS_PATH属性への影響」、進行中の作業、2014年1月。
[BGP-SECURITY] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SECURITY]クリスチャン、B。およびT.タウバー、「BGPセキュリティ要件」、2008年11月、作業中。
[LTA-USE-CASES] Bush, R., "RPKI Local Trust Anchor Use Cases", Work in Progress, June 2014.
[LTA-USE-CASES]ブッシュR。、「RPKI Local Trust Anchor Use Cases」、進行中の作業、2014年6月。
[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月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
[RFC6472]クマリW.およびK.スリラム、「BGPでAS_SETおよびAS_CONFED_SETを使用しない場合の推奨事項」、BCP 172、RFC 6472、2011年12月。
[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月。
[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月。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、2013年1月。
Authors' Addresses
著者のアドレス
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue, MC 0401 New York, New York 10027 USA
スティーブンM.ベロビンコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027アメリカ
Phone: +1 212 939 7149
EMail: bellovin@acm.org
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 USA
ランディブッシュインターネットイニシアティブ日本5147 Crystal Springsベインブリッジ島、ワシントン98110アメリカ
EMail: randy@psg.com
David Ward Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
David Ward Cisco Systems 170 W. Tasman Drive San Jose、CA 95134 USA
EMail: dward@cisco.com