Zenn
🐞

RFC 8205: BGPsecプロトコル仕様

2024/05/22に公開
Security
RFC
bgp
tech

要旨

本文書は、BGP UPDATEメッセージが通過する自律システム(AS)パスにセキュリティを提供する、ボーダー・ゲートウェイ・プロトコル(BGP)の拡張であるBGPsecについて説明する。BGPsecは、UPDATEメッセージを伝播する各ASで生成されたデジタル署名を伝送する、任意非推移型BGPパス属性によって実装される。このデジタル署名は、UPDATEメッセージに列挙されているASパス上のすべてのASが、経路広告を明示的に認可しているという信用を提供する。

本文書の位置付け

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

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

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

著作権表示

Copyright (c) 2017 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

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

1. はじめに

本文書では、ボーダー・ゲートウェイ・プロトコル(BGP)[RFC4271]の経路広告にパス・セキュリティを提供するメカニズム、BGPsecについて説明する。つまり、有効なBGPsec UPDATEメッセージを受信したBGPスピーカーは、広告された経路が「UPDATEメッセージに列挙されたASパス上のすべての自律システム(AS)がパスの後続ASへの経路広告を明示的に認可している」特性を持つことを暗号的に保証することである。

本文書は、任意(非推移型)BGPパス属性、BGPsec_PATHを規定する。また、BGPsec準拠のBGPスピーカー(以下、BGPsecスピーカーと呼ぶ)が、上記の保証を得るために、この属性を含むBGP UPDATEメッセージを生成、伝播、検証する方法を説明する。

BGPsecは、BGPオリジン検証[RFC6483] [RFC6811]を補完するために使用することを目的としており、オリジン検証と組み合わせて使用することで、BGPに対するさまざまな経路ハイジャック攻撃を防ぐことができる。

BGPsecは、AS番号とIPアドレス・リソースの割り当てを証明するリソース公開鍵基盤 (RPKI)証明書に依存している。(RPKIの詳細については、RFC 6480[RFC6480]とそこで参照されている文書を参照のこと。) BGPsec_PATHを含むBGP UPDATEメッセージを外部(eBGP)ピアに送信したいBGPsecスピーカーは、BGPsecスピーカーのAS番号に対応するRPKIルータ証明書[RFC8209]に関連付けられた秘密鍵を所有する必要がある。一方、BGPsecスピーカーは、BGPsec_PATH属性を含む受信したUPDATEメッセージを検証するために、そのような証明書を必要としないことに留意する(セクション5.2を参照)。

1.1. 要件言語

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

2. BGPsecのネゴシエーション

本文書は、BGPスピーカーがBGPsec UPDATEメッセージ (つまり、BGPsec_PATH属性を含むUPDATEメッセージ)を送信または受信する能力をネイバーに広告できるようにするBGPケーパビリティ[RFC5492]を定義する。

2.1. BGPsecケーパビリティ

このケーパビリティは、ケーパビリティ・コード「7」を持つ。

このケーパビリティのケーパビリティ長は「3」に設定しなければならない(MUST)。

ケーパビリティ・フォーマットの3オクテットを、図1で規定する。

fig01
図1: BGPsecケーパビリティ・フォーマット

最初のオクテットの最初の4ビットは、BGPスピーカーがサポートを広告しているBGPsecのバージョンを示す。本文書では、BGPsecバージョン0(4ビットすべてが0に設定)のみを定義する。他のバージョンのBGPsecは将来の文書で定義するかもしれない。BGPsecスピーカーは、BGP OPENメッセージに複数のバージョンのBGPsecケーパビリティを含めることで、複数バージョンのBGPsecのサポートを広告してもよい(MAY)。

第1オクテットの第5ビットは方向ビットで、BGPスピーカーがBGPsec UPDATEメッセージを送信するケーパビリティを広告しているか、BGPsec UPDATEメッセージを受信するケーパビリティを広告しているかを示す。BGPスピーカーは、BGPsec UPDATEメッセージを受信できることを示すために、このビットを0に設定する。BGPスピーカーは、BGPsec UPDATEメッセージを送信できることを示すために、このビットを1に設定する。

第1オクテットの残りの3ビットは未割り当てで、将来使用するために割り当てられている。これらのビットは、ケーパビリティの送信者によって0に設定され、ケーパビリティの受信者に無視される。

第2オクテットと第3オクテットは、16ビットのアドレスファミリー識別子(AFI)を含み、BGPsecスピーカーがBGPsecのサポートを広告しているアドレスファミリーを示す。本文書は、IPv4とIPv6という2つのアドレスファミリーで使用するBGPsecのみを規定し、それぞれAFI値は1と2を持つ[IANA-AF]。他のアドレスファミリーで使用するBGPsecは、将来の文書で規定されるかも知れない。

2.2. BGPsecサポートのネゴシエーション

BGPスピーカーが(特定のアドレスファミリに対して)BGPsec UPDATEメッセージを送信する意思があることを示すために、BGPスピーカーは方向ビット(第1オクテットの第5ビット)を1に設定して、BGPsecケーパビリティ(セクション2.1を参照)を送信する。BGPsec_PATH属性を含むBGPsec UPDATEメッセージを(特定のアドレスファミリーに対して)受信する意思があることを示すために、BGPスピーカーは方向ビットを0に設定してBGPsecケーパビリティを送信する。BGPsec UPDATEメッセージの送受信の両方のケーパビリティを広告するため、BGPスピーカーはBGPsecケーパビリティの2つのコピー(方向ビットが0に設定したコピーと、方向ビットを1に設定したコピー)を送信する。

同様に、BGPスピーカーが同じBGPセッション上で2つの異なるアドレスファミリー(IPv4とIPv6)でBGPsecを使いたい場合、スピーカーはBGP OPENメッセージこのケーパビリティの2つのインスタンス(アドレスファミリーごとに1つ)を含める。BGPスピーカーがBGPマルチプロトコル拡張[RFC4760]をサポートしていない場合、BGPsecケーパビリティをアナウンスしてはならない(MUST NOT)。さらに、BGPスピーカーは、同じAFIのマルチプロトコル拡張ケーパビリティ[RFC4760]も広告していない限り、特定のAFIのBGPsecサポート・ケーパビリティを広告してはならない(MUST NOT)。

BGPsecピアリング・セッションにおいて、ピアがBGPsec_PATH属性を含むUPDATEメッセージを送信することが許可されるのは、次の場合に限る:

  • ピアは、特定のバージョンのBGPsecと特定のアドレスファミリーに対するBGPsecケーパビリティを、方向ビットを1に設定して送信する。

  • もう一方の(受信側)ピアは、同じバージョンのBGPsecと同じアドレスファミリーのBGPsecケーパビリティを、方向ビットを0に設定して送信する。

このようなセッションでは、特定のアドレスファミリーに対して特定のバージョンのBGPsecの使用がネゴシエートされたと言える。従来のBGP UPDATEメッセージ(つまり、署名なし、AS_PATH属性を含む)は、BGPsecの使用が正常にネゴシエートされたかどうかに関係なく、セッション内で送信してもよい(MAY)。ただし、BGPsecが正常にネゴシエートされない場合、BGPsec_PATH属性を含むBGP UPDATEメッセージを送信してはならない(MUST NOT)。

本文書では、BGPsecバージョン0がネゴシエートに成功した唯一のバージョンである場合の実装の動作を定義する。BGPsecの追加バージョンを規定する将来の文書では、複数のバージョンのサポートがネゴシエートされた場合の動作を規定する必要がある。

BGPsecは、4バイトAS番号をサポートなしでは、意味のあるセキュリティ保証を提供できない。したがって、BGPsecケーパビリティをアナウンスするBGPスピーカーは、4バイトASサポートのケーパビリティもアナウンスしなければならない[RFC6793]。もし、BGPスピーカーがBGPsecケーパビリティを送信するが、4バイトASサポートのケーパビリティを送信しない場合、BGPsecは正常にネゴシエートされないため、そのようなセッション内でBGPsec_PATH属性を含むUPDATEメッセージを送信してはならない(MUST NOT)。

⚠️ BGPsecケーパビリティ

WiresharkのSample CapturesにBGPsec(RFC 8205)のパケットキャプチャが掲載されている。これを見ると、IPv4/IPv6で送受信とした場合、4つのケーパビリティが送信されていることが分かる。

bgpsec-cap

3. BGPsec_PATH属性

BGPsec_PATH属性は、任意非推移型BGPパス属性である。

本文書では、この属性の属性タイプコードBGPsec_PATHを登録する(セクション9を参照)。

BGPsec_PATH属性は、UPDATEメッセージが通過するASパスに関する保護された情報を運ぶ。これには、パス情報を保護するために使用されるデジタル署名が含まれる。BGPsec_PATH 属性を含むUPDATEメッセージを「BGPsec UPDATEメッセージ」と呼ぶ。BGPsec_PATH属性は、BGPsec UPDATEメッセージのAS_PATH属性を置き換える。つまり、BGPsec_PATH属性を含むUPDATEメッセージはAS_PATH属性を含んではならず(MUST NOT)、逆も同様。

BGPsec_PATH属性は、いくつかの部分で構成されている。図2の概要図は、BGPsec_PATH属性の構造の概要を示している。(図2で使用されている「SKI」は「サブジェクト鍵識別子」を意味する。)

fig02
図2: BGPsec_PATH属性の概要図

図3は、BGPsec_PATH属性のフォーマットの仕様を示す。

fig03
図3: BGPsec_PATH属性のフォーマット

Secure_Pathには、BGPsec UPDATEメッセージのASパス情報が含まれる。これは、論理的には、非BGPsec AS_PATH属性に含まれる情報と等価である。Secure_Path情報は、AS_PATH情報が非BGPsecスピーカーで使用されるのと同じ方法で、BGPsecスピーカーで使用される。Secure_Pathのフォーマットは、以下のセクション3.1で説明する。

BGPsec_PATH属性は1つまたは2つのSignature_Blockを含み、それぞれが異なるアルゴリズム・スイートに対応する。各Signature_Blockには、Secure_Path内の各AS番号の署名セグメント(つまり、Secure_Pathセグメント)が含まれる。最も一般的なケースでは、BGPsec_PATH属性は1つの Signature_Blockのみが含まれる。しかし、旧アルゴリズム・スイートから新しいアルゴリズム・スイートへの移行を(フラグデイなしで)を可能にするには、移行期間中に2つのSignature_Blocks(旧アルゴリズム・スイート用と新しいアルゴリズム・スイート用)を含める必要がある。(アルゴリズム移行の詳細については、セクション6.1を参照。) Signature_Blocksのフォーマットについては、以下のセクション3.2で説明する。

⚠️ BGPsec_PATH属性

セキュアパス情報とそれに対応する署名ブロックがあるのが分かる。セキュアパス情報は残念ながら、1つのASのパス情報しかないが、複数のASをまたがって到着した情報であれば、セキュアパス・セグメントが複数となる。署名ブロックについても、通過したAS分の署名セグメントが付加される。(RFC 8608付録A参照)

bgpsec-path

NLRI情報については、セクション4.1で述べられているように、MP_REACH_NLRI属性の中にある。ただし、

BGPsec UPDATEメッセージは、1つのプレフィックスの経路のみ広告しなければならない(MUST)。BGPsecスピーカーが複数のプレフィックスの経路を広告したい場合、プレフィックスごとに個別のBGPsec UPDATEメッセージを生成しなければならない(MUST)。

とあるが、このサンプルには、2つのプレフィックス経路が含まれている。このサンプルは間違っている可能性がある。

bgpsec-path

3.1. Secure_Path

ここでは、BGPsec_PATH属性のSecure_Path情報の詳細を説明する。Secure_Pathフィールドの仕様を図4と5に示す。

fig04
図4: Secure_Pathのフォーマット

Secure_Path長には、Secure_Path全体の長さ(オクテット単位)が含まれる(この長さフィールドを表現するために使用される2オクテットを含む)。以下に説明するように、各Secure_Pathセグメントの長さは6オクテットである。これは、Secure_Path長が Secure_Pathセグメント数(つまり、パス内のAS番号の数)の6倍より2大きいことを意味することに留意する。

Secure_Pathには、UPDATEメッセージで指定されたプレフィックスの発信元ASまでのパスの各ASに対して、1つのSecure_Pathセグメント(図5を参照)が含まれる。(注: 以下で説明するように、繰り返されるASはpCountフィールドを使用して「圧縮」される。)

fig05
図5: Secure_Pathセグメントのフォーマット

AS番号(図5)は、このSecure_PathセグメントをBGPsec_PATH属性に追加したBGPスピーカーのAS番号である。(このフィールドへの入力の詳細については、セクション4を参照。)

