RFC 8634 - BGPsec Router Certificate Rollover 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8634
タイトル : RFC 8634 - BGPsecルーター証明書のロールオーバー
翻訳編集 : 自動生成

[要約] RFC 8634は、BGPsecルーター証明書のロールオーバーに関するガイドラインです。目的は、BGPsecルーターの証明書を安全に更新するための手順とポリシーを提供することです。

Internet Engineering Task Force (IETF)                           B. Weis
Request for Comments: 8634                                   Independent
BCP: 224                                                     R. Gagliano
Category: Best Current Practice                            Cisco Systems
ISSN: 2070-1721                                                 K. Patel
                                                            Arrcus, Inc.
                                                             August 2019

BGPsec Router Certificate Rollover

BGPsecルーター証明書のロールオーバー

Abstract

概要

Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.

Resource Public Key Infrastructure（RPKI）内の認証局（CA）は、BGPsecルーター証明書とRPKI証明書を管理します。 BGPsecルーター証明書のロールオーバーは、ルーター公開鍵の配布を、それらのルーター公開鍵で検証されたBGPsec UPDATEメッセージと同期させるために、慎重に実行する必要があります。このドキュメントでは、安全なロールオーバープロセスについて説明し、BGPsecルーター証明書のロールオーバーが必要になるタイミングと理由について説明します。このロールオーバープロセスが実行されると、ルーティング情報が失われることなくロールオーバーが実行されます。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8634.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8634で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Key Rollover in BGPsec  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Rollover Process  . . . . . . . . . . . . . . . . . . . .   5
   4.  BGPsec Router Key Rollover as a Measure against Replay
       Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  BGP UPDATE Window of Exposure Requirement . . . . . . . .   7
     4.2.  BGPsec Key Rollover as a Mechanism to Protect against
           Replay Attacks  . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

In BGPsec, a key rollover (or re-key) is the process of changing a router's BGPsec key pair (or key pairs), issuing the corresponding new BGPsec router certificate, and (if the old certificate is still valid) revoking the old certificate. This process will need to happen at regular intervals, normally due to policies of the local network. This document describes a safe rollover process that results in a BGPsec receiver always having the needed verification keys. Certification Practice Statement (CPS) documents may reference this memo. This memo only addresses changing of a router's BGPsec key pair within the RPKI. Refer to [RFC6489] for a procedure to roll over RPKI Certification Authority key pairs.

BGPsecでは、キーロールオーバー（またはキーの再生成）は、ルーターのBGPsecキーペア（またはキーペア）を変更し、対応する新しいBGPsecルーター証明書を発行し、（古い証明書がまだ有効な場合）古い証明書を取り消すプロセスです。。通常、ローカルネットワークのポリシーにより、このプロセスは定期的に実行する必要があります。このドキュメントでは、BGPsecレシーバーに必要な検証キーが常に保持される安全なロールオーバープロセスについて説明します。認定実務声明（CPS）文書はこのメモを参照する場合があります。このメモは、RPKI内のルーターのBGPsecキーペアの変更のみを扱います。 RPKI認証局の鍵ペアをロールオーバーする手順については、[RFC6489]を参照してください。

When a router receives or creates a new key pair (using a key provisioning mechanism), this key pair will be used to sign new BGPsec UPDATE messages [RFC8205] that are originated at or that transit through the BGP speaker. Additionally, the BGP speaker will refresh its outbound BGPsec UPDATE messages to include a signature using the new key (replacing the old key). When the rollover process finishes, the old BGPsec router certificate (and its key) will no longer be valid; thus, any BGPsec UPDATE message that includes a signature performed by the old key will be invalid. Consequently, if the router does not refresh its outbound BGPsec UPDATE messages, previously sent routing information may be treated as unauthenticated after the rollover process is finished. Therefore, it is extremely important that new BGPsec router certificates have been distributed throughout the RPKI before the router begins signing BGPsec UPDATE messages with a new private key.

ルータが（キープロビジョニングメカニズムを使用して）新しいキーペアを受信または作成すると、このキーペアを使用して、BGPスピーカーで発信または通過する新しいBGPsec UPDATEメッセージ[RFC8205]に署名します。さらに、BGPスピーカーは送信BGPsec UPDATEメッセージを更新して、新しいキーを使用する署名を含めます（古いキーを置き換える）。ロールオーバープロセスが完了すると、古いBGPsecルーター証明書（およびそのキー）は無効になります。したがって、古いキーによって実行された署名を含むBGPsec UPDATEメッセージは無効になります。その結果、ルーターがそのアウトバウンドBGPsec UPDATEメッセージを更新しない場合、以前に送信されたルーティング情報は、ロールオーバープロセスの完了後に認証されていないものとして扱われる可能性があります。したがって、ルーターが新しい秘密鍵でBGPsec UPDATEメッセージに署名を始める前に、新しいBGPsecルーター証明書がRPKI全体に配布されていることが非常に重要です。

