[要約] RFC 8893は、BGPエクスポートのためのRPKI起源検証に関する標準仕様です。このRFCの目的は、インターネットルーティングにおける偽装経路攻撃を防ぐために、RPKIを使用してBGP経路の起源を検証することです。

Internet Engineering Task Force (IETF)                           R. Bush
Request for Comments: 8893            Internet Initiative Japan & Arrcus
Updates: 6811                                                    R. Volk
Category: Standards Track
ISSN: 2070-1721                                                 J. Heitz
                                                                   Cisco
                                                          September 2020
        

Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export

BGPエクスポートのリソース公開鍵インフラストラクチャ(RPKI)Origin検証

Abstract

概要

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. This document updates RFC 6811.

BGPスピーカーは、リソース公開鍵インフラストラクチャ(RPKI)Origin検証(RPKI)Origin検証を実行してもよく、他のルーティングプロトコルから再配布されたルートだけでなく、それがBGPネイバーに送信されるルートでも実行できます。出力方針の場合、分類は処理経路の「有効な原点として有効な原点」を使用することが重要です。これは、秘密のASS、連携処理、および原点のその他の変更など、一般に利用可能なノブによって変更される可能性があります。この文書はRFC 6811を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8893.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8893で入手できます。

Copyright Notice

著作権表示

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

