Zenn
🦺

RFC 6480: 安全なインターネット・ルーティングをサポートする基盤

2024/02/15に公開
Security
#
rfc
#
bgp
tech

要旨

本文書は、インターネット・ルーティングのセキュリティ向上をサポートする基盤のアーキテクチャについて説明する。このアーキテクチャの基盤は、IPアドレス空間と自律システム(AS)番号の割り当て階層を表すリソース公開鍵基盤 (RPKI)、およびRPKIを構成するデータ・オブジェクトや、ルーティング・セキュリティの向上に必要な他の署名済みオブジェクトを保管し、配布するための分散リポジトリ・システムである。このアーキテクチャの最初の応用例として、本文書は、IPアドレス空間の正統な(legitimate)保有者が、そのアドレス空間への経路を発信する1つ以上のASを明示的かつ検証可能な形で認可する(authorize)方法について説明する。このような検証可能な認可は、例えば、BGP経路フィルタをより安全に作るために使用できる。

⚠️ RPKIのRFCについて

RPKIに関連するRFC(仕様)は様々なカテゴリに分かれており、40件以上ある。ただし、RPKIは2012年に公開された本RFC 6480で最初に定義されたフレームワークであり、この文書からさまざまな関連するRFCが登場している。どこから手をつけていいかは難しいが、有用なRFCを効率よく見つけるウェブサイトがある(https://rpki-rfc.routingsecurity.net)。

https://manrs.org/2021/02/new-tool-helps-answer-which-rpki-related-rfcs-should-i-read/

また、RFC 8897では、RFC 6480をサポートするために、リライング・パーティーに課せられた要件が記載されたRFCを列挙している。

  • RFC 6481 (Repository Structure)
  • RFC 6482 (ROA format)
  • RFC 6486 (Manifests)
  • RFC 6487 (Certificate and CRL profile)
  • RFC 6488 (RPKI Signed Objects)
  • RFC 6489 (Key Rollover)
  • RFC 6810 (RPKI to Router Protocol)
  • RFC 6916 (Algorithm Agility)
  • RFC 7935 (Algorithms)
  • RFC 8209 (Router Certificates)
  • RFC 8210 (RPKI to Router Protocol, Version 1)
  • RFC 8360 (Certificate Validation Procedure)
  • RFC 8630 (Trust Anchor Locator)

rpki-clientのマニュアルでは次のRFCが挙げられている。

また、ARINが読むことを推奨しているRFCは次のとおり。

  • RFC 6480: An Infrastructure to Support Secure Internet Routing
  • RFC 6481: A Profile for Resource Certificate Repository Structure
  • RFC 6482: A Profile for Route Origin Authorizations (ROAs)
  • RFC 6483: Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)
  • RFC 6484: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)
  • RFC 6485: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)
  • RFC 6486: Manifests for the Resource Public Key Infrastructure (RPKI)
  • RFC 6487: A Profile for X.509 PKIX Resource Certificates
  • RFC 6488: Signed Object Template for the Resource Public Key Infrastructure (RPKI)
  • RFC 6489: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)
  • RFC 6490: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator
  • RFC 6491: Resource Public Key Infrastructure (RPKI) Objects Issued by IANA
  • RFC 6492: A Protocol for Provisioning Resource Certificates

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

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

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

著作権表示

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

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

1. はじめに

本文書は、インターネットのおけるBGPルーティング[RFC4271]のセキュリティ向上をサポートする基盤のアーキテクチャについて説明する。このアーキテクチャは、次の3つの主要素を含んでいる。

  • リソース公開鍵基盤 (RPKI)

  • ルーティング・セキュリティをサポートするための、デジタル署名済みルーティング・オブジェクト

  • PKIオブジェクトと署名済みルーティング・オブジェクトを保管する分散リポジトリ・システム

⚠️RPKIのアーキテクチャ

本文書で説明するアーキテクチャは、エンティティ(事業体)がIPアドレスまたは自律システム(AS)番号の正統な保有者であることを検証可能な形でアサートすることを可能にする。このアーキテクチャの最初の応用例として、本文書は、IPアドレス空間の正統な保有者が、そのアドレス空間への経路を発信する1つ以上のASを明示的かつ検証可能な形で認可する方法について説明する。このような検証可能な認可は、例えば、BGP経路フィルタをより安全に作るために使用できる。この最初の応用例に加えて、このアーキテクチャによって定義された基盤は、セキュアBGP[S-BGP]やセキュア・オリジンBGP[soBGP]などのセキュリティ・プロトコルを将来サポートすることも目的としている。このアーキテクチャは、IPv4とIPv6の両データグラムのルーティングに適用できる。現在、このアーキテクチャがサポートする唯一のアドレスファミリーはIPv4とIPv6のみである。したがって、例えば、このアーキテクチャをMPLSラベルで使用することは、本文書の範囲外である。

導入を容易にするため、このアーキテクチャは既存の技術と慣行を活用する。アーキテクチャのPKI要素の構造は、既存のリソース割り当て構造に対応している。したがって、このPKIの管理は、すでにIPアドレスとAS番号のリソース割り当てを担当している組織のリソース管理機能の自然な拡張である。同様に、既存のリソース割り当てと失効の慣行は、このアーキテクチャに明確に定義された対応関係がある。このアーキテクチャの最初の焦点はルーティング・セキュリティ・アプリケーションだが、本文書で説明するPKIは、IPアドレスまたはAS番号のリソースの保有証明を利用する他のアプリケーションをサポートするために使用できることに留意すること。

実装を容易にするために、可能な限り既存のIETF標準を使用する。例えば、公開鍵基盤 (X.509)(PKIX)[RFC5280]ワーキンググループによって定義されたX.509証明書プロファイルや、RFC 3779[RFC3779]で定義されたIPアドレスとAS番号表現の拡張が広範に使用されている。また、暗号メッセージ構文(CMS)[RFC5652]は、この基盤で必要とされる、新しく定義された署名済みオブジェクト[RFC6488]の構文として使用されている。

上で述べたように、このアーキテクチャは3つの主要コンポーネントで構成される。IPアドレス空間とAS番号の保有を証明する証明書が存在するX.509 PKI、基盤で使用される証明書以外の署名済みオブジェクト(経路発信の認可とマニフェストを含む)、そしてISPがルーティングを決定する際にこれらの署名済みオブジェクトのすべてを使用できるようにする分散リポジトリ・システムである。これら3つの基本コンポーネントは、いくつかのセキュリティ機能を可能にする。最も重要なのは、自律システムが特定のプレフィックスへの経路発信を認可されているかどうかを暗号的に検証することである[RFC6483]。

1.1. 用語

読者は、「インターネットX.509公開鍵基盤証明書および証明書失効リスト(CRL)プロファイル」[RFC5280]および「IPアドレスおよびAS識別子のX.509拡張」[RFC3779]に記載されている用語および概念に精通しているものとする。