pCountフィールドは、署名がカバーする関連するAS番号の繰り返し数を含む。このフィールドは、BGPsecスピーカーが複数の署名を生成することなく、AS_PATHの前に複数のASのコピーを追加するセマンティクスを模倣できるようになる。[RFC4271]のセクション9.1.2.2(「タイブレーク(フェーズ2)」)で、経路選択プロセスで使用されるAS_PATH属性の「AS番号の数」について言及していることに留意する。この指標(AS番号の数)は、BGPsec_PATH属性のpCount値を合計して、BGPsecで取得されるASパス長と同じである。pCountフィールドは、経路サーバ(セクション4.2を参照)、ASコンフェデレーション(セクション4.3を参照)、およびAS番号のマイグレーション(詳細は[RFC8206]を参照)を管理する際にも有用である。

⚠️ pCountフィールドについて

pCountがない場合 (5つの署名)

AS-PATH: X Y Z Z Z

pCountがある場合 (3つの署名)

pCount: 1 1 3

AS-PATH: X Y Z

図5のFlagsフィールドの左端(つまり、最上位)ビットは、Confed_Segmentフラグである。Confed_Segmentフラグを1に設定することで、このSecure_Pathセグメントを構築したBGPsecスピーカーが同じASコンフェデーレション内のピアASにUPDATEメッセージを送信していることを示す[RFC5065]。(つまり、非BGPsec UPDATEメッセージ内でAS_CONFED_SEQUENCEタイプのAS_PATHセグメントが発生するたびに、連続するConfed_Segmentフラグの数列がBGPsec UPDATEメッセージに設定される。) それ以外の場合、Confed_Segmentフラグは0に設定される。

Flagsフィールドの残りの7ビットは未割り当てである。送信者はこれらを0に設定し、受信者は無視しなければならない(MUST)。ただし、署名はFlagsフィールドの8ビットすべてに対して計算されることに留意する。

セクション2.2で前述したように、BGPsecピアリングはピアリングASがそれぞれ4バイトのAS番号をサポートしなければならない(MUST)。現在割り当てられている2バイトAS番号は、4オクテット・フィールドの上位2オクテットを0に設定することで4バイトAS番号に変換される[RFC6793]。

3.2. Signature_Block

BGPsec_PATH属性のSignature_Blocksの詳細については、図6と7を使用して説明する。

fig06
図6: Signature_Blockのフォーマット

図6のSignature_Block長は、Signature_Blockの総オクテット数である(この長さフィールドを表現するために使用される2オクテットを含む)。

アルゴリズム・スイート識別子は、各署名セグメントでデジタル署名を生成するために使用されるダイジェスト・アルゴリズムとデジタル署名アルゴリズムを指定する1オクテットの識別子である。BGPsecで使用されるアルゴリズム・スイート識別子のIANAレジストリは、BGPsecアルゴリズム文書[RFC8208]で規定されている。

図6のSignature_Blockは、BGPsec_PATH属性のSecure_Path部分の各Secure_Pathセグメントに対して正確に1つの署名セグメント(図7を参照)を持つ(つまり、UPDATEメッセージのプレフィックスに対するパス上の個別のASごとに1つの署名セグメントを持つ)。

fig07
図7: 署名セグメントのフォーマット

図7のサブジェクト鍵識別子(SKI)フィールドには、署名の検証に使用されるRPKIルータ証明書 [RFC6487]のサブジェクト鍵識別子拡張の値が含まれる(BGPsec UPDATEメッセージの有効性の詳細については、セクション5を参照)。SKIフィールドのサイズは20オクテットの固定サイズである。SKIサイズの考慮事項については、セクション6.2を参照のこと。

⚠️ サブジェクト鍵識別子

サブジェクト鍵識別子とは、サブジェクト公開鍵をDERで符号化したASN.1ビット列値の160ビットSHA-1ハッシュ値である。

署名長フィールドには、署名セグメントの署名フィールドの値のサイズ(オクテット単位)を含む。

図7の署名フィールドには、プレフィックスとBGPsec_PATH属性を保護するデジタル署名を含む(署名の生成と検証の詳細については、それぞれセクション4と5を参照のこと)。

4. BGPsec UPDATEメッセージ

セクション4.1では、BGPsec UPDATEメッセージ、つまりBGPsec_PATH属性を含むUPDATEメッセージの作成に関する一般的なガイダンスを提供する。

セクション4.2では、BGPsecスピーカーがBGPsec UPDATEメッセージに含むためのBGPsec_PATH属性を生成する方法を指定する。

セクション4.3には、ASコンフェデレーション[RFC5065]のメンバーに対する特別な処理命令が含まれている。このようなコンフェデレーションのメンバーではないBGPsecスピーカーは、送信するすべてのBGPsec UPDATEメッセージのSecure_PathセグメントにConfed_Segmentフラグを設定してはならない(つまり、Confed_Segmentフラグをデフォルト値の0のままにしておく)。

セクション4.4には、BGPsecスピーカーがBGPsec_PATH属性を持つUPDATEメッセージを受信し、BGPsecをサポートしていないピアに、UPDATEメッセージを伝播したい場合にAS_PATH属性を再構築する手順が含まれている。

4.1. 一般的なガイダンス

BGPsec UPDATEメッセージの署名によって保護される情報には、UPDATEメッセージの送信先ピアのAS番号が含まれる。したがって、BGPsecスピーカーが複数のBGPピアにBGPsec UPDATEメッセージを送信したい場合、UPDATEメッセージの送信先となるユニークなピアASごとに別々のBGPsec UPDATEメッセージを生成しなければならない(MUST)。

⚠️ コメント

「BGPsec UPDATEメッセージの署名によって保護される情報には、UPDATEメッセージの送信先ピアのAS番号が含まれる」と書かれているが、UPDATEメッセージに送信先ピアのAS番号フィールドがあるわけではない。デジタル署名を計算する際、送信先ピアのAS番号を使っているため(図8参照)、「署名によって保護される情報」と表現しているのかも知れない。いずれにしろ、ピアAS毎にデジタル署名を生成することになるため、記載されているとおり、UPDATEメッセージはピアAS毎に異なる。

BGPsec UPDATEメッセージは、1つのプレフィックスへの経路のみ広告しなければならない(MUST)。これは、複数のプレフィックスを含むUPDATEメッセージを受信したBGPsecスピーカーが、受信したUPDATEに含まれるプレフィックスの一部を含む有効なBGPsec UPDATEメッセージ(つまり、有効なパス署名)を構築できないだめである。BGPsecスピーカーが複数のプレフィックスの経路を広告したい場合、プレフィックスごとに個別のBGPsec UPDATEメッセージを生成しなければならない(MUST)。さらに、BGPsec UPDATEメッセージは、MP_REACH_NLRI属性 [RFC4760]を使用して、プレフィックスを符号化しなければならない(MUST)。

BGPsec_PATH属性とAS_PATH属性は相互に排他的である。つまり、BGPsec_PATH属性を含むUPDATEメッセージはAS_PATH属性を含んではならない(MUST NOT)。AS_PATH属性に含まれる情報は、BGPsec_PATH属性のSecure_Path部分で伝達する。

指定されたアルゴリズム・スイートを持つBGPsec UPDATEメッセージに新しい署名を作成または追加するには、BGPsecスピーカーは、このアルゴリズム・スイートの署名を生成するのに適した秘密鍵を所有しなければならない(MUST)。さらに、この秘密鍵は、AS番号リソース拡張に、BGPsecスピーカーのAS番号を含む有効なRPKIエンド・エンティティ証明書の公開鍵に対応しなければならない[RFC8209]。また、新しい署名がBGPsec UPDATEメッセージに追加されるのは、BGPsecスピーカが外部ピアに送信するUPDATEメッセージを生成するときだけであること(つまり、ピアのAS番号がBGPsecスピーカ自身のAS番号と等しくない)にも留意する。

RPKIは、IPアドレス・プレフィックスの正当な保有者が、特定のASが特定のプレフィックス・セットへの経路を発信することを認可する経路オリジン認可(ROA)と呼ばれる署名付きオブジェクトを発行できる(RFC 6482[RFC6482]参照)。ほとんどのリライング・パーテイー(RP)は、オリジン検証と並行してBGPsecを利用すると予想される(RFC 6483[RFC6483]およびRFC 6811[RFC6811]を参照)。したがって、BGPsecスピーカーのASがこのプレフィックスへの経路を発信することを認可する有効なROAが存在する場合にのみ、BGPsecスピーカーは、特定のプレフィックスへの経路を広告するBGPsec UPDATEメッセージを発信することが推奨される(RECOMMENDED)。

BGPsecルータが、特定のプレフィックスに対してピアからAS_PATH属性(BGPsec_PATH属性ではなく)を含む非BGPsec UPDATEメッセージのみを受信した場合、UPDATEメッセージを伝播するときにBGPsec_PATH属性を付加してはならない(MUST NOT)。(BGPsecルータは、AS_PATH属性のない、つまり内部ピアからネットワーク層到達性情報(NLRI)のみが含まれた非BGPsec UPDATEメッセージを受信する場合もあることに留意する。その場合、そのプレフィックスはそのASから発信されたもので、そのプレフィックスを広告する場合、BGPsecスピーカーはBGPsec_PATH 属性を付加し、(そのプレフィックスに対する)署名付き経路を外部BGPsecスピーカーに発信する必要がある(SHOULD)。)

逆に、BGPsecルータがあるプレフィックスについて、ピアからBGPsec UPDATEメッセージ(BGPsec_PATH属性付き)を受信し、そのプレフィックスにのピアの経路を伝播する場合、BGPsec_PATH 属性を含むBGPsec UPDATEメッセージで経路を伝搬する必要がある(SHOULD)。

BGPsec署名を削除すること(つまり、BGPsec_PATH属性を使用せずに経路広告を伝播すること)は、セキュリティに重大な影響を及ぼすことに留意する。(BGPsec署名を削除することのセキュリティ上の影響については、セクション8を参照のこと。) したがって、BGPsec UPDATEメッセージで経路広告を受信した場合、BGPsec_PATH属性を使用せずに経路広告を伝播することは、BGPsec UPDATEメッセージを受信するケーパビリティを広告していないピアに送信しない限り、推奨しない(セクション4.4を参照)。

さらに、BGPsecスピーカーがBGPsec_PATH属性を使用して経路広告を伝播する場合、受信したUPDATEメッセージの検証状態を証明するものではないことに留意する。(BGPsecの署名のセキュリティ・セマンティクスの詳細については、セクション8を参照のこと。)

BGPsecのないAS_SETを含むUPDATEメッセージを、BGPsecスピーカーが生成する場合(例えば、BGPsecスピーカーがプロキシ集約を実行している場合)、BGPsecスピーカーはBGPsec_PATH属性を含めてはならない(MUST NOT)。このような場合、BGPsecスピーカーは、このプレフィックスに対して受信した広告の既存のBGPsec_PATHをすべて削除して、従来の(非BGPsec)UPDATEメッセージを生成しなければならない(MUST)。BCP 172[RFC6472]は、BGP UPDATEメッセージのAS_PATHでAS_SETとAS_CONFED_SETを使用しないことを推奨していることに留意する必要がある。

BGPsecスピーカーがiBGP(内部BGP)ピアにBGPsec UPDATEメッセージを送信するケースはごく普通のことである。新しい経路広告を発信し、それをBGPsec対応のiBGPピアに送信する場合、BGPsecスピーカーはBGPsec_PATH属性を省略する。新しい経路広告を発信し、それを非BGPsec iBGPピアに送信する場合、BGPsecスピーカーはUPDATEメッセージに空のAS_PATH属性を含める。(空のAS_PATH属性とは、長さフィールドが値0を含む属性である[RFC4271]。) BGPsecスピーカーがBGPsec UPDATEメッセージをiBGPピアに転送することを選択した場合、ピアがBGPsecをサポートしていなければ、BGPsec_PATH属性は削除すべきではない(SHOULD NOT)。iBGPピアがBGPsecをサポートしていない場合、AS_PATHを含むBGP UPDATEメッセージがBGPsec UPDATEメッセージから再構成して転送する(セクション4.4を参照)。特に、BGPsec対応のiBGP(またはeBGP)ピアに転送する場合、BGPsec UPDATEメッセージが正常に検証されなかった場合でも、BGPsec_PATH属性を削除すべきではない(SHOULD NOT)。(検証の詳細についてはセクション5を、BGPsec署名の削除することによるセキュリティ上の影響についてはセクション8を参照のこと。)

すべてのBGPsec UPDATEメッセージは、BGPの最大メッセージ・サイズに準拠しなければならない(MUST)。結果のメッセージが最大メッセージ・サイズを超える場合は、RFC 4271[RFC4271]のセクション9.2のガイドラインに従わなければならない(MUST)。

4.2. BGPsec_PATH属性の構成

BGPsecスピーカーは、(内部または外部)ピアからBGPsec_PATH属性(1つ以上の署名付き) を含むBGPsec UPDATEメッセージを受信すると、その経路広告を他の(内部または外部)ピアに送信して伝播することを選択できる。経路広告を内部のBGPsec対応ピアに送信する場合、BGPsec_PATH属性は変更してはならない(SHALL NOT)。外部のBGPsec対応ピアに経路広告を送信する場合、BGPsec_PATH属性を形成または更新するために以下の手順を使用する。

