💨

RFC 8416: RPKIによる簡易ローカル・インターネット番号リソース管理(SLURM)

2024/03/29に公開

要旨

リソース公開鍵基盤(RPKI)は、インターネット番号リソース(INR)の保有者が、それらのリソースについて検証可能なステートメントを行えるようにするグローバル認証基盤である。インターネット・サービス・プロバイダ(ISP)などのネットワーク・オペレータは、RPKIを使用してBGP経路オリジンのアサーションを検証できる。ISPは、RPKIを使用して BGP経路パスを検証することもできる。一方、ISPは、ローカル・フィルタや追加という形で、RPKIデータに対する例外のローカル・ビューを確立したい場合がある。本文書で説明するメカニズムは、INRの保有者がRPKIのローカルかつカスタマイズされたビューを確立し、必要に応じてグローバルRPKIリポジトリ・データをオーバーライドできるようにする簡易な方法を提供する。

本文書の位置付け

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

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc8416 で入手できる。

著作権表示

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

1. はじめに

リソース公開鍵基盤(RPKI)は、インターネット番号リソース(INR)の保有者が、それらのリソースについて検証可能なステートメントを行えるようにするグローバル認証基盤である。例えば、IP(v4またはv6)アドレス・ブロックの保有者は、経路オリジン認可(ROA)[RFC6482]を発行して、そのブロックの経路を発信する自律システム(AS)を認可できる。その後、インターネット・サービス・プロバイダ(ISP)はRPKIを使用して、BGP経路を検証できる。(経路オリジン検証は [RFC6811]に説明されており、経路パス検証は[RFC8205]で説明されています。)

一方、RPKIリライング・パーティー(RP)は、設定されたトラストアンカー(TA)およびRPKIリポジトリ・システムからダウンロードされた証明書によって表明された情報の一部をオーバーライドしたい場合がある。例えば、[RFC6491]は、予約済みおよび未割り当てのアドレス空間のパブリック経路を無効にするROAの作成を推奨しているが、一部のISPは、プライベート・アドレス空間([RFC1918]、[RFC4193]、[RFC6598]を参照)やプライベートAS番号([RFC1930]と[RFC6996]を参照)を使用してBGPとRPKIを使用したい場合がある。上記で引用したRFCと一致する、プライベート・アドレス空間やプライベートAS番号のローカル使用はグローバルRPKIでは検証できない。そのため、ネットワーク・オペレータが、(自社および顧客のために)フィルタと追加機能という形で、RPKIに対する例外を独自の裁量で公開できるメカニズムを開発する動機付けとなる。さらに、ネットワーク・オペレータは、そのような動きが議論される結果が出るまで、有害な動きから経路を保護するために、ローカル・オーバーライド機能を利用することを望むかもしれない[RFC8211]。この機能をネットワーク・オペレータに提供するために開発されたメカニズムは、「RPKIによる簡易ローカル・インターネット番号リソース管理(SLURM: Simplified Local Internet Number Resource Management with the RPKI )」と呼ばれる。

SLURMは、オペレータがアサーション・セットを作成することで、グローバルRPKIのローカル・ビューを作成できる。オリジン検証[RFC6811]の場合、アサーションは、RPKI-Routerプロトコルのバージョン0[RFC6810]およびバージョン1[RFC8210]で使用される、{IPプレフィックス, プレフィックス長, 最大長, 自律システム番号(ASN)}というタプルである。BGPsec[RFC8205]では、アサーションは、RPKI-Routerプロトコルのバージョン1で使用される{ASN, サブジェクト鍵識別子, ルータ公開鍵}というタプルである。(本文書の残りの部分では、これらのアサーションをそれぞれ「ROAプレフィックス・アサーション」および「BGPsecアサーション」と呼ぶ。)

1.1. 用語

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

2. SLURMのあるRP

SLURMは、RPがRPKIのローカルでカスタマイズされたビューを確立し、必要に応じてRPKIリポジトリ・データをオーバーライドできるようにする簡易な方法を提供する。そのため、SLURMのあるRPは、ローカルROAプレフィックス・アサーションおよびBGPsecアサーションによってオーバーライドされるRPKIのアサーションを除外する(つまり、ルーティング決定の考慮事項から除外する)。

⚠️ SLURMの有無による違い

通常のRPKIでは、AS100からの10.0.0.0/24に対する経路を無効と判断する。

cfig1

無効と判断した経路を、自ASの中では有効としたい場合、SLURMを用いることができる。SLURMでローカルROAプレイフィックス・アサーションを設定する。