本書では、「アドレス空間保有者」または「IPアドレス空間保有者」という用語を、標準的なIPアドレス割り当て階層を通じてアドレス空間を受け取った正統なIPアドレス空間保有者を指すために、同じ意味で使用する。つまり、アドレス空間保有者は、地域インターネット・レジストリ(RIR)またはIANAから直接割り当てを受けるか、国別インターネット・レジストリ(NIR)またはローカル・インターネット・レジストリ(LIR)から部分割り当てを受ける。IPアドレスまたはAS番号リソースの正当な保有者を指すために、 「リソース保有者」という用語を使用する。

本文書を通じて、「レジストリ」および「ISP」という用語は、部分割り当てが許可されるIPアドレス空間および/またはAS番号の割り当てを持つエンティティを指すために使用する。

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. インターネット番号リソースの公開鍵基盤

IPアドレス空間のブロックの保有者は、そのブロック内に宛先を持つIPデータグラムのトポロジー的な宛先を定義する権利が与えられるため、ドメイン間ルーティングに関する決定は、本質的にIPアドレス空間の割り当てに関する知識に基づいている。したがって、このアーキテクチャの基本的な機能は、これらの割り当てについて暗号的に検証可能な証明を提供することである。現行の慣行では、IPアドレスの割り当ては階層的である。その階層のルートはIANAである。IANAの下には5つの地域インターネット・レジストリ(RIR)があり、それぞれが定義された地政学的地域内のアドレスとAS番号の割り当てを管理している。地域によっては、第3階層に、国別インターネット・レジストリ(NIR)、ローカル・インターネット・レジストリ(LIR)、そしていわゆるプロバイダ非・依存(「ポータブル」)割り当ての加入者が含まれる。(「LIR」という用語は、他の地域がISPと定義しているものを指すために、一部の地域で使用されている。本文書の残りの部分では、これらのエンティティへの参照を簡略化するために、「LIR/ISP」という用語を使用する。) 他の地域では、第3階層は、LIR/ISP とプロバイダに依存しない割り当てを持つ加入者のみで構成される。

⚠️ 番号リソース割り当ての階層

一般に、IPアドレス空間のブロックの保有者は、レジストリによって確立された契約上の制約に従い、そのブロックの一部を自分自身(例えば、同じ組織の特定の部門)、または別の組織に部分割り当てすることができる。この構造のため、IPアドレスの割り当ては、各証明書がIPアドレスの割り当てを証明し、下位の証明書の発行がIPアドレスの部分割り当てに対応する、階層的な公開鍵基盤によって自然に記述することができる。上記の論拠は、AS番号リソースにも当てはまるが、慣例上、AS番号はRIRまたはNIRによって割り当てられる場合を除き、部分割り当てされないという違いがある。したがって、IPアドレスとAS番号の両方の割り当ては、同じPKIで表現できる。このようなPKIは、以後「リソース公開鍵基盤(RPKI)」と呼ばれ、このアーキテクチャの中心的なコンポーネントである。

2.1. アーキテクチャ全体における役割

このPKIの証明書はリソース証明書と呼ばれ、このような証明書の証明書プロファイル[RFC6487]に準拠する。リソース証明書は、(証明書の)発行者がIPアドレスまたはAS 番号をサブジェクト(対象者)に割り当てることを証明する。リソース証明書は、RFC 3779[RFC3779]で定義するとおり、証明書のIPアドレス委任またはAS識別子委任拡張に含まれるIPアドレスまたはAS番号に、リソース証明書に含まれる公開鍵を結び付けることでこれを行う。

⚠️ リソース証明書

証明書の構造

% openssl x509 -noout -text -in DmWk9f02tb1o6zySNAiXjJB6p58.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 776 (0x308)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = apnic-rpki-root-intermediate, serialNumber = 98142C9D0B41A3B9FB603D769848236FD1F31924
        Validity
            Not Before: Jan 18 05:15:55 2024 GMT
            Not After : Jul 18 15:15:54 2024 GMT
        Subject: CN = A90DC5BE, serialNumber = 0E65A4F5FD36B5BD68EB3C923408978C907AA79F
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:c3:d4:2c:dd:0b:45:1f:79:24:93:b7:d7:1e:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                0E:65:A4:F5:FD:36:B5:BD:68:EB:3C:92:34:08:97:8C:90:7A:A7:9F
            X509v3 Authority Key Identifier: 
                98:14:2C:9D:0B:41:A3:B9:FB:60:3D:76:98:48:23:6F:D1:F3:19:24
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:rsync://rpki.apnic.net/repository/980652E0B77E11E7A96A39521A4F4FB4/mBQsnQtBo7n7YD12mEgjb9HzGSQ.crl
            Authority Information Access: 
                CA Issuers - URI:rsync://rpki.apnic.net/repository/838DB214166511E2B3BC286172FD1FF2/mBQsnQtBo7n7YD12mEgjb9HzGSQ.cer
            X509v3 Certificate Policies: critical
                Policy: ipAddr-asNumber
                  CPS: https://www.apnic.net/RPKI/CPS.pdf
            Subject Information Access: 
                CA Repository - URI:rsync://rpki.apnic.net/repository/B527EF581D6611E2BB468F7C72FD1FF2/
                RPKI Manifest - URI:rsync://rpki.apnic.net/repository/B527EF581D6611E2BB468F7C72FD1FF2/DmWk9f02tb1o6zySNAiXjJB6p58.mft
                RPKI Notify - URI:https://rrdp.apnic.net/notification.xml
            sbgp-autonomousSysNum: critical
                Autonomous System Numbers:
                  173
                  ...
            sbgp-ipAddrBlock: critical
                IPv4:
                  1.0.0.0/8
                  ...
                IPv6:
                  2001:200::/23
                  ...

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        2f:c3:8c:4c:2c:94:ca:d1:9d:b1:92:a0:52:2a:de:7f:7f:5e:
        ...
        d2:57:f4:f8

このPKIの重要な特性は、証明書はサブジェクトの身元を証明しないことにある。したがって、証明書に使用されるサブジェクト名は、「記述的」(descriptive)であることを意図したものではない。リソースPKIは、認可(authorization)を提供することを目的としているが、認証(authentication)を提供することは目的ではない。これは、ほとんどのPKIでは、証明書内の記述的なサブジェクト名が、証明書内の公開鍵に対応する秘密鍵を保持するエンティティ(組織)に適切に関連付けられていることを、発行者が保証するのとは対照的である。発行者は、証明書内のサブジェクト名を使用するエンティティの権利を検証する必要がないため、そのような検証にかかるコストと責任を回避することができる。そのため、これらのエンティティは認証局(CA)という追加の役割を担うことが容易となる。

PKI内のほとんどの証明書は、基盤全体が運用されているという基本的な事実をアサートする。PKI内のCA証明書は、IPアドレス空間およびAS番号の保有を証明する。リソース保有CAが、その割り当て証明書によって証明される権限を委任する(delegate)ためにエンド・エンティティ(EE)証明書を発行する。EE証明書の主な用途は、経路発信認可 (ROA)の検証である。この署名済みオブジェクトは、特定のASが一連のアドレスへの経路を発信することが許可されているという、アドレス保有者による明示的な認可を提供する(セクション3を参照)。エンド・エンティティ証明書は、リポジトリ・システムの完全性を保証するために使用するマニフェストなど、他の署名済みオブジェクトの検証にも使われる(セクション5参照)。