It is also important for an AS to minimize the BGPsec router key-rollover interval (i.e., the period between the time when an AS distributes a BGPsec router certificate with a new public key and the time a BGPsec router begins to use its new private key). This can be due to a need for a BGPsec router to distribute BGPsec UPDATE messages signed with a new private key in order to invalidate BGPsec UPDATE messages signed with the old private key. In particular, if the AS suspects that a stale BGPsec UPDATE message is being distributed instead of the most recently signed attribute, it can cause the stale BGPsec UPDATE messages to be invalidated by completing a key-rollover procedure. The BGPsec router rollover interval can be minimized when an automated certificate provisioning process such as Enrollment over Secure Transport (EST) [RFC7030] is used.

ASがBGPsecルーターのキーロールオーバー間隔（つまり、ASが新しい公開鍵でBGPsecルーター証明書を配布してから、BGPsecルーターが新しい秘密鍵の使用を開始するまでの時間）を最小限に抑えることも重要です。）。これは、古い秘密鍵で署名されたBGPsec UPDATEメッセージを無効にするために、BGPsecルーターが新しい秘密鍵で署名されたBGPsec UPDATEメッセージを配布する必要があるためです。特に、ASが、最新の署名された属性の代わりに古いBGPsec UPDATEメッセージが配信されていると疑う場合、キーロールオーバー手順を完了することにより、古いBGPsec UPDATEメッセージが無効になる可能性があります。 BGPsecルーターのロールオーバー間隔は、Enrollment over Secure Transport（EST）[RFC7030]などの自動化された証明書プロビジョニングプロセスを使用すると最小化できます。

"Security Requirements for BGP Path Validation" [RFC7353] also describes the need for protecting against suppression of BGP UPDATE messages with Withdrawn Routes or replay of BGP UPDATE messages, such as controlling BGPsec's window of exposure to such attacks. The BGPsec router certificate rollover method in this document can be used to achieve this goal.

「BGPパス検証のセキュリティ要件」[RFC7353]では、撤回されたルートによるBGP UPDATEメッセージの抑制や、BGPsecのこのような攻撃への露出のウィンドウの制御など、BGP UPDATEメッセージの再生に対する保護の必要性についても説明しています。このドキュメントのBGPsecルーター証明書のロールオーバー方法は、この目標を達成するために使用できます。

In [RFC8635], the "operator-driven" method is introduced, in which a key pair can be shared among multiple BGP speakers. In this scenario, the rollover of the corresponding BGPsec router certificate will impact all the BGP speakers sharing the same private key.

[RFC8635]では、「オペレーター主導」の方法が導入されています。この方法では、キーペアを複数のBGPスピーカー間で共有できます。このシナリオでは、対応するBGPsecルーター証明書のロールオーバーは、同じ秘密鍵を共有するすべてのBGPスピーカーに影響します。

2. Requirements Notation

2. 要件表記

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Key Rollover in BGPsec

3. BGPsecでのキーロールオーバー

A BGPsec router certificate SHOULD be replaced when the following events occur, and it can be replaced for any other reason at the discretion of the AS responsible for the BGPsec router certificate.

BGPsecルーター証明書は、次のイベントが発生したときに交換する必要があります。また、BGPsecルーター証明書を担当するASの裁量により、他の理由で交換することができます。

Scheduled rollover: BGPsec router certificates have an expiration date (NotValidAfter) that requires a frequent rollover process to refresh certificates or issue new certificates. The validity period for these certificates is typically expressed in the CA's CPS document.

スケジュールされたロールオーバー：BGPsecルーター証明書には、証明書を更新したり新しい証明書を発行したりするために頻繁なロールオーバープロセスが必要な有効期限（NotValidAfter）があります。これらの証明書の有効期間は、通常、CAのCPSドキュメントに記載されています。

Router certificate field changes: Information contained in a BGPsec router certificate (such as the Autonomous System Number (ASN) or the Subject) may need to be changed.

