📘

RFC 9234: UPDATEとOPENメッセージでロールを使用した経路漏洩の防止と検出

2024/01/14に公開

Security

RFC

bgp

tech

要旨

経路漏洩とは、BGPトポロジー関係の前提に違反するBGPプレフィックスの伝播のことをいう。例えば、あるトランジット・プロバイダから学習した経路を別のトランジット・プロバイダやラテラル (つまり、非・トランジット)ピアにアナウンスしたり、あるラテラルピアから学習した経路を別のラテラルピアやトランジット・プロバイダにアナウンスしたりすることである。経路漏洩は通常、BGP経路フィルタリングの設定ミスや欠落、あるいは自律システム(AS)間の調整不足の結果である。漏洩を防止するための既存の取り組みは、オペレータが経路設定に注意を払うことに依存しており、その設定が外部BGP(eBGP)ネイバーの設定に対応しているかどうかのチェックや、双方のeBGPスピーカーがピアリング関係に同意しているかどうかの確認は行われていない。本文書では、自律システム間のeBGPセッション毎にピアリング関係の合意を確立し、双方に適切な設定を強制するために、BGP OPENメッセージを拡張する。伝播された経路は、合意された関係に従ってマークされ、経路漏洩の防止と検出の両方が可能となる。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9234 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

経路漏洩とは、BGPトポロジー関係の前提に違反するBGPプレフィックスの伝播のことである。例えば、あるトランジット・プロバイダから学習した経路を別のトランジット・プロバイダやラテラル (つまり、非・トランジット)ピアにアナウンスしたり、あるラテラルピアから学習した経路を別のラテラルピアやトランジット・プロバイダにアナウンスしたりすることである。経路漏洩は通常、BGP経路フィルタリングの設定ミスや欠落、あるいは自律システム(AS)間の調整不足の結果である。

漏洩を防止するための既存のアプローチは、オペレータが経路設定に注意を払うことに依存しており、その設定が外部BGP(eBGP)ネイバーの設定に対応しているかどうかのチェックや、双方のeBGPスピーカーがピアリング関係に同意しているかどうかの確認は行われていない。本文書では、自律システム間のeBGPセッション毎にピアリング関係の合意を確立し、双方に適切な設定を強制するために、BGP OPENメッセージを拡張する。伝播された経路は、合意された関係に従ってマークされ、経路漏洩の防止と検出の両方が可能となる。

本文書は、前述のオペレータ主導の設定に基づく経路漏洩の防止方法を、経路漏洩の防止と検出のためのインバンド方法に置き換える手段を規定する。

この方法は、OPENメッセージ[RFC5492]のBGPロール・ケイパビリティーを使用してネゴシエートされる新しい設定パラメータ「BGPロール」を使用する。eBGPスピーカーは、BGP OPENを成功させるために、このケイパビリティーの使用とネイバーとのBGPロールの確認を必要とする。

セクション5では、「Only to Customer (OTC)」と呼ばれるオプションの推移型(ASを跨いで伝達可能な)BGPパス属性を規定する。これは、ASによる漏洩の発生を防止し、ASパスの途中で発生した漏洩を検出する。主な対象/適用範囲はインターネット(IPv4やIPv6のユニキャスト経路広告)である。

2. 要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

3. 用語

「ローカルAS」と「リモートAS」という用語は、eBGPセッションの両端を指すために使われる。「ローカルAS」とは、記載されているプロトコルの動きを実行するASのことで、「リモートAS」とは、考慮するeBGPセッションの相手方ASを指す。

本文書における「経路は不適格」という用語の使用は、[RFC4271]と同じ意味を持つ。つまり、「経路はLoc-RIBにインストールするのに不適格で、次の経路選択フェーズから除外される」という意味である。

3.1. ピアリング関係

この文書で定義し、使用するピアリング関係の用語(以下を参照)は、必ずしも支払い契約に基づくビジネス関係を表すものではない。これらの用語は、BGPの経路伝播に関する制限を表すために使用され、Gao-Rexfordモデル[GAO-REXFORD]として知られている。ここで使われている「プロバイダ(Provider)」、「カスタマ(Customer)」、「ピア(Peer)」という用語は、[RFC7908]で使われている用語「トランジット・プロバイダ」、「カスタマ」(顧客)、「ラテラル(つまり、非・トランジット)ピア」と同義である。

以下は、eBGPピアリングのBGPロールのリストと、それに対応する経路伝播の規定である。