2.2. CA証明書

リソースの部分割り当てを認可されたリソース保有者は、これらの部分割り当てに対応するリソース証明書を発行しなければならない。したがって、一例を挙げると、CA証明書は、IANAおよびRIR、NIR、LIR/ISPにそれぞれに関連付けられる。また、リソース保有者がROAを発行するには、各ROAの検証に使用される対応するエンド・エンティティ証明書を発行しなければならないため、CA証明書が必要となる。したがって、プロバイダに依存しない割り当てを持つマルチホーム加入者など、リソースを部分割り当てしないエンティティの中にも、ROAを発行できるようにするために、その割り当てに対するCA証明書が必要となるものがある。(マルチホームではなく、その割り当てがLIR/ISPに由来し、別のLIR/ISPに移動していない加入者は、PKIに申し立てる必要はない。さらに、セクション7.3.2で説明するように、LIR/ISPからの割り当てを持つマルチホーム加入者は、明示的に申し立てる必要がある場合もあれば、そうでない場合もある。)

ほとんどのPKIとは異なり、CA証明書のサブジェクトの識別名は、証明書発行者が選択する。サブジェクトの識別名は、記述的な方法でサブジェクトの身元を伝えようとしてはならない。サブジェクトの識別名にはCommonName属性を含めなければならず、さらにシリアル属性を含めることもできる。

このPKIでは、証明書発行者はRIR、NIR、またはLIR/ISPだが、サブジェクトが特定のIDをアサートする法的権利を検証する業務は行わない。したがって、記述的な方法でサブジェクトの身元を伝えない識別名を選択することで、サブジェクトが身元を主張するために証明書を悪用する機会を最小限に抑え、発行者の法的責任を最小限に抑えることができる。すべてのCA証明書は、発行者が既存の関係を有するサブジェクトに対して発行されるため、発行者は、証明書をサブジェクトに関連する既存のデータベース・レコードに容易に結び付けることができるサブジェクト名を選択することが推奨される。例えば、当局は、発行する証明書のサブジェクトのコモンネームとして、内部データベースの鍵または加入者IDを使用することができる。

証明書内のサブジェクトのコモンネームは、身元を伝えるものではないが、認証局が証明書を発行するすべてのサブジェクトの間で、コモンネームが一意でなければならないことに変わりない。すなわち、CAは、サブジェクトに同じコモンネームを使用する2つの異なるエンティティに証明書を発行してはならない。

⚠️ サブジェクトのコモンネーム
Subject: CN = A90DC5BE, serialNumber = 0E65A4F5FD36B5BD68EB3C923408978C907AA79F

各リソース証明書は、リソース保有者へのリソースの割り当てを証明するものであるため、複数のソースから割り当てを受けるエンティティは、複数のCA証明書を持つことになる。エンティティが異なる発行者から複数の証明書を受け取る場合、これらの証明書のサブジェクト名は一般に異なることに注意すること。CAおよびリソース保有者が、証明書の管理および使用を容易にするため、このような取り決めを行うことに同意した場合、CAは同じエンティティに対する各割り当てに対して、異なる証明書を発行することもできる。例えば、LIR/ISPは、1つのレジストリから複数の証明書を発行してもらうことがあるが、LIR/ISPは割り当てを別個として扱いため、それぞれ別個のアドレス・ブロックを記述する。

2.3. エンド・エンティティ(EE)証明書

EE証明書に含まれる公開鍵に対応する秘密鍵は、PKIにおける他の証明書の署名には使用されない。このPKIにおけるエンド・エンティティ証明書の主な機能は、証明書に記載されるリソースの使用に関連する署名済みオブジェクト(ROAやマニフェストなど)の検証である。

⚠️ 証明書チェーン(Chain of trust)

ROAとマニフェストでは、エンド・エンティティ証明書と署名済みオブジェクトとの間に1対1の対応関係が存在する。つまり、各エンド・エンティティ証明書に対応する秘密鍵は正確に1つのオブジェクトに署名するために使用され、各オブジェクトはただ1つの鍵で署名される。この特性により、PKIは新たな失効メカニズムを構築せずに、これらの署名済みオブジェクトを失効させることができる。オブジェクトへの署名に使用されたエンド・エンティティ証明書が失効すると、そのオブジェクトに対する署名(および対応するすべてのアサーション)は無効とみなされるため、署名済みオブジェクトは、そのオブジェクトへの署名に使用されたエンド・エンティティ証明書を失効させることにより、効果的に失効させることができる。

この1対1の対応による2次的利点は、証明書の公開鍵に対応する秘密鍵は、その存続期間中に1度だけしか使用されないため、1つのオブジェクトへの署名に使用された後は破棄できる。この事実は、秘密鍵を長期間保護する必要がないため、鍵管理が簡素化できるはずである。

署名済みオブジェクトを検証するために使用されるEE証明書は、署名済みオブジェクトの暗号メッセージ構文(CMS)ラッパー([RFC6488]を参照)に表示される。したがって、EE証明書を署名済みオブジェクトとは別に送信する必要はない。同様に、EE証明書は、対応する署名済みオブジェクトの一部としてでなければ、RPKIリポジトリ・システムに表示する必要はない。

本文書では、エンド・エンティティ証明書の2つの用途についてのみ説明するが、将来的にはさらなる用途が定義される可能性が高い。例えば、エンド・エンティティ証明書は、そのサブジェクトが指定されたリソース保有者の代わりに行動するための、より一般的な認可として使用できる。これにより、ISP間の相互作用の認証、リポジトリ・システムとの相互作用の認証が容易になる。エンド・エンティティ証明書のこれらの追加用途は、対応する秘密鍵の保持を必要とする場合がある。ただし、ROAとマニフェストの署名に使われる鍵に、そのような保持は要求されない。

2.4. トラストアンカー

どのようなPKIでも、各リライング・パーティー(RP)は独自のトラストアンカー(TA)を選択する。PKIのこの一般的な特性は、ここにも当てはまる。IPアドレス空間とAS番号の割り当て階層が存在するので、IANAおよび/または5つのRIRは、デフォルトのTAになる明らかな候補である。とはいえ、各RPは最終的に、証明書の検証に使用するトラストアンカーを選択する。

⚠️ トラストアンカー

アドレス割り当ての構造上はIANAがトップだが、実際には各RIRが自己証明書を作成している。

例えば、RP(LIR/ISPなど)は、すべてのアドレス空間および/またはすべてのAS番号が割り当てられ、RPが対応する秘密鍵を知るトラストアンカーを作成することができる。その後、RPは、このトラストアンカーに基づき、希望するPKI内の任意のエンティティに証明書を発行することができる。その結果、ローカルにインストールされたこのトラストアンカーを終端とする証明書パスは、RFC 3779で規定される検証要件を満たすことになる。プライベートIPアドレス空間(すなわち、RFC 1918)を使用し、内部でBGPを実行する大規模ISPは、すべてのプライベート・アドレス空間が割り当てられているCAを収容するために、この種のトラストアンカーを作成する必要がある。その後、RPは、このCAの下で、RPが内部で使用するプライベート・アドレス空間に対応する証明書を発行できる。