ルーター証明書フィールドの変更：BGPsecルーター証明書に含まれる情報（自律システム番号（ASN）やサブジェクトなど）を変更する必要がある場合があります。

Emergency router key rollover: Some special circumstances (such as a compromised key) may require the replacement of a BGPsec router certificate.

緊急ルーターキーのロールオーバー：いくつかの特別な状況（キーのセキュリティ侵害など）では、BGPsecルーター証明書の交換が必要になる場合があります。

Protection against withdrawal suppression and replay attacks: An AS may determine that withdrawn BGPsec UPDATE messages are being propagated instead of the most recently propagated BGPsec UPDATE messages. Changing the BGPsec router signing key, distributing a new BGPsec router certificate, and revoking the old BGPsec router certificate will invalidate the replayed BGPsec UPDATE messages.

撤回抑制およびリプレイ攻撃に対する保護：ASは、最後に伝搬されたBGPsec UPDATEメッセージではなく、撤回されたBGPsec UPDATEメッセージが伝搬されていると判断する場合があります。 BGPsecルーターの署名鍵を変更し、新しいBGPsecルーター証明書を配布し、古いBGPsecルーター証明書を取り消すと、再生されたBGPsec UPDATEメッセージが無効になります。

In some of these cases, it is possible to generate a new certificate without changing the key pair. This practice simplifies the rollover process as the BGP speakers receiving BGPsec UPDATE messages do not even need to be aware of the change of certificate. However, not replacing the certificate key for a long period of time increases the risk that a compromised router private key may be used by an attacker to deliver unauthorized or false BGPsec UPDATE messages. Distributing the old public key in a new certificate is NOT RECOMMENDED when the rollover event is due to a compromised key or when it is suspected that withdrawn BGPsec UPDATE messages are being distributed.

これらのケースのいくつかでは、鍵ペアを変更せずに新しい証明書を生成することが可能です。 BGPsec UPDATEメッセージを受信するBGPスピーカーは証明書の変更を認識する必要さえないので、この方法はロールオーバープロセスを簡素化します。ただし、証明書キーを長期間置換しないと、攻撃者が不正に使用された、または偽のBGPsec UPDATEメッセージを配信するために、侵害されたルーターの秘密キーを使用するリスクが高まります。ロールオーバーイベントがキーの侵害によるものである場合、または撤回されたBGPsec UPDATEメッセージが配信されている疑いがある場合は、古い証明書を新しい証明書で配布することはお勧めしません。

3.1. Rollover Process

3.1. ロールオーバープロセス

The key-rollover process is dependent on the key provisioning mechanisms adopted by an AS [RFC8635]. An automatic provisioning mechanism such as EST will allow procedures for router key management to include automatic re-keying methods with minimum development cost.

キーロールオーバープロセスは、AS [RFC8635]で採用されているキープロビジョニングメカニズムに依存しています。 ESTなどの自動プロビジョニングメカニズムにより、ルーターのキー管理の手順に、最小限の開発コストで自動再キー方式を含めることができます。

A safe BGPsec router key-rollover process is as follows.

安全なBGPsecルーターのキーロールオーバープロセスは次のとおりです。

1. New Certificate Publication: The first step in the rollover mechanism is to publish the new certificate. If required, a new key pair will be generated for the BGPsec router. A new certificate will be generated and the certificate will be published at the appropriate RPKI repository publication point.

1. 新しい証明書の発行：ロールオーバーメカニズムの最初のステップは、新しい証明書を発行することです。必要に応じて、BGPsecルーター用に新しいキーペアが生成されます。新しい証明書が生成され、証明書は適切なRPKIリポジトリ公開ポイントで公開されます。

The details of this process will vary as they depend on 1) whether the keys are assigned per-BGPsec speaker or shared among multiple BGPsec speakers, 2) whether the keys are generated on each BGPsec speaker or in a central location, and 3) whether the RPKI repository is locally or externally hosted.

このプロセスの詳細は、1）キーがBGPsecスピーカーごとに割り当てられるか、複数のBGPsecスピーカー間で共有されるか、2）キーが各BGPsecスピーカーで生成されるか、中央の場所で生成されるか、および3） RPKIリポジトリはローカルまたは外部でホストされます。