発信UPDATEメッセージにBGPsec_PATH属性を生成するために、BGPsecスピーカーはまず新しいSecure_Pathセグメントを生成する。BGPsecスピーカーがオリジンASではなく、既存のBGPsec_PATH属性がある場合、BGPsecスピーカーはその新しいSecure_Pathセグメントを既存のSecure_Pathの先頭に追加する(最初の位置に配置く)ことに留意する。

このSecure_PathセグメントのAS番号は、このBGPsecスピーカーが構築したデジタル署名を検証するために使用されるRPKIルータ証明書のSubjectフィールドのAS番号と一致しなければならない([RFC8209]のセクション3.1.1 とRFC 6487[RFC6487]を参照)。

Secure_PathセグメントのpCountフィールドは通常、値1に設定される。ただし、BGPsecスピーカーはpCountフィールドを1より大きい値に設定する場合がある。pCountフィールドを1より大きい値に設定することは、非BGPsec UPDATEメッセージのAS_PATH内でAS番号を複数回繰り返すのと同じ意味を持つ(例: トラフィック・エンジニアリング目的)。

BGPsec署名の検証における不必要な処理負荷を防ぐために、BGPsecスピーカーは同じAS番号を持つ複数の連続したSecure_Pathセグメントを生成すべきではない(SHOULD NOT)。これは、同じAS番号をk回先頭に追加するというセマンティクスを実現するには、BGPsecスピーカーは、pCountがkの単一のSecure_Pathセグメントと、それに対応する単一の署名セグメントを生成する必要がある(SHOULD)ことを意味する。

BGPコントロール・プレーンに参加するが、データ・プレーンではトランジットASとして動作しない経路サーバは、pCountを0に設定することができる。このオプションは、経路サーバがBGPsecに参加し、ASパス長さを増やすことなく関連するセキュリティ保証を取得できるようになる。(BGPsecスピーカーは、BGPsec_PATH属性のpCount値を合計することで、ASパスの長さを計算することに留意する。セクション5を参照のこと。) ただし、経路サーバがpCount値を0に設定しても、経路サーバが追加した署名を検証するために必要な情報であるため、そのAS番号をSecure_Pathセグメントに挿入する。AS番号の移行を容易にするために、pCountを0に設定する方法については、[RFC8206]を参照のこと。また、ASコンフェデレーションの文脈でのpCount=0の使用については、セクション4.3を参照のこと。pCount=0を設定したり、ピアからpCount=0を受け入れたりするためのBGPsecルータの設定に関する運用ガイダンスについては、セクション7.2を参照のこと。

次に、BGPsecスピーカーは1つまたは2つのSignature_Blockを生成する。通常、BGPsecスピーカーは1つのアルゴリズム・スイートのみを使用するため、BGPsec_PATH属性に1つのSignature_Blockのみを生成する。ただし、「現在の」アルゴリズム・スイートから「新しい」アルゴリズム・スイートへの移行期間中の下位互換性を確保するため、「現在の」アルゴリズムと「新しい」アルゴリズムの両方の Signature_Blockを含むUPDATEメッセージを発信する必要がある(セクション6.1を参照)。

受信したBGPsec UPDATEメッセージに2つのSignature_Blocksを含み、BGPsecスピーカーが対応する両アルゴリズム・スイートをサポートする場合、BGPsecスピーカーが生成する新しいUPDATEメッセージには両方のSignature_Blockを含まなければならない(MUST)。受信したBGPsec UPDATEメッセージは2つのSignature_Blockを含み、BGPsecスピーカーが対応する2つのアルゴリズム・スイートのうち1つしかサポートしていない場合、BGPsecスピーカーは理解していないアルゴリズム・スイートに対応するSignature_Blockを削除しなければならない(MUST)。BGPsecスピーカーが、受信したUPDATEメッセージに含まれるSignature_Blocksのアルゴリズム・スイートをサポートしていない場合、BGPsecスピーカーは、BGPsec_PATH属性を持つ経路広告を伝播してはならない(MUST NOT)。(つまり、この経路広告を伝播することを選択した場合は、署名なしのBGP UPDATEメッセージとして伝搬しなければならない。署名なしのBGP UPDATEメッセージへの変換の詳細については、セクション4.4を参照のこと。)

BGPsec_PATHに2つのSignature_Blocks(異なるアルゴリズム・スイートに対応)がある場合、検証アルゴリズム(セクション5.2を参照)はサポートされているアルゴリズム・スイート(および対応する Signature_Block)が少なくとも1つでもあれば、BGPsec UPDATEメッセージを「有効」と見なすことに留意する。これは、「有効」なBGPsec UPDATEメッセージが「有効」とはみなされないSignature_Blockを含むかも知れないことを意味する(例えば、BGPsecが正常に検証できない署名を含む)。それにもかかわらず、そのようなSignature_Blockを削除してはならない(MUST NOT)。 (この設計上の選択によるセキュリティへの影響については、セクション8を参照のこと。)

BGPsecスピーカーがサポートするアルゴリズム・スイートに対応する各Signature_Blockに対して、BGPsecスピーカーはSignature_Blockに新しいSignature Segmentを追加しなければならない(MUST)。この署名セグメントは、署名セグメントのリストが対応するSecure_Pathセグメントと同じ順序で表示されるように、署名セグメントのリスト(最初の位置に配置)の先頭に追加する。BGPsecスピーカーは、この新しい署名セグメントのフィールドに以下の通り追加する。

新しいセグメントのサブジェクト鍵識別子フィールドは、BGPsecスピーカー[RFC8209]に対応するRPKIルータ証明書のサブジェクト鍵識別子拡張に含まれる識別子を追加する。このサブジェクト鍵識別子は、経路広告の受信者が署名を検証する際に使用する適切な証明書を識別するために使用される。

新しいセグメントの署名フィールドは、プレフィックスとBGPsec_PATH属性を、BGPsecスピーカーに対応するRPKIルータ証明書にバインドするデジタル署名を含む。デジタル署名は以下のように計算する:

  • 明確にするため、Secure_Pathと対応する署名セグメントに1からNまでの番号を付ける。Secure_Pathセグメント1と署名セグメント1をオリジンASが生成したセグメントとする。Secure_Pathセグメント2と署名セグメント2を、オリジンの次のASが追加するセグメントとする。この番号付け方法を継続し、最終的にSecure_PathセグメントNと署名セグメントNを現在のASが追加するセグメントとする。現在のAS(N番目のAS)は、UPDATEメッセージに署名し、ASパスを形成するASチェーン内の次のAS(つまり、(N+1)番目のAS)にフォワーディングする。

  • 署名セグメントN(現在のASによって生成される署名セグメント)のデジタル署名を構築するには、図8に示すように、ハッシュ化されるオクテットのシーケンスを構築する。このオクテットのシーケンスは、(N+1)番目のASのBGPsecスピーカーにフォワードされるUPDATEメッセージにデジタル署名を追加することによって、N番目のASが証明するすべてのデータを含む。(図8の特定の構造を選択するための設計上の理論的根拠については、[Borchert]を参照のこと。)

    fig08
    図8: ハッシュ化されるオクテットのシーケンス

    このシーケンス(図8)内の要素は、示されているとおりに正確に並べなければならない(MUST)。「ターゲットAS番号」は、BGPsecスピーカーがUPDATEメッセージを送信しようとするASである。(「ターゲットAS番号」は、UPDATEメッセージが送信されるBGPセッションのOPENメッセージでピアからアナウンスされたAS番号であることに留意する。) Secure_Pathと署名セグメント(1 ～ N-1)は、 BGPsec_PATH 属性から得られる。最後に、アドレスファミリー識別子(AFI)、後続アドレスファミリー識別子(SAFI)、およびNLRIフィールドは、MP_REACH_NLRI属性[RFC4760]から取得する。さらに、NLRIフィールド内のプレフィックス・フィールド(RFC 4760[RFC4760]のセクション5を参照)では、このシーケンスを構築するときに、末尾のビットをすべて0に設定しなければならない(MUST)。

  • このオクテット・シーケンス(図8)にダイジェスト・アルゴリズム(この Signature_Blockのアルゴリズム・スイートの)を適用し、ダイジェスト値を取得する。

  • このダイジェスト値に、(このSignature_Blockのアルゴリズム・スイートの)署名アルゴリズムを適用して、デジタル署名を取得する。次に、署名フィールド(図7)にこのデジタル署名を入力する。