独自のトラストアンカーを作成・管理することを選択したRPは、そのような状況下で発生する割り当てエラーを検出できない可能性はあるが、結果として生じる脆弱性はRPにとって局所的なものであることに留意すること。既存のIPアドレス空間とAS番号の割り当て階層内の一部のパーティーは、リライング・パーティーが使用する可能性を考慮して、トラストアンカー情報の公開を希望することが予想される。この公開鍵基盤のトラストアンカー情報を公開するための標準プロファイルは、[RFC6490]に含まれている。

3. 経路発信認可 (Route Origination Authorizations)

PKIが提供するIPアドレス割り当てに関する情報は、それ自体ではルーティングの決定を導くのに十分ではない。特に、BGPは、特定のプレフィックスに対する経路を発信するASが、そのプレフィックス(またはプレフィックスを含むアドレス・ブロック)の保有者から経路を発信することを認可されているという前提に基づいている。PKIは、これらの認可に関する情報を含まない。経路発信認可(ROA)は、このような認可を明確化することで、IPアドレス空間の保有者が、プレフィックス・セットへの経路発信をASが認可されていることを明示的かつ検証可能な形でアサートするオブジェクトを作成できるようにする。

⚠️ROA

3.1. アーキテクチャ全体における役割

ROAは、プレフィックス・セットの保有者が、そのプレフィックスの経路発信を自律システムに認可したことを証明するものである。ROAは、[RFC6482]に記載されている形式に従って構成される。この認可の有効性は、ROAの署名者がROA内のプレフィックスの保有者であるかどうかに依存する。この事実は、PKIのエンド・エンティティ証明書によって保証され、対応する秘密鍵がROAの署名に使用される。

ROAは、特定のIPアドレス・プレフィックスの経路を発信するASが、そのプレフィックスの保有者からそのような経路を発信することを認可されていることを検証するために、リライング・パーティーによって使用されることがある。例えば、ISPは検証済みROAを、BGPルータが使用する経路フィルタ作成への入力として使用することがある。(BGP経路の発信元を検証するためのROAの使用については、[RFC6483]を参照のこと。)

当初、リポジトリはROAを検証するために必要な証明書とCRLを保持するため、リポジトリシステムがROAを配布する主要なメカニズムとなる。さらに、ROAもまた、適時性要件(timeliness requirements)を満たすために必要であれば、BGP UPDATEメッセージや他の通信パス経由で配布することもできる。

3.2. 構文とセマンティクス

ROAは、単一ASが1つ以上のプレフィックスへの経路を発信するための明示的な認可を構成し、そのプレフィックスの保有者が署名を行う。概念的には、ROAの構文は、すべてのRPKI署名オブジェクトに共通する一般的なCMSテンプレート[RFC6488]と、認可を表現するROA固有のカプセル化されたコンテンツ[RFC6482]の2つの部分から構成される。

ざっくり言うと、ROAの内容には (1) AS番号、(2) IPアドレスのプレフィックス・リスト、(3) オプションで、各プレフィックスについて、ASが広告することを認可されている、More Specificな(より長い)プレフィックスの最大長を含む。(この最後の要素は、例えば、指定された長さ20のプレフィックス内に含まれる長さ20～24ビットのプレフィックスを広告するための、簡潔な認可を容易にする。)

ROAにはAS番号が1つしか含まれないことに留意すること。したがって、ISPがROA内のプレフィックスへの経路を発信することを認可されるAS番号を複数持つ場合、アドレス空間保有者は、ISPがこれらのASのいずれかから経路を発信することを認可するため、複数のROAを発行する必要がある。

ROAは、PKIのエンド・エンティティ(EE)証明書の公開鍵に対応する秘密鍵を使用して署名される。ROAが有効であるためには、対応するエンド・エンティティ証明書が有効でなければならず、ROAのIPアドレス・プレフィックスがEE証明書のRFC 3779拡張で指定されるIPアドレス・プレフィックスと正確に一致しなければならない。したがって、ROAの有効期間は、対応する証明書の有効期間と暗黙的に一致する。ROAは、対応するEE証明書を失効させることで失効する。ROAを失効させる独立した方法はない。この失効モデルにより、EE証明書に署名しているCA証明書のCRLが長くなることを心配する人がいるかもしれない。しかし、パブリック・インターネット上のルーティング・アナウンスは、一般的に非常に長期間存続する。したがって、ROAの検証に使用されるEE証明書に数か月の有効期間が与える限り、その期間内に多くのROAを失効する必要が生じる可能性は極めて低い。

fig1
図1: この図は、2つのソース(RIRとNIR)からの割り当てを持つISPを示している。RFC 3779で定義されているルールにより、2つのCA証明書が必要となる。

各ROAは1つのエンド・エンティティ証明書に関連付けられるため、ROAに含まれるIPプレフィックス・セットは、単一のソースによる割り当てから取り出さなければならない。つまり、ROAは複数のソースの割り当てを組み合わせることはできない。複数のソースの割り当てを持つアドレス空間保有者で、これらの割り当ての経路を発信させることをASに認可したい者は、そのASへの複数のROAを発行しなければならない。

4. リポジトリ

最初に、LIR/ISPはすべてのROAを取得して検証することで、リソースPKIを利用し、各ASが経路の発信を認可されているプレフィックスのテーブルを作成する。すべてのROAを検証するには、LIR/ISPはすべての証明書とCRLを取得する必要がある。ここで説明する分散リポジトリ・システムの主な機能は、これらの署名済みオブジェクトを保存し、LIR/ISPがダウンロードできるようにすることである。このリポジトリ・システムは、リライング・パーティーが適切と考える頻度で新しいデータを取得できるメカニズムを提供することに留意する。ただし、新しいデータをリライング・パーティーにプッシュするメカニズム(例えば、BGPまたは他のプロトコル・メッセージにリソースPKIオブジェクトを含めるなど)は規定しておらず、そのようなメカニズムは本文書の範囲外である。

リポジトリ内のすべてのオブジェクトのデジタル署名は、有効なオブジェクトの不正な変更がリライング・パーティーによって検出可能なことを保証する。さらに、リポジトリ・システムはマニフェスト(セクション5を参照)を使用して、リライング・パーティーが有効なオブジェクトの削除と、期限切れの有効な署名済みオブジェクトの挿入を検出できるようにしている。

リポジトリ・システムは、そこに格納された署名済みオブジェクトのアクセス制御の実施するポイントでもあり、例えば、リソースの割り当てに関連するレコードが、認可された当事者によってのみ操作できることを保証する。アクセス制御の使用は、リポジトリ・オブジェクトの削除や改ざんに基づくサービス拒否攻撃を防止できる。 実際、リライング・パーティーはリポジトリ内のオブジェクトの改ざんを検出できるが、リポジトリ・システムがそのような不正な変更を可能な限り防止することが望ましい。