2. Staging Period: A staging period will be required from the time a new certificate is published in the global RPKI repository until the time it is fetched by RPKI caches around the globe. The exact minimum staging time will be dictated by the conventional interval chosen between repository fetches. If rollovers will be done more frequently, an administrator can provision two certificates for every router concurrently with different valid start times. In this case, when the rollover operation is needed, the relying parties around the globe would already have the new router public keys. However, if an administrator has not previously provisioned the next certificate, implementing a staging period may not be possible during emergency key rollover. If there is no staging period, routing may be disrupted due to the inability of a BGPsec router to validate BGPsec UPDATE messages signed with a new private key.

2. ステージング期間：新しい証明書がグローバルRPKIリポジトリで公開されてから、世界中のRPKIキャッシュによってフェッチされるまでのステージング期間が必要です。正確な最小ステージング時間は、リポジトリーのフェッチ間で選択される従来の間隔によって決まります。ロールオーバーがより頻繁に行われる場合、管理者は、異なる有効な開始時間で同時にすべてのルーターに2つの証明書をプロビジョニングできます。この場合、ロールオーバー操作が必要なときに、世界中の証明書利用者は既に新しいルーターの公開キーを持っています。ただし、管理者が以前に次の証明書をプロビジョニングしていない場合、緊急キーのロールオーバー中にステージング期間を実装できない可能性があります。ステージング期間がない場合、BGPsecルーターが新しい秘密鍵で署名されたBGPsec UPDATEメッセージを検証できないため、ルーティングが中断される可能性があります。

3. Twilight: In this step, the BGPsec speaker holding the rolled-over private key will stop using the old key for signing and will start using the new key. Also, the router will generate appropriate refreshed BGPsec UPDATE messages, just as in the typical operation of refreshing outbound BGP polices. This operation may generate a great number of BGPsec UPDATE messages. A BGPsec speaker may vary the distribution of BGPsec UPDATE messages in this step for every peer in order to distribute the system load (e.g., skewing the rollover for different peers by a few minutes each would be sufficient and effective).

3. トワイライト：このステップでは、ロールオーバーされた秘密キーを保持しているBGPsecスピーカーは、署名に古いキーの使用を停止し、新しいキーの使用を開始します。また、ルーターは、発信BGPポリシーを更新する通常の操作と同様に、適切な更新されたBGPsec UPDATEメッセージを生成します。この操作により、多数のBGPsec UPDATEメッセージが生成される場合があります。 BGPsecスピーカーは、システム負荷を分散するために、このステップでの各ピアのBGPsec UPDATEメッセージの分散を変えることができます（たとえば、異なるピアのロールオーバーを数分だけスキューすることで十分かつ効果的です）。

4. Certificate Revocation: This is an optional step, but it SHOULD be taken when the goal is to invalidate BGPsec UPDATE messages signed with the old key. Reasons to invalidate old BGPsec UPDATE messages include (a) the AS has reason to believe that the router signing key has been compromised, and (b) the AS needs to invalidate already-propagated BGPsec UPDATE messages signed with the old key. As part of the rollover process, a CA MAY decide to revoke the old certificate by publishing its serial number on the CA's Certificate Revocation List (CRL). Alternatively, the CA will just let the old certificate expire and not revoke it. This choice will depend on the reasons that motivated the rollover process.

4. 証明書の失効：これはオプションの手順ですが、古い鍵で署名されたBGPsec UPDATEメッセージを無効にすることを目的とする場合に行う必要があります。古いBGPsec UPDATEメッセージを無効にする理由には、（a）ASがルーターの署名鍵が危険にさらされていると信じる理由があり、（b）ASが古い鍵で署名された、すでに伝達されたBGPsec UPDATEメッセージを無効にする必要がある場合があります。ロールオーバープロセスの一部として、CAは、CAの証明書失効リスト（CRL）でシリアル番号を公開することにより、古い証明書を取り消すことを決定できます（MAY）。または、CAは古い証明書を失効させるだけで、失効させません。この選択は、ロールオーバープロセスの動機となった理由によって異なります。

5. RPKI-Router Protocol Withdrawals: At the expiration of the old certificate's validation, the RPKI relying parties around the globe will need to communicate to their router peers that the old certificate's public key is no longer valid (e.g., using the RPKI-Router Protocol described in [RFC8210]). A router's reaction to a message indicating withdrawal of a router key in the RPKI-Router Protocol SHOULD include the removal of any RIB entries (i.e., BGPsec updates) signed with that key and the generation of the corresponding BGP UPDATE message with Withdrawn Routes (either implicit or explicit).