ロール	経路伝播の規定
プロバイダ(Provider)	利用可能な経路はすべてカスタマに伝播してもよい(MAY)。
カスタマ(Customer)	カスタマ(顧客)から学習した経路、またはローカルで発信した経路をプロバイダに伝播してもよい(MAY) 。それ以外の経路は伝播してはならない(MUST NOT)。
ルートサーバ(RS)	利用可能な経路をルートサーバ・クライアント(RS-Client)に伝播してもよい(MAY) 。
ルートサーバ・クライアント(RS-Client)	カスタマから学習した経路、またはローカルで発信した経路をRSに伝播してもよい(MAY)。それ以外のすべての経路は伝播してはならない(MUST NOT)。
ピア(Peer)	カスタマから学習した経路、またはローカルで発信した経路をピアに伝播してもよい(MAY)。それ以外のすべての経路は伝播してはならない(MUST NOT)。

ローカルASが上記の役割(表示された順)のいずれかの場合、対応するリモートASとのピアリング関係はそれぞれ、Provider-to-Customer(プロバイダからカスタマ)、Customer-to-Provider(カスタマからプロバイダ)、RS-to-RS-Client(RSからRSクライアント)、RS-Client-to-RS(RS クライアントからRS)、Peer-to-Peer(つまり、ラテラルピア)である。これらは通常のピアリング関係と呼ばれる。

ローカルASがリモートASと複数のピアリング・ロールを持つ場合、そのようなピアリング関係は「複合的」(Complex)と呼ばれる。例えば、ピアリング関係が、あるプレフィックスではProvider-to-Customerで、他のプレフィックスではPeer-to-Peerの場合である[GAO-REXFORD]。

BGPスピーカーはポリシーを適用してアナウンスする経路を減らすことができ、受信者はポリシーを適用して受け入れる経路を減らすことができる。

上記の経路伝播ルールに違反すると、経路漏洩[RFC7908]を引き起こす可能性がある。これらのルールの自動実施は、手動の設定ミスで起こり得る経路漏洩を大幅に減らすはずである。

セクション5で規定するように、OTC属性はピア、プロバイダ、またはRSから受信したAS内のすべての経路を識別するために使われる。

4. BGPロール

BGPロールは、セッションを形成するeBGPスピーカー間の関係を特徴付ける。以下に説明するロールの1つは、各eBGPセッション(セクション3の定義を参照)ごとに、ローカルASのロールに関する情報に基づいて、ローカルASで設定する必要がある(SHOULD)。唯一の例外は、eBGP接続が複合的な場合である(セクション6を参照)。BGPロールは、各eBGPセッションでBGPロール・ケーパビリティ(セクション4.1で説明)を使用して互いに確認できる。

eBGPセッションに許可されるロールは次のとおり:

ロール	説明
プロバイダ(Provider)	ローカルASはリモートASのトランジット・プロバイダである。
カスタマ(Customer)	ローカルASはリモートASのトランジットのカスタマである。
RS	ローカルASはルートサーバ(通常はインターネット交換ポイントにある)であり、リモートASはそのRSクライアントである。
RSクライアント(RS-Client)	ローカルASはRSのクライアントであり、RSはリモートASである。
ピア(Peer)	ローカルASとリモートASはピアである(つまり、ラテラル・ピアリング関係がある)。

4.1. BGPロール・ケーパビリティ

BGPロール・ケーパビリティは以下のように定義する:

コード: 9
長さ: 1 (オクテット)
値: スピーカーのBGPロールに対応する整数(表1を参照)

値	(ローカルASの)ロール名
0	プロバイダ
1	RS
2	RSクライアント
3	カスタマ
4	ピア(つまり、ラテラルピア)
5-255	未割り当て

表1: 定義済のBGPロール値

⚠️ OPENメッセージ(Wireshark)

BGPロールがローカルに設定されている場合、eBGPスピーカーはBGP OPENメッセージでBGPロール・ケーパビリティを広告しなければならない(MUST) 。eBGPスピーカーは、複数のBGPロール・ケーパビリティを広告してはならない(MUST NOT)。複数のBGPロール・ケーパビリティを受信したときのエラー処理については、セクション4.2で説明する。

4.2. ロールの正確性

セクション4.1では、 BGPロールがAS間の各eBGPセッションの関係をどのように符号化するかを説明している。