⚠️リポジトリ・システム

4.1. アーキテクチャ全体における役割

リポジトリ・システムは、リライング・パーティーがグローバルにアクセス可能でなければならない、すべての署名済みオブジェクトのための信頼できないクリアリングハウス(情報センター)である。証明書とCRLが作成されると、それらはこのリポジトリにアップロードされ、リライング・パーティー(主にLIR/ISP)が使用するためにダウンロードされる。ROAとマニフェストは、そのようなオブジェクトの追加例だが、将来的には他のタイプの署名済みオブジェクトがこのアーキテクチャに追加されるかもしれない。本文書では、署名済みオブジェクト(証明書、CRL、ROA、マニフェスト)がリポジトリ・システムで管理される方法を簡単に説明する。他のタイプの署名済みオブジェクトがリポジトリ・システムに追加された場合、記述を変更する必要はあるが、設計原則のほとんどはそのまま適用されるだろう。リポジトリ・システムの詳細は[RFC6481]に記載されている。

4.2. 内容と構造

リライング・パーティーがアクセスするリポジトリ・システムは1つだが、複数のデータベースで構成される。これらのデータベースは、レジストリ(RIR、NIR、LIR/ISP)間に分散されている。少なくとも、各レジストリによって運営されるデータベースには、そのレジストリに関連するCAによって署名されたすべててのCA証明書、EE証明書、CRL、およびマニフェストが格納される。LIR/ISPが運営するリポジトリにもROAが含まれる。レジストリは、リライング・パーティーによるリポジトリ内容全体の検索を容易にするため、その顧客およびその顧客の顧客(など)のリポジトリ・データのコピーを保持することが推奨される。理想的には、各RIRはその地政学的範囲内のすべてのエンティティのPKIデータを保持する。

PKI内のすべての証明書について、この証明書を介して検証可能なすべてのオブジェクト(証明書、CRL、ROA、マニフェスト)の信頼できる公開ポイントとなる対応するファイル・システム・ディレクトリがリポジトリ内に存在する。証明書のSubject Information Access (SIA)拡張[RFC5280]には、このディレクトリを参照するURIが含まれる。さらに、証明書のAuthority Information Access (AIA)拡張[RFC5280]には、特定の証明書が発行されたCA証明書の信頼できる場所を参照するURIが含まれている。つまり、証明書Aが証明書Bの検証に使用される場合、証明書BのAIA拡張は証明書Aを指し、証明書AのSIA拡張は証明書Bを含むディレクトリを指す(図2を参照)。

fig2
図2: RPKIにおけるSIAおよびAIA拡張の使用

図2では、CA Aを証明書BとCが発行している。したがって、証明書BとCのAIA拡張は(証明書)Aを指し、証明書AのSIA拡張はCA Aの下位のリポジトリ公開ポイントを指す。これには、証明書BとC、およびAが発行したCRLが含まれる。証明書BとCのCRL配布ポイント(CRLDP)拡張は、いずれもAが発行したCRLを指す。

CA証明書が同じ公開鍵で再発行される場合、再発行される証明書によって署名されたすべての証明書を(更新されたAIA URIで)再発行する必要はない。したがって、認証局は、発行された証明書について、永続化URI命名スキームを使用する必要がある(SHOULD)。つまり、再発行された証明書は、同じサブジェクトと公開鍵を持つ前に発行された証明書と同じ発行ポイントを使用し、そのような証明書を上書きする必要がある。

4.3. アクセス・プロトコル

リポジトリの運営者は、リライング・パーティーがリポジトリ・システムにアクセスするために使用できる1つ以上のアクセス・プロトコルを選択する。これらのプロトコルは、基盤の多数の参加者(例えば、すべてのレジストリ、ISP、マルチホーム加入者など)がそれぞれの部分を維持するために使用する。これらの活動をサポートするために、以下で述べるように、アクセス・プロトコルにいくつかの基本的な機能が要求される。単一のアクセス・プロトコルがこれらすべての機能を実装する必要はないが(そうなるかもしれないが)、各機能はリポジトリ・オペレータが展開する少なくとも1つのアクセス・プロトコルを実装しなければならない(MUST)。

ダウンロード: アクセス・プロトコルは、リポジトリ・コンテンツの一括ダウンロードと、その後のダウンロードされたコンテンツへの差分ダウンロードをサポートしなければならない。これは、リライング・パーティーがリポジトリ・システムとやり取りする最も一般的な方法になる。他の種類のダウンロードのやり取り(例えば、単一オブジェクトのダウンロードなど)もサポートされるかもしれない。

アップロード/変更/削除: アクセス・プロトコルは、証明書、CRL、その他の署名済みオブジェクトの発行者が、それらをリポジトリに追加したり削除したりするメカニズムもサポートしなければならない。リポジトリ内のオブジェクトを変更するメカニズムも提供されるかもしれない。リポジトリへの変更(内容の追加、削除、修正)を許可するすべてのアクセス・プロトコルは、適切なアクセス制御を適用できるように、変更を実行するエンティティの認可検証をサポートしなければならない(セクション4.4参照)。

すべてのリライング・パーティーがすべてのRPKI署名オブジェクトを確実に取得できるようにするため、すべての公開ポイントはrsync([RFC5781]および[RSYNC]を参照)経由でアクセスできなければならない(MUST)。ただし、他のダウンロード・プロトコルをサポートしてもよい(MAY)。リポジトリ公開ポイントは、サポートされるプロトコルが、ある公開ポイントでデータを公開しているすべての認証局に明確に通知されていることを条件として、自らが望む(一連の)アクセス・プロトコルを通じて更新/変更/削除機能を提供することができる。

4.4. アクセス制御

リポジトリ内の情報の完全性を維持するためには、権限のない当事者によるリポジトリ内のオブジェクトの追加、削除、変更を防止するための制御を導入しなければならない。そのような変更を行おうとする当事者の身元は、関連するアクセス・プロトコルによって認証できる。具体的なアクセス制御ポリシーはリポジトリ・オペレータのローカル制御に従うが、リポジトリは署名済みオブジェクトの発行者のみにポリシーを追加、削除、変更できるようにすることが推奨される(RECOMMENDED)。あるいは、セクション2.3で提案しているように、リソース保有者が他の当事者に代理行為を許可するための正式な委任メカニズムを定義することが、将来的に有益かもしれない。

5. マニフェスト

マニフェストとは、リポジトリ・システム内のパブリケーションに責任を持つオーソリティによって発行された、(マニフェスト自身を除く)すべての署名済みオブジェクトのリストである。オーソリティによって発行された有効期限が切れていない証明書、CRL、またはROAそれぞれについて、マニフェストにはオブジェクトを含むファイル名とファイルの内容のハッシュの両方が含まれる。

⚠️リポジトリの構造