5. RPKIルータープロトコルの撤回：古い証明書の検証の期限が切れると、世界中のRPKI証明書利用者は、古い証明書の公開キーが有効ではなくなったことをルーターピアと通信する必要があります（たとえば、説明したRPKIルータープロトコルを使用） [RFC8210]で）。 RPKIルータープロトコルでルーターキーの撤回を示すメッセージに対するルーターの反応には、そのキーで署名されたすべてのRIBエントリ（つまり、BGPsec更新）の削除と、撤回されたルート（いずれか）を使用した対応するBGP UPDATEメッセージの生成が含まれる必要があります（SHOULD）。暗黙的または明示的）。

This rollover mechanism depends on the existence of an automatic provisioning process for BGPsec router certificates. It requires a staging mechanism based on the RPKI propagation time (at the time of writing, this is typically a 24-hour period), and an AS is REQUIRED to re-sign all originated and transited BGPsec UPDATE messages that were previously signed with the old key.

このロールオーバーメカニズムは、BGPsecルーター証明書の自動プロビジョニングプロセスの存在に依存します。 RPKI伝播時間に基づいたステージングメカニズムが必要です（執筆時点では、これは通常24時間です）。以前にで署名されたすべての発信および転送されたBGPsec UPDATEメッセージに再署名するには、ASが必要です古い鍵。

The first two steps (New Certificate Publication and Staging Period) may happen in advance of the rest of the process. This will allow a network operator to perform its subsequent key rollover in an efficient and timely manner.

最初の2つのステップ（新しい証明書の発行とステージング期間）は、残りのプロセスの前に行われる場合があります。これにより、ネットワークオペレーターはその後のキーロールオーバーを効率的かつタイムリーに実行できます。

When a new BGPsec router certificate is generated without changing its key, steps 3 (Twilight) and 5 (RPKI-Router Protocol Withdrawals) SHOULD NOT be executed.

キーを変更せずに新しいBGPsecルーター証明書を生成する場合、手順3（トワイライト）および5（RPKIルータープロトコルの取り消し）は実行しないでください。

4. BGPsec Router Key Rollover as a Measure against Replay Attacks

4. リプレイ攻撃への対策としてのBGPsecルーターキーのロールオーバー

There are two typical generic measures to mitigate replay attacks in any protocol: the addition of a timestamp or the addition of a serial number. However, neither BGP nor BGPsec provides these measures. The timestamp approach was originally proposed for BGPsec [PROTECTION-DESIGN-DISCUSSION] but was later dropped in favor of the key-rollover approach. This section discusses the use of key rollover as a measure to mitigate replay attacks.

任意のプロトコルでのリプレイ攻撃を軽減するための2つの一般的な一般的な対策があります。タイムスタンプの追加またはシリアル番号の追加です。ただし、BGPもBGPsecもこれらの対策を提供していません。タイムスタンプアプローチは、もともとBGPsec [PROTECTION-DESIGN-DISCUSSION]のために提案されましたが、後でキーロールオーバーアプローチに代わって廃止されました。このセクションでは、リプレイ攻撃を軽減する手段としてのキーロールオーバーの使用について説明します。

4.1. BGP UPDATE Window of Exposure Requirement

4.1. 露出要件のBGP UPDATEウィンドウ

The need to limit the vulnerability to replay attacks is described in Section 4.3 of [RFC7353]. One important comment is that during a window of exposure, a replay attack is effective only in very specific circumstances: there is a downstream topology change that makes the signed AS path no longer current, and the topology change makes the replayed route preferable to the route associated with the new update. In particular, if there is no topology change at all, then no security threat comes from a replay of a BGPsec UPDATE message because the signed information is still valid.

リプレイ攻撃に対する脆弱性を制限する必要性は、[RFC7353]のセクション4.3で説明されています。重要なコメントの1つは、暴露の期間中、リプレイ攻撃は非常に特定の状況でのみ有効であるということです。ダウンストリームトポロジーの変更により、署名済みASパスが最新でなくなり、トポロジーの変更により、ルートよりもリプレイルートが優先されます。新しい更新に関連付けられています。特に、トポロジの変更がまったくない場合、署名された情報がまだ有効であるため、BGPsec UPDATEメッセージの再生によるセキュリティ上の脅威は発生しません。

"BGPsec Operational Considerations" [RFC8207] gives some idea of requirements for the size of the window of exposure to replay attacks. It states that the requirement will be in the order of a day or longer.

「BGPsec運用上の考慮事項」[RFC8207]は、リプレイアタックにさらされるウィンドウのサイズの要件に関するいくつかのアイデアを提供します。要件は1日以上のオーダーになると述べています。