cfig1

一般に、RPの主な出力は、RPKI-Routerプロトコル[RFC8210]を介して、ルータに送信するデータである。RPKI-Routerプロトコルを使用すると、ルータはRPに、RPが知っているすべてのアサーションについて問い合わせるか(リセット・クエリ)、アサーションの変更のみの更新を問い合わせることができる(シリアル・クエリ)。本文書に規定されるメカニズムは、リセット・クエリの結果セット、およびシリアル・クエリで比較される新旧セットの両方に適用される。RPソフトウェアは、同様の方法で他の形式の出力を変更することができるが、それは本文書の範囲外である。

fig1
図1: RPスタックにおけるSLURMの位置付け

⚠️ 各種実装について

Routinator: -x file, --exceptions=fileオプションでSLURMファイルのパスを指定して起動する。https://routinator.docs.nlnetlabs.nl/en/stable/local-exceptions.html
FORT Validator: 実行時に、--slurmオプションを使用する。https://nicmx.github.io/FORT-validator/slurm.html

3. SLURMファイルとメカニズム

3.1. JSONの使用

SLURMフィルタとアサーションは、JSON形式[RFC8259]で指定する。ここで定義されていないJSONメンバーは、SLURMファイルで使用してはならない。RPは仕様からの逸脱をエラーとみなさなければならない(MUST)。将来、本文書の仕様に追加する場合は、「slurmVersion」メンバーの増分値を使用しなければならない(MUST)。

3.2. SLURMファイルの概要

SLURMファイルは、以下のメンバーを含む1つのJSONオブジェクトで構成される。

「slurmVersion」メンバーは、数値として符号化された1に設定しなければならない(MUST)。
「validationOutputFilters」メンバー(セクション3.3)の値はオブジェクトである。オブジェクトは正確に2つのメンバーが含まれていなければならない(MUST)。
- 「prefixFilters」メンバーの値はセクション3.3.1に記載されている。
- 「bgpsecFilters」メンバーの値はセクション3.3.2に記載されている。
「locallyAddedAssertions」メンバー(セクション 3.4)の値はオブジェクトである。オブジェクトは正確に2つのメンバーが含まれていなければならない(MUST)。
- 「prefixAssertions」メンバーの値はセクション3.4.1に記載されている。
- 「bgpsecAssertions」メンバーの値はセクション3.4.2に記載されている。

想定される一般的な使用例では、RPは検証出力フィルタとローカルに追加されたアサーションの両方を使用する。この場合、結果として得られるアサーションは、アサーションをローカルに追加する前に出力フィルタリングが実行された場合と同じでなければならない(MUST)。つまり、ローカルに追加されたアサーションは出力フィルタリングによって削除してはならない(MUST NOT)。

以下のJSONメンバーを持つJSON構造は、フィルタやアサーションを持たないSLURMファイルを表している。

{
  "slurmVersion": 1,
  "validationOutputFilters": {
    "prefixFilters": [],
    "bgpsecFilters": []
  },
  "locallyAddedAssertions": {
    "prefixAssertions": [],
    "bgpsecAssertions": []
  }
}

図2: 空のSLURMファイル

3.3. 検証出力フィルタ

3.3.1. 検証済みROAプレフィックス・フィルタ

RPは、0個以上の検証済みROAプレフィックス・フィルター (略して「プレフィックス・フィルタ」)を設定できる。各プレフィックス・フィルタには、IPv4またはIPv6プレフィックス、および/またはASNを含めることができる。RPソフトウェアのユーザに表示できるように、各プレフィックス・フィルタに説明コメントを含めることを推奨する。

上記は、「prefixFilters」メンバーの値は、0個以上のオブジェクトの配列として表される。各オブジェクトは、1) 以下のメンバーのいずれか1つ、または 2) 以下の各メンバーの1つを含めなければならない(MUST)

「prefix」メンバー。その値は、IPv4プレフィックス([RFC4632]のセクション3.1を参照)またはIPv6プレフィックス([RFC5952]を参照)を表す文字列である。
「asn」メンバー。その値は数値である。

さらに、各オブジェクトは、値が文字列であるオプションの「comment」メンバーを1つ含めてもよい(MAY)。