署名の長さフィールド(図7 には、署名フィールドの値の長さ(オクテット単位)を入力する。

4.3. コンフェデレーション・メンバー向けの処理手順

ASコンフェデレーション[RFC5065]のメンバーは、BGPsec UPDATEメッセージを処理するために、さらにこのセクションの指示に従わなければならない(MUST)。

ASコンフェデレーション内のBGPsecスピーカーが、コンフェデレーションの外部であるピアからBGPsec UPDATEメッセージを受信し、コンフェデレーション内でUPDATEメッセージを伝播することを選択すると、最初に自身のメンバーASに署名された署名(すなわち、「ターゲットAS番号」は、BGPsecスピーカーのメンバーAS番号である)を追加する。この内部的に変更されたUPDATEメッセージでは、新しく追加されたSecure_PathセグメントにパブリックAS番号(つまり、コンフェデレーション識別子)が含まれ、セグメントのpCount値は0に設定され、Confed_Segmentフラグが1に設定される。この場合、pCount=0を設定することで、ASパス長が不必要に増加しないようにできる。新しく追加された署名は、コンフェデレーションの公開AS番号に対応する秘密鍵を使用して生成される。BGPsecスピーカーは、修正されたUPDATEメッセージをコンフェデレーション内のピアに伝播する。

コンフェデレーション内でのUPDATEメッセージの伝播という文脈で以下で説明するBGPsec_PATHの修正は、上記の修正(つまり、pCount=0)に加えて行われる。

BGPsecスピーカーがBGPsec UPDATEメッセージを自身のメンバーAS内に属するピアに送信するとき、コンフェデレーション・メンバーはBGPsec_PATH属性を変更してはならない(SHALL NOT)。BGPsecスピーカーが、同じコンフェデレーション内で別のメンバーASにあるピアにBGPsec UPDATEメッセージを送信する場合、BGPsecスピーカーは、そのメンバーAS番号をBGPsec UPDATEメッセージに追加するSecure_PathセグメントのAS番号フィールドに加える。さらに、この場合、Secure_Pathセグメントを生成するメンバーASは、Confed_Segmentフラグを1に設定する。さらにまた、署名は、BGPsecスピーカーのメンバーAS番号に対応する秘密鍵で生成される。(注: 本文書では、メンバーAS内ピアリングはiBGPとみなされ、メンバーAS間ピアリングはeBGPとみなされる。後者はコンフェデレーションeBGPとも呼ばれる。)

コンフェデレーション内では、コンフェデレーションの他のメンバーによって追加されたBGPsec署名の検証はオプションである。コンフェデレーション内でデジタル署名を検証しないことをコンフェデレーションで選択した場合、BGPsecは、Confed_Segmentフラグが1に設定されたSecure_Pathセグメントに配置されたメンバーAS番号の完全性についての保証を提供できないことに留意する。

コンフェデレーション・メンバーがコンフェデレーション内のピアからBGPsec UPDATEメッセージを受信し、それをコンフェデレーション外のピアに伝播する場合、コンフェデレーション・メンバーによって追加されたすべてのSecure_Pathセグメントと、対応する署名セグメントを削除する必要がある。これを行うために、コンフェデレーション外の経路を伝播するコンフェデレーション・メンバーは以下の操作を実行する:

  • まず、最後追加されたSecure_Pathセグメントから始めて、Confed_Segmentフラグが1に設定されている連続するSecure_Pathセグメントをすべて削除する。Confed_Segmentフラグが0に設定されているSecure_Pathセグメントに到達したら、この処理を停止する。このようにして削除されたセグメントの数をカウントしておく。

  • 次に、最後に追加した署名セグメントから始めて、前の手順で削除したSecure_Pathセグメントの数と同じ数の署名セグメントを削除する。(つまり、最近追加されたK個の署名セグメントを削除する。ここでKは、前の手順で削除したSecure_Pathセグメントの数である。)

  • 最後に、ASフィールドにASコンフェデレーション識別子(コンフェデレーションのパブリックAS番号)と対応する署名セグメントを含むSecure_Pathセグメントを追加する。ASフィールド以外のすべてのフィールドはセクション4.2に従って入力されることに留意する。

最後に、上述したように、ASコンフェデレーションはそのメンバーが追加したデジタル署名を検証しないことを任意に決定してもよい(MAY)。このようなコンフェデレーションでは、BGPsecスピーカーがセクション5.2のアルゴリズムを実行するとき、署名検証のプロセス中に、BGPsecスピーカーはまずSecure_PathセグメントのConfed_Segmentフラグが1に設定されているかどうかを確認する。フラグが1に設定されている場合、 BGPsecスピーカーは対応する署名の検証をスキップし、すぐに次のSecure_Pathセグメントに進む。セクション5.2で指定されているように、同じASコンフェデレーションに属していないピアから、Confed_Segmentフラグが1に設定されたBGPsec UPDATEメッセージをBGPsecスピーカが受信した場合はエラーであることに留意する。

4.4. AS_PATH属性の再構築

BGPsec UPDATEメッセージにはAS_PATH属性が含まれていない。しかし、AS_PATH属性はBGPsec_PATH 属性から再構築できる。これは、経路広告をBGPsec UPDATEメッセージを介して受信し、非BGPsec UPDATEメッセージを介してピアに伝播する場合に必要である(例えば、後者のピアがBGPsecをサポートしていないため)。実装がこの再構築を実行することが有用であると判断するケースが他にもあるかもしれないことに留意する。署名されていない(非BGPsec)UPDATEメッセージをピアに転送する目的でAS_PATHの再構築を試みる前に、BGPsecスピーカーは受信した BGPsec UPDATEメッセージが適切に形成されていることを確認するため、セクション5.2にリストされている基本的な完全性チェックを実行しなければならない(MUST)。

AS_PATH属性は、BGPsec_PATH属性から以下のように構築できる。空のAS_PATH属性から始めて、(オリジンに対応する)最近追加されたものから最近追加されたものの順にSecure_Pathセグメントを処理する。各Secure_Pathセグメントに対して、以下の手順を実行する:

  1. Secure_PathセグメントのpCount=0の場合は、何もしない(つまり、次の Secure_Pathセグメントの処理に進む)。

  2. Secure_PathセグメントのpCountが0より大きく、Confed_Segmentフラグが1に設定されている場合、AS_PATH内で最後に追加されたセグメントを調べる。

    • AS_PATHが空白の場合、または最後に追加されたセグメントがAS_SEQUENCEの場合は、AS_CONFED_SEQUENCEの新しいAS_PATHセグメントを追加する(AS_PATHの前に追加する)。このAS_CONFED_SEQUENCEのセグメントには、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素が含まれる。これらの各要素は、現在のSecure_Pathセグメントに含まれるAS番号になる。(つまり、pCountフィールドがXの場合、AS_CONFED_SEQUENCEのセグメントには、Secure_PathセグメントのAS番号フィールドのコピーがX個含まれる。)

    • AS_PATHに最後に追加されたセグメントがAS_CONFED_SEQUENCEの場合、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素を追加する(セグメントの先頭に追加する)。これらの各要素の値は、現在のSecure_Pathセグメントに含まれるAS番号である。(つまり、pCountフィールドがXの場合、既存のAS_CONFED_SEQUENCEにSecure_PathセグメントのAS番号フィールドのコピーがX個追加する。)

  3. Secure_PathセグメントのpCountが0より大きく、Confed_Segmentフラグが0に設定されている場合、AS_PATHに最後に追加されたセグメントを調べる。

    • AS_PATHが空白の場合、または最後に追加されたセグメントがAS_CONFED_SEQUENCEの場合は、AS_SEQUENCEの新しいAS_PATHセグメントを追加する(AS_PATHの先頭に追加する)。このAS_SEQUENCEのセグメントには、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素を含める。これらの各要素は、現在のSecure_Pathセグメントに含まれるAS番号になる。(つまり、pCountフィールドがXの場合、AS_SEQUENCEのセグメントにはSecure_PathセグメントのAS番号フィールドのコピーがX個含む。)

    • AS_PATHに最後に追加されたセグメントがAS_SEQUENCEの場合、現在のSecure_PathセグメントのpCountフィールドに等しい数の要素を追加する(セグメントの先頭に追加する)。これらの各要素の値は、現在のSecure_Pathセグメントに含まれるAS番号とする。(つまり、pCountフィールドがXの場合、既存のAS_SEQUENCEにSecure_PathセグメントのAS番号フィールドのコピーをX個追加する。)

上記手順の一環として、AS_SEQUENCE及びAS_CONFED_SEQUENCEのサイズ制限を超えないように、以下の追加アクションを実行する。次のSecure_Pathセグメント(もし、存在すればそのプリペンドも含む)を組み立てているAS_PATHに追加している間に、手元のAS_SEQUENCE(またはAS_CONFED_SEQUENCE)がセグメントあたり255個のAS番号の制限[RFC4271] [RFC5065]を超えるようであれば、BGPsecスピーカーは、RFC 4271[RFC4271]とRFC 5065[RFC5065]の推奨事項に従って、同じタイプの別セグメント(AS_SEQUENCEまたはAS_CONFED_SEQUENCE)を作成し、そのセグメントの注入を続ける。

最後に、AS_PATHの再構築の特殊なケースとして、BGPsec_PATH属性が存在しない場合がある。セクション4.1で説明したように、BGPsecスピーカーがプレフィックスを生成し、それをBGPsec対応iBGPピアに送信するとき、BGPsec_PATHは付加されない。したがって、BGPsec対応iBGPピアから受信した場合、BGPsec UPDATEメッセージにBGPsec_PATH属性がないことは、空のAS_PATH[RFC4271]に相当する。

5. 受信したBGPsec UPDATEメッセージの処理

外部(eBGP)ピアからBGPsec UPDATEメッセージを受信すると、BGPsecスピーカーは、BGPsec_PATH属性に含まれるパス情報の真正性を判断するために、メッセージを検証する必要がある(SHOULD)。通常、BGPsecスピーカーは受信するBGPsec UPDATEメッセージに対してオリジン検証(RFC 6483[RFC6483]及びRFC 6811[RFC6811]を参照)も行いたいと考えるが、そのような検証は本セクションで説明する検証とは無関係である。

セクション5.1はBGPsec検証の概要を説明し、セクション5.2ではそのような検証を実行するための具体的なアルゴリズムを規定する。(検証の入出力動作がセクション5.2のアルゴリズムと同一である限り、実装はセクション5.2の特定のアルゴリズムに従う必要はないことに留意する。) 例外的な状況(例えば、BGPsecスピーカーが同時に多くのUPDATEメッセージを受信した場合)では、BGPsecスピーカーは受信するBGPsec UPDATEメッセージの検証を一時的に延期してもよい(MAY)。検証を延期したそのようなBGPsec UPDATEメッセージの処理は、ローカルポリシーの問題である。しかし、実装は検証の延期と延期されたメッセージの状態がオペレータに見えるようにする必要がある(SHOULD)。

BGPsec UPDATEメッセージの有効性は、現在のRPKI状態によって決まる。BGPsecスピーカーがRPKI状態が変化したことを知ったとき(例えば、RPKI-Routerプロトコル[RFC8210]を介したRPKI検証キャッシュから)、BGPsecスピーカーはAdj-RIB-In[RFC4271]に格納されている影響を受けるすべてのUPDATEメッセージの検証を再実行しなければならない(MUST)。例えば、あるRPKIルータ証明書が有効でなくなった場合(例えば、期限切れや失効)、そのSKIが特定の証明書のSKIと一致する署名を含むすべてのUPDATEメッセージを再評価して、まだ有効かどうかを判断しなければならない(MUST)。この再評価によってUPDATEメッセージの有効性が変化したと判断された場合、ローカルポリシーによっては最適パスの選択を再実行する必要がある。

BGPsec UPDATEメッセージはAS_PATH属性を含まない。Secure_Pathは、BGPsec UPDATEメッセージのASパス情報が含む。したがって、BGPsecスピーカーは、AS_PATH属性のASパス情報を使用するすべての場合に、Secure_PathのASパス情報を利用しなければならない(MUST)。このルールの唯一の例外は、経路をピアに伝播するためにASパス情報を更新しなければならない場合である(この場合、BGPsecスピーカーはセクション4の指示に従う)。セクション4.4では、BGPsec_PATH属性からAS_PATH属性を構築するアルゴリズムを提供している。ASパス情報の使用が要求されるときはいつでも(例えば、ループ検出や最適パス選択におけるASパス長の使用)、実装の外部から見える動作は、実装がセクション4.4のアルゴリズムを実行し、結果のAS_PATH属性を非BGPsec UPDATEメッセージと同じように使用した場合と同じでなければならない。

5.1. BGPsec検証の概要

BGPsec UPDATEメッセージの検証は、RPKIルータ証明書のデータを使用する。特に、受信者が有効なRPKIルータ証明書から取得した以下のデータ、つまり、有効な各RPKIルータ証明書のAS番号、公開鍵、サブジェクト鍵識別子にアクセスできる必要がある。

BGPsecスピーカーは、RPKIルータ証明書の検証を独自に実行して必要なデータを抽出することもできるし、(一部の)BGPsecスピーカーに代わってRPKI検証を実行する信頼できるキャッシュから同じデータを受け取ることもできることに留意する。(例えば、信頼できるキャッシュは、RPKI-Routerプロトコル[RFC8210]のルータ鍵PDU(プロトコル・データ・ユニット)を使用して、必要な有効性情報をBGPsecスピーカーに配信できる。)

BGPsec_PATH属性を含むBGPsec UPDATEメッセージを検証するには、受信者はセクション5.2で規定されている検証手順を実行する。検証手順の結果は、「有効」または「無効」の2つの状態のいずれかが得られる。

検証手順の出力は、BGP経路選択への入力として使用されることが想定される。ただし、BGP経路の選択、つまり検証状態の処理はローカル・ポリシーの問題であり、ローカル・ポリシー・メカニズムを使って処理される。実装は、オペレータがセッションごとにそのようなローカル・ポリシーを設定できるようにする必要がある(SHOULD)。(つまり、異なるBGPセッションで受信したUPDATEメッセージに対して、BGPsec検証状態を異なる方法で処理することを選択するオペレータがいることが想定される。)

BGPsec検証はeBGPエッジでのみ実行する必要がある。BGP署名/未署名UPDATEメッセージの検証状態は、AS内のローカル・ポリシーに従って、何らかのメカニズムを介して、イングレス・エッジ・ルータからエグレス・エッジ・ルータにiBGP経由で伝達してもよい(MAY)。セクション4で説明したように、BGPsecスピーカーが(構文的に正しい)BGPsec UPDATEメッセージを転送することを選択した場合、(UPDATEメッセージの検証状態に関係なく)そのBGPsec_PATH属性をそのままにして転送する必要がある(SHOULD)。完全にローカル・ポリシーに基づいて、自身のAS内からBGPsec UPDATEメッセージを受信するエグレス・ルータは、自身の検証を実行することを選択してもよい(MAY)。

5.2. 検証アルゴリズム

このセクションでは、BGPsec UPDATEメッセージの検証アルゴリズムを規定する。準拠した実装は、このアルゴリズムの外部から見える動作と機能的に等価なBGPsec更新検証アルゴリズムを含めなければならない(MUST)。

まず、BGPsec UPDATEメッセージの受信者は、メッセージが適切に形成されているかどうかを確認するためにチェックを実行する。構文違反エラーとプロトコル違反エラーの両方をチェックする。BGPsec_PATH 属性は、BGPsec UPDATEメッセージが外部(eBGP)BGPsecピアから受信されるとき、及びそのようなUPDATEメッセージが内部(iBGP)BGPsecピアに伝播されるときにも存在しなければならない(セクション4.2を参照)。[RFC4271]のセクション6.3で規定されているエラーチェックを実行する。ただし、BGPsec UPDATEメッセージでは、AS_PATH属性のチェックは適用されず、代わりにBGPsec_PATH属性の以下のチェックを実行する:

  1. BGPsec_PATH属性全体が構文的に正しい(本文書の仕様に準拠している)ことを確認する。

  2. 最後に追加されたSecure_Pathセグメント(つまり、UPDATEメッセージの受信元のeBGPピアに対応するセグメント)のAS番号が、BGP OPENメッセージで規定されているそのピアのAS番号と一致することを確認する。(注記: このチェックは、UPDATEメッセージがピアASから最初に受信したイングレスBGPsecルータでのみ実行する。)

  3. 各Signature_Blockに、BGPsec_PATH属性のSecure_Path部分の各Secure_Pathセグメントに1つの署名セグメントが含まれていることを確認する。(すべての署名が暗号的に検証する前に検証プロセスが終了する可能性があるとしても、各Signature_Block全体が適切に形成されていることを確認するためにチェックしなければならない(MUST)ことに留意する。)

  4. UPDATEメッセージにAS_PATH属性が含まれていないことを確認する。

  5. BGPsecスピーカーのASコンフェデレーションのメンバーではないBGPsecピアからUPDATEメッセージを受信した場合、Secure_PathセグメントのどれにもConfed_Segmentフラグが1に設定されたFlagsフィールドを含まないことを確認する。

  6. BGPsecスピーカーのASコンフェデレーションのメンバーであるBGPsecピアからUPDATE メッセージを受信した場合、そのピアに対応するSecure_Pathセグメントに、Confed_Segmentフラグが1に設定されたFlagsフィールドを含むことを確認する。

  7. pCount=0を設定することが想定されていないピアからUPDATEメッセージを受信した場合(セクション4.2及び4.3を参照)、最後に追加されたSecure_PathセグメントのpCountフィールドが0になっていないことを確認する。(注記: この項目に関連するルータの構成ガイダンスについては、セクション7.2を参照。)

  8. UPDATEメッセージのSecure_Pathに相当するAS_PATHを使用して(セクション4.4を参照)、ローカルAS番号がASパスに存在しないことを確認する(つまり、ASループを除外する)。

これらのチェックのいずれかが失敗した場合、それはBGPsec_PATH属性のエラーである。BGPsecスピーカーは、RFC 7606[RFC7606]で定義されている「treat-as-withdraw」アプローチを使用して、BGPsec_PATH属性の構文エラーまたはプロトコル・エラーを処理しなければならない(MUST)。(注記: 透過経路サーバのAS番号はpCount=0のSecure_Pathに表示されるため、経路サーバはローカルASがSecure_Pathにリストされているかどうかを確認してもよい(MAY)。また、このチェックは上記のループ検出チェックに含めてもよい(MAY)。)

次に、BGPsecスピーカーは、BGPsec_PATH属性のSignature_Blocksを調べる。BGPsecスピーカーがサポートしていないアルゴリズム・スイートに対応するSignature_Blockは、検証プロセスでは考慮されない。BGPsecスピーカーがサポートするアルゴリズム・スイートに対応するSignature_Blockがない場合、経路選択プロセスでUPDATEメッセージを考慮するため、BGPsecスピーカーはSignature_Blockを削除し、Secure_PathからAS_PATHを再構築し(セクション4.4を参照)、UPDATEメッセージを署名のないBGP UPDATEメッセージとして受信したかのように扱わなければならない(MUST)。

残りの各Signature_Block(BGPsecスピーカーによってサポートされるアルゴリズム・スイートに対応)に対して、BGPsecスピーカーは、Signature_Block内の署名セグメントを、最後に追加されたセグメントから順に(最後に最も新しく追加されたセグメントで終了)を繰り返す。BGPsec_PATH 属性内の署名セグメントとSecure_Pathセグメントの間には1対1の対応関係があることに留意する。以下の手順では、この対応関係を利用する:

  • ステップ1: 受信したBGPsec_PATH属性に検証対象のK ASホップが存在するとする。AS(1), AS(2), ..., AS(K+1)は、オリジンASから検証ASまでのAS番号のシーケンスを表すものとする。BGPsec_PATH属性のSecure_PathセグメントNと署名セグメントNをAS(N) (ここでN = 1, 2, ..., K)に対応するものとする。BGPsec_PATH属性を処理し、検証するBGPsecスピーカーはAS(K+1)に存在する。署名セグメントNを現在検証中の署名セグメントとする。

  • ステップ 2: 署名の検証するために必要な公開鍵を(現在の署名セグメント内で)検索する。これを行うには、有効なRPKIルータ証明書データを参照し、ASが対応するSecure_PathセグメントのAS番号と一致する有効な(AS番号、公開鍵、サブジェクト鍵識別子)トリプルをすべて検索する。AS番号と一致するこれらのトリプルのうち、署名セグメントのサブジェクト鍵識別子フィールドの値と一致するSKIがあるかどうかを確認する。このチェックで一致するSKI値が見つからなかった場合、Signature_Block全体を「無効」とマークし、次のSignature_Blockに進む。

  • ステップ3: 適切なデータに対して(指定されたアルゴリズム・スイートの)ダイジェスト関数を計算する。

    署名セグメントNのデジタル署名を検証するには、図9に示すようにハッシュ化するオクテットのシーケンスを構築する(手順1で定義した表記を使用)。(このシーケンスは、署名セグメントNを作成したAS(N)が使用したシーケンスと同じであることに留意する(セクション4.2と図8を参照)。

    fig09
    図9: 署名セグメントNの署名検証のためにハッシュ化されるオクテットのシーケンス「N = 1,2, ..., K」、ここでKはBGPsec_PATH属性のASホップ数である

    このシーケンス内の要素(図9)は、示されているとおりに正確に順序付けられなければならない(MUST)。処理される最初のセグメント(Secure_PathにK個のホップがあることを考えると、最も最近追加されたセグメント(つまり、N = K))の場合、「ターゲットAS番号」はAS(K+1)、つまりUPDATEメッセージを検証するBGPsecスピーカーのAS番号である。BGPsecスピーカーが複数のAS番号を使用する場合(例えば、BGPsecスピーカーがコンフェデレーションのメンバーである場合)、ここで使用するAS番号は、BGPsec UPDATEメッセージを受信したBGPセッションのOPENメッセージでアナウンスされたAS番号でなければならない(MUST)ことに留意すること。

    他の各署名セグメント(NがKより小さい)の「ターゲットAS番号」はAS(N+1)であり、処理中の署名セグメントの直後に追加された署名セグメントに対応するSecure_Pathセグメント(つまり、 バリデータが処理を終了したばかりの署名セグメントに対応するSecure_Pathセグメント)のAS番号である。

    Secure_Pathと署名セグメントは、BGPsec_PATH属性から取得する。AFI、SAFI、NLRIフィールドは、MP_REACH_NLRI 属性[RFC4760]から取得する。さらに、NLRIフィールド内のプレフィックス・フィールド(RFC 4760 [RFC4760]のセクション5を参照)では、このシーケンスを組み立てるときに、後続ビットのすべて0に設定しなければならない(MUST)。

  • ステップ 4: (指定されたアルゴリズム・スイートの)署名検証アルゴリズムを使用して、現在のセグメントの署名を検証する。つまり、現在のセグメントの署名フィールドの値、上記の手順3で計算したダイジェスト値、及び上記のステップ2で有効なRPKIデータから取得した公開鍵の3つの入力に対して、署名検証アルゴリズムを呼び出す。署名検証アルゴリズムが署名を無効と判断した場合、Signature_Block全体を「無効」とマークし、次のSignature_Blockに進む。署名検証アルゴリズムが署名を有効と判断した場合は、署名セグメント(現在の Signature_Block内)の処理を続行する。

Signature_Block内のすべての署名セグメントが検証に合格した場合(つまり、すべてのSignature_Blockが処理され、まだ「無効」とマークされていない場合)、Signature_Blockは「有効」とマークされる。

少なくとも1つのSignature_Blockが「有効」とマークされた場合、検証アルゴリズムは終了し、BGPsec UPDATEメッセージは「有効」とみなされる。(つまり、BGPsec UPDATEメッセージが2つのSignature_Blockを含む場合、最初のSignature_Blockが「有効」とマークされるか、2つ目のSignature_Blockが「有効」とマークされれば、UPDATEメッセージは「有効」とみなされる。)

6. アルゴリズムと拡張性

6.1. アルゴリズム・スイートの考慮事項

現在のところ、特定の(ダイジェストと署名)アルゴリズム・スイートを使用するために、BGPsecピア間で(BGP機能を使用して)双方向ネゴシエーションをサポートしないことに留意する。これは、BGPsec UPDATEメッセージの送信者が使用するアルゴリズム・スイートは、メッセージの直接送信するピアだけでなく、経路広告が最終的に伝播されるすべてのBGPsecスピーカーによっても理解されなければならない(MUST)からである。したがって、アルゴリズム・スイートの選択は、BGPピアによってネゴシエートされるローカルな問題ではなく、代わりにインターネット全体で調整されなければならない。

この目的のために、[RFC8208]は、すべてのBGPsecスピーカーが使用するために、強制的に使用する「現在の」アルゴリズム・スイートを規定している。

将来、[RFC8208]またはその後継が更新され、「現在の」アルゴリズム・スイートから「新しい」アルゴリズム・スイートへの移行が指定されることが予想される。移行期間中、すべてのBGPsec UPDATEメッセージは、「現在の」アルゴリズム・スイートと「新しい」アルゴリズム・スイートの両方を同時に使用する必要がある(SHOULD)。(セクション3と4では、BGPsec_PATH属性に2つのアルゴリズム・スイートに対する署名をどのように並列に含めることができるかが規定されていることに留意する。) 移行が完了すると、古い「現在の」アルゴリズムの使用は非推奨となり、「新しい」アルゴリズムの使用は必須となる。その後の「さらに新しい」アルゴリズム・スイートが「実装推奨」として指定されるかも知れない。この方法で移行が正常に完了すると、BGPsecスピーカーには (「新しい」アルゴリズムに対応する)1つのSignature_Blockだけを含める必要がある(SHOULD)。

6.2. SKIサイズに関する考慮事項

鍵識別子の生成方法[RFC7093]によって、RPKIルータ証明書のSKIのサイズは異なる場合がある。BGPsec_PATH属性のSKIフィールドのサイズは20オクテットに固定されている(図7を参照)。SKIが20オクテットより長い場合は、SKIの左端の20オクテット(タグと長さを除く)を使用する[RFC7093]。SKIの値が20オクテットより短い場合、SKI(タグと長さを除く)の右側(最下位オクテット)に「0」値を持つオクテットを埋める。

6.3. 拡張性に関する考慮事項

このセクションでは、BGPsec_PATHの処理に大幅な変更を必要とし、新しいバージョンのBGPsecが必要となる、BGPsecへの潜在的な変更について説明する。そのような変更の例には以下のようなものがある。

  • 可変長の署名を生成する新しいタイプの署名アルゴリズム

  • Signature_Block内の署名の数がSecure_Path内のASの数と等しくない、新しいタイプの署名アルゴリズム(例えば、集約署名)

  • BGPsec署名によって保護されるデータの変更(例えば、ASパス以外の属性)

BGPsecに対するこのような変更が望ましいと考えられる場合、BGPsecの後続バージョンが開発され、このバージョンのBGPsecが、BGPsecへの必要な変更に対応するように設計された新しいBGPパス属性 ─ 「BGPsec_PATH_Two」と呼ぶことにする ─ を指定することが期待される。このような場合、[RFC8208]またはその後継が更新され、新しいバージョンのBGPsecに適切なアルゴリズム・スイートを規定することになる。

この時点で、セクション6.1で説明したアルゴリズム移行と同様の移行が始まるだろう。移行期間中、すべてのBGPsecスピーカーは、BGPsec_PATH属性と新しいBGPsec_PATH_Two属性の両方を同時に含む必要がある(SHOULD)。移行が完了したら、BGPsec_PATHの使用は非推奨となり、その時点で、BGPsecスピーカーには新しいBGPsec_PATH_Two属性のみを含めるべきである。このようなプロセスは、後方互換性のある方法で新しいBGPsecセマンティクスへの移行を促進することができる。

7. 運用と管理に関する考慮事項

ここでは、BGPsecプロトコルの仕様と展開に密接に関連する運用と管理の問題のいくつかを取り上げる。BGPsecの運用と展開に関するベスト・プラクティスは[RFC8207]で提供されている。

7.1. ケーパビリティ・ネゴシエーションの失敗

セクション2.2では、BGPsec対応のピアリング・セッションを確立するために必要なネゴシエーションについて説明している。BGPsecケーパビリティを交換(および合意)しなければならないだけでなく、同じAFIのBGPマルチプロトコル拡張[RFC4760]および4バイトAS機能[RFC6793]も交換しなければならない。BGPsecセッションの適切なネゴシエーションに失敗した場合 ─ 例えば、ケーパビリティが欠落している ─ BGP(未署名の)UPDATEメッセージが交換される可能性がある。実装は、BGPsecセッションの適切なネゴシエーションの失敗をログに記録することが推奨される。また、BGPsecのみを使用するように設定されている場合、実装はBGPセッションが確立されないようにする機能を備えていなければならない(MUST)。

7.2. pCount=0の誤用防止

透過ASを持つインターネット交換ポイント(IXP)(つまり、経路サーバ)であるピアは、ピアにUPDATEメッセージを転送する際に、そのSecure_PathセグメントにpCount=0を設定することが期待される(セクション4.2を参照)。明らかに、そのようなIXPは、Secure_PathセグメントにpCount=0を設定するようにBGPsecルータを設定しなければならない。これは、BGPsecスピーカーがIXPピアからのpCount=0を許可するように設定しなければならない(MUST)ことも意味する。pCountが0に設定される他の2つのケースは、ASコンフェデレーション(セクション4.3を参照)とASマイグレーション[RFC8206]の文脈にある。これら2つのケースでは、pCount=0が設定され、同じAS内で受け入れられる(ASは2つの異なるIDを持つ)。BGPsecスピーカーがピアASがpCount=0を設定することを予期しておらず、そのピアから受信したUPDATEメッセージがこれに違反する場合、そのUPDATEメッセージはエラーと見なされなければならないことに留意する(セクション5.2のチェックリストを参照)。pCount=0に関するセキュリティ上の考慮事項については、セクション8.4を参照のこと。

7.3. 署名検証の早期終了

BGPsec UPDATEメッセージの検証中に、以下の考えを組み込むことで経路プロセッサの性能の高速化を実現できる。UPDATE メッセージは、少なくとも1つの Signature_Blocksが「有効」とマークされていれば、「有効」とみなされる(セクション5.2参照)。したがって、UPDATEメッセージに2つのSignature_Blockを含み、最初に検証されたSignature_Blockが「有効」であると判明した場合、2番目のSignature_Blockを検証する必要はない。UPDATEメッセージが最適パスとして選択された場合、BGPsecスピーカーは2つのSignature_Blockのそれぞれに(それぞれのアルゴリズムで生成された)署名を追加し、UPDATEメッセージを転送する。また、BGPsec UPDATE メッセージは、各Signature_Blockの少なくとも1つの署名が無効な場合、「無効」とみなす。この原則は、経路プロセッサの作業負荷を節約するためにも使用できる。つまり、Signature_Blockの検証は、最初の無効な署名が見つかった時点で早期に終了する。

7.4. 非決定論的署名アルゴリズム

多くの署名アルゴリズムは非決定論的である。つまり、多くの署名アルゴリズムは、(同じ鍵で同じデータに署名する場合でも)実行するたびに異なる署名を生成する。したがって、BGPsecルータがピアからBGPsec UPDATEメッセージを受信し、その後、同じピアから同じSecure_PathとSKIを持つ同じプレフィックスに対する2番目のBGPsec UPDATEメッセージを受信した場合、2番目のUPDATEメッセージは、最初のUPDATEメッセージと署名フィールドが異なってもよい(非決定論的署名アルゴリズムの場合)(MAY)。ただし、送信者が以前の署名をキャッシュして再利用する場合、2組の署名フィールドが異なることはない。決定論的署名アルゴリズムの場合、署名フィールドは2つのUPDATEメッセージ間で同一でなければならない(MUST)。これらの観察結果に基づき、実装は更新検証処理に最適化を組み込んでもよい(MAY)。

7.5. プライベートAS番号

ISPのスタブ・カスタマがプライベートAS番号を使用している可能性がある。このようなスタブ・カスタマは、プライベートAS番号と使用するプレフィックスについて、グローバルRPKIでROAを公開できない。また、グローバルRPKIはプライベートAS番号をサポートできない(つまり、プライベートASのBGPsecスピーカーはグローバルRPKIでルータ証明書を発行できない)。(プライベートAS番号を持つ)スタブ・カスタマとISP間のやり取りでは、以下の2つのシナリオが考えられる。

  1. スタブ・カスタマはISPのASにプレフィックスに対する未署名のBGP UPDATEメッセージを送信する。ISPのASのエッジBGPsecスピーカーは、そのプレフィックスを非BGPsecピアおよびBGPsecピアに伝播することを選択するかも知れない。その場合、ISPのエッジBGPsecスピーカーは、AS_PATHからプライベートAS番号を取り除き、(a) 非BGPsecピアに対して未署名でプレフィックスを再発信し、(b) BGPsecピアに対して自身の署名を含むプレフィックスを再発信しなければならない(MUST)。どちらの場合(つまり、(a)と(b))も、ISPのASがそのプレフィックスを発信することを許可するROAをグローバルRPKIに持たなければならない(MUST)。

  2. ISPとスタブ・カスタマは、ローカルRPKIリポジトリ([SLURM]に記載されているメカニズムの1つなどを使用)を使用することができる。その場合、スタブASが発信したプレフィックスに対するROAが存在し、スタブASのeBGPスピーカーはルータ証明書を持つBGPsecスピーカーにできるが、ROAとルータ証明書はローカルでのみ有効である。この構成では、スタブASはISPのASにプレフィックスの署名付きUPDATEメッセージを送信する。ISPのASのエッジBGPsecスピーカーは、ローカルRPKIビューに基づくRPKIデータを使用して、UPDATEメッセージを検証する。さらに、プレフィックスを非BGPsecピアおよびBGPsecピアに伝播することを選択する場合がある。その場合、ISPのエッジBGPsecスピーカーは、スタブASから受け取ったSecure_Pathと署名セグメントをプライベートAS番号で取り除いた上で、(a) 非BGPsecピアに向けて署名なしでプレフィックスを再発信し、(b) BGPsecピアに向けて自身の署名を含むプレフィックスを再発信しなければならない(MUST)。どちらの場合も(つまり、(a)と(b))、ISPのASがそのプレフィックスを発信することを許可するROAをグローバルRPKIにROAを持たなければならない(MUST)。

ASコンフェデレーション[RFC5065]ではプライベートAS番号を使用する可能性がある。BGPsecプロトコルは、BGPsec UPDATEメッセージがコンフェデレーションを通じて伝播するとき、それをピアとなるメンバーASに転送する各メンバーASがUPDATEメッセージに署名しなければならない(MUST)ことを要求する(セクション4.3を参照)。ただし、グローバルRPKIはプライベートAS番号をサポートできない。プライベートAS番号を持つメンバーASのBGPsecスピーカーがデジタル証明書を持つためには、必要に応じて、グローバルRPKIリポジトリ・データを拡張して、ローカルでカスタマイズされたRPKIのビューを確立できるメカニズムが、コンフェデレーション内に存在しなければならない(MUST)。このメカニズム(RPKIデータのローカルイメージを拡張および維持するため)は、ASまたはASコンフェデレーション内でローカルに動作するため、標準ベースである必要はない。ただし、標準ベースのメカニズムを使用することはできる([SLURM]を参照)。ASコンフェデレーション内部の漏洩を防ぐため、非メンバーにエクスポートするBGPsecスピーカーは、コンフェデレーション内のSecure_Pathセグメントと署名をすべて削除することを思い出してほしい(セクション4.3を参照)。

7.6. RPKIデータにアクセスするための堅牢性に関する考慮事項

(ローカルRPKIキャッシュ経由で)グローバルRPKIデータがルータに到達するための展開構造、技術、ベストプラクティスは、[RFC6810]、[RFC8210]、[RFC8181]、[RFC7115]、[RFC8207]、[RFC8182]に記載されている。例えば、シリアル番号ベースの増分更新メカニズムは、最後の更新以降に変更されたデータレコードだけを効率的に転送するために使用される[RFC6810] [RFC8210]。更新通知ファイルは、リライング・パーティー(RP)がグローバルRPKIリポジトリの状態とRPのキャッシュ[RFC8182]との間に変更があるかどうかを検出するために使用される。通知には、(1) スナップショットを含むファイルと、(2) RPがリポジトリと同期するために使用できる増分デルタの場所が記述されている。これらの技術とベストプラクティスを活用することで、リポジトリからRPKIキャッシュ、そしてルータへのRPKIデータの流れに関して、BGPsecルータとRPKIキャッシュの堅牢性、効率性、セキュリティの向上が可能になる。これらのメカニズムにより、攻撃者はRPKIデータフローとBGPsec RP(またはルータ)のアクションを有意に関連付けることができなくなると考えられるため、RPとRPKIサーバ間の相互作用を通じて、RPと相互作用するASを特定しようとする攻撃を回避することができる。

7.7. グレースフル・リスタート

グレースフル・リスタート(GR)の間、BGPsecスピーカの再起動と受信は、BGPスピーカーの再起動と受信に関して、それぞれ[RFC4724]で規定された手順に従わなければならない(MUST)。特に、Loc-RIB[RFC4271]にある経路の転送状態を保持し、それらをstale(古い)とマークする動作や、転送中に古いルーティング情報と他の情報を区別しない動作は、[RFC4724]で規定された動作と同じになる。

7.8. ECDSAにおける秘密乱数の堅牢性

BGPsec[RFC8208]のUPDATEメッセージの署名には、曲線P-256を持つ楕円曲線デジタル署名アルゴリズム(ECDSA)が使用される。ECDSAについては、[FIPS186-4]のセクション6.3で、各デジタル署名の生成前に新しい秘密乱数「k」を生成しなければならないと記載されている。「k」の生成には高エントロピーのランダムビット生成器(RBG)を使用し、「k」生成アルゴリズムにおける潜在的なバイアスを軽減しなければならない([FIPS186-4]および[SP800-90A]に記載された方法を参照)。

7.9. 増分/部分展開の考慮事項

BGPからBGPsecへの移行はどうなるのか? 最初に採用する人にはどのようなメリットがあるのか? 当初は、隣接するASの小さなグループがBGPsecを行うだろう。このようなグループは、グローバル・インターネットのさまざまな地理的地域に、1つ以上存在する可能性がある。各グループ内で発信され、その境界内で伝播する経路だけが、暗号化ASパス保護の恩恵を受けることになる。BGPsecの採用が拡大するにつれて、各グループの規模が大きくなり、最終的にはそれらが結合し、連続するASのさらに大きなBGPsec対応グループを形成する。早期採用者にとってのメリットは、それぞれのグループにまたがる連続ASの領域内のASパスのセキュリティから始まる。時間の経過とともに、隣接するASの領域がさらに大きくなっていくだろう。

部分的な展開中に、パス内のASがBGPsecをサポートしていない場合、BGPは従来のモードに戻る。つまり、BGPsec UPDATEメッセージは、そのASに転送する前に署名なしのUPDATEメッセージに変換される(セクション4.4を参照)。この時点で、UPDATEメッセージが一連のASを経由して伝播するという保証は失われる。言い換えれば、オリジンASから始まり、BGPsecをサポートしていないASの前のASに存在するBGPsecルータに対しては、保証は引き続き提供できるが、それを超えることはできない(UPDATEメッセージを考慮している場合)。

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

BGPsecの脅威モデルと関連するセキュリティ上の考慮事項については、RFC 7132 [RFC7132]を参照のこと。

8.1. 安全性の保証

オリジン検証(RFC 6483[RFC6483]及びRFC 6811[RFC6811]を参照)と併用する場合、あるプレフィックスの経路広告を含む有効なBGPsec UPDATEメッセージを受信するBGPsecスピーカーは、以下のセキュリティ保証が提供される。

  • オリジンAS番号は、RPKIにおいて、あるプレフィックスに対する経路広告を発信することをIPアドレス空間保有者から認可されたASに対応する。

  • パス内の各ASに対して、AS番号の保有者によって認可されたBGPsecスピーカーが、(ローカル・ポリシーに従って)意図的に経路広告をパスの後続ASに伝播することを選択する。

つまり、有効なBGPsec UPDATEメッセージの受信者は、そのUPDATE メッセージがBGPsec_PATH属性のSecure_Path部分にリストされたASシーケンスを介して伝播したことが保証される。(BGPsecは、データパケットが指定されたパスに沿って流れることを保証するものではなく、パスを伝えるBGP UPDATEメッセージが指示されたパスに沿って実際に伝播したことだけを保証するものであることに留意すること。) さらに、受信者はこのパスがあるプレフィックスへのトラフィックの正当な宛先としてIPアドレス空間の保有者によって認可されたASで終了することが保証される。

BGPsecは、ASが受信したUPDATEメッセージが信頼できるセキュリティ特性を持つことを検証するメカニズムを提供するが、経路選択に影響を与えるためにそのようなメカニズムを使用することは完全にローカルポリシーの問題であることに留意すること。したがって、BGPsecスピーカーは、外部(eBGP)BGPsecピアから受信した経路の有効性について仮定することはできない。つまり、準拠しているBGPsecピアは、(そのピアのローカルポリシーに応じて)セクション5の有効性テストに失敗するUPDATEメッセージを送信するかも知れない。したがって、BGPsecスピーカーは、外部ピアから受信したすべてのBGPsec UPDATEメッセージを完全に検証しなければならない(MUST)。(内部ピアから受信したUPDATEメッセージの検証もローカルポリシーの問題である。セクション5を参照。)

8.2. BGPsec署名の削除について

BGPsecスピーカーが、(セクション5.2の検証アルゴリズムに従って)「有効」と「無効」の両方のSignature_Blockを含むBGPsec UPDATEメッセージを「有効」とみなす場合がある。つまり、UPDATEメッセージは2つのアルゴリズム・スイートに対応する2組の署名を含み、1組の署名は正しく検証され、もう1組の署名は検証に失敗する。この場合、プロトコルは、そのようなUPDATEメッセージで経路広告を伝播することを選択したBGPsecスピーカーは、それぞれのSignature_Blocksに署名を追加しなければならない(MUST)と規定している(セクション4.2を参照)。したがって、BGPsecスピーカーは、両方のアルゴリズム・スイートを使用して署名を作成し、(自身の観点から)「有効」と「無効」の両方の署名セットを含む新しいUPDATEメッセージを作成する。

このような設計上の決定の理由を理解するために、BGPsecスピーカーが「有効」であるアルゴリズムAの署名セットと「無効」であるアルゴリズムBの署名セットの両方を含むUPDATEメッセージを受信した場合を考える。このような場合、BGPsecスピーカーのピアの一部(またはBGPトポロジのさらにダウンストリームにある他のエンティティ)がアルゴリズムAをサポートしていない可能性がある(アルゴリズム遷移の状態によっては、その可能性が高くなる)。したがって、BGPsecスピーカーがアルゴリズムBに対応する「無効」の署名セットを削除した場合、そのようなエンティティは署名されていないかのようにメッセージを扱うだろう。経路広告を伝播するときに「無効」の署名セットを含めることで、BGPsecスピーカーはダウンストリーム・エンティティがBGPsec UPDATEメッセージの検証状態について情報に基づいた意見を述べるために可能な限り多くの情報を確実に保持できるようにする。

また、BGPsecの部分的な展開の期間中、ダウンストリーム・エンティティは、署名のないメッセージを、1組の「無効」署名を含むBGPsec UPDATEメッセージとは異なる方法で合理的に扱うかも知れないことに留意すること。つまり、「無効」署名セットを削除することで、BGPsecスピーカーは実際にダウンストリーム・エンティティに経路広告の状態を「無効」から署名なしに「アップグレード」するかも知れない。最後に、上記シナリオでは、BGPsecスピーカーは、そのASのローカルなRPKI状態に何らかの問題があるため(例えば、そのASがアルゴリズムAの署名を検証するために使用された鍵が、新たに失効した証明書に属することを示す証明書失効リスト(CRL)をまだ取得していないかも知れない)、アルゴリズムAの署名を「有効」とみなしたかも知れないことに留意する。このような場合、ダウンストリーム・エンティテが、UPDATEメッセージを「無効」(失効のため) として処理し、「署名なし」(「無効」 Signature_Blocksが途中で削除された場合に発生する)として処理することが非常に望ましい。

同様の議論は、(実行可能な代替手段がないなどの何らかの理由で)BGPsecスピーカーが 「無効」のBGPsec UPDATEメッセージで取得した経路を(与えられたプレフィックスへの)最適パスとして選択する場合にも当てはまる。このような場合、BGPsecスピーカーは、既存の「無効」署名に署名を追加して、署名済みBGPsec UPDATEメッセージを伝播すべきである。繰り返しになるが、これはダウンストリーム・エンティティが情報に基づいた判断を下せるようにするためであり、誤って経路を署名なしと扱わないようにするためである。また、ネットワーク内のさまざまな場所で観察されるRPKIデータに差異がある可能性により、アップストリームのBGPsecスピーカーで「無効」と判断されたBGPsec UPDATEメッセージが、ダウンストリームの別のBGPスピーカーでは「有効」と判断される可能性があることにも留意する必要がある。

実際、BGPsecスピーカーが発信UPDATEメッセージに署名する場合、そのスピーカーは自分の署名以前のすべての署名が有効であるという信念を証明するものではない。代わりに、以下のことを表明している。

  • BGPsecスピーカーは、指定されたプレフィックス、AFI、SAFI、Secure_Pathを持つ経路広告を受信した。

  • BGPsecスピーカーは、「ターゲットAS番号」で示されるピアに(暗黙的に) 、この経路広告を伝播することを選択した。

8.3. サービス拒否攻撃の軽減

BGPsecの更新検証手順は、BGPsecスピーカーに対するサービス拒否攻撃の潜在的な標的である。ここでは、BGPsecプロトコルに特有のサービス拒否攻撃の軽減について検討する。

このようなサービス拒否攻撃の有効性を軽減するため、BGPsecスピーカーは、低コストのチェック(構文チェックなど)を実行した後に高コストのチェック(署名検証など)を実行する更新検証アルゴリズムを実装する必要がある。セクション5.2で規定された検証アルゴリズムは、安価である可能性が高いチェックの後に、コストがかかる可能性が高いチェックを実行するように選択した。しかし、必要な検証手順を実行する相対的なコストは実装によって異なる可能性があるため、セクション5.2で規定されるアルゴリズムは、すべての実装に対して最適なサービス拒否防御を提供できるとは限らない。

さらに、非常に長いASパス(したがって多数の署名)を含むUPDATEメッセージを送信することは、サービス拒否攻撃を実行する潜在的なメカニズムである。このため、検証アルゴリズムの実装では、無効な署名が見つかった時点で署名の検証を停止することが重要である。(これにより、無効な署名の長いシーケンスがサービス拒否攻撃に使用できないことが保証される。)さらに、実装では、有効であれば最適パスとして選択されるUPDATEメッセージに対してのみ検証を実行することで、このような攻撃を軽減することができる。つまり、UPDATEメッセージに他の理由(例えば、非常に長いASパスなど)で最適パスの選択に失敗する経路が含まれている場合、その経路のBGPsec有効性状態を判断する必要はない。

8.4. 追加のセキュリティに関する考慮事項

pCountフィールドを0に設定するメカニズムは、ASパスの長さを増やすことなく、制御パス内の経路サーバがBGPsecに参加できるようにするために、この仕様に含まれている。pCount=0が利用される他の2つのシナリオは、ASコンフェデレーション(セクション4.3を参照)とASマイグレーション[RFC8206]のコンテキストである。これら2つのシナリオでは、pCount=0が設定され、同じAS内でも受け入れられる(ASは2つの異なるIDを持つ)。しかし、経路サーバ、コンフェデレーションAS、またはマイグレーションAS以外のエンティティは、このメカニズム(pCountを0に設定する)を使用して、(ASパス長を短縮することによって)トラフィックを不正に引き寄せることが考えられる。このリスクは、すべてのBGPsecスピーカーが、pCount=0を設定したり、ピアからpCount=0を受け入れたりするための設定について、セクション7.2の運用ガイダンスに従うならば、このリスクは大幅に軽減される。しかし、2ホップ以上離れた上流エンティティがpCountを0に設定したBGPsec UPDATEメッセージの受信者は、pCountが正当に0に設定されたかどうかを自分で検証できないことに留意する。

共謀しているAS間のトンネリングを介してBGPsec UPDATEメッセージを渡す可能性がある。例えば、AS-XがAS-Yとピア関係を持たず、AS-Yと共謀し、トンネリングによってBGPsec UPDATEメッセージに署名し、AS-Yに送信したとする。AS-YはさらにBGPsec UPDATEメッセージに署名し、そのピアに伝播することができる。このような悪意のある動作を検出することは、BGPsecプロトコルの範囲を超えている。BGPsecは、BGP内(つまり、コントロールプレーン内)で送信されるメッセージを保護するように設計されている ─ コントロールプレーンが迂回された場合は保護されない。

上述のトンネリングによる共謀の変形が、ASコンフェデレーションのコンテキストで起こる可能性がある。BGPsecルータ(コンフェデレーションの外部)がUPDATEメッセージを、ASコンフェデレーションのメンバーASに転送する場合、BGPsecルータはメンバーのAS番号ではなく、ASコンフェデレーションのパブリックAS番号にUPDATEメッセージを署名する(セクション4.3を参照)。メンバーASは、署名されたUPDATEメッセージを受信したまま(つまり、署名を追加せずに)別のメンバーASにトンネリングすることができる。UPDATEメッセージはその後、BGPsecを使用して他のコンフェデレーション・メンバーまたはコンフェデレーション外のBGPsecネイバーに伝播することができる。この種の操作は可能だが、以下の理由から重大なセキュリティや到達性のセキュリティ侵害は懸念されない。

  • コンフェデレーション・メンバーは1つの組織に属しており、内部の信頼が厚いことが期待される。

  • 外部のBGPsecルータにUPDATEメッセージを転送する前に、コンフェデレーション内部の署名を削除しなければならない(MUST)ことを思い出しほしい(セクション4.3を参照)。

BGPsecは、トランスポート層での攻撃に対する保護を提供しない。他のBGPセッションと同様、BGPsecスピーカーとそのピアの間のパス上の敵対者は、有効なBGPsec UPDATEメッセージを修正して検証に失敗させたり、BGPsec_PATH属性のない(署名のない)BGP UPDATEメッセージを注入したり、検証に失敗したBGPsec_PATH属性のあるBGPsec UPDATE メッセージを注入したり、ピアにBGPセッションを停止させるような攻撃を行うことができる。BGPsecの使用は、パス上の敵対者の力を増大させることはない ─ 特に、パス上の敵対者であっても、BGPsecの無効な経路が有効であると、BGPsecスピーカーに信じさせることはできない。ただし、他のBGPセッションと同様、BGPsecセッションは適切なトランスポート・セキュリティ・メカニズムによって保護すべきである(SHOULD)([RFC4271]のセキュリティに関する考慮事項を参照)。

以下のように定義されるリプレイ攻撃の可能性がある。BGPsecの文脈では、ASパスの悪意のあるBGPsecスピーカーが(暗黙的または明示的に)プレフィックスの撤回を抑止した場合にリプレイ攻撃が発生する。さらに、リプレイ攻撃は、悪意のあるBGPsecスピーカーが、撤回されたプレフィックスに対して以前に受信したBGPsecアナウンスを再生したときにも発生すると言われている。リプレイ攻撃の軽減戦略には、ルータ証明書のロールオーバーが含まれる。詳細は「ロールオーバー」を参照のこと。

⚠️ 実装について

BGPsecは、BGPプロトコルの改変になる点やルータに計算負荷が掛かる点などから、商用ルータでBGPsecを実装しているベンダーは存在しない。IETFでのBGP ASパスの保護については、ASPAを中心に議論されている。実証のための実装として、

が存在する。今回、BIRDをテスト(BIRD対向でBGPsecを交換)してみたが、実装がRFCの発行前だったため、本文書が規定しているものと仕様が異なっている。

BIRDの起動ログ

# bird -d
bird: BPGPSEC: Adding origination prefix: 10.2.1.0/24
bird: BPGPSEC: Adding origination prefix: 10.2.2.0/24
2024-05-21 16:27:20 <INFO> Started
2024-05-21 16:27:24 <DBG> parse_capability: Multiprotocol Extension AFI: IPv4
2024-05-21 16:27:24 <DBG> parse_capability: Route refresh
2024-05-21 16:27:24 <DBG> parse_capability: Graceful restart
2024-05-21 16:27:24 <DBG> parse_capability: AS4
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender BGPSEC_VERSION matches : 8
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender can send BGPSEC messages : 8
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender bgpsec AFI: IPV4 : 1
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender BGPSEC_VERSION matches : 0
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender can receive BGPSEC messages : 0
2024-05-21 16:27:24 <DBG> bgp_parse_capabilities: sender bgpsec AFI: IPV4 : 1
2024-05-21 16:27:24 <DBG> parse_capability: Enhanced route refresh
2024-05-21 16:27:24 <DBG> bgp1: bgp_create_update
2024-05-21 16:27:24 <DBG> 	bgpsec_get_buck_prefix: 10.2.2.0/24

2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.2.0/24 = 10.2.2.0/24
2024-05-21 16:27:24 <TRACE> is_bgpsec_route: BGPsec route : 10.2.2.0
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_ORIGIN
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_ORIGIN
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_AS_PATH
2024-05-21 16:27:24 <TRACE> bgp1:  BGPsec route: Dropping: BA_AS_PATH
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_NEXT_HOP
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_NEXT_HOP
2024-05-21 16:27:24 <DBG> bgp1: create update: Adding Next Hop to MP_REACH: 192.168.0.13
2024-05-21 16:27:24 <DBG>     Encode Prefix: 10.2.2.0/24
2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.2.0/24 = 10.2.2.0/24
2024-05-21 16:27:24 <TRACE> is_bgpsec_route: BGPsec route : 10.2.2.0
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_MP_REACH_NLRI
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_MP_REACH_NLRI
2024-05-21 16:27:24 <TRACE> encode_bgpsec_attr: 65100 > 65000, using NLRI 10.2.2.0/24
2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.2.0/24 = 10.2.2.0/24
2024-05-21 16:27:24 <DBG> encode_bgpsec_attr: 65100 > 65000 : AS PATH length: 1
2024-05-21 16:27:24 <TRACE> bgpsec_get_pcount: 1
2024-05-21 16:27:24 <DBG> encode_bgpsec_attr:O: Signed 65100 > 65000, signature length = 71
2024-05-21 16:27:24 <DBG>     Encode Prefix: Dequeued route 10.2.2.0/24
2024-05-21 16:27:24 <DBG> bgp1: bgp_create_update
2024-05-21 16:27:24 <DBG> 	bgpsec_get_buck_prefix: 10.2.1.0/24
2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.1.0/24 = 10.2.1.0/24
2024-05-21 16:27:24 <TRACE> is_bgpsec_route: BGPsec route : 10.2.1.0
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_ORIGIN
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_ORIGIN
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_AS_PATH
2024-05-21 16:27:24 <TRACE> bgp1:  BGPsec route: Dropping: BA_AS_PATH
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_NEXT_HOP
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_NEXT_HOP
2024-05-21 16:27:24 <DBG> bgp1: create update: Adding Next Hop to MP_REACH: 192.168.0.13
2024-05-21 16:27:24 <DBG>     Encode Prefix: 10.2.1.0/24
2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.1.0/24 = 10.2.1.0/24
2024-05-21 16:27:24 <TRACE> is_bgpsec_route: BGPsec route : 10.2.1.0
2024-05-21 16:27:24 <DBG> bgp1: bgp_encode_attrs: Attr BA_MP_REACH_NLRI
2024-05-21 16:27:24 <TRACE> bgp1:  Adding to Upd: BA_MP_REACH_NLRI
2024-05-21 16:27:24 <TRACE> encode_bgpsec_attr: 65100 > 65000, using NLRI 10.2.1.0/24
2024-05-21 16:27:24 <TRACE> BGPsec Origination Route:  10.2.1.0/24 = 10.2.1.0/24
2024-05-21 16:27:24 <DBG> encode_bgpsec_attr: 65100 > 65000 : AS PATH length: 1
2024-05-21 16:27:24 <TRACE> bgpsec_get_pcount: 1
2024-05-21 16:27:24 <DBG> encode_bgpsec_attr:O: Signed 65100 > 65000, signature length = 70
2024-05-21 16:27:24 <DBG>     Encode Prefix: Dequeued route 10.2.1.0/24
2024-05-21 16:27:24 <DBG> bgp1: bgp_create_update
2024-05-21 16:27:24 <DBG> bgp1: bgp_create_update
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_ORIGIN : 01 40 1
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_NEXT_HOP : 03 40 4
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_MP_REACH_NLRI : 0e 80 13
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_BGPSEC_SIGNATURE : 1e 80 105
2024-05-21 16:27:24 <TRACE> DECODE_BGPSEC_ATTR: 65100 < 65000
2024-05-21 16:27:24 <DBG> decode_bgpsec: 65100 < 65000 : using NLRI 10.1.2.0/24
2024-05-21 16:27:24 <DBG> decode_bgpsec: 65100 < 65000 : good last sig. AS: 65000, marked BGPsec Valid
2024-05-21 16:27:24 <DBG> bgpsec_create_aspath: tot pcount/as path length : 1
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update: using MP_REACH: x: 8.192.136.198, len: 4
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update: Adding: 10.1.2.0/24
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_ORIGIN : 01 40 1
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_NEXT_HOP : 03 40 4
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_MP_REACH_NLRI : 0e 80 13
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_BGPSEC_SIGNATURE : 1e 80 103
2024-05-21 16:27:24 <TRACE> DECODE_BGPSEC_ATTR: 65100 < 65000
2024-05-21 16:27:24 <DBG> decode_bgpsec: 65100 < 65000 : using NLRI 10.1.1.0/24
2024-05-21 16:27:24 <DBG> decode_bgpsec: 65100 < 65000 : good last sig. AS: 65000, marked BGPsec Valid
2024-05-21 16:27:24 <DBG> bgpsec_create_aspath: tot pcount/as path length : 1
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update: using MP_REACH: x: 8.192.137.104, len: 4
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update: Adding: 10.1.1.0/24
2024-05-21 16:27:24 <DBG> bgp1: bgp_do_rx_update
2024-05-21 16:27:24 <DBG> bgp1: BGP Decode: Attr BA_MP_UNREACH_NLRI : 0f 80 3

BIRDコンソールの情報

# birdc
BIRD 1.6.0 ready.
bird> show route
10.2.2.0/24        dev ens160 [static1 16:27:20] * (200)
10.2.1.0/24        dev ens160 [static1 16:27:20] * (200)
10.1.2.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:24] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
10.1.1.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:24] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
bird> show route 10.1.2.0/24
10.1.2.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:25] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
bird> show route 10.1.2.0/24 
10.1.2.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:25] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
bird> show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     16:27:25    Established   
  Description:    BGPSEC-1 Link
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  ACCEPT
  Routes:         2 imported, 2 exported, 2 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              2          0          0          0          2
    Import withdraws:            0          0        ---          0          0
    Export updates:              4          2          0        ---          2
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 192.168.0.12
    Neighbor AS:      65000
    Neighbor ID:      192.168.0.12
    Neighbor caps:    refresh enhanced-refresh restart-aware AS4
    Session:          external AS4
    Source address:   192.168.0.13
    Hold timer:       184/240
    Keepalive timer:  38/80