4.2. BGPsec Key Rollover as a Mechanism to Protect against Replay Attacks

4.2. リプレイ攻撃から保護するメカニズムとしてのBGPsecキーロールオーバー

Since the window requirement is on the order of a day (as documented in [RFC8207]) and the BGP speaker performing re-keying is the edge router of the origin AS, it is feasible to use key rollover to mitigate replays. In this case, it is important to complete the full process (i.e., the old and new certificates do not share the same key). By re-keying, an AS is letting the BGPsec router certificate validation time be a type of "timestamp" to mitigate replay attacks. However, the use of frequent key rollovers comes with an additional administrative cost and risks if the process fails. As documented in [RFC8207], re-keying should be supported by automatic tools, and for the great majority of the Internet, it will be done with good lead time to ensure that the public key corresponding to the new router certificate will be available to validate the corresponding BGPsec UPDATE messages when received.

ウィンドウ要件は（[RFC8207]で文書化されているように）1日のオーダーであり、キー再生成を実行するBGPスピーカーはオリジンASのエッジルーターであるため、キーロールオーバーを使用してリプレイを軽減することができます。この場合、プロセス全体を完了することが重要です（つまり、古い証明書と新しい証明書は同じキーを共有しません）。鍵を再入力することにより、ASは、BGPsecルーターの証明書検証時間を「タイムスタンプ」の一種にして、リプレイアタックを緩和します。ただし、キーのロールオーバーを頻繁に使用すると、追加の管理コストとプロセスが失敗した場合のリスクが伴います。 [RFC8207]で文書化されているように、鍵の再生成は自動ツールでサポートされている必要があり、インターネットの大部分では、新しいルーター証明書に対応する公開鍵が受信時に対応するBGPsec UPDATEメッセージを検証します。

If a transit AS also originates BGPsec UPDATE messages for its own prefixes and it wishes to mitigate replay attacks on those prefixes, then the transit AS SHOULD be provisioned with two unique key pairs and certificates. One of the key pairs is used to sign BGPsec UPDATE messages for prefixes originated from the transit AS, and it can have a replay protection policy applied to it. The other key pair is used to sign BGPsec UPDATE messages in transit and SHOULD NOT have a replay protection policy applied to it. Because the transit AS is not likely to know or care about the policy of origin ASes elsewhere, there is no value gained by the transit AS performing key rollovers to mitigate replay attacks against prefixes originated elsewhere. If the transit AS were instead to perform replay protection for all updates that it signs, its process for key rollovers would generate a large number of BGPsec UPDATE messages, even in the complete Default-Free Zone (DFZ). Therefore, it is best to let each AS independently manage the replay attack vulnerability window for the prefixes it originates.

トランジットASが自身のプレフィックスのBGPsec UPDATEメッセージも発信し、それらのプレフィックスに対するリプレイアタックを軽減したい場合、トランジットASは2つの一意のキーペアと証明書でプロビジョニングする必要があります（SHOULD）。トランジットASから発信されたプレフィックスのBGPsec UPDATEメッセージに署名するためにキーペアの1つが使用され、それに再生保護ポリシーを適用できます。もう一方のキーペアは、転送中のBGPsec UPDATEメッセージに署名するために使用され、リプレイ保護ポリシーを適用してはいけません（SHOULD NOT）。トランジットASは他の場所にある発信元ASのポリシーを認識または考慮しない可能性が高いため、トランジットASがキーロールオーバーを実行して他の場所から発信されたプレフィックスに対するリプレイ攻撃を軽減することで得られる価値はありません。トランジットASが署名するすべての更新に対して代わりに再生保護を実行する場合、完全なデフォルトフリーゾーン（DFZ）であっても、キーロールオーバーのプロセスにより多数のBGPsec UPDATEメッセージが生成されます。したがって、各ASに、それが発生したプレフィックスのリプレイアタックの脆弱性ウィンドウを個別に管理させるのが最善です。

Advantages to re-keying as a replay attack protection mechanism are as follows:

リプレイ攻撃保護メカニズムとしてのキー再生成の利点は次のとおりです。

1. All expiration policies are maintained in the RPKI.

1. すべての有効期限ポリシーはRPKIで維持されます。

2. Much of the additional administrative cost is paid by the provider that wants to protect its infrastructure, as it bears the cost of creating and initiating distribution of new router key pairs and BGPsec router certificates. (It is true that the cost of relying parties will be affected by the new objects, but their responses should be completely automated or otherwise routine.)