ROAと同様、マニフェストは秘密鍵によって署名され、対応する公開鍵がエンド・エンティティ証明書に記載される。このEE証明書は、対象のCAによって署名される。EE証明書の秘密鍵は1つのマニフェストへの署名にのみ使用されるため、EE証明書を失効することで、マニフェストを失効させることができる。このような場合、不必要なCRLの増加を避けるために、マニフェストの検証に使用されるEE証明書は、マニフェストの有効期限と同時に失効する必要がある(SHOULD)。

マニフェストは、リポジトリからファイルを削除したり、現在の署名済みオブジェクトを同じオブジェクトの古いバージョンに置き換えたりする攻撃者のリスクを軽減するために、ローカルキャッシュ(セクション6を参照)を構築する際に、リライング・パーティーが使用することができる。このような保護が必要なのは、リポジトリ・システム内のすべてのオブジェクトは署名されているが、リポジトリ・システム自体は信頼できないからである。

5.1. 構文とセマンティクス

マニフェストは、特定の時点におけるリポジトリ・ポイントのすべてのファイル(のハッシュ)のリストから成る。マニフェストの内容の詳細な仕様は[RFC6486]で規定されているが、大まかに言うと、マニフェストは(1) マニフェスト番号、(2) マニフェストが発行された時刻、(3) 次の更新予定時刻、(4) ファイル名とハッシュ値のペアのリストから構成される。

⚠️ マニフェスト
    # rpki-client -f is2rHh6mM7qK0Yoqy3I2DpKAxLY.mft 
    File:                     is2rHh6mM7qK0Yoqy3I2DpKAxLY.mft
    Hash identifier:          0EBiA4yH8ZpgWAzYo+kJabJ6Av/5rEyJ9yXZSn25fg4=
    Subject key identifier:   40:A4:5A:97:3E:2E:07:1A:BE:34:97:6B:57:2C:37:B6:A4:43:09:BE
    Authority key identifier: 8A:CD:AB:1E:1E:A6:33:BA:8A:D1:8A:2A:CB:72:36:0E:92:80:C4:B6
    Certificate issuer:       /CN=8ACDAB1E1EA633BA8AD18A2ACB72360E9280C4B6
    Certificate serial:       3C
    Authority info access:    rsync://rpki-repository.nic.ad.jp/ap/A91A73810000/is2rHh6mM7qK0Yoqy3I2DpKAxLY.cer
    Subject info access:      rsync://rpki-repository.nic.ad.jp/ap/A91A73810000/1003/is2rHh6mM7qK0Yoqy3I2DpKAxLY.mft
(1) Manifest number:          0106
(2) Signing time:             Mon 01 Jan 2024 01:30:20 +0000
    Manifest this update:     Mon 01 Jan 2024 01:30:20 +0000
(3) Manifest next update:     Thu 11 Jan 2024 01:30:20 +0000
(4) Files and hashes:         1: LqM5S1L3MvQEksB1Eh-fRZuvjh4.roa (hash: uBnDyJDBDF8I3MpaF+55rjXm7yWds5qh5LP7K5JusoA=)
                              2: dBEbtLs9cYmsMc6IzPy8PJR5nPg.roa (hash: lA0wLC0jTcTcH6nMT/ijVvKTWt4LHiYTaB35dXj1Fdg=)
                              3: is2rHh6mM7qK0Yoqy3I2DpKAxLY.crl (hash: 5zopkBa+qq5S023a87BeeGTFLfWuFS9U5j89gaslR1w=)
    Validation:               OK

マニフェスト番号は、オーソリティによってマニフェストが発行されるたびにインクリメントされるシーケンス番号である。リポジトリ内の項目を変更したとき、または指定された次の更新時刻に達したとき、オーソリティは常に新しいマニフェストを発行することが要求される(REQUIRED)。したがって、マニフェストは指定された次回変更時刻まで、またはより大きなマニフェスト番号を持つマニフェストが発行されるまでのいずれか早い時点まで有効である。(EE証明書が1つのマニフェストへの署名にのみ使用される場合、オーソリティが新しいマニフェストを発行するときはいつでも、CAは古いマニフェストに対応するEE証明書を含む新しいCRLも発行しなければならない(MUST)ことに留意する。古いマニフェストに対する失効したEE証明書は、 その有効期限が切れるとCRLから削除されるため、この手順によってCRLが大幅に増大することはない。)

6. ローカル・キャッシュのメンテナンス

このPKIに基づいて発行された署名済みオブジェクトを利用するには、リライング・パーティーはまず、PKIの有効なEE証明書のローカルコピーを取得しなければならない。そのために、リライング・パーティーは次の手順を実行する。

  1. リポジトリ・システムに照会し、PKIに基づいて発行されたすべての証明書、マニフェスト、CRLのコピーを取得する。

  2. PKI内の各CA証明書について、対応するマニフェストの署名を検証する。さらに、現在の時刻がマニフェストのnextUpdateフィールドに示された時刻よりも前であることを検証する。

  3. 各マニフェストについて、対応するCA証明書に基づいて発行された証明書とCRLが、マニフェストに含まれるハッシュ値と一致することを検証する。さらに、マニフェストに記載されている証明書またはマニフェストがリポジトリから欠落していないことを確認する。ハッシュ値が一致しない場合、または証明書またはCRLが欠落している場合は、リポジトリ・データが破損していることを適切なリポジトリ管理者に通知する。

  4. 各EE証明書は、ローカルに構成されたTA一式に対する証明書の証明書パス(関連するCRLの確認を含む)を構築・検証することによって確認する。(詳細については、[RFC6487]を参照。)

リライング・パーティーはこれらの操作を定期的に行うため、リライング・パーティーが最後にローカル・キャッシュを更新してから変更されたオブジェクトのみをリポジトリ・システムに要求する方が効率的であることに留意すること。

また、発行されたすべてのオブジェクトを適切なマニフェストと照合することで、リライング・パーティーはオブジェクトの更新バージョンも見逃していないことを確認できることにも留意すること。

7. 共通オペレーション

上記の基盤の構築と維持には、通常のリソース割り当てとルーティング認可手順の「副次的効果」(side effects)として、追加の操作が必要になる。例えば、プロバイダに依存しない(「ポータブル」)アドレス空間を持つ加入者がISPと関係を結ぶ場合、他の必要な技術的またはビジネス的手続きの処理に加えて、そのISPを識別する1つ以上のROAを発行する必要がある。基盤の現在の主な用途は、経路フィルタ作成である。ROAを使用することで、広告されたプレフィックスの保有者がオリジンASに広告された経路の発信を認可していることを高く保証しながら、自動化された方法で経路フィルタを作成することができる。

7.1. 証明書の発行

証明書の発行を必要とする運用シナリオはいくつかある。部分割り当てが行われる可能性がある割り当てには、CA証明書が必要となる。例えば、部分割り当てに必要に応じて証明書を発行できるようにするなどである。プロバイダに依存しないIPアドレス空間割り当ての保有者も、割り当ての経路を発信する権限を持つ各ISPにROAを発行できるように、証明書を持たなければならない(その割り当てはどのISPからも提供されないため)。さらに、マルチホーム加入者は、割り当てのROAを発行するつもりであれば、割り当ての証明書を必要とする(セクション7.3.2を参照)。他のリソース保有者は、PKI内でCA証明書を発行してもらう必要はない。