BGPロール・ケーパビリティを受信しただけでは、eBGPネイバー間のロールの合意が自動的に保証されるわけではない。BGPロール・ケーパビリティを広告し、ピアからも受信した場合に、ロールは表2の関係に対応しなければならない(MUST)。ロールが合致しなければ、BGPスピーカーはロール不一致Notification(コード 2、サブコード11)を使って接続を拒否しなければならない(MUST)。

ローカルASのロール	リモートASのロール
プロバイダ	カスタマ
カスタマ	プロバイダ
RS	RSクライアント
RSクライアント	RS
ピア	ピア

表2: 許可されるロール・ケーパビリティのペア

⚠️ BGPロールのあるネットワーク

BGPロール・ケーパビリティを送信したのに、相手からBGPロールを受信しなかった場合、下位互換性のために、BGPスピーカーはBGPロール・ケーパビリティがないことを無視して、セッション確立を続行する必要がある(SHOULD)。ローカルに設定したBGPロールは、セクション5で説明する手順で使用される。

⚠️ BGPロールの設定 (FRRとOpenBSD)

FRRは、次のルールで設定できる。https://docs.frrouting.org/en/latest/bgp.html#bgp-roles-and-only-to-customers

neighbor PEER local-role LOCAL-ROLE [strict-mode]

strict-modeを設定すると(デフォルト無効)、ネイバーがロールを設定するまでBGPセッションを確立しない(相手側にロールの設定を強制するために使われる)。
プロバイダ、RSサーバ、ピアから送信された経路には、後述のOnly-to-Customer (OTC)属性が付けられる。
OTC属性を持つ経路は、自身のlocal-roleがプロバイダまたはRSサーバの場合のみ、そのネイバーに送ることができる。また、local-roleがカスタマかRSクライアントの場合のみ受信できる。
互いにピアの場合、OTC値がネイバーのAS番号と等しい場合にのみ受信できる。

プロバイダの設定例:

router bgp 65000
  no bgp ebgp-requires-policy
  neighbor 192.168.1.2 remote-as 65001
  neighbor 192.168.1.2 local-role provider

カスタマの設定例:

router bgp 65001
  no bgp ebgp-requires-policy
  neighbor 192.168.1.1 remote-as 65000
  neighbor 192.168.1.1 local-role customer

OpenBSDは、neighborプロパティに次のルールが設定できるhttps://man.openbsd.org/bgpd.conf

role (none|provider|customer|rs|rs-client|peer)
announce policy (yes|no|enforce)

roleにローカルロールを設定する。IBGPでは強制的にnoneになる。
announce policyがyesに設定するとロール機能が有効になる。enforceを設定すると、相手にもケーパビリティが強制される。デフォルトはnoである。

設定例:

neighbor 192.168.1.2 {
        remote-as 65001
        role provider
        announce policy yes
}

オペレータは、リモートASにBGPロール・ケーパビリティを要求する「strict mode」(厳格モード)の適用を選択できる。「strict mode」で運用する場合、BGPロール・ケーパビリティを送信しても受信できない場合、ロール不一致Notification(コード2、サブコード11)を使用して接続は拒否される。セクション8のコメントを参照のこと。

⚠️NOTIFICATIONメッセージ (Wireshark)

Wireshark 4.2.2のデフォルトでは、サブコード11はUnknown。

eBGPスピーカーは、それぞれに同じ値を持つ複数のBGPロール・ケーパビリティを受信した場合、スピーカーはそれらを1つのBGPロール・ケーパビリティとみなして処理を進める[RFC5492]。複数のBGPロール・ケーパビリティを受信し、そのすべてが同じ値ではない場合、BGPスピーカーはロール不一致Notification(コード2、サブコード11)を使って、接続を拒否しなければならない(MUST)。

⚠️ 複数のBGPロール・ケーパビリティを受信とは

BGPロール・ケーパビリティは、ピアリング関係の中で設定されるものなので、AS内にリモートASと複数の出入口を持ち、それぞれのピアリングで異なるロールを持つ可能性がある。セクション3.1では、「複数のピアリング・ロールを持つ場合、そのようなピアリング関係は複合的と呼ばれる」と記載されており、セクション6では、「複合的なピアリング関係を持つeBGPセッションにロールを設定してはならない」とある。

ローカルASのBGPロール値(受信したUPDATEメッセージのOTC属性と組み合わせて)は、セクション5で説明する経路漏洩の防止および検出手順で使用される。