2. 追加の管理コストの多くは、インフラストラクチャを保護するプロバイダーによって支払われます。これは、新しいルーターキーペアとBGPsecルーター証明書の配布を作成および開始するコストを負担するためです。（依存パーティのコストは新しいオブジェクトの影響を受けることは事実ですが、その応答は完全に自動化するか、その他の方法でルーチン化する必要があります。）

3. The re-keying can be implemented in coordination with planned topology changes by either origin ASes or transit ASes (e.g., if an AS changes providers, it completes a key rollover).

3. 鍵の再生成は、元のASまたはトランジットASのいずれかによる計画的なトポロジ変更と連携して実装できます（たとえば、ASがプロバイダーを変更した場合、キーのロールオーバーが完了します）。

Disadvantages to re-keying as replay attack protection mechanism are as follows:

リプレイ攻撃保護メカニズムとしてのキー再生成の欠点は次のとおりです。

1. Frequent rollovers add administrative and BGP processing loads, although the required frequency is not clear. Some initial ideas are found in [RFC8207].

1. 頻繁なロールオーバーは、管理およびBGP処理の負荷を追加しますが、必要な頻度は明確ではありません。 [RFC8207]にはいくつかの最初のアイデアがあります。

2. The minimum replay vulnerability is bounded by the propagation time for RPKI caches to obtain the new certificate and CRL (2x propagation time because first the new certificate and then the CRL need to propagate through the RPKI system). If provisioning is done ahead of time, the minimum replay vulnerability window size is reduced to 1x propagation time (i.e., propagation of the CRL). However, these bounds will be better understood when the RPKI and RPKI relying party software are well deployed; this will also contribute to the propagation time for objects in the RPKI being better understood.

2.最小の再生の脆弱性は、新しい証明書とCRLを取得するためのRPKIキャッシュの伝播時間によって制限されます（最初に新しい証明書、次にCRLがRPKIシステムを通じて伝播する必要があるため、2倍の伝播時間）。プロビジョニングが事前に行われる場合、最小のリプレイ脆弱性ウィンドウサイズは1倍の伝播時間（つまり、CRLの伝播）に減少します。ただし、RPKIおよびRPKI依存パーティソフトウェアが適切に展開されている場合、これらの境界はよりよく理解されます。これは、RPKI内のオブジェクトの伝搬時間の理解にも貢献します。

3. Re-keying increases the dynamics and size of the RPKI repository.

3. 鍵の再生成により、RPKIリポジトリのダイナミクスとサイズが増加します。

5. IANA Considerations

5. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

6. Security Considerations

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

This document does not contain a protocol update to either the RPKI or BGPsec. It describes a process for managing BGPsec router certificates within the RPKI.

このドキュメントには、RPKIまたはBGPsecへのプロトコルアップデートは含まれていません。 RPKI内でBGPsecルーター証明書を管理するプロセスについて説明します。

Routers participating in BGPsec will need to roll over their signing keys as part of conventional processing of certificate management. However, because rolling over signing keys will also have the effect of invalidating BGPsec UPDATE message signatures, the rollover process must be carefully orchestrated to ensure that valid BGPsec UPDATE messages are not treated as invalid. This situation could affect Internet routing. This document describes a safe method for rolling over BGPsec router certificates. It takes into account both normal and emergency key-rollover requirements.

BGPsecに参加しているルーターは、証明書管理の従来の処理の一部として、署名キーをロールオーバーする必要があります。ただし、署名鍵のロールオーバーはBGPsec UPDATEメッセージの署名を無効にする効果もあるため、有効なBGPsec UPDATEメッセージが無効として扱われないように、ロールオーバープロセスを慎重に調整する必要があります。この状況は、インターネットルーティングに影響を与える可能性があります。このドキュメントでは、BGPsecルーター証明書をロールオーバーするための安全な方法について説明します。通常および緊急時の両方のキーロールオーバー要件が考慮されます。

Additionally, the key-rollover method described in this document can be used as a measure to mitigate BGP UPDATE replay attacks, in which an entity in the routing system is suppressing current BGPsec UPDATE messages and replaying withdrawn updates. When the key used to sign the withdrawn updates has been rolled over, the withdrawn updates will be considered invalid. When certificates containing a new public key are provisioned ahead of time, the minimum replay vulnerability window size is reduced to the propagation time of a CRL invalidating the certificate containing an old public key. For a discussion of the difficulties deploying a more effectual replay protection mechanism for BGPSEC, see [PROTECTION-DESIGN-DISCUSSION].

