ルートオリジン認証はデジタルで署名された RPKI BGPでIPプレフィックスを発信できるASNを識別する記録です。これは、関連するインターネット番号リソースを保有する組織によって作成されるか、その代行によって作成されます。ROAには通常3つの重要な要素が含まれます。IPプレフィックス、認可された出発ASN、およびASNが発信できる最大プレフィックス長です。例えば、ある組織がIPv4プレフィックス203.0.113.0/24を管理し、AS64500を使用してそれを発信する場合があります。対応するROAはAS64500にその/24の発信を許可することができます。簡単に言うと、この記録はルーティングエコシステムに次の指示を伝えています。「このASNはこのプレフィックスを発信することが許可されています。」RPKI検証を行うネットワークは、その後、BGPで観測される内容とこの記録を比較できます。ROAはIPアドレスブロックの所有権を移転しません。契約や登録情報、割当記録、またはIPv4転送契約を置き換えるものではありません。これはルートの出発に関する承認のみを公開します。法的な支配とルーティングの承認は関連していますが、同じものではありません。ROAはIPv4およびIPv6リソースの両方に対して作成できます。形式は似ていますが、プレフィックス長や運用設計は異なる場合があります。IPv4ネットワークでは/24などのプレフィックスを扱うことが多い一方、IPv6ネットワークでは/32、/36、/48、またはその配布およびルーティング計画に適した他の長さの集約をよく発信します。
ROAが必要な理由は何か？
ROAがない場合、他のネットワークはRPKIベースの承認を確認することができず、BGPオリジンASNが接頭辞を宣伝することを許可されているかどうかを確認できません。ルートが依然として正当である可能性はありますが、RPKI検証中に一致する承認がないため、一般的には「見つからない」という結果になります。「見つからない」結果は自動的にルーティングの問題ではありません。インターネット上の多くの有効なルートにはROAがありません。しかし、組織が正確なROAを公開すると、他のネットワークは期待されるオリジンと不正または誤設定されたオリジンを区別するために使用できるより強いシグナルを得ます。接頭辞が価値があり、ビジネス上で重要であるか、広く宣伝されている場合、ROAは特に役立ちます。企業は自社のアドレス空間を公開サービスに使用し、クラウドプラットフォームはカスタマーのインフラを宣伝し、ホスティングプロバイダーは複数の場所からの大規模なアドレス範囲を宣伝することがあります。これらの状況では、誤ったオリジンが多くのユーザーおよびサービスに影響を与えることがあります。ROAはイベント対応においても役立ちます。接頭辞が予期しないASNから突然現れた場合、ネットワークオペレーターはRPKIステータスをチェックし、宣伝がリソース所有者が公開した意図と衝突しているかどうかを迅速に判断できます。これはすべてのイベントの詳細を説明するものではありませんが、調査の重要な出発点を提供します。複数の上流プロバイダーを使用する組織の場合、ROAはどのプロバイダーがルートを運ぶかに関係なく一貫した承認を提供します。プロバイダーが変化しても、オリジンASNは同じままであることが多く、その場合、トランジット経路が変化しただけではROAを変更する必要が通常ありません。
ROAはBGPとどのように動作するのか？
BGPは自律システム間でルート公告を配布します。通常、ルート公告にはIPプレフィックスと出発ASN、および他の経路およびポリシー情報が含まれます。出発ASNは、ルートのソースであると主張する自律システムです。RPKI検証はBGPとともに動作します。検証者はRPKIシステムから署名された認証データを取得し、その記録が正当で最新であることを確認します。その後、ルーター、ルートサーバー、またはルーティングポリシーシステムで使用できる検証済みデータセットを作成します。ネットワークがBGP公告を受け取ると、公告されたプレフィックスと出発ASNを検証済みROA情報と比較します。3つの主要な結果があります。公告は「有効」、「無効」、または「見つからない」となる可能性があります。「有効」という結果は、公告がROAによってカバーされており、出発ASNが承認されていることを意味します。「無効」という結果は、関連するROAが存在するが、公告がそれと矛盾していることを意味します。「見つからない」という結果は、適用可能なROAが見つからないことを意味します。受信ネットワークはこれらの結果に対してどう処理するかを決定します。一部のオペレータは無効なルートを拒否します。他のオペレータはそれらに低い優先順位を付与し、アラームを発生させたり、ソースに応じて異なるポリシーを適用したりします。すべてのネットワークに対して単一の普遍的なポリシーは存在しませんが、多くのプロバイダーは無効な公告を重要なルーティングセキュリティ問題として扱います。重要な点は、ROAがグローバルインターネットを直接制御しないということです。ROAは認証情報を公開するだけです。実際の影響は、他のネットワークがその情報を取得し、検証し、ルーティング決定に使用するかどうかに依存します。
ROAの3つの主要な部分
ROAの最初の部分は、認可されたIPプレフィックスであり、オリジンASNが宣伝できるアドレス範囲を識別します。IPv4の場合、プレフィックスは198.51.100.0/24となることがあります。IPv6の場合、2001:db8:1234::/48となることがあります。プレフィックスは、関連する登録機関またはスポンサーシップ関係を通じて組織が管理する権限を持つリソースに対応している必要があります。プレフィックスは正確に入力する必要があります。タイポミス、誤ったネットワーク境界、または誤ったプレフィックス長により、ROAが効力を失うか、意図した範囲とは異なる範囲を認可してしまう可能性があります。
2番目の部分は、接頭辞を発信する権限を持つ元のASNであり、BGP公告で表示される元のASNと一致している必要があります。企業がアドレスブロックを所有しているが、トランジットプロバイダーのASNを通じて宣伝している場合、正しい元は実際のルーティング設計によります。ROAに記載されるASNは通常、ルートを発信するASNであり、上流キャリアのASNだけではありません。この区別は重要です。トランジットプロバイダーはルートを運ぶだけで、発信していない場合があります。顧客のASNが接頭辞を発信し、プロバイダーはそれのみを輸送している場合、通常顧客のASNが認可されるべき値です。
3番目の部分は最大プレフィックス長、しばしばmaxLengthと呼ばれるもので、ROAによってカバーされる範囲内でどのくらい特定のアノンセメントが可能かを定義します。198.51.100.0/24を、最大長が/24で許可されたROAがあると仮定してください。この場合、認可されたASNは正確な/24をアノンスすることができますが、/25や/26などのより小さなサブプレフィックスをアノンスすることは許可されていません。同じプレフィックスが最大長が/26で許可された場合、/24、/25、および/26のアノンスは、ルートと検証ルールの正確な内容に応じてカバーされていると見なされるかもしれません。これは柔軟性を提供しますが、より特定性の高いアノンスも許可することになります。したがって、最大長は実際のルーティング計画を反映すべきであり、あまりにも短く設定すると正当なより特定性の高いルートが無効になる可能性があり、逆に長く設定すると組織が許可したかったものよりも広いアノンスが許可されてしまう可能性があります。
maxLengthが重要な理由
最大プレフィックス長は、認可されたASNがリソースを宣伝する際に使用できる特異性のレベルを制御する、最も重要で頻繁に誤解されるROA設定の一つです。多くのネットワークオペレーターはルーティングテーブルの成長を抑えるために集約プレフィックスを宣伝します。例えば、ある組織が/20を持ちながらそれを単一の集約として宣伝することがあります。場合によっては、トラフィックエンジニアリング、地域接続、またはサービス分離のためにより小さなプレフィックスを宣伝する必要があることもあります。ROAが集約のみをカバーしている場合、ネットワークがより具体的なルートを宣伝すると、それらのルートは「無効」と見なされる可能性があります。BGP宣伝は組織の観点から技術的に正しいものであるかもしれませんが、RPKIに公開されている承認と一致しません。一方で、すべての可能なより具体的なルートを認可してしまうと、ポリシーの正確性が低下する可能性があります。たとえば、非常に広範な最大長で/20を認可すると、意図した設計とは関係なく、はるかに小さなサブプレフィックスが認可されているように見えることになります。実用的なアプローチとしては、アドレッシング計画、プロバイダーの要件、フェイルオーバー設計、トラフィックエンジニアリング戦略に基づいて、ネットワークが実際に宣伝すると予期するプレフィックス長のみを認可することが挙げられます。最大長の変更は慎重に行い、本番の宣伝が厳格なフィルタリングを適用する前に期待される検証結果を返すことを確認する必要があります。
ROAs for IPv4 and IPv6
ROAはIPv4およびIPv6ネットワークの両方に作成でき、基本的なセキュリティ原則は同じです。それは、接続するプレフィックスと承認されたオリジンASNを関連付けることです。主要な運用上の違いはアドレス構造にあります。IPv4リソースは限られており、一般的に小さなプレフィックスで公告されることが多く、公開インターネットでは/24が一般的な最小公告サイズです。IPv6ネットワークは通常、より大きな割当てを受け、それらをサイト、サービス、または地理的セグメントに分割し、1つの集約を公告しながらいくつかの内部プレフィックスを使用します。ROAは公開されているプレフィックスと一致している必要があります。IPv6オペレータは、大きなアドレス空間があるからといってルーティングリスクがなくなるわけではないことを理解すべきです。不正なIPv6公告は依然として到達不能問題やトラフィックの再ルーティング、または一貫性のないグローバルルーティングを引き起こす可能性があります。RPKIはIPv6オペレータに、IPv4オペレータと同じようにオリジン認証を公開する機会を提供します。IPv6 ROAを作成する前に、ネットワークチームはどの集約プレフィックスを公告するか、より具体的な公告が予期されるか、そしてどのASNがそれらを発信するかを文書化する必要があります。これにより、記録がしすぎたり、不必要なほど広すぎるものを避けることができます。
ROAを作成するべきタイミングはいつですか？
ROAは、リソース所有者が明確なルーティング計画を持っている場合、プロダクションで接頭辞が発表される前に作成する必要があります。これにより、検証ネットワークにルートが広く表示される前に情報を取得する時間が確保されます。組織は、新しい割当てを受けたとき、IPv4ブロックを取得したとき、アドレス転送を完了したとき、元のASNを変更したとき、または新しいIPv6割当てを開始したときにROAを再確認する必要があります。これらの出来事は、接頭辞と出発ネットワークの関係を変更するからです。プロバイダーの移行も一般的なトリガーです。組織が同じ元のASNを保持し、上流キャリアのみを変更する場合、ROAは有効のままになる可能性があります。移行によって元のASNが変更される場合は、ルーティングの変更の前または同時に記録を更新する必要があります。合併・買収、データセンターマイグレーション、ASNスポンサーシップの変更、主要なネットワークの再設計の際にROAを確認する必要があります。これにより、公開された承認が運用上の現実と一致していることを確認できます。変更が知られていない場合でも、定期的な確認は役立ちます。ネットワークドキュメントが古くなり、スタッフの責任範囲が変化し、古い承認が元のルーティング設計が置き換えられた後も長期間有効なままとなることがあるためです。
一般的なROA構成のミス
最も一般的なミスの一つは、誤った元 ASN を入力することであり、これはエンジニアが顧客 ASN と輸送事業者 ASN を混同するときや、移行後にも古い ASN が構成に残っているときに発生します。もう一つの一般的なミスは、IPv4の転送後にROAを更新しないことです。新しい所有者が自身のASNからプレフィックスを宣伝する一方で、古い認可が以前の元を指しているため、ルートが無効になります。組織が /24 だけを許可しているにもかかわらず、後のトラフィックエンジニアリングのために /25 を宣伝すると、不正確な最大長も同様の問題を引き起こします。いくつかの組織は、目的を文書化せずに複数の重複する ROA を作成します。特定の設計では有効ですが、予期しない結果を生じさせ、トラブルシューティングを複雑にすることがあります。古くなった記録を削除しないと、ネットワーク設計が変更された後でも、ASN がプレフィックスを元にすることがあります。最後に、組織が自身の宣伝をテストせずに無効ルートの厳格な拒否を有効にすることがあります。本番用のプレフィックス、最大長、および元 ASN は、自動フィルタリングに依存する前に常に検証する必要があります。
ROA and IPv4 Transfer Planning
IPv4の移管には特別な注意が必要です。これは、管理保持者、後援契約、およびルーティング元がプロセスの異なる段階で変化する可能性があるためです。移管前に、現在の保持者は既存のROAを文書化し、どのASNが現在接頭辞を元にしているかを確認する必要があります。一方、購入者は意図された元情報を作成し、トランジット提供者と調整する必要があります。移行中に、両者が承認記録の更新または置き換えについて明確な計画を持つ必要があります。以前のROAを長く有効にしたままにすると、移管後の古い元が許可されることになり、逆に早めに削除すると、新しいルートが準備できる前に既存のルートが無効になります。正確なプロセスは、レジストリ、リソースタイプ、移管契約、運用設計に依存するため、RPKIは登録機関の検証、契約レビュー、BGP公告、ルートオブジェクト、逆DNS、評判スクリーニングとともに重要なチェックリスト項目となります。公開の準備チェッカーは、プレフィックスの現在のオリジンASN、RPKI状態、登録情報、およびBGP可視性を技術的な事前チェックのために特定するのに役立ちますが、法的所有権を確認したり、移管資格を保証したりすることはできません。
ROAおよびASNの変更
ASNの変更は直接的にRPKI検証に影響を与えます。AS64500によって以前に宣伝されていたプレフィックスが今やAS64510によって宣伝される場合、BGP宣伝が有効とみなされるにはROAが新しい元を承認している必要があります。これは特に、組織がプロバイダー管理型ASNから自前のASNへ移行するときや、スポンサリングLIRの取り決めを変更するときに重要です。この場合、登録機関との関係性およびルーティングの承認を一緒に見直す必要があります。慎重に計画された移行では、古いおよび新しい元の両方を一時的に承認することで、制御された移行期間を作成することがあります。ただし、その際は文書化されており、完了後に古くなった承認が削除されている必要があります。ネットワークチームは、本番環境での変更を行う前に操作の順序をテストし、新しい承認が公開され、検証されていることを確認する必要があります。
ROAが動作しているかどうかを確認する方法は？
最初のチェックでは、ROAが意図されたプレフィックス、オリジンASN、および最大プレフィックス長を、関連するRIRポータル、スポンサーリンクインターフェース、またはRPKI管理システムを通じて含んでいることを確認します。次に、認証を実際のBGPアノンスメントと比較し、アノンスされたプレフィックス長がカバーされており、オリジンASNがROAと一致していることを検証します。その後、外部のRPKI検証ツールを使用して公開状態を確認し、正しい設定されたアノンスメントは「有効」と返されるはずです。結果が「無効」の場合、まずオリジンASNとプレフィックス長を確認してください。「見つからない」場合、ROAが公開されているか、検証ツールが取得する時間があるかを確認してください。結果は即座に更新されないのは、リポジトリ、検証ツール、ルーティングシステムがリフレッシュ間隔に依存しているためであり、配信中に短い遅延は通常です。複数の公開ソース（登録データ、検証結果、現在のBGP観測）を比較することで、キャッシュされた情報に頼らず全体像を把握できます。
ROAが無効な場合、どうなるのか？
BGPの公告が既存のROAと衝突すると、RPKI検証者はそれを「無効」と分類します。ルートはグローバルインターネットから自動的に削除されませんが、RPKIベースのポリシーを実施しているネットワークでは、これを拒否したり、優先度を低くしたりする可能性があります。運用上の影響は、実施範囲に依存します。一部のネットワークでは厳格にフィルタリングを行う一方、他のネットワークではステータスをモニタリングに使用するため、無効なルートはインターネットの一部では表示されるものの、他の場所では到達不能になることがあります。正当なルートが無効となった場合、その組織は緊急の設定問題として扱い、オリジンASN、発表されたプレフィックス長、およびROAの最大長のレビューを優先する必要があります。ルートを悪意あるものと仮定してはなりません。ほとんどの無効な結果は、不完全な移行や古くなった記録、誤ったプロバイダ情報、または誤ってより具体的なアノンセメントを行ったような日常的なミスに起因しています。修正後、システムには更新に時間がかかり、ネットワークチームはすべての観測ポイントでルートが安定するまでモニタリングを行う必要があります。
ROAを組織はどのように管理すべきか？
ROAの管理には、ネットワークエンジニアリングチーム、セキュリティチーム、後援するLIR、マネージドサービスプロバイダー、またはインターネット番号リソースを担当する他のグループのいずれかに明確な所有者がいる必要があります。組織は、各プレフィックス、オリジンASN、最大長、発表場所、および責任者連絡先を詳細に記載した在庫を維持すべきです。これにより、変更レビューおよびインシデント対応が簡略化されます。ROAの変更は、ASN移行、プロバイダースイッチ、IPv4転送、またはIPv6展開中にRPKIを明示的な要件として標準的なネットワーク変更手順に統合する必要があります。無効な結果、予期せぬオリジン、削除された承認、またはBGP可視性の変化に対するモニタリングとアラート設定が必要です。重要なのは、過度に広範な承認を避けることです。正確なROAは理解しやすく、監査が簡単で、意図しない発表を許可する可能性がはるかに少ないためです。
よくある質問
ROAはIP所有権文書と同じものですか？
いいえ。ROAは、BGPで接頭辞を生成できるAS番号を示すルーティング認証です。登録記録、契約、譲渡書類、または法的所有権の証拠を置き換えるものではありません。
1つのプレフィックスに複数のROAがあることは可能ですか？
はい。プレフィックスが複数のASNによって意図的に発信される場合、または制御された移行のために一時的な複数の元への承認が必要な場合、複数のROAが適切であることがあります。ただし、重複する記録は慎重に文書化する必要があります。
ROAは私のプレフィックスをBGPで宣伝しますか？
いいえ。ROAを作成してもBGPの宣伝は作成されません。ネットワークは依然としてルーターおよび上流プロバイダーを通じてBGPを構成する必要があります。
トランジット提供者がROAにリストされている必要があるのでしょうか？
通常、ROAは経路を発信するASNを特定する必要があります。ルートを運ぶだけのプロバイダーが必ずしも元のASNであるとは限らず、正しい値は実際のルーティング構造に依存します。
ROAが表示されるまでにどのくらいかかりますか？
タイミングはRIRシステム、公開リポジトリ、検証者の更新間隔およびキャッシュに依存します。更新はしばしば比較的迅速に表示されることがありますが、本番環境の変更には検証に十分な時間が確保される必要があります。
すべてのIPv4およびIPv6プレフィックスにROAが必要ですか？
BGPで発表されるプレフィックスの正確なROAを公開することは強く推奨されます。組織は、認可が正当な発表を誤って無効にしないようにするため、まずそのルーティング設計を確認する必要があります。
ROAはすべてのBGP攻撃を防止できるか？
いいえ。ROAは主にオリジン検証をサポートします。BGPパスのすべての部分を検証したり、すべてのルートリークを防止したり、トラフィックを暗号化したり、トラフィックがセキュアな物理的なルートをたどることを保証したりするものではありません。
ルートオリジン認証（ROA）は、RPKIの中心的な要素であり、IPプレフィックスとそのプレフィックスをBGPでオリジンするための承認されたASNとの暗号的に署名された関係を確立します。この記録には通常、プレフィックス、オリジンASN、および最大プレフィックス長が含まれており、それぞれがリソースの識別、オリジンの許可、および発表の具体的な範囲の定義において決定的な役割を果たします。正確なROAは、ネットワークが不正または誤設定された発表を特定するのに役立ち、IPv4の移転、ASNの変更、プロバイダの移行、IPv6の展開、マルチホームネットワーク運用において非常に重要です。同時に、ROAは法的所有権の証明でも、単独のルーティングセキュリティソリューションでもありません。正確な登録記録、厳格なBGP構成、IRRデータ、ルートモニタリング、文書化された変更プロセスとともに機能するのが最も効果的です。公開されるIPv4またはIPv6アドレス空間を発表するあらゆる組織にとって、実際のルールは単純です。使用する予定のオリジンのみを公開し、実際に発表する予定のプレフィックス長のみを承認し、ネットワークに変更があるたびに記録を確認してください。これにより、RPKIデータが現実のルーティング環境と一致し、正当なルートが無効と分類される可能性が低くなります。