5. BGP Only to Customer (OTC)属性

OTC属性は、属性タイプコード35、長さ4オクテットのUPDATEメッセージのオプションの推移型パス属性である。この属性の目的は、経路をカスタマ、ピア、RSクライアント(セクション3.1の定義を参照)に送る際、その経路がカスタマにのみ送られることを強制することにある。属性値は、後述の手順で決定されるAS番号(ASN)である。

⚠️ OTC属性 (Wireshark)

次のイングレス(入口)手順は、経路受信時のOTC属性の処理に適用される:

OTC属性を持つ経路をカスタマまたはRSクライアントから受信した場合、それは経路漏洩であり、不適格とみなされなければならない(MUST) (セクション3参照)。

⚠️ 不適格な理由

OTC属性を持つ経路は、プロバイダ、RS、ピアからしか来ないため。
OTC属性を持つ経路をピア(つまり、ピアのロールを持つリモートAS)から受信し、その属性の値がリモート(つまり、ピアの)AS番号と等しくない場合、それは経路漏洩であり、不適格とみなされなければならない(MUST)。
プロバイダ、ピア、RSから経路を受信し、OTC属性が存在しない場合は、リモートASのAS番号に等しい値を追加しなければならない(MUST)。

次のエグレス(出口)手順は、経路広告におけるOTC属性の処理に適用される:

経路をカスタマ、ピア、RSクライアント(送信者がRSの場合)に広告され、OTC属性が存在しない場合、ローカルASのAS番号と同じ値をOTC属性に追加しなければならない(MUST)。
経路が既にOTC属性を含む場合、その経路をプロバイダ、ピア、RSに伝播してはならない(MUST NOT)。

上で説明した手順は、ローカルASでの漏洩防止と、複数ホップ先での漏洩検出と軽減の両方を提供する。ローカルASでの防止の場合、OTC属性の存在は、経路がピア、プロバイダ、RSから学習されたことをエグレスルータに示し、その経路はカスタマにのみ広告できる。ローカルに設定される同じOTC属性は、カスタマ、ピア、またはRSクライアントから経路を受信した場合、複数ホップ離れたASによる経路漏洩を検出する方法も提供する。例えば、あるASがピアに送信した経路にOTC属性を設定し、その後、準拠ASがその経路をカスタマから受信した場合、受信ASは(OTC属性の存在に基づいて)その経路が漏洩であることを検出できる。

⚠️ BGP OTCネットワーク

OTC属性は、リモートASのエグレスまたはローカルASのイングレスで設定される。つまり、リモートASが本仕様に準拠していない場合、ローカルASはOTC属性が存在していなければ、OTC属性を設定しなければならない。どちらのシナリオでも、OTC値は同じになる。これにより、スキームはより堅牢になり、アーリーアダプタにもメリットがある。

⚠️ OTC属性を付加する場所

長さの値が4でない場合、OTC属性は不正であると見なされる。不正なOTC属性を持つUPDATEメッセージは、「Treat-as-withdraw」[RFC7606]のアプローチを使って処理することになる(SHALL)。

⚠️ Treat-as-withdraw

Treat-as-withdrawとは、UPDATEメッセージの処理でエラーが発生した場合、BGPセッションをクローズするのではなく、エラーとなったUPDATEメッセージに含まれる経路を撤回(withdraw)扱いにすることをいう。

本文書で規定されているBGPロールのネゴシエーションとOTC属性に基づく手順は、ASコンフェデレーション[RFC5065]内の自律システム間で使用することは推奨しない(NOT RECOMMENDED)。ASコンフェデレーションのエグレスでOTC属性が追加される場合、その値はASコンフェデレーション識別子と等しくなければならない(MUST)。また、ASコンフェデレーションのエグレスにおいて、UPDATEにASコンフェデレーション識別子以外のメンバーAS番号に対応する値を持つOTC属性を含んではならない(MUST NOT)。

インターネットに面したASN(例えば、データセンター・ネットワーク[RFC7938]やスタブ・カスタマ)の後方でプライベートAS番号を使用するシナリオでは、本文書で規定されている手順を使用できるが、詳細は本文書の範囲外である。インターネットに面したASからのエグレスにおいて、OTC属性はインターネットに面したASN以外の値を含んではならない(MUST NOT)。

一旦、OTC属性が設定されると、それは変更されずに保持しなければならない(MUST)(これはASコンフェデレーションにも適用される)。