長期的には、リソース保有者はリソース証明書を要求するのではなく、リソースの割り当てプロセスの副次的効果として証明書を受け取ることになる。ただし、RPKIの初期展開では、明示的なイベントとして、既存のリソース保有者への証明書を発行する。すべての場合において、CA証明書を発行する機関は、サブジェクトにリソースを割り当てるエンティティであることに留意する。これは、サブジェクトが任意の認証機関に証明書を要求できる多くのPKIとは異なる。

リソース保有者が複数の割り当てを長期的に受ける場合、それらを証明するリソース証明書のコレクションを獲得することができる。リソース保有者が同じ発行元から複数の割り当てを受けた場合、発行者とリソース保有者の双方が同意すれば、リソース証明書セットを1つのリソース証明書にまとめることができる。これは、IPアドレス委任拡張とAS識別子委任拡張を新しい証明書の1つの拡張(各タイプ)に統合することで実現される。ただし、これらの証明書が異なる有効期間の割り当てを証明したい場合、統合した証明書を作成すると、一つの有効期間しか表現できないため、問題が生じる可能性がある。

リソース保有者の割り当てが異なる発行者から提供されたものである場合、それらは異なるCAによって署名され、結合することはできない。リソース・セットがリソース保有者に割り当てられなくなった場合、割り当てを証明する証明書はすべて失効しなければならない。鍵ペアの再利用はパス構築を複雑にするため、リソース保有者は、同一または異なる認証局が発行する複数のCA証明書において、同じ公開鍵を使用する必要がない(SHOULD NOT)。サブジェクトの識別名は発行者が選択するため、通常、2つの発行元から割り当てを受けたサブジェクトは、一般に異なるサブジェクト名の証明書を受け取ることに留意する。

7.2. CA鍵のロールオーバー

認証局がRPKI CA証明書に関連付けられた公開鍵 (および対応する秘密鍵)を変更したい場合は常に、鍵ロールオーバー手順を行わなければならない(MUST)。鍵ロールオーバーは通常、定期的に行われる。鍵ロールオーバーの頻度は、指定のCAの認証業務運用規定に規定される。さらに、鍵のセキュリティ侵害が疑われる場合、予定外のロールオーバーが必要になることがある。

ロールオーバーが要求されるのは、CAの鍵が実際に変更された場合のみであり、新しいCA証明書がこのCAの前の証明書と同じ鍵で発行される場合には必要ないことに留意する。例えば、CAがリソースを取得または破棄した場合、あるいはリソース割り当ての有効期間が延長された場合は、新しいCA証明書を発行しなければならない。ただし、そのような場合、新しい証明書は通常、前の証明書と同じ公開鍵(および秘密鍵)を使用する。したがって、鍵ロールオーバーは必要ない。

文書[RFC6489]は、認証局がRPKIのCA証明書に関連付けられた公開鍵(および秘密鍵)を変更する際に使用する必要がある慎重な鍵ロールオーバー手順を規定している。大まかに言うと、ロールオーバー手順の重要な特性は以下の2点である。まず、RPKI署名付きオブジェクトのデータはルーティング操作で使用される可能性があるため、ロールオーバー手順のどの時点においても、この手順により、リライング・パーティが署名済みオブジェクトの有効性について誤った結論に達することはないこと。特に、CAには、リライング・パーティがEE 証明書からリライング・パーティのトラストアンカー(の1つ)までの証明書パスの構築に特定のアルゴリズムを使用するとは想定できない。したがって、鍵ロールオーバー手順は、RPKI階層内のSIAポイントとAIA ポイントの完全性を可能な限り最大限に保持するように設計されている。次に、鍵ロールオーバー手順は、RPKI階層内のCA以下のすべての証明書の再発行が不要になるように設計されていることに留意すること。もちろん、鍵が変更されるCAの直下で発行されたすべての証明書に再署名する必要がある。ただし、証明書内のSIAおよびAIAポインタには、それ以上の再発行は不要になるよう値が設定される。

7.3. ROAの管理

IPアドレス空間の保有者が、保有するプレフィックスの経路発信をASに認可したい場合は常に、IPアドレス委任拡張にそのプレフィックスを含むエンド・エンティティ証明書を発行しなければならない(MUST)。その後、対応する秘密鍵を使用して、指定されたプレフィックスとASのAS番号を含むROAに署名する。リソース保有者は、必要に応じて、EE証明書と対応するROAに複数のプレフィックスを含めてもよい(MAY)。したがって、前提条件として、あるプレフィックスのROAを発行するアドレス空間の保有者は、そのプレフィックスを含む割り当てのリソース証明書を持たなければならない。ROAを発行する標準的な手順は以下のとおりである。

⚠️ ROAの管理について

RFC 9455では、複数のプレフィックスを含むROAには運用上の問題があることを指摘している。

  1. ROAで認可されるプレフィックスを含むエンド・エンティティ証明書を作成する。

  2. エンド・エンティティ証明書内のプレフィックスと認可される AS番号を含む、ROAのペイロードを作成する。

  3. エンド・エンティティ証明書に対応する秘密鍵を使用して ROAに署名する(ROAは、CMS署名メッセージ [RFC5652]にカプセル化されたペイロードで構成される)。

  4. エンド・エンティティ証明書とROAをリポジトリ・システムにアップロードする。

ROAを失効させる標準的な手順は、適切なCRLを作成し、それをリポジトリ・システムにアップロードすることで、対応するエンド・エンティティ証明書を失効させることができる。失効したROAとエンド・エンティティ証明書はリポジトリ・システムから削除する必要がある(SHOULD)。

⚠️ 実際のCRL
# rpki-client -f is2rHh6mM7qK0Yoqy3I2DpKAxLY.crl
File:                     is2rHh6mM7qK0Yoqy3I2DpKAxLY.crl
Hash identifier:          5zopkBa+qq5S023a87BeeGTFLfWuFS9U5j89gaslR1w=
Authority key identifier: 8A:CD:AB:1E:1E:A6:33:BA:8A:D1:8A:2A:CB:72:36:0E:92:80:C4:B6
CRL issuer:               /CN=8ACDAB1E1EA633BA8AD18A2ACB72360E9280C4B6
CRL serial number:        0106
CRL last update:          Mon 01 Jan 2024 01:30:20 +0000
CRL next update:          Thu 11 Jan 2024 01:30:20 +0000
Revoked Certificates:
                          Serial:       30   Revocation Date: Mon 01 Jan 2024 01:30:20 +0000
Validation:               OK

