[要約] 要約：RFC 6382は、グローバルに任意の場所に配置されたサービスのためのユニークな起源の自律システム番号（ASN）の割り当てに関するガイドラインです。 目的：このRFCの目的は、グローバルに配置されたサービスのASNの割り当てに関する一貫性と一意性を確保することです。
Internet Engineering Task Force (IETF) D. McPherson
Request for Comments: 6382 R. Donnelly
BCP: 169 F. Scalzo
Category: Best Current Practice Verisign, Inc.
ISSN: 2070-1721 October 2011
Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services
グローバルにAnycasted Servicesのノードごとに一意のオリジン自律システム番号（ASNS）
Abstract
概要
This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment.
このドキュメントでは、特定の任意のプレフィックスにルーティングシステム識別器を提供するために、グローバルに任意の重要なインフラストラクチャサービスにノードごとに一意のオリジン自律システム番号（ASNS）の使用に関する推奨事項を作成します。ネットワーク管理と監視手法、またはその他の運用メカニズムは、この新しい判別器を、運用環境に最もよく対応するどんな方法でも採用する場合があります。
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6382.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6382で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Recommendation for Unique Origin ASNs ...........................5
4. Additional Recommendations for Globally Anycasted Services ......6
5. Security Considerations .........................................7
6. Deployment Considerations .......................................7
7. Acknowledgements ................................................9
8. IANA Considerations .............................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
IP anycasting [RFC4786] has been deployed for an array of network services since the early 1990s. It provides a mechanism for a given network resource to be available in a more distributed manner, locally and/or globally, with a more robust and resilient footprint, commonly yielding better localization and absorption of systemic query loads, as well as better protections in the face of distributed denial-of-service (DDoS) attacks, network partitions, and other similar incidents. A large part of the Internet root DNS infrastructure, as well as many other resources, has been anycasted for nearly a decade.
IP AnyCasting [RFC4786]は、1990年代初頭からネットワークサービスの配列用に展開されています。これは、特定のネットワークリソースが、より堅牢で回復力のあるフットプリントを備えた、より堅牢で回復力のあるフットプリントを備えた、より分散した方法で利用できるようにするメカニズムを提供します。分配されたサービス拒否（DDO）攻撃、ネットワークパーティション、およびその他の同様のインシデントの顔。インターネットルートDNSインフラストラクチャの大部分と、他の多くのリソースは、10年近くにわたって何度も獲得されてきました。
While the benefits realized by anycasting network services is proven, some issues do emerge with asserting routing system reachability for a common network identifier from multiple locations. Specifically, anycasting in BGP requires injection of reachability information in the routing system for a common IP address prefix from multiple locations. These anycasted prefixes and network services have traditionally employed a common origin autonomous system number (ASN) in order to preserve historically scarce 16-bit AS number space utilized by BGP for routing domain identifiers in the global routing system. Additionally, a common origin AS number was used in order to ease management overhead of resource operations associated with acquiring and maintaining multiple discrete AS numbers as well as to avoid triggering various operations-oriented reporting functions aimed at identifying "inconsistent origin AS announcements" observed in the routing system. As a result, the representation of routing system path attributes associated with those service instances, and that anycasted prefix itself, typically bear no per-instance discriminators in the routing system (i.e., within the network control plane itself).
AnyCasting Network Servicesによって実現される利点は証明されていますが、複数の場所からの共通ネットワーク識別子のルーティングシステムの到達可能性を主張することで、いくつかの問題が明らかになります。具体的には、BGPのAnycastingには、複数の場所からの一般的なIPアドレスプレフィックスについて、ルーティングシステムに到達可能な情報を注入する必要があります。これらの任意の任意のプレフィックスとネットワークサービスは、従来、グローバルルーティングシステムのルーティングドメイン識別子にBGPが使用する数値スペースとして歴史的に希少な16ビットとして歴史的に希少な16ビットを維持するために、従来、共通のオリジンの自律システム番号（ASN）を採用していました。さらに、数字として複数の個別の維持と維持に関連するリソース操作の管理オーバーヘッドを容易にするために、「アナウンスとして一貫性のない起源を発表」することを目的としたさまざまな操作指向のレポート機能のトリガーを避けるために、数としての共通の起源が使用されました。ルーティングシステム。その結果、それらのサービスインスタンスに関連付けられたルーティングシステムパス属性の表現、およびAnyCasted Prefix自体の表現は、通常、ルーティングシステム（つまり、ネットワークコントロールプレーン自体内）にインスタンスごとの判別器を担保していません。
Service-level query capabilities may or may not provide a mechanism to identify which anycast node responded to a particular query, although this is likely both service (e.g., DNS or NTP) and implementation dependent. For example, Name Server Daemon (NSD), Unbound, and BIND all provide 'hostname.bind or hostname.id' [RFC4892] [RFC5001] query support that enables service-level identification of a given server. Tools such as traceroute are also used to determine to which location a given query is being routed, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular, when multiple servers within an anycast node are connected to a single IP router. When utilizing these service-level capabilities, query responses are typically both deterministic and inherently topology dependent; however, these service-level identifiers at the data plane provide no control plane (routing system) uniqueness.
サービスレベルのクエリ機能は、特定のクエリに応答したAnycastノードを識別するメカニズムを提供する場合と提供しない場合がありますが、これはおそらくサービス（DNSまたはNTPなど）と実装依存の両方です。たとえば、Name Server Daemon（NSD）、Unbound、およびBindはすべて、hostname.bindまたはhostname.id '[rfc4892] [rfc4892] [rfc5001]クエリサポートを提供するサポートを提供します。 Tracerouteなどのツールは、特定のクエリがルーティングされている場所を決定するためにも使用されますが、ローカルスコープのAnycastインスタンスが表示されない場合があります。特に、Anycastノード内の複数のサーバーが単一のIPルーターに接続されている場合、クエリ。これらのサービスレベルの機能を利用する場合、クエリ応答は通常、決定論的であり、本質的にトポロジに依存します。ただし、データプレーンのこれらのサービスレベルの識別子は、制御プレーン（ルーティングシステム）の独自性を提供しません。
As more services are globally anycasted, and existing anycasted services realize wider deployment of anycast nodes for a given service address in order to accommodate growing system loads, the difficulty of providing safeguards and controls to better protect those resources expands. Intuitively, the more widely distributed a given anycasted service address is, the more difficult it becomes for network operators to detect operational and security issues that affect that service. Some examples of such security and operational issues include BGP route leaks affecting the anycasted service, rogue anycast nodes appearing for the service, or the emergence of other aberrant behavior in either the routing system, the forward query datapath, or query response datapath. Diagnosis of the routing system issues is complicated by the fact that no unique discriminators exist in the routing system to identify a given local or global anycast node. Furthermore, both datapath and routing system problem identification is compounded by the fact that these incident types can be topologically dependent, and only observable between a given client-server set.
より多くのサービスがグローバルにアニカストされており、既存のAnycastサービスは、成長するシステム負荷に対応するために、特定のサービスアドレスのAnycastノードの幅広い展開を実現しています。直感的には、特定のAnycastedサービスアドレスがより広く分散されるほど、ネットワークオペレーターがそのサービスに影響を与える運用およびセキュリティの問題を検出することはより困難になります。このようなセキュリティおよび運用上の問題のいくつかの例には、Anycasted Serviceに影響を与えるBGPルートリーク、サービスに表示されるRogue Anycastノード、またはルーティングシステム、フォワードクエリデータパス、またはクエリ応答データパスのいずれかにおける他の異常な動作の出現が含まれます。ルーティングシステムの問題の診断は、ルーティングシステムに特定のローカルまたはグローバルなアニカストノードを識別するためのユニークな判別器が存在しないという事実によって複雑になります。さらに、データパスとルーティングシステムの問題識別の両方は、これらのインシデントタイプがトポロジー的に依存し、特定のクライアントサーバーセットの間でのみ観察可能であるという事実によって悪化します。
Additionally, while it goes without saying that many anycasted services strive for exact synchronization across all instances of an anycasted service address, if local policies or data plane response manipulation techniques were to "influence" responses within a given region in such a way that those responses are no longer authentic or that they diverge from what other nodes within an anycasted service were providing, then it should be an absolute necessity that those modified resources only be utilized by service consumers within that region or influencer's jurisdiction.
さらに、多くのakycastedサービスが、キャストされたサービスアドレスのすべてのインスタンスにわたって正確な同期を求めていることは言うまでもありませんが、ローカルポリシーまたはデータプレーンの対応操作手法が、それらの応答のような方法で特定の領域内の応答に「影響を与える」ことがあった場合もはや本物ではない、またはそれらがアーカストサービス内の他のノードが提供しているものから分岐することは、それらの変更されたリソースがその地域またはインフルエンサーの管轄区域内のサービス消費者のみが利用することが絶対に必要であるはずです。
Mechanisms should exist at both the network- and service-layer to make it abundantly apparent to operators and users alike whether any of the query responses are not authentic. For DNS, DNSSEC [RFC4033] provides this capability at the service layer with object-level integrity, assuming validation is being performed by recursive name servers, and DNSSEC deployment at the root and top-level domain (TLD) levels is well underway [DNSSEC-DEPLOY]. Furthermore, control plane discriminators should exist to enable operators to know toward which of a given set of instances a query is being directed, and to enable detection and alerting capabilities when this changes. Such discriminators may also be employed to enable anycast node preference or filtering keys, should local operational policy require it.
メカニズムは、ネットワークとサービス層の両方に存在する必要があり、クエリ応答のいずれかが本物ではないかどうかをオペレーターとユーザーに豊富に明らかにする必要があります。DNSの場合、DNSSEC [RFC4033]は、オブジェクトレベルの整合性を持つサービスレイヤーでこの機能を提供します。これは、再帰名サーバーによって検証が実行され、DNSSEC展開がルートレベルおよびトップレベルドメイン（TLD）レベルでは十分に過程であると仮定しています[DNSSECECECEC-配備]。さらに、制御プレーンの識別器は、オペレーターが特定の一連のインスタンスのどのセットが指示されているかを知ることができるようにし、これが変更されたときに検出と警告機能を有効にすることを可能にする必要があります。このような判別器は、ローカルな運用ポリシーがそれを必要とする場合、Anycastノードの優先順位またはフィルタリングキーを有効にするために採用される場合があります。
This document employs much of the following terminology, which was taken in full from Section 2 of [RFC4786].
この文書は、次の用語の多くを採用しており、[RFC4786]のセクション2から完全に取得されました。
Service Address: an IP address associated with a particular service (e.g., the destination address used by DNS resolvers to reach a particular authority server).
サービスアドレス：特定のサービスに関連付けられたIPアドレス（例：DNSリゾルバーが特定の機関サーバーに到達するために使用される宛先アドレス）。
Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations.
Anycast：特定のサービスアドレスを複数の個別の自律的な場所で利用できるようにする慣行など、送信されたデータグラムがいくつかの利用可能な場所の1つにルーティングされます。
Anycast Node: an internally-connected collection of hosts and routers that together provide service for an anycast Service Address. An Anycast Node might be as simple as a single host participating in a routing system with adjacent routers, or it might include a number of hosts connected in some more elaborate fashion; in either case, to the routing system across which the service is being anycast, each Anycast Node presents a unique path to the Service Address. The entire anycast system for the service consists of two or more separate Anycast Nodes.
Anycastノード：HostsとRouterの内部に接続されたコレクションは、Anycastサービスアドレスにサービスを提供します。Anycastノードは、隣接するルーターを備えたルーティングシステムに参加する単一のホストと同じくらい簡単かもしれません。または、いくつかの精巧な方法で接続された多くのホストが含まれる場合があります。どちらの場合でも、サービスがAnycastであるルーティングシステムに、各Anycastノードはサービスアドレスへの一意のパスを提示します。サービスのAnycastシステム全体は、2つ以上の別々のAnycastノードで構成されています。
Catchment: in physical geography, an area drained by a river, also known as a drainage basin. By analogy, as used in this document, the topological region of a network within which packets directed at an Anycast Address are routed to one particular node.
集水域：物理的な地理では、川で排水された地域で、排水盆地としても知られています。類推により、このドキュメントで使用されているように、Anycastアドレスに向けられたパケットが特定のノードにルーティングされるネットワークのトポロジ領域。
Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system.
Local-Scope Anycast：AnycastサービスアドレスのReachability情報は、特定のAnycastノードがルーティングシステム全体のサブセットにのみ表示されるように、ルーティングシステムを介して伝播されます。
Local Node: an Anycast Node providing service using a Local-Scope Anycast Address.
ローカルノード：ローカルスコープAnycastアドレスを使用してサービスを提供するAnycastノード。
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
グローバルノード：グローバルスコープAnycastアドレスを使用してサービスを提供するAnycastノード。
Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system.
Global-Scope Anycast：AnycastサービスアドレスのReachability情報は、特定のAnycastノードがルーティングシステム全体に潜在的に表示できるように、ルーティングシステムを介して伝播されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In order to be able to better detect changes to routing information associated with critical anycasted resources, globally anycasted services with partitioned origin ASNs SHOULD utilize a unique origin ASN per node where possible, if appropriate in their operating environment and service model.
重要なAnycastedリソースに関連付けられたルーティング情報の変更をより適切に検出できるようにするために、操作環境とサービスモデルで適切な場合は、可能であれば、可能であればノードごとに一意のオリジンASNを使用して、グローバルにAnycasted Servicesを使用してグローバルにキャストされたサービスが必要です。
Discrete origin ASNs per node provide a discriminator in the routing system that would enable detection of leaked or hijacked instances more quickly and would enable operators that so choose to proactively develop routing policies that express preferences or avoidance for a given node or set of nodes associated with an anycasted service. This is particularly useful when it is observed that local policy or known issues exist with the performance or authenticity of responses returned from a specific anycast node, or that enacted policies meant to affect service within a particular region are affecting users outside of that region as a result of a given anycast catchment expanding beyond its intended scope.
ノードあたりの離散オリジンASNSは、ルーティングシステムで、リークまたはハイジャックされたインスタンスをより迅速に検出できるようにするため、特定のノードまたは回避を表現するルーティングポリシーまたは回避を表現するルーティングポリシーを積極的に開発できるようにするオペレーターを可能にするルーティングシステムで判別器を提供します。Anycastedサービス。これは、特定のAnycastノードから返された応答のパフォーマンスまたは信頼性に伴うローカルポリシーまたは既知の問題が存在する場合、または特定の地域内のサービスに影響を与えることを目的としたポリシーが、その地域以外のユーザーに影響を与えていることが、その地域以外のユーザーに影響を与えていることが特に役立ちます。特定のAnycast集水域が意図した範囲を超えて拡大した結果。
Furthermore, inconsistent origin AS announcements associated with anycasted services for critical infrastructure SHOULD NOT be deemed undesirable by routing system reporting functions, but should instead be embraced in order to better identify the connectedness and footprint of a given anycasted service.
さらに、重要なインフラストラクチャの任意のキャストされたサービスに関連するアナウンスとしての一貫性のない起源は、ルーティングシステムレポート機能によって望ましくないとみなされるべきではなく、代わりに、特定のエンジャストされたサービスの接続性とフットプリントをよりよく識別するために受け入れる必要があります。
While namespace conservation and reasonable use of AS number resources should always be a goal, the introduction of 32-bit ASNs significantly lessens concerns in this space. Globally anycasted resources, in particular, those associated with critical infrastructure-enabling services such as root and TLD name servers, SHOULD warrant special consideration with regard to AS number allocation practices during policy development by the constituents of
名前空間保存と数のリソースの合理的な使用は常に目標であるべきですが、32ビットASNの導入はこの分野での懸念を大幅に軽減します。グローバルに任意のリソース、特に、ルートやTLDネームサーバーなどの重要なインフラストラクチャエイラブルサービスに関連するリソースは、の成分による政策開発中の数値割り当て慣行としての特別な考慮事項を保証する必要があります。
those responsible organizations (e.g., the Regional Internet Registries). Additionally, defining precisely what constitutes "critical infrastructure services" or "special consideration" (e.g., some small range of 32-bit AS numbers might be provided) is left to the constituents of those organizations. Additionally, critical infrastructure employment of 32-bit ASNs for new nodes might well help to foster more rapid adoption of native 32-bit ASN support by network operators.
これらの責任ある組織（例：地域のインターネットレジストリ）。さらに、「重要なインフラストラクチャサービス」または「特別な考慮事項」を構成するものを正確に定義すること（たとえば、数字が提供されるように32ビットの小さな範囲）は、それらの組織の構成要素に残されます。さらに、新しいノードのために32ビットASNの重要なインフラストラクチャの雇用は、ネットワークオペレーターによるネイティブ32ビットASNサポートのより迅速な採用を促進するのに役立つ可能性があります。
One additional benefit of unique origin AS numbers per anycast node is that Resource Public Key Infrastructure (RPKI) Secure Inter-domain Routing [SIDR] machinery, and, in particular, that of Route Origin Authorizations (ROAs), and routing policies that may be derived based on those ROAs, can be employed with per-anycast-node resolution, rather than relying on a single ROA and common origin AS to cover all instantiations of an anycasted prefix (possibly hundreds) within the global routing system. For example, in the case of deployments that incorporate partitioned ASN anycast models that have a single ASN bound to all nodes but crossing organizational or political boundaries, a situation may arise where nobody would be deemed appropriate to hold the key for the ROA. Additionally, a globally anycasted service within a given IP prefix that shares a common ASN might be taken totally offline because of the revocation of an ROA for that origin ASN. Today's RPKI model already inherently accommodates issuance of multiple ROAs with unique origins for a given prefix.
Anycastノードごとに数字としての一意の原点の追加の利点の1つは、リソース公開キーインフラストラクチャ（RPKI）セキュアインタードメインルーティング[SIDR]機械、特にルート原点認証（ROA）、およびルーティングポリシーの追加のポリシーが保護されていることです。これらのROAに基づいて導出されたのは、グローバルルーティングシステム内の任意のキャストされたプレフィックス（おそらく数百）のすべてのインスタンス化をカバーするために、単一のROAと共通の起源に依存するのではなく、ANYCASTノードごとの解像度で使用できます。たとえば、すべてのノードにバインドされているが組織的または政治的境界を越えて単一のASNを持つASN ANYCASTモデルを組み込んだ展開の場合、ROAの鍵を保持するのに適切とみなされない状況が発生する可能性があります。さらに、一般的なASNを共有する特定のIPプレフィックス内のグローバルにアーカストサービスは、その原点ASNのROAの取り消しのために完全にオフラインにされる可能性があります。今日のRPKIモデルは、特定のプレフィックスの一意の起源を持つ複数のROAの発行に本質的に対応しています。
Two additional recommendations for globally anycasted critical infrastructure services are related to publication of information associated with a given node's physical location, and with which adjacent upstream ASNs an origin AS interconnects. The former would allow operators to better define and optimize preferences associated with a given node to align with local policy and service optimizations. The latter would allow expression through policy such as Routing Policy Specification Language [RFC4012] specified in Internet Routing Registries (IRRs) in a manner that illustrates a discrete set of upstream ASNs for each anycast node, rather than the current model where all upstream ASNs associated with a common origin AS may or may not be expressed. This information would provide an additional level of static routing policy or monitoring and detection models by network operators and perhaps explicit network-layer source address validation in the datapath.
グローバルにキャストされた重要なインフラストラクチャサービスに関する2つの追加の推奨事項は、特定のノードの物理的位置に関連付けられた情報の公開に関連しており、隣接する上流の上流には相互接続として起源があります。前者は、オペレーターが特定のノードに関連する設定をよりよく定義および最適化して、ローカルポリシーとサービスの最適化に合わせます。後者は、インターネットルーティングレジストリ（IRR）で指定されたルーティングポリシー仕様言語[RFC4012]などのポリシーを通じて表現を許可します。表現される場合と表現されない可能性のある共通の起源を持つ。この情報は、ネットワーク演算子による静的ルーティングポリシーまたは監視および検出モデルの追加レベルと、おそらくデータパスでの明示的なネットワーク層のソースアドレス検証を提供します。
The recommendations made in this memo aim to provide more flexibility for network operators hoping to better monitor and prevent issues related to globally anycasted critical infrastructure resources. Anycast itself provides considerable benefit in the face of certain attacks; yet, if a given instance of a service can appear at many points in the routing system and legitimate instances are difficult to distinguish from malicious ones, then anycast expands the service's attack surface rather than reducing it.
このメモで行われた推奨事項は、グローバルに獲得した重要なインフラストラクチャリソースに関連する問題をより適切に監視および防止することを望んでいるネットワークオペレーターにより柔軟性を提供することを目的としています。Anycast自体は、特定の攻撃に直面してかなりの利益をもたらします。しかし、サービスの特定のインスタンスがルーティングシステムの多くのポイントに表示され、合法的なインスタンスを悪意のあるインスタンスと区別することが困難な場合、AnyCastはサービスを減らすのではなく、サービスの攻撃面を拡張します。
The recommendations made in this document are expressed to assist with visibility and policy specification capabilities in order to improve the availability of critical Internet resources. Use cases, where the recommendations outlined in this memo may have helped to more easily detect or scope the impact of a particular incident, are illustrated in [RENESYS-BLOG].
このドキュメントで行われた推奨事項は、重要なインターネットリソースの可用性を改善するために、可視性とポリシー仕様機能を支援するために表明されます。このメモで概説されている推奨事項が、特定のインシデントの影響をより簡単に検出または範囲するのに役立つ可能性のあるユースケースは、[Renesys-blog]に示されています。
Furthermore, while application-layer protection mechanisms such as DNS security extensions (DNSSEC) provide object-level integrity and authentication, they often do so at the cost of introducing more failure conditions. For example, if a recursive name server is performing DNSSEC validator functions and receives a bogus response to a given query as a result of a man-in-the-middle (MITM) or injected spoofed response packet such as a cache-poisoning attempt, the possibility might exist that the response packet is processed by the server and results in some temporal or persistent DoS condition on the recursive name server and for its client set. The unique origin AS mechanism outlined in this document provides the capability for network operators to expressly avoid anycast node catchments known to regularly elicit bogus responses, while allowing the anycasted service address to remain available otherwise.
さらに、DNSセキュリティエクステンション（DNSSEC）などのアプリケーション層保護メカニズムは、オブジェクトレベルの整合性と認証を提供しますが、多くの場合、より多くの障害条件を導入するコストでそうします。たとえば、再帰名サーバーがDNSSECバリデーター関数を実行している場合、中間者（MITM）またはキャッシュポジションの試みなどの注入されたスプーフィングされた応答パケットの結果として、特定のクエリに対する偽の応答を受信した場合、応答パケットがサーバーによって処理され、再帰名サーバーとそのクライアントセットに対して何らかの時間的または永続的なDOS条件が得られる可能性が存在する可能性があります。このドキュメントで概説されているメカニズムとしてのユニークな起源は、ネットワークオペレーターが偽の応答を定期的に誘発することが知られているAnycastノードの集水域を明示的に回避する機能を提供し、それ以外の場合はAnycastのサービスアドレスを利用できるようにします。
Maintenance of unique ASNs for each node within an anycasted service may be challenging for some critical infrastructure service operators initially, but for globally anycasted resources, there needs to be some type of per-node discriminator in the control plane to enable detection, remediation, and optimally, preventative controls for dealing with routing system anomalies that are intensified by the application of IP anycasting. Additionally, this technique sets the stage to employ RPKI-enabled machinery and more secure and explicit routing policies, which all network operators should be considering.
アーカストサービス内の各ノードの一意のASNのメンテナンスは、最初はいくつかの重要なインフラストラクチャサービスオペレーターにとって困難な場合がありますが、グローバルに任意のリソースでは、検出、修復、および検出、修復、および検出を可能にするために、制御プレーンに何らかのタイプのノード識別器が必要です。最適には、IP Anycastingの適用によって強化されるルーティングシステムの異常を扱うための予防制御。さらに、この手法は、RPKI対応機械を使用して、より安全で明示的なルーティングポリシーを採用する段階を設定します。これは、すべてのネットワークオペレーターを検討する必要があります。
The granularity of data publication related to anycast node location should be left to the devises of each services operator, and the value of this mechanism in each operator's unique environment, but some reasonable level of detail to enable operators and service consumers to make informed decisions that align with their security and operational objectives as outlined herein should be provided by each critical services operator.
Anycastノードの位置に関連するデータ出版物の粒度は、各サービスオペレーターの開発者に任され、各オペレーターの独自の環境におけるこのメカニズムの価値を委ねる必要がありますが、オペレーターとサービス消費者が情報に基づいた決定を下すための合理的なレベルの詳細を任せる必要があります。本明細書に概説するように、セキュリティおよび運用目標に合わせて、各重要なサービスオペレーターが提供する必要があります。
Adjacent AS information for a given origin AS can already be obtained through careful routing system analysis when prefixes are advertised via a given set of AS adjacencies, and therefore, should present no new threat. However, network interconnection and peering policies may well present some challenges in this area. For example, if a technique such as unique origin AS per node is employed, then a single organization may no longer have a single AS for interconnection at each location, and interconnection policies should expressly consider this. That said, interconnection with networks that provide critical infrastructure services should certainly be given due consideration as such by network operators when evaluating interconnection strategies.
特定のルーティングシステム分析を介して既に取得できるように、特定のルーティングシステム分析を通じて既に取得できるように、特定のルーティングシステム分析として隣接するものとして隣接するAS AS AS隣接セットを介して宣伝されているため、新しい脅威を提示する必要はありません。ただし、ネットワークの相互接続とピアリングポリシーは、この分野でいくつかの課題を提示する可能性があります。たとえば、ノードごとの一意のオリジンなどの手法が採用されている場合、単一の組織には、各場所での相互接続のように単一の組織がない場合があり、相互接続ポリシーはこれを明示的に考慮する必要があります。とはいえ、重要なインフラストラクチャサービスを提供するネットワークとの相互接続は、相互接続戦略を評価する際にネットワークオペレーターによって、そのような適切な考慮を確実に与えられるべきです。
Today, some root and TLD operators identify erroneous anycast prefix announcements by detecting prefix announcements with an origin AS other than the common origin AS shared via all nodes. This detection model would need to be expanded to account for unique origin ASNs per node if a given service operator chooses to employ such a model. Given that AS paths are trivial to manipulate in the current system, the above technique would only assist in the event of unintentional configuration errors that reoriginate the route (e.g., it does not detect leaks that preserve the initial path elements). In that case, work underway on routing security origin and path validation in the SIDR working group and beyond should be consulted.
今日、一部のルートおよびTLDオペレーターは、すべてのノードを介して共有される共通起源以外としてプレフィックスアナウンスを検出することにより、誤ったAnycastプレフィックスの発表を特定します。特定のサービスオペレーターがそのようなモデルを使用することを選択した場合、この検出モデルは、ノードごとの一意の原点ASNを考慮するために拡張する必要があります。パスが現在のシステムで操作する些細なことであるため、上記の手法は、ルートを再調整する意図しない構成エラーが発生した場合にのみ役立ちます（たとえば、初期パス要素を維持する漏れを検出しません）。その場合、SIDRワーキンググループおよびそれ以降のルーティングセキュリティの原点とパス検証に関する作業に相談する必要があります。
While local policy based on any BGP attributes, to include AS path information, can influence policy within a local administrative domain and possibly downstream, there exists a possibility that upstream nodes continue to use a route deemed undesirable by the local administrator once data packets reach that network. Network operators must understand the implications of this property in their operating environment, as it is inherent in all Internet routing.
パス情報を含めるBGP属性に基づいたローカルポリシーは、ローカル管理ドメイン内およびおそらく下流のポリシーに影響を与える可能性がありますが、データパケットが到達すると、上流のノードがローカル管理者によって望ましくないとみなされるルートを引き続き使用し続ける可能性があります。通信網。ネットワークオペレーターは、すべてのインターネットルーティングに固有のものであるため、このプロパティの運用環境における意味を理解する必要があります。
Finally, anycast node presence at exchange points that employ route servers may make enumeration of adjacent ASNs for a given node challenging. While this is understood, service operators should make every effort to enumerate the set of adjacent ASNs associated with a given anycast node's origin AS. Without express understanding of legitimate AS interconnection and authorized origin AS information, more secure routing is difficult to achieve.
最後に、ルートサーバーを使用する交換ポイントでのAnycastノードの存在は、特定のノードの隣接するASNの列挙を挑戦する可能性があります。これは理解されていますが、サービスオペレーターは、特定のAnycastノードの起源に関連する隣接するASNのセットを列挙するためにあらゆる努力をする必要があります。相互接続としての正当な理解と情報としての認可された起源を明示的に理解しないと、より安全なルーティングを達成することは困難です。
Thanks to David Conrad, Steve Kent, Mark Kosters, Andrei Robachevsky, Paul Vixie, Brad Verd, Andrew Herrmann, Gaurab Raj Upadhaya, Joe Abley, Benson Schliesser, Shane Amante, Hugo Salgado, and Randy Bush for review and comments on this concept.
デビッド・コンラッド、スティーブ・ケント、マーク・コスターズ、アンドレイ・ロバチェフスキー、ポール・ビクシー、ブラッド・ヴェルド、アンドリュー・ハーマン、ガウラブ・ラジ・ウパダヤ、ジョー・ラジ・ウーダヤ、ベンソン・シュリッサー、シェーン・アマンテ、ヒューゴ・サルガド、ランディ・ブッシュのレビューとコメントのために、ランディ・ブッシュに感謝します。
This document requires no direct IANA actions, although it does provide general guidance to number resource allocation and policy development organizations, and, in particular, Regional Internet Registries, regarding allocation of AS numbers for globally anycasted services.
このドキュメントでは、直接的なIANAアクションは必要ありませんが、リソースの割り当てと政策開発組織、特に地域のインターネットレジストリには、グローバルに任意のサービスの番号の割り当てに関する一般的なガイダンスが提供されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Eabley、J。およびK. Lindqvist、「Anycast Servicesの運用」、BCP 126、RFC 4786、2006年12月。
[DNSSEC-DEPLOY] "Root DNSSEC", <http://www.root-dnssec.org/>
[dnssec-deploy] "root dnssec"、<http://www.root-dnssec.org/>
[RENESYS-BLOG] Zmijewski, E., "Accidentally Importing Censorship", Renesys Blog, March 30, 2010. <http://www.renesys.com/blog/2010/03/ fouling-the-global-nest.shtml>
[Renesys-blog] Zmijewski、E。、「偶然に検閲の輸入」、Renesys Blog、2010年3月30日。>
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005.
[RFC4012] Blunk、L.、Damas、J.、Parent、F。、およびA. Robachevsky、「ルーティングポリシー仕様言語次世代（RPSLNG）」、RFC 4012、2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism Identifying a Name Server Instance", RFC 4892, June 2007.
[RFC4892] Woolf、S。およびD. Conrad、「名前サーバーインスタンスを識別するメカニズムの要件」、RFC 4892、2007年6月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001] Austein、R。、「DNS Name Server Identifier（NSID）オプション」、RFC 5001、2007年8月。
[SIDR] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", Work in Progress, May 2011.
[SIDR] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、2011年5月の進行中。
Authors' Addresses
著者のアドレス
Danny McPherson Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Danny McPherson Verisign、Inc。21345 Ridgetop Circle Dulles、VA USA 20166電話：1 703.948.3200
EMail: dmcpherson@verisign.com
Ryan Donnelly Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Ryan Donnelly Verisign、Inc。21345 Ridgetop Circle Dulles、VA USA 20166電話：1 703.948.3200
EMail: rdonnelly@verisign.com
Frank Scalzo Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
Frank Scalzo Verisign、Inc。21345 Ridgetop Circle Dulles、VA USA 20166電話：1 703.948.3200
EMail: fscalzo@verisign.com