Copyright(C)2020 IETFの信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、この文書の公開日に有効なIETF文書(https://truste.ietf.org/License-info)に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。

Table of Contents

目次

   1.  Introduction
   2.  Suggested Reading
   3.  Egress Processing
   4.  Operational Considerations
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

This document does not change the protocol or semantics of [RFC6811], BGP prefix origin validation. It highlights an important use case of origin validation in external BGP (eBGP) egress policies, explaining specifics of correct implementation in this context.

この文書は[RFC6811]のプロトコルまたはセマンティクスを変更していません.BGPプレフィックスの起点検証。これは、このコンテキストにおける正しい実装の詳細を説明する、外部BGP(EBGP)の出力ポリシーで重要な使用例を強調しています。

The term 'effective origin AS' as used in this document refers to the Route Origin Autonomous System Number (ASN) [RFC6811] of the UPDATE to be sent to neighboring BGP speakers.

この文書で使用されている「有効な原点」という用語は、隣接するBGPスピーカーに送信される更新の経路原点の自律システム番号(ASN)[RFC6811]を指します。

The effective origin AS of a BGP UPDATE is decided by configuration and outbound policy of the BGP speaker. A validating BGP speaker MUST apply Route Origin Validation policy semantics (see Section 2 of [RFC6811] and Section 4 of [RFC8481]) after applying any egress configuration and policy.

BGP更新時の有効な原点は、BGPスピーカーの構成とアウトバウンドポリシーによって決定されます。検証のあるBGPスピーカーは、出力構成とポリシーを適用した後、Route Origin検証ポリシーセマンティクス([RFC6811]のセクション2と[RFC8481]のセクション4を参照)を適用しなければなりません。

This effective origin AS of the announcement might be affected by removal of private ASes, confederation [RFC5065], migration [RFC7705], etc. Any AS_PATH modifications resulting in effective origin AS change MUST be taken into account.

発表のこの有効な原点は、プライベートASES、コンフェデレーション[RFC5065]、移行[RFC7705]などの削除の影響を受ける可能性があります。

This document updates [RFC6811] by clarifying that implementations must use the effective origin AS to determine the Origin Validation state when applying egress policy.

この文書は、出力ポリシーを適用するときに有効な原点を決定するために実装の原点を使用する必要があることを明確にすることによって、[RFC6811]を更新します。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。

2. Suggested Reading
2. 推奨読書

It is assumed that the reader understands BGP [RFC4271], the RPKI [RFC6480], Route Origin Authorizations (ROAs) [RFC6482], RPKI-based Prefix Validation [RFC6811], and Origin Validation Clarifications [RFC8481].

リーダーはBGP [RFC4271]、RPKI [RFC6480]、ROUT ORIGIN承認(ROAS)[RFC6482]、RPKIベースの接頭辞検証[RFC6811]、およびOrigin検証の説明[RFC8481]を理解していると仮定する。

3. Egress Processing
3. 出力処理

BGP implementations supporting RPKI-based origin validation MUST provide the same policy configuration primitives for decisions based on the validation state available for use in ingress, redistribution, and egress policies. When applied to egress policy, validation state MUST be determined using the effective origin AS of the route as it will (or would) be announced to the peer. The effective origin AS may differ from that of the route in the RIB due to commonly available knobs, such as removal of private ASes, AS path manipulation, confederation handling, etc.

RPKIベースの原点検証をサポートするBGP実装は、入力、再配布、および出力ポリシーで使用可能な検証状態に基づいて、同じポリシー構成プリミティブを決定する必要があります。出力ポリシーに適用されると、検証状態は、それがピアに発表される(または)経路のように有効な原点を使用して決定されなければなりません。有効な原点は、秘密のASSの除去などの一般的に利用可能なノブ、経路操作、連携処理などのために、リブ内の経路とは異なる場合があります。

Egress policy handling can provide more robust protection for outbound eBGP than relying solely on ingress (iBGP, eBGP, connected, static, etc.) redistribution being configured and working correctly -- i.e., better support for the robustness principle.

出力ポリシー処理は、入力(IBGP、EBGP、接続された、静的など)の再配布のみに頼りにするよりも、アウトバウンドEBGPをより堅牢な保護を提供することができます。

4. Operational Considerations
4. 運用上の考慮事項

Configurations may have a complex policy where the effective origin AS may not be easily determined before the outbound policies have been run. It SHOULD be possible to specify a selective origin validation policy to be applied after any existing non-validating outbound policies.

構成は、アウトバウンドポリシーが実行される前に効果的な原点が容易に決定されない可能性がある複雑なポリシーを持つことがあります。既存の検証されていないアウトバウンドポリシーの後に適用される選択的原点検証ポリシーを指定することが可能であるべきです。

An implementation SHOULD be able to list announcements that were not sent to a peer, e.g., because they were marked Invalid, as long as the router still has them in memory.

実装は、プロメモリがまだメモリ内にそれらを持っている限り、それらが無効になっているため、ピアに送信されなかったアナウンスメントをリストすることができるはずです。

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

This document does not create security considerations beyond those of [RFC6811] and [RFC8481]. By facilitating more correct validation, it attempts to improve BGP reliability.

この文書は、[RFC6811]と[RFC8481]のそれ以外のセキュリティ上の考慮事項を作成しません。より正確な検証を容易にすることで、BGPの信頼性を向上させようとします。

6. IANA Considerations
6. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4(BGP-4)」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。

[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.

[RFC5065] Traina、P.、McPherson、D.、およびJ.Scudder、2007年8月、<https://www.rfc-editor.org/情報/ RFC5065>。

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC6482] Lepinski、M.、Kent、S.、D.Kong、 "Route Origin承認のプロフィール(ROAS Origin認証のプロフィール(ROAS)、RFC 6482、DOI 10.17487 / RFC6482、2012年2月、<https:///www.rfc-Editor.org/info/rfc6482>。

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.

[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R.、およびR.Austein、RFC 6811、DOI 10.17487 / RFC6811、2013年1月、<https://ww.rfc-editor.org/info/rfc6811>。

[RFC7705] George, W. and S. Amante, "Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, <https://www.rfc-editor.org/info/rfc7705>.

[RFC7705]ジョージ、W.およびS. Amante、「自律システム移行メカニズムとBGP AS_PATH属性への影響」、RFC 7705、DOI 10.17487 / RFC7705、2015年11月、<https://www.rfc-editor.org/ info / rfc7705>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/RFC8174>。

[RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI)", RFC 8481, DOI 10.17487/RFC8481, September 2018, <https://www.rfc-editor.org/info/rfc8481>.

[RFC8481] BUSH、R。、「リソース公開鍵インフラストラクチャ(RPKI)」、RFC 8481、DOI 10.17487 / RFC8481、2018年9月、<https://www.rfc-editor.org/infoに基づくBGP起源検証への説明/ RFC8481>。

7.2. Informative References
7.2. 参考引用

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6480] Lepinski、M.およびS. Kent、「安全なインターネットルーティングをサポートするためのインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480>。

Acknowledgments

謝辞

Thanks to reviews and comments from Linda Dunbar, Nick Hilliard, Benjamin Kaduk, Chris Morrow, Keyur Patel, Alvaro Retana, Job Snijders, Robert Sparks, and Robert Wilton.

Linda Dunbar、Nick Hilliard、Chris Morrow、Keyur Patel、Alvaro retana、Job Snijders、Robert Sparks、Robert Wiltonのレビューやコメントをお紹介しています。

Authors' Addresses

著者の住所

Randy Bush Internet Initiative Japan & Arrcus 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America

Randy Bushインターネットイニシアチブジャパン&アーカス5147クリスタルスプリングスベインブリッジアイランド、ワシントン州98110アメリカ

   Email: randy@psg.com
        

Rüdiger Volk

Rüdigervolk

   Email: ietf@rewvolk.de
        

Jakob Heitz Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America

Jakob Heitz Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ

   Email: jheitz@cisco.com