ROAを失効する場合、ROAに含まれるプレフィックスとオリジンAS番号に対応するルーティング広告を、リライング・パーティーが不正なものとして扱う可能性がある (さらに、それらの広告に基づいてパケットを転送しなくなるように、ルーティング動作を変更する可能性すらある)という点で留意が必要である。特に、リソース保有者は、以下のように「メイク・ビフォア・ブレーク」の原則を守る必要がある。リソース保有者がインターネット上でルーティング可能したいプレフィックスに対応するROAを失効する前に、リソース保有者は同じプレフィックス (異なるAS番号を示す可能性もある)をリストする別の有効な代替ROAが存在することを確認することが非常に重要である。さらに、リソース保有者は、有効な代替ROAで示されるASが、問題のプレフィックスへのルーティング広告を実際に発信していることを確認する必要がある。さらに、リライング・パーティーは、ROA失効に対応するルーティング・アクションを取る前に、リポジトリ・システムから新しいROAを取得しなければならない。

7.3.1. シングルホーム加入者

BGPでは、プロバイダ集約可能(PA)アドレス空間を持つシングルホーム加入者は、 ISPがすでに内部機能として、普通のプレフィックスを広告し、加入者のプレフィックスのトラフィックをルーティングしているため、使用しているプレフィックスに対して発信する経路を明示的に認可する必要はない。このような加入者が保持するプレフィックスに特化した経路は生成されることがないため、その割り当てに基づいてROAを発行する必要はない。むしろ、加入者のISPは、自身の割り当てからのリソース証明書に基づいて、より一般的なプレフィックスに対して必要なROAを発行する。したがって、サービス・プロバイダからIPアドレスが割り当てを受けたシングル・ホーム加入者は、RPKIに含まれない。つまり、CA証明書を受け取らず、EE証明書もROAも発行しない。

⚠️ シングルホームについて

シングルホームはBGPを利用しないケースがほとんど。多くが、PAアドレスのROAを上位で定義している。自分でROAを持つことはない。

7.3.2. マルチホーム加入者

ここでは、プライマリISPからプロバイダ集約可能(PA)IPアドレス空間を受け取り(つまり、加入者が使用するIPアドレスは、ISP AのIPアドレス空間割り当ての一部である)、プライマリISPに加えて、1つ以上のセカンダリISPから冗長アップストリーム接続を受け取る加入者を考える。このようなマルチホームの加入者にとって好ましいオプションは、加入者がAS番号を取得し、各アップストリーム・プロバイダでBGPを実行することである。このような場合、ROA管理には2つの推奨される方法がある。1つ目は、プライマリISPが加入者にCA証明書を発行し、加入者が加入者のAS番号と加入者のIPアドレス・プレフィックスを含むROAを発行する。2番目の可能性は、プライマリISPが加入者にCA証明書を発行せず、代わりに加入者のAS番号と加入者のIPアドレス・プレフィックスを含むROAを加入者に代わって発行することである。

⚠️ 要するに

①加入者自身がROAを発行する。②ISPが加入者の代理でROAを発行する。

マルチホーム加入者が、AS番号を取得してBGPを実行できないか、または望んでいない場合、別の選択肢として、加入者は、主ISPに対して、各セカンダリISP向けのROAを作成するように要求する可能性がある。これにより、セカンダリISPはその加入者のプレフィックスの経路を発信する権限を得ることができる。主要なISPはおそらくその場合、加入者のプレフィックスを正確に広告する一方で、包括的な集約経路を広告したくないと考えるため、自分自身のAS番号と加入者のプレフィックスを含むROAも作成するだろう。このアプローチは、加入者のプレフィックスのオリジンAS番号が、パブリック・インターネットで望ましくないとされる一貫性のないものとなってしまうことに留意する。したがって、このアプローチは推奨されない(NOT RECOMMENDED)。

7.3.3. プロバイダ非・依存(Provider-Independent)アドレス空間

リソース保有者がRIRまたはNIRから直接割り当てを受けた場合、そのリソース保有者はプロバイダ非・依存(ポータブル)アドレス空間を持つという。このような割り当てで表されるプレフィックスは、ISPが保持する割り当て(プール)から取得したものではないため、より一般的なプレフィックス(more general prefix)を保持して広告するISPは存在しない。ポータブルIPアドレス空間割り当ての保有者は、1つ以上のASがこれらのプレフィックスへの経路を発信することを認可しなければならない(MUST)。したがって、リソース保有者は、ASが問題のプレフィックスの経路を発信できるように、1つ以上のEE証明書と関連するROAを生成しなければならない(MUST)。ISPの既存のROAのいずれも、加入者のプロバイダに依存しない割り当てへの経路を発信することをISPに許可していないため、この ROAが必要である。

⚠️ PIアドレスについて

JPNICでは、プロバイダ非・依存のプレフィックスは「歴史的PIアドレス」として個別に管理されている(https://www.nic.ad.jp/ja/ip/hr/)。

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

この文書の焦点はセキュリティである。したがって、セキュリティに関する考慮事項はこの仕様に浸透している。

このアーキテクチャによって提供され、実現されるセキュリティ・メカニズムは、このアーキテクチャが記述する基盤の完全性と可用性に依存する。基盤内のオブジェクトの完全性は、セクション4.4で説明するように、リポジトリ・システム上の適切な制御によって確保される。同様に、リポジトリ・システムは分散データベースとして構造化されているため、本質的にサービス妨害攻撃に対して耐性がなくてはならない。それにも関わらず、構成データベースの複製とバックアップ、データベース・サーバの物理的セキュリティの両面から、適切な予防措置を講じる必要がある。

9. IANA に関する考慮事項

RPKIへのIANA関与に関する指示は、[RFC6491]で規定されている。

10. 謝辞

この文書に記載されているアーキテクチャは、多くの個人のグループの集合的なアイデアと作業から生まれたものである。この作業は、APNICのジョージ・ミケルソン、ロバート・ルーマンス、サンジャヤ、ジェフ・ヒューストン、RIPE NCCのロバート・キステレキとヘンク・ウイツェルワール、ARINのティム・クリステンセンとキャシー・マーフィー、ISCのロブ・オースティン、そしてIIJのランディ・ブッシュの知的貢献なしには成し得なかっただろう。

私たちはこのアーキテクチャに貢献してくれたすべての人に感謝しているが、特にマニフェストのコンセプトを提供してくれたロブ・オースティン、使い捨てのEE証明書の鍵ペアを通じてオブジェクトの正当性を管理するというコンセプトを提供してくれたジェフ・ヒューストン、そしてこの文書の初期バージョンの作成に協力してくれたリチャード・バーンズに感謝したい。

11. 参考文献

11.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6486] Austein, R., Huston., G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure", RFC 6486, February 2012.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure", RFC 6488, February 2012.

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012.

11.2. 参考規格

[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, February 2012.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.

[RFC6490] Huston, G., Weiler, S., Michaelson, G., and S. Kent, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 6490, February 2012.

[RSYNC] rsync web pages, http://rsync.samba.org/.

[S-BGP] Kent, S., Lynn, C., and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000.

[soBGP] White, R., "soBGP", May 2005, ftp://ftp-eng.cisco.com/sobgp/index.html

著者のアドレス

マット・レピンスキー
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
メール: mlepinski@bbn.com

スティーブン・ケント
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
メール: kent@bbn.com

変更履歴

  • 2024.2.15
  • 2024.2.23: Errataを追記
  • 2024.3.5
  • 2024.4.1
GitHubで編集を提案

Discussion