さらに、このドキュメントで説明されているキーロールオーバー方法は、ルーティングシステムのエンティティが現在のBGPsec UPDATEメッセージを抑制し、撤回された更新を再生するBGP UPDATEリプレイ攻撃を緩和する手段として使用できます。撤回された更新の署名に使用されたキーがロールオーバーされた場合、撤回された更新は無効と見なされます。新しい公開キーを含む証明書が事前にプロビジョニングされると、最小の再生脆弱性ウィンドウサイズは、古い公開キーを含む証明書を無効にするCRLの伝播時間まで短縮されます。 BGPSECのより効果的なリプレイ保護メカニズムを展開する難しさの説明については、[PROTECTION-DESIGN-DISCUSSION]を参照してください。

7. References

7. 参考文献

7.1. Normative References

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

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

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, <https://www.rfc-editor.org/info/rfc8635>.

[RFC8635]ブッシュ、R。、ターナー、S。、およびK.パテル、「BGPsecのルーターキーイング」、RFC 8635、DOI 10.17487 / RFC8635、2019年8月、<https://www.rfc-editor.org/info / rfc8635>。

7.2. Informative References

7.2. 参考引用

[PROTECTION-DESIGN-DISCUSSION] Sriram, K. and D. Montgomery, "Design Discussion and Comparison of Protection Mechanisms for Replay Attack and Withdrawal Suppression in BGPsec", Work in Progress, draft-sriram-replay-protection-design-discussion-12, April 2019.

[PROTECTION-DESIGN-DISCUSSION]スリラム、K。、およびD.モンゴメリー、「BGPsecでのリプレイ攻撃と撤退抑制の設計メカニズムと保護メカニズムの比較」、進行中の作業、ドラフト-スリラム-リプレイ-保護-デザイン-ディスカッション- 2019年4月12日。

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.

[RFC6489] Huston、G.、Michaelson、G。、およびS. Kent、「Certification Authority（CA）Key Rollover in the Resource Public Key Infrastructure（RPKI）」、BCP 174、RFC 6489、DOI 10.17487 / RFC6489、February 2012 、<https://www.rfc-editor.org/info/rfc6489>。

[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.

[RFC7030] Pritikin、M。、編、Yee、P。、編、およびD. Harkins、編、「Enrollment over Secure Transport」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：// www.rfc-editor.org/info/rfc7030>。

[RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, DOI 10.17487/RFC7353, August 2014, <https://www.rfc-editor.org/info/rfc7353>.

[RFC7353] Bellovin、S.、Bush、R。、およびD. Ward、「BGPパス検証のセキュリティ要件」、RFC 7353、DOI 10.17487 / RFC7353、2014年8月、<https://www.rfc-editor.org / info / rfc7353>。

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

[RFC8205]レピンスキー、M。、エド。 K. Sriram、編、「BGPsecプロトコル仕様」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8205>。

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

[RFC8207] Bush、R。、「BGPsec Operational Considerations」、BCP 211、RFC 8207、DOI 10.17487 / RFC8207、2017年9月、<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>.

[RFC8210] Bush、R。およびR. Austein、「The Resource Public Key Infrastructure（RPKI）to Router Protocol、Version 1」、RFC 8210、DOI 10.17487 / RFC8210、2017年9月、<https：//www.rfc-editor .org / info / rfc8210>。

Acknowledgments

謝辞

Randy Bush, Kotikalapudi Sriram, Stephen Kent, and Sandy Murphy each provided valuable suggestions resulting in an improved document. Kotikalapudi Sriram contributed valuable guidance regarding the use of key rollovers to mitigate BGP UPDATE replay attacks.

Randy Bush、Kotikalapudi Sriram、Stephen Kent、Sandy Murphyはそれぞれ、価値の高い提案を提供して、ドキュメントを改善しました。 Kotikalapudi Sriramは、BGP UPDATEリプレイ攻撃を軽減するためのキーロールオーバーの使用に関する貴重なガイダンスを提供しました。

Authors' Addresses

著者のアドレス

Brian Weis Independent

ブライアンワイスインディペンデント

   Email: bew.stds@gmail.com

Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, VD 1180 Switzerland

Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle、VD 1180 Switzerland

   Email: rogaglia@cisco.com

Keyur Patel Arrcus, Inc.

Keur Patel Recurs、Inc.

   Email: keyur@arrcus.com