以下のJSON構造例は、「prefixFilters」メンバーに上記の各ユースケースに対応するオブジェクトの例を配列で表したものである。

    "prefixFilters": [
      {
        "prefix": "192.0.2.0/24",
        "comment": "All VRPs encompassed by prefix"
      },
      {
        "asn": 64496,
        "comment": "All VRPs matching ASN"
      },
      {
        "prefix": "198.51.100.0/24",
        "asn": 64497,
        "comment": "All VRPs encompassed by prefix, matching ASN"
      }
    ]

図3: 「prefixFilters」の例

設定されたプレフィックス・フィルタに一致する検証済みROAペイロード(VRP)[RFC6811]は、RPの出力から削除しなければならない(MUST)。

以下のいずれかに該当する場合、VRPはプレフィックス・フィルタと一致するとみなされる:

プレフィックス・フィルタにIPv4またはIPv6プレフィックスしか含まれていない場合、VRPのプレフィックスがプレフィックス・フィルタのプレフィックスと等しいか、またはプレフィックスでカバーされていれば、VRPはフィルタに一致するとみなす。
プレフィックス・フィルタがASNだけを含む場合、VRPのASNがプレフィックス・フィルタのASNと一致すれば、VRPはフィルタに一致するとみなされる。
プレフィックス・フィルタにIPv4またはIPv6プレフィックスとASNの両方が含まれている場合、VRPのプレフィックスがプレフィックス・フィルタのプレフィックスと等しいか、またはプレフィックスでカバーされており、かつVRPのASNがプレフィックス・フィルタのASNと一致すれば、VRPはフィルタに一致すると見なされる。

3.3.2. BGPsecアサーション・フィルタ

RPは、0個以上のBGPsecアサーション・フィルタ(略して「BGPsecフィルタ」)を設定できる。各BGPsecフィルタは、[RFC8209]および[RFC6487]で説明されているように、ASNおよび/またはルータのサブジェクト鍵識別子(SKI)のBase64[RFC4648]で符号化したものを含めることができる。RPソフトウェアのユーザに示すことができるように、各BGPsecフィルタには説明コメントも含めることが推奨される(RECOMMENDED)。

上記は、「bgpsecFilters」メンバーの値として、0個以上のオブジェクトの配列で表される。各オブジェクトは、以下のメンバーのいずれか1つ、または両方のメンバーを1つずつ含まなければならない(MUST)。

「asn」メンバー、その値は数値である
「SKI」メンバー。その値は、[RFC6487]のセクション4.8.2に記載されている、証明書のサブジェクト鍵識別子の末尾に「=」([RFC4648]のセクション5)を付けずに、Base64で符号化したものである。(これは、ASN.1 OCTET STRINGからASN.1タグや長さフィールドを除いた値である。)

さらに、各オブジェクトはオプションの「comment」メンバーを1つ含めてもよい (MAY)。その値は文字列である。

以下のJSON構造例は、上記の各ユースケースのオブジェクト例の配列を持つ「bgpsecFilters」メンバーを表している:

    "bgpsecFilters": [
      {
        "asn": 64496,
        "comment": "All keys for ASN"
      },
      {
        "SKI": "<Base 64 of some SKI>",
        "comment": "Key matching Router SKI"
      },
      {
        "asn": 64497,
        "SKI": "<Base 64 of some SKI>",
        "comment": "Key for ASN 64497 matching Router SKI"
      }
    ]

図4: 「bgpsecFilters」の例

設定されたBGPsecフィルタに一致するBGPsecアサーションは、RPの出力から削除しなければならない(MUST)。次のいずれかの場合に該当する場合、BGPsecアサーションはBGPsecフィルタと一致すると見なされる:

BGPsecフィルタがASNのみを含む場合、アサーションASNがフィルタASNと一致すれば、BGPsecアサーションは一致するとみなされる。
BGPsecフィルタがSKIのみを含む場合、アサーション・ルータSKIがフィルタSKIと一致すれば、BGPsec アサーションは一致するとみなされる。
BGPsecフィルタがASNとルータSKIの両方を含む場合、アサーションASNがフィルタASNと一致し、アサーション・ルータSKIがフィルタSKIと一致すれば、BGPsecアサーションは一致するとみなされる。

3.4. ローカルに追加されたアサーション

3.4.1. ROAプレフィックス・アサーション

各RPは、ROAプレフィックス・アサーション(略して「プレフィックス・アサーション」)の(おそらく空)配列をローカルに設定する。各ROAプレフィックス・アサーションは、IPv4またはIPv6プレフィックスとASNが含まなければならない(MUST)。プレフィックス最大長の値を含めてもよい(MAY)。RPソフトウェアのユーザに示すことができるように、それぞれに説明コメントも含めることが推奨される(RECOMMENDED)。