記載されているイングレスとエグレスの手順は、いずれの場合もアドレスファミリAFI 1(IPv4)とAFI 2(IPv6)のSAFI 1(ユニキャスト)のみに適用され、デフォルトで他のアドレスファミリに適用してはならない(MUST NOT)。オペレータは、このセクションで定義された手順を変更する能力を持ってはならない(MUST NOT)。

6. 追加の考慮事項

複合的なピアリング関係を持つeBGPセッションにロールを設定してはならない(MUST NOT)。複数のeBGPセッションが複合的なピアリング関係を、通常のピアリング関係を持つeBGPセッションに分ける場合、BGPロールは結果として得られる各eBGPセッションで使用する必要がある(SHOULD)。

⚠️ 複合的なピアリング関係

「複合的」なピアリング関係も存在する。ローカルASがリモートASと複数のピアリングの役割を持つ場合である。例えば、お互いが受信したプレフィックスを意図的にピアやトランジット・プロバイダに送信するピアリング関係が考えられる。複数の複合的なピアリング関係から、複合的な部分を分離できる場合、複合的なピアリングの役割は、異なる通常のBGPセッションに分離することができ、BGPロールは、通常のBGPセッションで使用できる。

オペレータは、セクション3.1に記載されているピアリング関係の定義に従うよう、プレフィックスごとにポリシーを設定することで、同等の結果を達成したいと思うかも知れない。しかし、その場合、プレフィックスごとのピアリング設定の正確性をインバンドでチェックを行う手段がない。

BGPロールおよび/またはOTC属性の設定を誤ると、プレフィックス伝播に影響を与える可能性がある。さらに、この文書では、OTC属性内の不正なAS番号に対する特別な処理は規定しない。

ASの移行シナリオ[RFC7705]では、ルータが自身を複数の異なるASのいずれかと表すことがある。セクション5のエグレス手順では、OTC属性が経路送信の一部として付加することを規定しているので、これは問題にはならない。したがって、ルータはOTC値を、現在自身を表すASNと同じ設定をすることが期待される。

[RFC7606]のセクション6では、「Treat-as-withdraw」動作が及ぼし得る悪影響が記載されている。そのような悪影響には、フォワーディング・ループやトラフィックのドロップが含まれる。また、この動作に関連するデバッグの考慮事項についても言及する。

7. IANAに関する考慮事項

IANAは、新しいBGPケーパビリティ(セクション4.1)を、「IETFレビュー」の範囲内の「ケーパビリティ・コード」登録簿に登録した[RFC5492]。新しいケーパビリティの種類は「BGPロール」である。IANAは値9を割り当てた。この文書は新しいケーパビリティのための照会先となる。

IANAは、「ケーパビリティ・コード」登録簿の中に「BGPロール値」と呼ばれる新しい副登録簿を作成し、管理している。登録簿には、値、ロール名、定義文書への照会先を含んでいる。IANAは表3の値を登録している。今後の割り当ては、[RFC8126]で定義されている「IETFレビュー」ポリシーによって行われる。

BGPロール値	ロール名 (ローカルASの場合)	参照先
0	プロバイダ	本文書
1	RS	本文書
2	RSクライアント	本文書
3	カスタマ	本文書
4	ピア (つまり、ラテラルピア)	本文書
5-255	IETFレビューにより割り当てられる予定	本文書

表3: BGPロールのIANA登録簿

IANAは、「Role Mismatch」(セクション4.2参照)という新しい「OPEN メッセージ・エラー・サブコード」登録簿に登録した。IANAは値11を割り当てた。この文書はこの新しいサブコードの照会先である。

IANAは、値8、9、10の不適正使用(improper use)のため、「OPENメッセージ・エラー・サブコード」登録簿の値8～10を「非推奨」(Deprecated)とした。この文書は照会先として記載されている。

IANAはまた、「Only to Customer (OTC)」という新しいパス属性を「BGPパス属性」登録簿に登録した(セクション5参照)。IANAはコード値35を割り当てた。この文書は新しい属性の照会先である。

8. セキュリティに関する考慮事項

BGP のセキュリティに関する考慮事項([RFC4271]と[RFC4272]で規定)が適用される。