bird> show route all
10.2.2.0/24        dev ens160 [static1 16:27:21] * (200)
	Type: static-device unicast univ
10.2.1.0/24        dev ens160 [static1 16:27:21] * (200)
	Type: static-device unicast univ
10.1.2.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:25] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 65000
	BGP.next_hop: 192.168.0.12
	BGP.local_pref: 100
	BGP.bgpsec_signature: 00 08 01 00 00 00 fd e8 00 61 01 ea ca e7 4c 7d 85 99 ba 5e 6e 67 da c8 84 09 9f de 29 18 93 00 48 30 46 02 21 00 d3 e4 a1 24 d6 bf d0 d1 00 2f 9e 35 a2 3e 36 e0 c9 70 d7 6a 45 2a 38 46 87 20 8e 3a 27 dc a5 78 02 21 00 dc 15 14 6b f1 e4 fb 49 99 dc bf 8b 92 13 e0 52 c6 c7 72 7a f4 f4 be a6 ac ff e7 27 55 f0 eb f4
	BGP.dd: 1
10.1.1.0/24        via 192.168.0.12 on ens224 [bgp1 16:27:25] * (100) [AS65000i] ASP:1 (BSEC VALID: 65000)
	Type: BGP unicast univ
	BGP.origin: IGP
	BGP.as_path: 65000
	BGP.next_hop: 192.168.0.12
	BGP.local_pref: 100
	BGP.bgpsec_signature: 00 08 01 00 00 00 fd e8 00 5f 01 ea ca e7 4c 7d 85 99 ba 5e 6e 67 da c8 84 09 9f de 29 18 93 00 46 30 44 02 20 33 2e 18 5a c8 9b 53 93 d3 5a 07 38 01 ae 96 23 bc 5c d4 f9 ad 58 f1 08 d2 7a 04 e4 35 e5 22 af 02 20 34 3e b0 41 42 7a 78 01 8c 70 2f 01 31 54 0f fe e3 f8 3f 05 78 f9 98 b5 04 2a 25 81 64 30 82 00
        BGP.dd: 1