上記は、「prefixAssertions」メンバーの値として、0個以上のオブジェクトの配列で表される。各オブジェクトは、以下の各メンバーを1つずつ含まなければならない(MUST)。

「prefix」メンバー。その値は、IPv4プレフィックス([RFC4632]のセクション3.1を参照)またはIPv6プレフィックス([RFC5952]を参照)を表す文字列である。
「asn」メンバー。その値は数値である。

さらに、各オブジェクトは以下の各メンバーが1つずつ含んでもよい(MAY):

「maxPrefixLength」メンバー。その値は数値である。
「comment」メンバー。その値は文字列である。

以下のJSON構造例は、「prefixAssertions」メンバーに、上記の各ユースケースのオブジェクト例の配列で表している。

  "prefixAssertions": [
    {
      "asn": 64496,
      "prefix": "198.51.100.0/24",
      "comment": "My other important route"
    },
    {
      "asn": 64496,
      "prefix": "2001:DB8::/32",
      "maxPrefixLength": 48,
      "comment": "My other important de-aggregated routes"
    }
  ]

図5: 「prefixAssertions」の例

プレフィックス、ASN、およびオプションの最大長の組み合わせは、[RFC6811]に記載されているように、VRPを記述することに留意する。RPは、RPKI検証で見つかったVRPに、この方法で見つかったすべてのプレフィックス・アサーションを追加し、RPKI-Routerプロトコルを使用する場合は、重複を除いたプロトコル・データ・ユニット(PDU) の完全セットを送信するようにしなければならない([RFC8210])。

3.4.2. BGPsecアサーション

各RPは、BGPsecアサーションの(おそらく空)配列でローカルに設定される。各BGPsecアサーションはAS番号、ルータSKI、ルータ公開鍵を含まなければならない(MUST)。RPソフトウェアのユーザに表示できるように、説明コメントを含めることが推奨される(RECOMMENDED)。

上記は、「bgpsecAssertions」メンバーの値として、0個以上のオブジェクトの配列で表せる。各オブジェクトは、以下のすべてのメンバーを1つずつ含まなければならない(MUST)。

~~「asn」メンバー。その値は数値である。~~
「SKI」メンバー。その値は、[RFC6487]のセクション4.8.2に記載されているように、証明書のサブジェクト鍵識別子の末尾に「=」([RFC4648]のセクション5)を付けずに、Base64で符号化した値である。(これは、ASN.1 OCTET STRINGからASN.1タグや長さフィールドを除いた値である。)
「routerPublicKey」メンバー。その値は、[RFC8208]に記載されているように、ルータ証明書の公開鍵のsubjectPublicKeyInfo値に相当する値を、末尾に「=」を付けずにBase64で符号化([RFC4648]のセクション5)した値である。これは、subjectPublicKeyInfo SEQUENCEのASN.1タグと長さの値を含む、subjectPublicKeyInfoの完全なASN.1 DERの符号化である。

Errata (保留中)

セクション3.4.2の上記部分は以下のように書くべきである:

上記は、「bgpsecAssertions」メンバーの値として、0個以上のオブジェクトの配列で表され、各オブジェクトは、以下のすべてのメンバーがそれぞれ1つずつ含まなければならない(MUST)。

「asn」メンバー。その値は数値である。

「SKI」メンバー。その値は、[RFC6487]のセクション4.8.2に記載されているように、証明書のサブジェクト鍵識別子の末尾「=」([RFC4648]のセクション5)を付けずに、Base64で符号化した値である(これは、ASN.1 OCTET STRINGからASN.1タグや長さフィールドを除いた値である。)

「routerPublicKey」メンバー。その値は、[RFC8208]に記載されているように、ルータ証明書の公開鍵subjectPublicKeyInfo値に相当する値を、末尾に「=」を付けずにBase64で符号化([RFC4648]のセクション5)した値である。これは、subjectPublicKeyInfo SEQUENCEのASN.1タグと長さの値を含む、subjectPublicKeyInfoの完全なASN.1 DERの符号化である。

さらに、各オブジェクトは、値が文字列のオプション「comment」メンバーを1つ含んでもよい(MAY)。

注記:

「comment」メンバーは、本文書で定義されている他のすべての構造に現れることが許可されており、セクション3.4.2と3.5に示された例にも現れていることから、ここでも許可されることが意図されていることは明らかである。