本文書は、BGPポリシーの設定ミスに起因する経路漏洩の防止と検出のために、BGPロールを利用するメカニズムを提案する。BGPロールの設定ミスは、プレフィックスの伝播に影響を与える可能性がある。例えば、ダウンストリーム(つまり、カスタマ方向)のピアリング・リンクがプロバイダまたはピアロールと、誤って設定された場合、この方向に広告できるプレフィックス数が制限される。一方、アップストリーム・プロバイダが(ローカルASによって)カスタマロールと誤って設定した場合、他のプロバイダまたはピアから受信した経路を伝播することになるかも知れない。しかし、BGPロールのネゴシエーションとその結果としてのロールの確認によって、そのような設定ミスは起こりにくくなる。

BGPロールのネゴシエーションのstrict modeをデフォルトに設定すると、ソフトウェア・アップデート後にeBGPセッションが立ち上がらないという状況が発生する可能性がある。このようなデフォルト動作の実装は強く推奨しない。

OTC属性を削除したり、その値を変更すると、経路漏洩の検出の機会を制限する可能性がある。このような行為は、オンパス攻撃の一部として意図的に行われる可能性がある。例えば、ASは受信した経路のOTC属性を削除し、その経路をトランジット・プロバイダに漏洩する可能性がある。この種の脅威はBGPでは新しいものではなく、あらゆる属性にも影響を与える可能性がある(BGPsec[RFC8205]はASパス属性に対してのみ保護を提供していることに注意)。

経路がカスタマからプロバイダに広告される際にOTC属性を追加すると、経路の伝播が制限される。そのような経路は、直属のプロバイダ、またはそのピアや上位層のプロバイダから不適格と見なされる可能性がある。この種のOTC属性の追加は、プロバイダ側では、カスタマへのトラフィック量を制限するため起こりにくい。カスタマ側でも、トラフィック・エンジニアリング目的でOTC属性を追加することは、予測できない方法で経路伝播を制限することになるため推奨しない。

9.参考文献

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

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

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

[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, <https://www.rfc-editor.org/info/rfc7908>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

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

9.2 参考規格

[GAO-REXFORD] Gao, L. and J. Rexford, "Stable Internet routing without global coordination", IEEE/ACM Transactions on Networking, Volume 9, Issue 6, pp. 689-692 , DOI 10.1109/90.974523, December 2001, <https://ieeexplore.ieee.org/document/974523>.

⚠️ 参考URL

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/info/rfc4272>.

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

[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/info/rfc7938>.

[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

謝辞

著者らは、この作業中にレビュー、コメント、提案をいただいたアルヴァロ・レナータ、ブルーノ・デクレーヌ、ジェフ・ハース、ジョン・スカダー、スー・ハレス、ベン・マジソン、アンドレイ・ロバチェフスキー、ダニエル・ピンスバーグ、リュディガー・ヴォルク、パヴェル・ルーニン、ギャン・ミシュラ、イグナス・バグドナスに感謝する。また、多くのIESGの査読者のコメントにより、文書の明確さ、正確さ、表現が大幅に完全されたことにも感謝する。

貢献者

ブライアン・ディクソン
個人
メール: brian.peter.dickson@gmail.com

ダグ・モンゴメリー
米国国立標準技術研究所
メール: dougm@nist.gov

著者のアドレス

アレクサンダー・アジモフ
Qrator Labs & Yandex
ウリツァ・ルヴァ・トルストゴ 16
モスクワ
119021
ロシア連邦
メール: a.e.azimov@gmail.com

ユージン・ボゴマゾフ
Qrator Labs
1-y Magistralnyy tupik 5A
モスクワ
123290
ロシア連邦
メール: eb@qrator.net

ランディ・ブッシュ
インターネットイニシアティブ & 株式会社アーカス
5147 クリスタルスプリングス
ベインブリッジ島、ワシントン州 98110
アメリカ合衆国
メール: randy@psg.com

ケユル・パテル
アーカス
2077 ゲートウェイプレイス
スイート #400
カリフォルニア州サンノゼ 95119
アメリカ合衆国
メール: keyur@arrcus.com

コティカラプディ・スリラム
米国国立標準技術研究所
100 ビューロードライブ
ゲイサーズバーグ、メリーランド州 20899
アメリカ合衆国
メール: ksriram@nist.gov

変更履歴

2024.1.14
2024.1.15
2014.1.16
2024.1.18
2024.1.25
2024.1.28
2024.1.31
2024.3.14: transitive/non-transitive
2024.7.10: 複雑→Complex
2024.8.1: Complex→複合的

GitHubで編集を提案

要旨