bird>

9. IANAに関する考慮事項

IANAは、セクション2.1で説明した新しいBGPケーパビリティ「Capability Codes」レジストリの「IETF Review」範囲に登録した[RFC8126]。新しいケーパビリティの説明は「BGPsec Capability」である。本文書は、新しいケーパビリティのリファレンスである。

IANAはまた、セクション3で説明した新しいパス属性も「BGP Path Attributes」レジストリに登録した。この新しい属性のコードは「BGPsec_PATH」である。本文書は、新しい属性のリファレンスである。

IANAは、「Resource Public Key Infrastructure (RPKI)」グループに「BGPsec Capability」レジストリを定義した。レジストリは図10に示すとおりで、セクション2.1から値が割り当てられている。

ビット フィールド 参考資料
0-3 バージョン
値 = 0x0		 [RFC8205]
4 方向
(可能な値0と1の両方が、このRFCで完全に規定されている)		 [RFC8205]
5-7 未割り当て
値 = 000 (2進数)		 [RFC8205]

図10: BGPsecケーパビリティのIANAレジストリ

方向ビット(4番目のビット)の値は0または1であり、どちらの値も本文書で完全に指定されている。将来のバージョン値と未割り当てビットの将来の値は、RFC 8126[RFC8126]で定義されている「Standards Action」登録手順を使用して割り当てられる。