[ウォーレン・クマリ: スレッド https://mailarchive.ietf.org/arch/msg/sidrops/uEc7K01ex0GJ6tE_FqfDwDTZTws/ を参照のこと

コメントで詰まるような実装は知らない]

次のJSON構造例は、上記で説明したように1つのオブジェクトを持つ「bgpsecAssertions」メンバーを表す:

  "bgpsecAssertions": [
    {
      "asn": 64496,
      "SKI": "<some base64 SKI>",
      "routerPublicKey": "<some base64 public key>",
      "comment": "My known key for my important ASN"
    }
  ]

図6: 「bgpsecAssertions」の例

「bgpsecAssertions」メンバーは、[RFC8210]のセクション5.10に記載されている Router Key PDUの構文と一致することに留意する。リライング・パーティーは、RPKI-Routerプロトコル[RFC8210]を使用する場合、重複を除いて、このようにして見つかった「bgpsecAssertions」メンバーをRouter Key PDUセットに追加しなければならない(MUST)。

3.5. フィルタとアサーションを含むSLURMファイルの例

以下のJSON構造は、前のセクションで説明したすべての要素を使用するSLURMファイルの例を表している:

  {
    "slurmVersion": 1,
    "validationOutputFilters": {
      "prefixFilters": [
        {
          "prefix": "192.0.2.0/24",
          "comment": "All VRPs encompassed by prefix"
        },
        {
          "asn": 64496,
          "comment": "All VRPs matching ASN"
        },
        {
          "prefix": "198.51.100.0/24",
          "asn": 64497,
          "comment": "All VRPs encompassed by prefix, matching ASN"
        }
      ],
      "bgpsecFilters": [
        {
          "asn": 64496,
          "comment": "All keys for ASN"
        },
        {
          "SKI": "Zm9v",
          "comment": "Key matching Router SKI"
        },
        {
          "asn": 64497,
          "SKI": "YmFy",
          "comment": "Key for ASN 64497 matching Router SKI"
        }
      ]
    },
    "locallyAddedAssertions": {
      "prefixAssertions": [
        {
          "asn": 64496,
          "prefix": "198.51.100.0/24",
          "comment": "My other important route"
        },
        {
          "asn": 64496,
          "prefix": "2001:DB8::/32",
          "maxPrefixLength": 48,
          "comment": "My other important de-aggregated routes"
        }
      ],
      "bgpsecAssertions": [
        {
          "asn": 64496,
          "comment" : "My known key for my important ASN",
          "SKI": "<some base64 SKI>",
          "routerPublicKey": "<some base64 public key>"
        }
      ]
    }
  }

図7: 完全なSLURMファイルの例

4. SLURMファイルの設定

4.1. SLURMファイルの原子性

ローカルな一貫性を保証するには、SLURMの効果はアトミックでなければならない(MUST)。つまり、RPの出力は、SLURMファイルが使われなかった場合と同じでなければならない(MUST)か、SLURM設定全体を反映しなければならない(MUST)。これが必要な理由の例として、同じプレフィックスで送信元ASNが異なる2つのローカル経路を考えてみる。どちらの経路もローカルに追加されたアサーションで設定されている。どちらの追加も行われなかった場合、両方の経路がNotFound状態になる可能性がある[RFC6811]。両方が追加された場合、両方の経路が有効状態になる。しかし、一方が追加され、もう一方が追加されない場合、一方が無効で、もう一方が有効になる可能性がある。

4.2. 複数のSLURMファイル

実装は、複数のSLURMファイルの同時使用をサポートしてもよい(MAY)。この場合、検証出力フィルタとローカルに追加されたアサーションへの入力は、各ファイルからの入力を結合したものになる。複数のファイルの想定される一般的な使用例は、ファイルが個別のスコープを持つ場合である。例えば、2つの異なるネットワークのオペレータが、ルーティング決定を組み立てるため、1つのRPシステムに頼ることがある。そのような場合、おそらくこのRPにSLURMファイルを個別に配信する必要がある。RPは、さまざまなソースからSLURMファイルを設定する前に、これらのSLURMファイルのINRアサーション間に内部衝突がないことを確認しなければならない(MUST)。そのために、RPはINRアサーションの重複に関して各SLURMファイルのエントリをチェックし、問題のSLURMファイルを作成したソースにエラーを報告する必要がある(SHOULD)。RPは複数のSLURMファイルをセットとして取得し、SLURMファイル間に重複がある場合にはセット全体を拒否しなければならない(MUST)。

