[要約] 要約：RFC 8206は、自律システム（AS）の移行に関するBGPsecの考慮事項を提供するものである。 目的：このRFCの目的は、BGPsecを使用してASの移行をサポートし、セキュリティと信頼性を確保するためのガイダンスを提供することである。
Internet Engineering Task Force (IETF) W. George
Request for Comments: 8206 Neustar
Updates: 8205 S. Murphy
Category: Standards Track PARSONS, Inc.
ISSN: 2070-1721 September 2017
BGPsec Considerations for Autonomous System (AS) Migration
自律システム（AS）の移行に関するBGPsecの考慮事項
Abstract
概要
This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.
このドキュメントでは、BGPsecプロトコル内で自律システム（AS）を移行するための一般的な方法をサポートおよび保護するための考慮事項と方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc8206.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8206で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4
3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Outbound Announcements (PE-->CE) . . . . . . . . . . 5
3.2.2. Inbound Announcements (CE-->PE) . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Outbound (PE-->CE) . . . . . . . . . . . . . . . . . . . 8
5.2. Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . . 8
5.3. Other Considerations . . . . . . . . . . . . . . . . . . 9
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
A method of managing a BGP Autonomous System Number (ASN) migration is described in RFC 7705 [RFC7705]. Since it concerns the handling of AS_PATH attributes, it is necessary to ensure that the process and features are properly supported in BGPsec [RFC8205] because BGPsec is explicitly designed to protect against changes in the BGP AS_PATH, whether by choice, by misconfiguration, or by malicious intent. It is critical that the BGPsec protocol framework be able to support this operationally necessary tool without creating an unacceptable security risk or exploit in the process.
BGP自律システム番号（ASN）の移行を管理する方法は、RFC 7705 [RFC7705]で説明されています。 AS_PATH属性の処理に関係するため、BGPsecは、選択、設定ミス、または設定のいずれによっても、BGP AS_PATHの変更から保護するように明示的に設計されているため、プロセスと機能がBGPsec [RFC8205]で適切にサポートされていることを確認する必要があります。悪意。 BGPsecプロトコルフレームワークが、許容できないセキュリティリスクやプロセスの悪用を引き起こすことなく、この運用上必要なツールをサポートできることが重要です。
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]で説明されているように解釈されます。
This document uses ASNs from the range reserved for documentation as described in RFC 5398 [RFC5398]. In the examples used here, they are intended to represent Globally Unique ASNs, not ASNs reserved for private use as documented in Section 10 of RFC 1930 [RFC1930].
このドキュメントでは、RFC 5398 [RFC5398]で説明されているように、ドキュメント用に予約された範囲のASNを使用します。ここで使用されている例では、RFC 1930 [RFC1930]のセクション10に記載されているように、私的使用のために予約されているASNではなく、グローバルに一意のASNを表すことを意図しています。
This document assumes that the reader has read and understood the ASN migration method discussed in RFC 7705 [RFC7705] including its examples (see Section 2 of the referenced document), as they will be heavily referenced here. The use case being discussed in RFC 7705 [RFC7705] is as follows: For whatever the reason, a provider is in the process of merging two or more ASes, where eventually one subsumes the other(s). BGP AS confederations [RFC5065] are not enabled between the ASes, but a mechanism is being used to modify BGP's default behavior and allow the migrating Provider Edge (PE) router to masquerade as the old ASN for the Provider-Edge-to-Customer-Edge (PE-CE) eBGP (external BGP) session, or to manipulate the AS_PATH, or both. While BGPsec [RFC8205] does have a method to handle standard confederation implementations, it is not applicable in this exact case. This migration requires a slightly different solution in BGPsec than for a standard confederation because unlike in a confederation, eBGP peers may not be peering with the "correct" external ASN, and the forward-signed updates are for a public ASN, rather than a private one; so, there is no expectation that the BGP speaker would strip the affected signatures before propagating the route to its eBGP neighbors.
このドキュメントは、ここで頻繁に参照されるため、読者がその例（参照ドキュメントのセクション2を参照）を含め、RFC 7705 [RFC7705]で説明されているASN移行方法を読んで理解していることを前提としています。 RFC 7705 [RFC7705]で説明されているユースケースは次のとおりです。理由は何であれ、プロバイダーは2つ以上のASをマージする過程にあり、最終的に1つは他を包含します。 BGP ASコンフェデレーション[RFC5065]はAS間で有効になっていませんが、BGPのデフォルトの動作を変更し、移行するプロバイダーエッジ（PE）ルーターがプロバイダーエッジからカスタマーへの古いASNを偽装できるようにするメカニズムが使用されていますエッジ（PE-CE）eBGP（外部BGP）セッション、またはAS_PATHの操作、あるいはその両方。 BGPsec [RFC8205]には標準のコンフェデレーション実装を処理する方法がありますが、この場合には適用できません。コンフェデレーションとは異なり、eBGPピアは「正しい」外部ASNとピアリングしていない可能性があり、転送署名された更新はプライベートではなくパブリックASNを対象としているため、この移行にはBGPsecでの標準コンフェデレーションとは少し異なるソリューションが必要です。 1;そのため、BGPスピーカーがeBGPネイバーにルートを伝播する前に、影響を受けるシグネチャを取り除くことは期待されていません。
In the examples in Section 5.4, AS64510 is being subsumed by AS64500, and both ASNs represent a Service Provider (SP) network (see Figures 1 and 2 in RFC 7705 [RFC7705]). AS64496 and 64499 represent end-customer networks. References to PE, CE, and P routers mirror the diagrams and references in RFC 7705.
セクション5.4の例では、AS64510はAS64500に組み込まれ、両方のASNはサービスプロバイダー（SP）ネットワークを表します（RFC 7705 [RFC7705]の図1および2を参照）。 AS64496および64499はエンドカスタマーネットワークを表します。 PE、CE、およびPルーターへの参照は、RFC 7705の図と参照を反映しています。
The methods and implementation discussed in RFC 7705 [RFC7705] are widely used during network integrations resulting from mergers and acquisitions, as well as network redesigns; therefore, it is necessary to support this capability on any BGPsec-enabled routers/ ASNs. What follows is a discussion of the potential issues to be considered regarding how ASN migration and BGPsec [RFC8205] validation might interact.
RFC 7705 [RFC7705]で説明されている方法と実装は、合併や買収によるネットワーク統合、およびネットワークの再設計中に広く使用されています。したがって、BGPsec対応のルーター/ ASNでこの機能をサポートする必要があります。以下は、ASN移行とBGPsec [RFC8205]検証がどのように相互作用するかに関して考慮すべき潜在的な問題の説明です。
One of the primary considerations for this document and migration is that service providers (SPs) rarely stop after one merger/acquisition/divestiture; they end up accumulating several legacy ASNs over time. Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they do not have as much control over the length of the transition period as they might with something completely under their administrative control (e.g., a key roll). Because they are not forcing a simultaneous migration (i.e., both ends switch to the new ASN at an agreed-upon time), there is no incentive for a given customer to complete the move from the old ASN to the new one. This leaves many SPs with multiple legacy ASNs that don't go away very quickly, if at all. As solutions were being proposed for Resource Public Key Infrastructure (RPKI) implementations to solve this transition case, the WG carefully considered operational complexity and hardware scaling issues associated with maintaining multiple legacy ASN keys on routers throughout the combined network. While SPs who choose to remain in this transition phase indefinitely invite added risks because of the operational complexity and scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network, saying "don't do this" is of limited utility as a solution. As a result, this solution attempts to minimize the additional complexity during the transition period, on the assumption that it will likely be protracted. Note that while this document primarily discusses service provider considerations, it is not solely applicable to SPs, as enterprises often migrate between ASNs using the same functionality. What follows is a discussion of origin and path validation functions and how they interact with ASN migrations.
このドキュメントと移行に関する主な考慮事項の1つは、サービスプロバイダー（SP）が1つの合併/買収/分割後にめったに停止しないことです。最終的には、いくつかのレガシーASNが蓄積されていきます。 SPは顧客に対して透過的であり、顧客との調整を必要としない移行方法を使用しているため、完全に管理上の管理下にあるもの（たとえば、キーロール）のように移行期間の長さを制御することはできません。 ）。彼らは同時移行を強制しない（つまり、両端が合意した時間に新しいASNに切り替える）ため、特定の顧客が古いASNから新しいASNへの移行を完了するインセンティブはありません。これにより、多数のSPに複数のレガシーASNが残されます。この移行ケースを解決するためのリソース公開鍵インフラストラクチャ（RPKI）実装のソリューションが提案されているため、WGは、結合されたネットワーク全体のルーターで複数のレガシーASNキーを維持することに関連する操作の複雑さとハードウェアスケーリングの問題を慎重に検討しました。この移行フェーズに留まることを選択したSPは、結合されたネットワーク全体のルーターで複数のレガシーASNキーを維持することに関連する操作の複雑さとスケーリングの考慮事項のため、無期限に追加のリスクを招きますが、「これを行わない」と言うのは、解決。その結果、このソリューションは、長期化する可能性が高いと想定して、移行期間中の追加の複雑さを最小限に抑えようとします。このドキュメントでは主にサービスプロバイダーの考慮事項について説明しますが、企業は多くの場合同じ機能を使用してASN間を移行するため、SPだけに当てはまるわけではないことに注意してください。次に、オリジンとパスの検証機能と、ASN移行との相互作用について説明します。
Route Origin Validation as defined by RFC 6480 [RFC6480] does not require modification to enable AS migration, as the existing protocol and procedure allow for a solution. In the scenario discussed in RFC 7705 [RFC7705], AS64510 is being replaced by AS64500. If there are any existing routes originated by AS64510 on the router being moved into the new ASN, new Route Origination Authorizations (ROAs) for the routes with the new ASN should be generated, and they should be treated as new routes to be added to AS64500. However, we also need to consider the situation where one or more other PEs are still in AS64510 and are originating one or more routes that may be distinct from any that the router under migration is originating. PE1 (which is now a part of AS64500 and instructed to use "Replace Old AS" as defined in [RFC7705] to remove AS64510 from the path) needs to be able to properly handle routes originated from AS64510. If the route now shows up as originating from AS64500, any downstream peers' validation check will fail unless a ROA is *also* available for AS64500 as the origin ASN. In addition to generating a ROA for 65400 for any prefixes originated by the router being moved, it may be necessary to generate ROAs for 65400 for prefixes that are originating on routers still in 65410, since the AS replacement function will change the origin AS in some cases. This means that there will be multiple ROAs showing different ASes authorized to originate the same prefixes until all routers originating prefixes from AS64510 are migrated to AS64500. Multiple ROAs of this type are permissible per Section 3.2 of RFC 6480 [RFC6480] so managing origin validation during a migration like this is merely applying the defined case where a set of prefixes are originated from more than one ASN. Therefore, for each ROA that authorizes the old ASN (e.g., AS64510) to originate a prefix, a new ROA MUST also be created that authorizes the replacing ASN (e.g., AS64500) to originate the same prefix.
RFC 6480 [RFC6480]で定義されているルートオリジン検証では、既存のプロトコルと手順で解決できるため、AS移行を有効にするための変更は必要ありません。 RFC 7705 [RFC7705]で説明されているシナリオでは、AS64510はAS64500に置き換えられています。新しいASNに移動されるルーター上にAS64510から発信された既存のルートがある場合、新しいASNを持つルートの新しいルート発信許可（ROA）が生成され、AS64500に追加される新しいルートとして扱われる必要があります。 。ただし、他の1つ以上のPEがまだAS64510にあり、移行中のルーターが発信しているものとは異なる可能性がある1つ以上のルートを発信している状況も考慮する必要があります。 PE1（AS64500の一部になり、[RFC7705]で定義されている「古いASを置き換える」を使用してパスからAS64510を削除するように指示された）は、AS64510から発信されたルートを適切に処理できる必要があります。ルートがAS64500から発信されたものとして表示される場合、ROAがAS64500にも発信元ASNとして*利用可能*でない限り、ダウンストリームピアの検証チェックは失敗します。移動されるルーターによって発信されたプレフィックスに対して65400のROAを生成することに加えて、ASの置換機能によって発信元ASが変更されるため、65510にあるルーターで発信されているプレフィックスに対して65400のROAを生成する必要がある場合があります。ケース。これは、AS64510からプレフィックスを発信するすべてのルーターがAS64500に移行されるまで、同じプレフィックスを発信することが許可されたさまざまなASを示す複数のROAが存在することを意味します。このタイプの複数のROAは、RFC 6480 [RFC6480]のセクション3.2で許可されているため、このような移行中のオリジン検証の管理は、一連のプレフィックスが複数のASNから発信されている定義済みのケースを適用するだけです。したがって、古いASN（AS64510など）がプレフィックスを生成することを承認する各ROAについては、置換するASN（AS64500など）が同じプレフィックスを生成することを承認する新しいROAも作成する必要があります。
BGPsec path validation requires that each router in the AS path cryptographically sign its update to assert that "every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path" (see Section 1 of RFC 8205 [RFC8205]). Since the referenced AS-migration technique explicitly modifies the AS_PATH between two eBGP peers who are not coordinating with one another (are not in the same administrative domain), no level of trust can be assumed; therefore, it may be difficult to identify legitimate manipulation of the AS_PATH for migration activities when compared to manipulation due to misconfiguration or malicious intent.
BGPsecパス検証では、ASパス内の各ルーターが更新に暗号で署名し、「UPDATEメッセージにリストされているASのパス上のすべての自律システム（AS）が、パス内の後続のASへのルートのアドバタイズを明示的に承認していることを要求する必要があります。 」（RFC 8205 [RFC8205]のセクション1を参照）。参照されているAS移行技法は、互いに調整していない（同じ管理ドメインに属していない）2つのeBGPピア間のAS_PATHを明示的に変更するため、信頼レベルは想定できません。したがって、構成の誤りや悪意による操作と比較した場合、移行アクティビティのAS_PATHの正当な操作を識別するのは難しい場合があります。
When PE1 is moved from AS64510 to AS64500, it will be provisioned with the appropriate keys for AS64500 to allow it to forward-sign routes using AS64500. However, there is no guidance in the BGPsec protocol specification [RFC8205] on whether or not the forward-signed ASN value is required to match the configured remote AS to validate properly. That is, if CE1's BGP session is configured as "remote AS 64510", the presence of "local AS 64510" on PE1 will ensure that there is no ASN mismatch on the BGP session itself, but if CE1 receives updates from its remote neighbor (PE1) forward-signed from AS64500, there is no guidance as to whether the BGPsec validator on CE1 still considers those valid by default. Section 6.3 of RFC 4271 [RFC4271] mentions this match between the ASN of the peer and the AS_PATH data, but it is listed as an optional validation, rather than a requirement. We cannot assume that this mismatch will be allowed by vendor implementations, so using it as a means to solve this migration case is likely to be problematic.
PE1がAS64510からAS64500に移動されると、AS64500を使用してルートに転送署名できるように、AS64500に適切なキーがプロビジョニングされます。ただし、BGPsecプロトコル仕様[RFC8205]には、構成を検証するために構成されたリモートASと一致するために前方署名されたASN値が必要かどうかについてのガイダンスはありません。つまり、CE1のBGPセッションが「リモートAS 64510」として構成されている場合、PE1に「ローカルAS 64510」が存在すると、BGPセッション自体にASNの不一致がないことが保証されますが、CE1がリモートネイバーから更新を受信した場合（ PE1）AS64500から前方署名された場合、CE1のBGPsecバリデーターがデフォルトで有効であると見なすかどうかに関するガイダンスはありません。 RFC 4271 [RFC4271]のセクション6.3は、ピアのASNとAS_PATHデータの間のこの一致について言及していますが、要件ではなくオプションの検証としてリストされています。この不一致がベンダーの実装によって許可されるとは想定できないため、この移行ケースを解決する手段としてこれを使用すると問題が発生する可能性があります。
Inbound is more complicated, because the CE doesn't know that PE1 has changed ASNs, so it is forward-signing all of its routes with AS64510, not AS64500. The BGPsec speaker cannot manipulate previous signatures and therefore cannot manipulate the previous AS path without causing a mismatch that will invalidate the route. If the updates are simply left intact, the ISP would still need to publish and maintain valid and active public keys for AS 64510 if it is to appear in the BGPsec_PATH signature so that receivers can validate that the BGPsec_PATH signature arrived intact/whole. However, if the updates are left intact, this will cause the AS path length to be increased, which is unacceptable as discussed in RFC 7705 [RFC7705].
PE1がASNを変更したことをCEが認識しないため、CEはAS64500ではなくAS64510ですべてのルートに前方署名しているため、インバウンドはより複雑です。 BGPsecスピーカーは以前のシグネチャを操作できないため、ルートを無効にする不一致を引き起こさずに以前のASパスを操作できません。更新がそのまま残されている場合、BGPsec_PATHシグニチャに表示されるようにするには、ISPはAS 64510の有効かつアクティブな公開キーを公開および維持する必要があるため、受信者はBGPsec_PATHシグニチャが無傷/全体に到着したことを検証できます。ただし、更新をそのままにしておくと、ASパスの長さが長くなり、RFC 7705 [RFC7705]で説明されているように、これは受け入れられません。
In order to be deployable, any solution to the described problem needs to consider the following requirements, listed in no particular order. BGPsec:
展開可能にするために、説明されている問題の解決策は、特定の順序でリストされていない以下の要件を考慮する必要があります。 BGPsec：
o MUST support AS migration for both inbound and outbound route announcements (see Sections 3.2.1 and 3.2.2), without reducing BGPsec's protections for route path.
o ルートパスに対するBGPsecの保護を減らすことなく、インバウンドとアウトバウンドの両方のルートアナウンス（セクション3.2.1および3.2.2を参照）のAS移行をサポートする必要があります。
o MUST NOT require any reconfiguration on the remote eBGP neighbor (CE).
o リモートeBGPネイバー（CE）で再構成を要求してはなりません（MUST NOT）。
o SHOULD NOT require global (i.e., network-wide) configuration changes to support migration. The goal is to limit required configuration changes to the devices (PEs) being migrated.
o 移行をサポートするために、グローバル（つまり、ネットワーク全体）の構成変更を必要としないでください。目標は、移行するデバイス（PE）に必要な構成変更を制限することです。
o MUST NOT lengthen the AS path during migration.
o 移行中はASパスを長くしてはいけません。
o MUST operate within existing trust boundaries, e.g., can't expect remote side to accept pCount=0 (see Section 4.2 of RFC 8205 [RFC8205]) from untrusted/non-confederation neighbor.
o 既存の信頼境界内で動作する必要があります。たとえば、リモート側が信頼されていない/非連合の近隣からのpCount = 0（RFC 8205 [RFC8205]のセクション4.2を参照）を受け入れることを期待できません。
As noted in Section 4.2 of RFC 8205 [RFC8205], BGPsec already has a solution for hiding ASNs where increasing the AS path length is undesirable. So a simple solution would be to retain the keys for AS64510 on PE1 and forward-sign towards CE1 with AS64510 and pCount=0. However, this would mean passing a pCount=0 between two ASNs that are in different administrative and trust domains such that it could represent a significant attack vector to manipulate BGPsec-signed paths. The expectation for legitimate instances of pCount=0 (to make a route server that is not part of the transit path invisible) is that there is some sort of existing trust relationship between the operators of the route server and the downstream peers such that the peers could be explicitly configured by policy to accept pCount=0 announcements only on the sessions where they are expected. For the same reason that things like "Local AS" [RFC7705] are used for ASN migration without end-customer coordination, it is unrealistic to assume any sort of coordination between the SP and the administrators of CE1 to ensure that they will by policy accept pCount=0 signatures during the transition period; therefore, this is not a workable solution.
RFC 8205 [RFC8205]のセクション4.2に記載されているように、BGPsecには、ASパス長の増加が望ましくない場合にASNを非表示にするソリューションがすでにあります。したがって、簡単な解決策は、PE1でAS64510のキーを保持し、AS64510とpCount = 0を使用してCE1にフォワード署名することです。ただし、これは、異なる管理ドメインと信頼ドメインにある2つのASN間でpCount = 0を渡すことを意味し、BGPsec署名付きパスを操作するための重要な攻撃ベクトルを表す可能性があります。中継パスの一部ではないルートサーバーを非表示にするためのpCount = 0の正当なインスタンスの期待は、ピアがルートサーバーのオペレーターとダウンストリームピアの間にある種の既存の信頼関係があることです。期待されるセッションでのみpCount = 0アナウンスを受け入れるように、ポリシーによって明示的に構成できます。 「ローカルAS」[RFC7705]のようなものがエンドカスタマーの調整なしでASN移行に使用されるのと同じ理由で、SPとCE1の管理者の間のあらゆる種類の調整を想定して、それらがポリシーによって確実に受け入れられるようにすることは非現実的です移行期間中のpCount = 0の署名。したがって、これは実行可能なソリューションではありません。
A better solution presents itself when considering how to handle routes coming from the CE toward the PE, where the routes are forward-signed to AS64510, but will eventually need to show AS64500 in the outbound route announcement. Because both AS64500 and AS64510 are in the same administrative domain, a signature from AS64510 forward-signed to AS64500 with pCount=0 would be acceptable as it would be within the appropriate trust boundary so that each BGP speaker could be explicitly configured to accept pCount=0 where appropriate between the two ASNs. At the very simplest, this could potentially be used at the eBGP boundary between the two ASNs during migration. Since the AS_PATH manipulation described above usually happens at the PE router on a per-session basis and does not happen network-wide simultaneously, it is not generally appropriate to apply this AS-hiding technique across all routes exchanged between the two ASNs, as it may result in routing loops and other undesirable behavior. Therefore, the most appropriate place to implement this is on the local PE that still has eBGP sessions with peers expecting to peer with AS64510 (using the transition mechanisms detailed in RFC 7705 [RFC7705]). Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPsec behavior to address this use case.
CEからPEに向かうルートを処理する方法を検討する場合、より良いソリューションが提示されます。ルートはAS64510にフォワード署名されますが、最終的にはアウトバウンドルートアナウンスでAS64500を示す必要があります。 AS64500とAS64510の両方が同じ管理ドメインにあるため、適切な信頼境界内にあり、pCOUNT =を受け入れるように各BGPスピーカーを明示的に構成できるため、AS64510からpCount = 0でAS64500に前方署名された署名は許容されます。 2つのASN間で適切な場合は0。非常に簡単に言えば、これは移行中に2つのASN間のeBGP境界で使用される可能性があります。上記のAS_PATH操作は通常、セッションごとにPEルータで発生し、ネットワーク全体で同時に発生しないため、2つのASN間で交換されるすべてのルートにこのAS非表示技術を適用することは一般的に適切ではありません。ルーティングループやその他の望ましくない動作が発生する可能性があります。したがって、これを実装する最も適切な場所は、AS64510とピアリングすることを期待しているピアとのeBGPセッションがまだあるローカルPEです（RFC 7705 [RFC7705]で詳述されている移行メカニズムを使用）。そのPEはAS64500に移動されているため、このユースケースに対処するためにBGPsecの動作を少し変更しない限り、pCount = 0でAS64510に前方署名することはできません。
AS migration is using AS_PATH and remote AS manipulation to act as if a PE under migration exists simultaneously in both ASNs even though it is only configured with one global ASN. This document describes applying a similar technique to the BGPsec signatures generated for routing updates processed through this migration machinery. Each routing update that is received from or destined to an eBGP neighbor that is still using the old ASN (64510) will be signed twice, once with the ASN to be hidden and once with the ASN that will remain visible. In essence, we are treating the update as if the PE had an internal BGP hop and the update was passed across an eBGP session between AS64500 and AS64510, configured to use and accept pCount=0, while eliminating the processing and storage overhead of creating an actual eBGP session between the two ASNs within the PE router. This will result in a properly secured AS path in the affected route updates, because the PE router will be provisioned with valid keys for both AS64500 and AS64510. An important distinction here is that while AS migration under standard BGP4 is manipulating the AS_PATH attribute, BGPsec uses an attribute called the "Secure_Path" (see Section 3.1 of RFC 8205 [RFC8205]) and BGPsec-capable neighbors do not exchange AS_PATH information in their route announcements. However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor will use the information found in the Secure_Path to reconstruct a standard AS_PATH for updates sent to that neighbor. Unlike in the Secure_Path where the ASN to be hidden is still present but ignored when considering the AS path (due to pCount=0), when reconstructing an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not appear in the AS_PATH at all (see Section 4.4 of RFC 8205 [RFC8205]). This document is not changing existing AS_PATH reconstruction behavior, merely highlighting it for clarity.
ASマイグレーションは、AS_PATHおよびリモートAS操作を使用して、1つのグローバルASNのみで構成されている場合でも、移行中のPEが両方のASNに同時に存在するかのように動作します。このドキュメントでは、この移行機構によって処理されるルーティング更新用に生成されたBGPsecシグネチャに同様の手法を適用することについて説明します。まだ古いASN（64510）を使用しているeBGPネイバーとの間で送受信される各ルーティングアップデートは、2回署名されます。基本的に、PEに内部BGPホップがあり、更新がAS64500とAS64510の間のeBGPセッションに渡され、pCount = 0を使用して受け入れるように構成されているかのように更新を処理します。 PEルータ内の2つのASN間の実際のeBGPセッション。これにより、影響を受けるルートアップデートでASパスが適切に保護されます。これは、PEルーターがAS64500とAS64510の両方の有効なキーでプロビジョニングされるためです。ここでの重要な違いは、標準のBGP4でのAS移行がAS_PATH属性を操作している間、BGPsecは「Secure_Path」と呼ばれる属性を使用し（RFC 8205 [RFC8205]のセクション3.1を参照）、BGPsec対応のネイバーがAS_PATH情報を交換しないことです。ルートアナウンス。ただし、BGPsec非対応ネイバーとピアリングするBGPsecネイバーは、Secure_Pathにある情報を使用して、そのネイバーに送信される更新の標準AS_PATHを再構築します。非表示にするASNがまだ存在するが、ASパスを検討するときに無視されるSecure_Pathとは異なり（pCount = 0のため）、非BGPsecネイバーのAS_PATHを再構築すると、pCount = 0 ASNはAS_PATHに表示されません。まったく（RFC 8205 [RFC8205]のセクション4.4を参照）。このドキュメントは、既存のAS_PATH再構築動作を変更するものではなく、明確にするために強調表示しているだけです。
The procedure to support AS migration in BGPsec is slightly different depending on whether the PE under migration is receiving the routes from one of its eBGP peers ("inbound" as in Section 3.2.2) or destined toward the eBGP peers ("outbound" as in Section 3.2.1).
BGPsecでAS移行をサポートする手順は、移行中のPEがeBGPピアの1つからルートを受信するか（セクション3.2.2の「インバウンド」）、eBGPピアに向かう（「アウトバウンド」として）かによって少し異なります。セクション3.2.1）。
When a PE router receives an update destined for an eBGP neighbor that is locally configured with AS-migration mechanisms as discussed in RFC 7705 [RFC7705], it MUST generate a valid BGPsec signature as defined in RFC 8205 [RFC8205] for _both_ configured ASNs. It MUST generate a signature from the new (global) ASN forward-signing to the old (local) ASN with pCount=0, and then it MUST generate a forward signature from the old (local) ASN to the target eBGP ASN with pCount=1 as normal.
PEルーターは、RFC 7705 [RFC7705]で説明されているように、AS移行メカニズムでローカルに構成されたeBGPネイバー宛ての更新を受信すると、_both_構成されたASNに対してRFC 8205 [RFC8205]で定義されている有効なBGPsec署名を生成する必要があります。新しい（グローバル）ASNからpCount = 0の古い（ローカル）ASNへのフォワード署名の署名を生成する必要があり、その後、古い（ローカル）ASNからpCount =のターゲットeBGP ASNへのフォワード署名を生成する必要があります。通常どおり1。
When a PE router receives an update from an eBGP neighbor that is locally configured with AS-migration mechanisms (i.e., the opposite direction of the previous route flow), it MUST generate a signature from the old (local) ASN forward-signing to the new (global) ASN with pCount=0. It is not necessary to generate the second signature from the new (global) ASN because the Autonomous System Border Router (ASBR) will generate that when it forward-signs towards its eBGP peers as defined in normal BGPsec operation. Note that a signature is not normally added when a routing update is sent across an iBGP (internal BGP) session. The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration scenario only.
PEルーターは、AS移行メカニズムでローカルに構成されたeBGPネイバーから更新を受信すると（つまり、前のルートフローの反対方向）、古い（ローカル）ASNからへの署名を生成しなければなりません（MUST）。 pCount = 0の新しい（グローバル）ASN。 Autonomous System Border Router（ASBR）は、通常のBGPsec操作で定義されているようにeBGPピアにフォワード署名するときにそれを生成するため、新しい（グローバル）ASNから2番目の署名を生成する必要はありません。ルーティングアップデートがiBGP（内部BGP）セッションを介して送信される場合、署名は通常追加されないことに注意してください。 iBGPで更新に署名する要件は、この特定のAS移行シナリオのみの通常の動作への変更を表します。
In the inbound case discussed in Section 5.2, the PE is adding BGPsec attributes to routes received from or destined to an iBGP neighbor and using pCount=0 to mask them. While this is not prohibited by BGPsec [RFC8205], BGPsec-capable routers that receive updates from BGPsec-enabled iBGP neighbors MUST accept updates with new (properly formed) BGPsec attributes, including the presence of pCount=0 on a previous signature, or they will interfere with this method. In a similar fashion, any BGPsec-capable route-reflectors in the path of these updates MUST reflect them transparently to their BGPsec-capable clients.
セクション5.2で説明したインバウンドの場合、PEは、BGPsec属性をiBGPネイバーから受信または宛先するルートに追加し、pCount = 0を使用してそれらをマスクします。これはBGPsec [RFC8205]で禁止されていませんが、BGPsec対応のiBGPネイバーから更新を受信するBGPsec対応ルーターは、新しい（適切に形成された）BGPsec属性を持つ更新を受け入れる必要があります。このメソッドを妨害します。同様に、これらのアップデートのパスにあるBGPsec対応のルートリフレクタは、BGPsec対応のクライアントに透過的に反映する必要があります。
In order to secure this set of signatures, the PE router MUST be provisioned with valid keys for _both_ configured ASNs (old and new), and the key for the old ASN MUST be kept valid until all eBGP sessions are migrated to the new ASN. Downstream neighbors will see this as a valid BGPsec path, as they will simply trust that their upstream neighbor accepted pCount=0 because it was explicitly configured to do so based on a trust relationship and business relationship between the upstream and its neighbor (the old and new ASNs).
この一連のシグネチャを保護するには、PEルーターに_both_設定されたASN（古いものと新しいもの）の有効なキーをプロビジョニングする必要があり、古いASNのキーは、すべてのeBGPセッションが新しいASNに移行されるまで有効に保つ必要があります。ダウンストリームネイバーはこれを有効なBGPsecパスとして認識します。なぜなら、アップストリームとネイバーの間の信頼関係とビジネス関係に基づいて明示的に設定されているため、上流ネイバーがpCount = 0を受け入れたことを単に信頼するからです。新しいASN）。
Additionally, Section 4 of RFC 7705 [RFC7705] discusses methods in which AS migrations can be completed for iBGP peers such that a session between two routers will be treated as iBGP even if the neighbor ASN is not the same ASN on each peer's global configuration. As far as BGPsec is concerned, this requires the same procedure as when the routers migrating are applying AS-migration mechanisms to eBGP peers, but the router functioning as the "ASBR" between old and new ASN is different. In eBGP, the router being migrated has direct eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before passing the update along to additional routers in its global (new) ASN. In iBGP, the router being migrated is receiving updates (that may have originated either from eBGP neighbors or other iBGP neighbors) from its downstream neighbors in the old ASN and MUST sign those updates from old ASN to new with pCount=0 before sending them on to other peers.
さらに、RFC 7705 [RFC7705]のセクション4では、2つのルーター間のセッションが各ピアのグローバル構成で同じASNでない場合でも、2つのルーター間のセッションがiBGPとして扱われるように、ASの移行を完了できる方法について説明しています。 BGPsecに関しては、移行するルーターがAS移行メカニズムをeBGPピアに適用する場合と同じ手順が必要ですが、新旧のASN間で「ASBR」として機能するルーターは異なります。 eBGPでは、移行されるルーターは古いASNへの直接のeBGPセッションを持ち、更新をグローバル（新しい）ASNの追加のルーターに渡す前に、pCount = 0で古いASNから新しいASNに署名します。 iBGPでは、移行中のルータは、古いASNのダウンストリームネイバーから更新（eBGPネイバーまたは他のiBGPネイバーから発信された可能性がある）を受信しており、それらを更新する前に、古いASNから新しいASNへの更新にpCount = 0で署名する必要があります他のピアに。
The following example will illustrate the method being used above. As with previous examples, PE1 is the router being migrated, AS64510 is the old ASN, which is being subsumed by AS64500, the ASN to be permanently retained. 64505 is another external peer, used to demonstrate what the announcements will look like to a third-party peer that is not part of the migration. Some additional notation is used to delineate the details of each signature as follows: The origin BGPsec Signature Segment takes the form: sig(Target ASN, (pCount,...,Origin ASN), NLRI) key.
次の例は、上記で使用されている方法を示しています。前の例と同様に、PE1は移行中のルーター、AS64510は古いASNであり、AS64500に組み込まれ、ASNは永続的に保持されます。 64505は別の外部ピアであり、移行の一部ではないサードパーティのピアに対してアナウンスがどのように見えるかを示すために使用されます。いくつかの追加表記を使用して、各署名の詳細を次のように記述します。元のBGPsec署名セグメントは、sig（Target ASN、（pCount、...、Origin ASN）、NLRI）キーの形式を取ります。
Intermediate BGPsec Signature Segments take the form: sig(Target ASN,...,(pCount,...,Signer ASN),...,NLRI) key.
中間BGPsec署名セグメントは、sig（Target ASN、...、（pCount、...、Signer ASN）、...、NLRI）キーの形式を取ります。
(pCount,...,ASN) refers to the new Secure_Path Segment added to the BGPsec_PATH attribute by the ASN (Origin ASN or Signer ASN).
（pCount、...、ASN）は、ASN（Origin ASNまたはSigner ASN）によってBGPsec_PATH属性に追加された新しいSecure_Pathセグメントを指します。
"Equivalent AS_PATH" refers to what the AS_PATH would look like if it was reconstructed to be sent to a non-BGPsec peer, while the Securedpath shows the AS path as represented between BGPsec peers.
「同等のAS_PATH」は、非BGPsecピアに送信されるように再構築された場合のAS_PATHを示しますが、Securedpathは、BGPsecピア間で表されるASパスを示します。
Note: The representation of Signature Segment generation is being simplified here somewhat for the sake of brevity; the actual details of the signing process are as described in Sections 4.1 and 4.2 of [RFC8205]. For example, what is covered by the signature also includes Flags, Algorithm Suite Identifier, NLRI length, etc. Also, the key is not carried in the update; instead, the Subject Key Identifier (SKI) is carried.
注：ここでは、簡潔にするために、署名セグメント生成の表現を多少簡略化しています。署名プロセスの実際の詳細は、[RFC8205]のセクション4.1および4.2で説明されています。たとえば、署名でカバーされるものには、フラグ、アルゴリズムスイート識別子、NLRI長さなども含まれます。また、キーは更新に含まれていません。代わりに、Subject Key Identifier（SKI）が使用されます。
Before Merger
合併前
64505
|
ISP B ISP A
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH= (64510,64500,64499)
Securedpath=(64510,64500,64499)
length=sum(pCount)=3
Migrating, route flow outbound PE-1 to CE-1
移行、ルートフローのアウトバウンドPE-1からCE-1へ
64505
|
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64500, (pCount=1,...,64499), N)K_64499-CE2 Equivalent AS_PATH=(64499) Securedpath=(64499) length=sum(pCount)=1 #PE-2 sends to PE-1 (in iBGP) the exact same update #as it received from AS64499.
PE-2からPE-1へ：sig（64500、（pCount = 1、...、64499）、N）K_64499-CE2同等のAS_PATH =（64499）Securedpath =（64499）length = sum（pCount）= 1 #PE -2は、AS64499から受信したものとまったく同じ更新を＃iBGPでPE-1に送信します。
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64510,64499)
Securedpath=(64510, 64500 (pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3)
#PE-1 adds the Secure_Path Segment in (*) acting as AS64500
#PE-1 accepts (*) with pCount=0 acting as AS64510,
#as it would if it received (*) from an eBGP peer
Migrating, route flow inbound CE-1 to PE-1
移行、ルートフローインバウンドCE-1からPE-1へ
64505
|
ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-1 to PE-1: sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64496)
length=sum(pCount)=1
PE-1 to PE-2: sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2)
#PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
RFC 7705 [RFC7705] discusses a process by which one ASN is migrated into and subsumed by another. Because this process involves manipulating the AS_Path in a BGP route to make it deviate from the actual path that it took through the network, this migration process is attempting to do exactly what BGPsec is working to prevent. BGPsec MUST be able to manage this legitimate use of AS_Path manipulation without generating a vulnerability in the RPKI route security infrastructure, and this document was written to define the method by which the protocol can meet this need.
RFC 7705 [RFC7705]は、あるASNが別のASNに移行され、別のASNに包含されるプロセスについて説明しています。このプロセスでは、BGPルートのAS_Pathを操作して、ネットワークを通過した実際のパスから逸脱させるため、この移行プロセスは、BGPsecが防止するために機能していることを正確に実行しようとしています。 BGPsecは、RPKIルートセキュリティインフラストラクチャに脆弱性を生成することなく、AS_Path操作の正当な使用を管理できなければならず（MUST）、このドキュメントは、プロトコルがこのニーズを満たす方法を定義するために書かれました。
The solution discussed above is considered to be reasonably secure from exploitation by a malicious actor because it requires both signatures to be secured as if they were forward-signed between two eBGP neighbors. This requires any router using this solution to be provisioned with valid keys for both the migrated and subsumed ASN so that it can generate valid signatures for each of the two ASNs it is adding to the path. If the AS's keys are compromised, or zero-length keys are permitted, this does potentially enable an AS_PATH shortening attack, but these are existing security risks for BGPsec.
上記のソリューションは、2つのeBGPネイバー間で前方署名されているかのように両方の署名を保護する必要があるため、悪意のある攻撃者による悪用からかなり安全であると見なされています。パスに追加する2つのASNのそれぞれに有効な署名を生成できるように、このソリューションを使用するルーターには、移行したASNと包含されたASNの両方に有効なキーをプロビジョニングする必要があります。 ASのキーが危険にさらされている場合、または長さがゼロのキーが許可されている場合、これは潜在的にAS_PATH短縮攻撃を有効にしますが、これらはBGPsecの既存のセキュリティリスクです。
[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>。
[RFC7705] George, W. and S. Amante, "Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, <https://www.rfc-editor.org/info/rfc7705>.
[RFC7705]ジョージW.およびS.アマンテ、「自律システム移行メカニズムとBGP AS_PATH属性への影響」、RFC 7705、DOI 10.17487 / RFC7705、2015年11月、<https://www.rfc-editor.org / info / rfc7705>。
[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>。
[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/rfc8105>.
[RFC8205]レピンスキー、M。、エド。 K. Sriram、Ed。、「BGPsec Protocol Specification」、RFC 8205、DOI 10.17487 / RFC8205、2017年9月、<https://www.rfc-editor.org/info/rfc8105>。
[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>.
[RFC1930] Hawkinson、J。およびT. Bates、「自律システム（AS）の作成、選択、および登録に関するガイドライン」、BCP 6、RFC 1930、DOI 10.17487 / RFC1930、1996年3月、<https：// www .rfc-editor.org / info / rfc1930>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.
[RFC5065] Traina、P.、McPherson、D。、およびJ. Scudder、「BGPの自律システム連合」、RFC 5065、DOI 10.17487 / RFC5065、2007年8月、<https://www.rfc-editor.org/ info / rfc5065>。
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC5398] Huston、G。、「Autonomous System（AS）Number Reservation for Documentation Use」、RFC 5398、DOI 10.17487 / RFC5398、2008年12月、<https://www.rfc-editor.org/info/rfc5398>。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487 / RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480> 。
Acknowledgements
謝辞
Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their review comments.
レビューコメントを提供してくれたKotikalapudi Sriram、Shane Amante、Warren Kumari、Terry Manderson、Keyur Patel、Alia Atlas、Alvaro Retanaに感謝します。
The authors particularly wish to acknowledge Kotikalapudi Sriram, Oliver Borchert, and Michael Baer for their review and suggestions for the examples in Section 5.4, which made an important contribution to the quality of the text.
著者は特に、テキストの品質に重要な貢献をしたセクション5.4の例のレビューと提案について、Kotikalapudi Sriram、Oliver Borchert、およびMichael Baerに感謝します。
Additionally, the solution presented in this document is an amalgam of several Secure Inter-Domain Routing (SIDR) interim meeting discussions plus a discussion at IETF 85, collected and articulated thanks to Sandy Murphy.
さらに、このドキュメントで紹介するソリューションは、いくつかのセキュアドメイン間ルーティング（SIDR）の中間会議の議論に加えて、サンディマーフィーのおかげで収集され、明確に表現されたIETF 85での議論の融合です。
Authors' Addresses
著者のアドレス
Wesley George Neustar 45980 Center Oak Plaza Sterling, VA 20166 United States of America
ウェズリージョージノイスター45980センターオークプラザスターリング、バージニア州20166アメリカ合衆国
Email: wesgeorge@puck.nether.net
Sandy Murphy PARSONS, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 United States of America
Sandy Murphy PARSONS、Inc. 7110サミュエルモースドライブコロンビア、MD 21046アメリカ合衆国
Phone: +1 443-430-8000
Email: sandy@tislabs.com