IANAは、「Resource Public Key Infrastructure (RPKI)」グループに「BGPsec_PATH Flags」レジストリを定義した。レジストリは図11に示すとおりで、セクション3.1で1つの値が割り当てられている。

フラグ 説明 参考文献
0 Confed_Segment
ビット値 = 1はフラグが設定されていることを意味する(Confed_Segment を示す)
ビット値 = 0 がデフォルト		 [RFC8205]
1-7 未割り当て
値: 7 ビットすべてがゼロに設定される		 [RFC8205]

図11: BGPsec_PATHフラグ・フィールドのIANAレジストリ

未割り当てビットの将来の値は、RFC 8126[RFC8126]で定義されている「Standards Action」登録手順を使用して割り当てられる。

10. 参考文献

10.1. 引用規格

[IANA-AF] IANA, "Address Family Numbers", <https://www.iana.org/assignments/address-family-numbers>.

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

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/info/rfc4724>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

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

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

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-editor.org/info/rfc6793>.

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

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

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.

[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.

10.2. 参考規格

[Borchert] Borchert, O. and M. Baer, "Subject: Modification request: draft-ietf-sidr-bgpsec-protocol-14", message to the IETF SIDR WG Mailing List, 10 February 2016, <https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>.

[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", NIST FIPS Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, DOI 10.17487/RFC6472, December 2011, <https://www.rfc-editor.org/info/rfc6472>.

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

[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012, <https://www.rfc-editor.org/info/rfc6483>.

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.

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

[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods for Generating Key Identifiers Values", RFC 7093, DOI 10.17487/RFC7093, December 2013, <https://www.rfc-editor.org/info/rfc7093>.

[RFC7115] Bush, R., "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 7115, DOI 10.17487/RFC7115, January 2014, <https://www.rfc-editor.org/info/rfc7115>.

[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, DOI 10.17487/RFC7132, February 2014, <https://www.rfc-editor.org/info/rfc7132>.

[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", July 2017, <https://www.rfc-editor.org/info/rfc8181>.

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.

[RFC8206] George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>.

[RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, RFC 8207, DOI 10.17487/RFC8207, September 2017, <https://www.rfc-editor.org/info/rfc8207>.

[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.

[ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf-sidrops-bgpsec-rollover-01, August 2017.

[SLURM] Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified Local internet nUmber Resource Management with the RPKI", Work in Progress, draft-ietf-sidr-slurm-04, March 2017.

[SP800-90A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf>.

謝辞

著者らは、マイケル・ベアー、オリバー・ボルヒャート、デビッド・マンデルバーグ、メフメット・アダリエ、ショーン・ターナー、ウェス・ジョージ、ジェフ・ハース、アルバロ・レタナ、ネビル・ブラウンリー、マティアス・ヴァエリッシュ、ティム・ポーク、ラス・マンディ、ウェス・ハーデカー、シャロン・ゴールドバーグ、エド・カーン、ダグ・モーガン、プラドシュ・モハパトラ、マーク・レイノルズ、ヘザー・シラー、ジェイソン・シラー、ルディガー・ヴォルク、デヴィッド・ウォードら、各氏の作業の過程でのレビュー、コメント、提案に感謝する。また、多くのIESGレビュアーの方々のコメントにより、文書の明瞭性、正確性、表現の向上に大きく貢献したことにも感謝する。

著者らは特に、オリバー・ボルヒャートとマイケル・ベアーの、ハッシュ化されるオクテットのシーケンスに関するレビューと提案[Borchert]に対して、感謝したい(それぞれセクション4.2と5.2の図8と9)。これは、彼らの実装経験に基づいた重要な貢献だった。

貢献者

以下の人々は本文書に多大な貢献をしており、共著者とみなされるべきである。

ロブ・オースタイン
Dragon Research Labs
メール: sra@hactrn.net

スティーブン・ベロビン
コロンビア大学
電子メール: smb@cs.columbia.edu

ラス・ハウスリー
Vigil Security
メール: housley@vigilsec.com

スティーブン・ケント
BBN Technologies
メール: kent@alum.mit.edu

ウォーレン・クマリ
Google
メール: warren@kumari.net

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

クリス・モロー
Google, Inc.
メール: morrowc@google.com

サンディ・マーフィー
SPARTA, Inc., a Parsons Company
メール: Sandy@tislabs.com

ケユル・パテル
Arrcus
メール: keyur@arrcus.com

ジョン・スカダー
Juniper Networks
メール: jgs@juniper.net

サミュエル・ワイラー
W3C/MIT
メール: weiler@csail.mit.edu

著者のアドレス

マシュー・レピンスキー (編集者)
New College of Florida
5800 Bay Shore Road
Sarasota, FL 34243
アメリカ合衆国
メール: mlepinski@ncf.edu

コティカラプディ・スリラム (編集者)
米国国立標準技術研究所
100 Bureau Drive
Gaithersburg, MD 20899
アメリカ合衆国
メール: kotikalapudi.sriram@nist.gov

更新履歴

  • 2024.5.17
  • 2024.7.1: オプションの→任意
GitHubで編集を提案

Discussion