これらのSLURMファイルの中のINRアサーションで問題が検出された場合、RPはそれらを使用してはならず(MUST NOT)、以下の場合はエラーを報告して警告を発する必要がある(SHOULD)。

SLURMファイルYとZに異なるIPアドレスXが存在し、XがファイルYの「prefixAssertions」または「prefixFilters」のいずれかのプレフィックスに含まれ、XがファイルZの「prefixAssertions」または「prefixFilters」のいずれかのプレフィックスに含まれる場合、ROAのプレフィックス・アサーションに矛盾する変更が発生する可能性がある。
SLURMファイルYとZに異なるASN Xが存在し、XがファイルYの「bgpsecAssertions」または「bgpsecFilters」で使用され、XがファイルZの「bgpsecAssertions」または「bgpsecFilters」で使用される場合、BGPsecアサーションに矛盾した変更が発生する可能性がある。

5. IANAに関する考慮事項

本文書にはIANAのアクションはない。

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

本文書で説明するメカニズムは、アドレス空間とASN管理の自律性を維持しながら、RPKIデータの使用をコントロールする追加の方法をネットワーク・オペレータに提供する。これらのメカニズムはローカルでのみ適用され、他のネットワーク・オペレータがRPKIデータを解釈する方法に影響を与えるものではない。それでもやはり、これらのメカニズムの採用方法には注意が必要である。SLURMを使用して、(グローバルにルーティングされる割り当てられたアドレス空間など) 、非プライベートINRに関するアサーションを(ローカルに)操作することも可能であることに留意する。例えば、ネットワーク・オペレータが有害な行為によって破損したと考えるRPKIデータをオーバーライドするために、SLURMファイルを使用することができる。このような方法でSLURMを使用するネットワーク・オペレータは、細心の注意を払うべきである。

本文書で説明するメカニズムの目的は、RPがRPKIの独自のビューを作成できるようにすることであり、これは本質的にセキュリティ機能である。SLURMファイルを使用するRPは、そのファイル内のアサーションを信頼する。RPが使用するSLURMファイルにエラーがあると、RPKIによってそのRPに提供されるセキュリティを損う可能性がある。SLURMファイルは、本来であれば有効なはずのROAを無効として宣言する可能性があり、その逆も同様である。結果として、RPは、特にファイルがサードパーティによって提供されている場合、使用するSLURMファイルのセキュリティへの影響を慎重に考慮しなければならない(MUST)。

さらに、SLURMを使用する各RPは、使用するSLURMファイルの真正性と完全性を保証しなければならない(MUST)。当初、SLURMファイルはアウト・オブ・バンドで事前に設定されているかもしれないが、RPがネットワーク経由でSLURMファイルを更新する場合、更新されたSLURMファイルの真正性と完全性をRPが検証しなければならない(MUST)。真正性と完全性を保証するためにSLURMファイルを更新するメカニズムは、本文書の範囲外である。

7. 参考文献

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.

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, https://www.rfc-editor.org/info/rfc4632.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, https://www.rfc-editor.org/info/rfc4648.

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, https://www.rfc-editor.org/info/rfc5952.

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

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

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

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

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

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.

7.2. 参考規格

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, https://www.rfc-editor.org/info/rfc1918.

[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, https://www.rfc-editor.org/info/rfc1930.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, https://www.rfc-editor.org/info/rfc4193.

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

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, DOI 10.17487/RFC6491, February 2012, https://www.rfc-editor.org/info/rfc6491.

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, https://www.rfc-editor.org/info/rfc6598.

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

[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, https://www.rfc-editor.org/info/rfc6996.

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

[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", RFC 8211, DOI 10.17487/RFC8211, September 2017, https://www.rfc-editor.org/info/rfc8211.

謝辞

スティーブン・ケントの指導と詳細なレビューに感謝する。また、リチャード・ハンセンの入念なレビューと、ホイ・ゾウとチュンリン・アンの編集協力にも感謝する。

著者のアドレス

ディ・マ
ZDNS
4 South 4th St. Zhongguancun
Haidian, Beijing 100190
中国
メール: madi@zdns.cn

デビッド・マンデルバーグ
無所属
メール: david@mandelberg.org
URI: https://david.mandelberg.org

ティム・ブルインジールス
NLnet Labs
Science Park 400
Amsterdam 1098 XH
オランダ
メール: tim@nlnetlabs.nl

更新履歴

2024.3.29

GitHubで編集を提案

要旨