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
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.
この文書では、世界的に与えられたanycasted接頭辞のためのルーティングシステム弁別器を提供するために、重要なインフラストラクチャサービスをanycastedためにノードごとに一意の原点自律システム番号の使用に関する勧告（AS番号）を行います。ネットワーク管理とモニタリング技術、または他の動作メカニズムは、最高のは、彼らの動作環境を収容してどんな方法でこの新しい弁別を利用することができます。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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のエニーキャスト[RFC4786]は、1990年代初頭以来、ネットワークサービスの配列のために配備されています。これは、一般的により優れた局在化及び全身クエリ負荷の吸収、ならびにより良好な保護をもたらす、より堅牢で弾力フットプリントで、ローカルおよび/またはグローバルに、より分散的に与えられたネットワークリソースのための機構が利用可能であることを提供します分散型サービス拒否（DDoS攻撃）攻撃、ネットワークパーティション、および他の同様の事件の面。インターネットのルートDNSインフラストラクチャだけでなく、他の多くのリソースの大部分は、10年近くanycastedされています。
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).
ネットワークサービスをエニーキャストすることによって実現利益が証明されている間、いくつかの問題は、複数の場所から共通のネットワーク識別子のためのルーティングシステムの到達可能性を主張して出てくるん。具体的には、BGPにエニーキャストは複数の場所から共通のIPアドレス・プレフィクスのためのルーティングシステムで到達可能性情報の注射を必要とします。これらanycastedプレフィックスとネットワークサービスは、伝統的に、グローバルルーティングシステム内のドメイン識別子をルーティングするためにBGPによって利用数空間として歴史的に乏しい16ビットを保持するために共通の起源自律システム番号（ASN）を採用しています。また、番号が複数の個別の取得及び維持に関連した資源運用管理オーバーヘッドを容易にするためにAS番号ならびににおいて観察された「アナウンスAS矛盾起源」を特定することを目的と各種動作指向のレポート機能をトリガ回避するために使用されたように、共通の起源ルーティングシステム。結果として、システムパスルーティングの表現は、これらのサービスインスタンスに関連付けられた属性、及びそのanycastedプレフィックス自体は、典型的に（すなわち、ネットワーク制御プレーン自体内）ルーティングシステムにはインスタンスごとの識別器を負いません。
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.
これはおそらく、両方のサービス（例えば、DNS又はNTP）と実装依存であるが、サービス・レベル・クエリ機能は、または、特定のクエリに応答したエニーキャストノードを識別するためのメカニズムを提供してもしなくてもよいです。例えば、ネームサーバデーモン（NSD）、結合していない、すべてを結合は、特定のサーバのサービスレベルの同定を可能に「hostname.bind又はhostname.id」[RFC4892]、[RFC5001]のクエリのサポートを提供します。それはローカルスコープのエニーキャスト・インスタンスを明らかにしないかもしれないが、このようなトレースルートなどのツールはまた、どの位置所与の照会がルーティングされるかを決定するために使用され、または複数のサーバは、所与のに応答サーバの所定のエニーキャスト・ノード内にある場合クエリ、特に、エニーキャストノード内の複数のサーバーを単一の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.
より多くのサービスがグローバルanycasted、および既存anycastedサービスが成長して、システムの負荷に対応するために、特定のサービスアドレスのエニーキャストノードの広い展開を実現しているとして、よりよいそれらのリソースを保護するためのセーフガードとコントロールを提供することの難しさが広がります。直感的に、より広く与えられたanycastedサービスアドレスは、ネットワークオペレータがそのサービスに影響を与える運用とセキュリティの問題を検出するためのより困難となり、ある分散。このようなセキュリティや運用上の問題のいくつかの例では、サービス、またはルーティングシステム、フォワード・クエリのデータパス、またはクエリ応答データパスのいずれかの他の異常行動の出現のために表示される不正なエニーキャストノードをanycastedサービスに影響を与えるBGPルートリークを含んでいます。ルーティングシステムの問題の診断は、一意の識別器は、所与のローカルまたはグローバルエニーキャストノードを識別するために、ルーティングシステムに存在しないという事実によって複雑になります。さらに、両方のデータパスおよびルーティングシステム問題の識別は、これらの事件タイプは、所与のクライアント・サーバ・セットとの間の位相幾何学的に依存する、とのみ観察することができるという事実によって悪化します。
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.
さらに、それは、ローカルポリシーまたはデータプレーン応答操作技術は、このような方法で、所定の領域内への「影響力」応答であれば、多くのanycastedサービスは、anycastedサービスアドレスのすべてのインスタンス間での正確な同期のために努力することは言うまでもないながら、ものの応答もはや本物か、彼らはanycastedサービス内の他のノードが提供していたものから分岐するということです、それらの変更されたリソースは、その領域のみやインフルエンサーの管轄内のサービス消費者が利用することが絶対的な必要ないはずです。
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）のレベルが[DNSSECよく進行中であると仮定すると、オブジェクト・レベルの整合性とサービス層でこの機能を提供します-deploy]。さらに、制御プレーン識別器が知ってオペレータを可能にするために存在するべきクエリが向けられているインスタンスの所定のセットのどちらに向けて、これが変化したときに検出及び警告機能を有効にします。ローカル運用ポリシーがそれを必要としなければならないような識別器はまた、エニーキャストノード好みやフィルタリングキーを有効にするために使用することができます。
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 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.
エニーキャストノード：一緒にエニーキャストサービスアドレスのためのサービスを提供するホストとルータの内部で接続されたコレクション。エニーキャストノードは、隣接するルータとルーティングシステムに参加している単一のホストと同じくらい簡単であるかもしれない、またはそれは、いくつかのより複雑な方法で接続されたホストの数を含み得ます。いずれの場合も、サービスはエニーキャストされている間でルーティングシステムに、各エニーキャストノードは、サービスのアドレスに一意のパスを提示します。サービスの全体エニーキャストシステムは、2つの以上の別個のエニーキャストノードで構成されています。
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.
流域：物理的な地理で、川で排水面積は、また流域として知られています。本書で使用されるように類推して、ネットワークのトポロジー領域がその中にある特定のノードにルーティングされるエニーキャストアドレスに向けられたパケット。
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 Node: an Anycast Node providing service using a Local-Scope Anycast Address.
ローカル・ノード：ローカルスコープエニーキャストアドレスを使用してサービスを提供するエニーキャストノード。
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
グローバルノード：グローバル・スコープエニーキャストアドレスを使用してサービスを提供するエニーキャストノード。
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.
グローバルスコープエニーキャスト：エニーキャストサービスアドレスの到達可能性情報は、特定のエニーキャストノードが全体のルーティングシステムに潜在的に見えるようにルーティングシステムを介して伝播されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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リソースに関連付けられたルーティング情報を変更を検出することができるようにするために、分割された元のAS番号を持つグローバルanycastedサービスは、動作環境およびサービスモデルでは、適切な場合、ノード可能であればごとに固有の原点ASNを利用すべきです。
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.
ノードあたりの離散起源のASNは、より迅速に漏洩又はハイジャックインスタンスの検出を可能にするので、積極的に与えられたノードの好みまたは回避を発現するか、関連付けられたノードのセットのルーティングポリシーを開発することを選択するオペレータを可能にするルーティングシステムにおける識別器を提供しますanycastedサービス。ローカルポリシーや既知の問題は、特定のエニーキャストノードから返された応答のパフォーマンスや信頼性に存在することが観察された、または特定の領域内のサービスに影響することを意図している制定された政策としてその領域の外側のユーザーに影響を与えている場合に特に便利ですその意図した範囲を超えて拡大して与えられたエニーキャスト流域の結果。
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.
さらに、重要なインフラストラクチャのためのanycastedサービスに関連する発表AS矛盾した原点は、システムのレポート機能をルーティングすることによって、望ましくないものではないが、その代わりに、より良い与えanycastedサービスのつながりやフットプリントを特定するために抱かれなければなりません。
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 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.
名前空間の保全とAS番号資源の合理的な使用は、常に目標であるべきであるが、32ビットのAS番号の導入が大幅にこの空間に懸念を軽減します。グローバルanycasted資源は、特に、そのようなルートやTLDネームサーバなどの重要なインフラ・サービスを可能に関連したものは、責任者の組織（例えば、地域インターネットの成分によって政策開発中のAS番号の割り当て慣行に関して特別な配慮を保証すべきですレジストリ）。また、「重要なインフラストラクチャサービス」または「特別な配慮」（例えば、AS番号の32ビットのいくつかの小さな範囲が提供される可能性があります）を構成し、正確に何を定義すると、それらの団体の構成要素に委ねられています。さらに、新しいノードのための32ビットのAS番号の重要なインフラの雇用がうまくネットワークオペレータによってネイティブ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.
エニーキャストノードあたりのAS番号のユニークな起源の一つの追加の利点は、資源公開鍵インフラストラクチャ（RPKI）セキュアドメイン間ルーティング[SIDR]機械、及び、特に、国道起源承認のもの（資産収益率）、およびルーティングポリシーがあってもよいことということですこれらの資産収益率に基づいて導出、むしろグローバルルーティングシステム内anycastedプレフィックス（おそらく数百）のすべてのインスタンスを覆うように、単一のROAと共通の起源に依存するよりも、単位のエニーキャストノード解像度で使用することができます。誰もがROAのキーを保持するために適切であると考えないであろう場所たとえば、すべてのノードに結合された単一のASNを持っていますが、組織や政治的境界を横断するパーティションASNエニーキャストモデルを組み込む展開した場合には、状況が発生する可能性があります。また、一般的なASNを共有する与えられたIPプレフィックス内のグローバルanycastedサービスがあるため、その原点ASNのためのROAの取消しを完全にオフラインにされる可能性があります。今日のRPKIモデルがすでに本質的に与えられた接頭語のためのユニークな起源を持つ複数の資産収益率の発行に対応します。
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.
グローバルanycasted重要なインフラストラクチャサービスの二つの追加の推奨事項は、所与のノードの物理的位置に関連する情報の公開に関連する、および相互接続ASと隣接する上流のASNが原点れます。前者は、オペレータがより良く定義し、ローカル・ポリシーおよびサービスの最適化と整合する所定のノードに関連付けられた優先条件を最適化することを可能にします。後者は、むしろ全ての上流のASNは、関連する現在のモデルよりも、各エニーキャストノードの上流のASNの離散的なセットを示すように、インターネットルーティングレジストリ（のIRR）で指定されたルーティングポリシー言語仕様[RFC4012]などのポリシーによって発現を可能にします共通の起源とASは、または表現してもしなくてもよいです。この情報は、ネットワークオペレータとデータパスにおそらく明示ネットワーク層ソースアドレス検証によって静的ルーティングポリシーまたはモニタリング及び検出モデルの追加のレベルを提供するであろう。
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.
このメモで作られた勧告は、より良い監視し、世界的に重要なインフラストラクチャリソースをanycastedに関連する問題を防ぐことを期待してネットワークオペレータのためのより多くの柔軟性を提供することを目指しています。それ自体が特定の攻撃の面でかなりの利益を提供するエニーキャスト。サービスの特定のインスタンスは、ルーティングシステムに多くのポイントで表示されますと、正当なインスタンスは悪意のあるものと区別することが困難な場合は、まだ、その後、エニーキャストは、それを減らすのではなく、サービスの攻撃面を拡大します。
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ブログ]に示されています。
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状態でサーバーとの結果によって処理されていることを存在している場合があります。 anycastedサービスアドレスは、そうでない場合は使用可能な状態を可能にしながら、この文書で概説メカニズムとしてユニークな起源は、明示的に定期的に偽の応答を誘発することが知られているエニーキャストノード流域を避けるために、ネットワークオペレータのための機能を提供します。
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.
anycastedサービス内の各ノードは、最初にいくつかの重要なインフラストラクチャサービス事業者のために挑戦することができるの一意のASNのメンテナンスが、グローバルanycastedリソースに対して、検出を可能にするための制御プレーンにおけるノードごとのディスクリミネータの何らかのタイプが必要である、修復、および最適に、IPのエニーキャストを適用することによって強化されているルーティングシステムの異常に対処するための予防的コントロール。また、この技術は、すべてのネットワークオペレータが考慮されなければならない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.
エニーキャストノード位置に関連するデータの出版物の粒度は、その情報に基づいた意思決定を行うために事業者やサービスの消費者を有効にするには、各サービス事業者の工夫と、各オペレータのユニークな環境におけるこのメカニズムの値が、細部のいくつかの合理的なレベルに委ねられるべきここで概説として、セキュリティと運用の目的に合わせた各重要なサービス事業者によって提供されるべきです。
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事業者は、すべてのノードを介して共有などの共通の起源以外のAS原点とプレフィックスのアナウンスを検出することにより、誤ったエニーキャストプレフィックスのアナウンスを識別する。この検出モデルは、特定のサービスオペレータは、このようなモデルを採用することを選択した場合、ノードごとに固有の原点のASNを考慮するために拡張する必要があります。 （例えば、それが最初のパス要素を保持漏れが検出されない）パスが、現在のシステムで操作するのは簡単されているので、上記の技術は唯一のルートをreoriginate意図しない構成エラーが発生した場合に役立つであろうことを考えます。その場合には、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.
最後に、ルートサーバーを採用交換ポイントでエニーキャストノードの存在が困難な特定のノードのために、隣接するAS番号の列挙を行うことができます。これが理解されている間、サービス事業者は、与えられたエニーキャストノードの原点ASに関連付けられた隣接するAS番号のセットを列挙するためにあらゆる努力をするべきです。情報AS相互接続AS合法と認可起源の明示を理解せずに、より安全なルーティングを達成することは困難です。
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.
レビューのためのデヴィッド・コンラッド、スティーブケント、マーク・Kosters、アンドレイRobachevsky、ポール・ヴィクシー、ブラッドVerdの、アンドリュー・ヘルマン、GaurabラジUpadhaya、ジョーAbley、ベンソンSchliesser、シェーンAmante、ヒューゴ・サルガド、およびランディブッシュ大統領に感謝し、この概念についてのコメント。
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.
それは世界的にanycastedサービスのためのAS番号の割り当てに関する多数のリソース割り当てと政策開発機関、及び、特に、地域インターネットレジストリへの一般的なガイダンスを提供していますが、この文書は、いかなる直接IANAのアクションを必要としません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Abley、J.およびK. Lindqvist、 "エニーキャストサービスの運用"、BCP 126、RFC 4786、2006年12月。
[DNSSEC-DEPLOY] "Root DNSSEC", <http://www.root-dnssec.org/>
[DNSSEC-DEPLOY "ルート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ブログ "偶然検閲のインポート" を、3月30日、2010年には、<http://www.renesys.com/blog/2010/03/汚れ-グローバルnest.shtmlを>
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005.
[RFC4012]ブルンク、L.、ダマ、J.、親、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]ウルフ、S.およびD.コンラッド、RFC 4892「ネームサーバーインスタンスを識別機構の要件」、2007年6月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001] Austeinと、R.、 "識別（NSID）のためのDNSネームサーバオプション"、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.ケント、進歩、2011年5月における作業「安全なインターネットルーティングをサポートするインフラストラクチャ」。
Authors' Addresses
著者のアドレス
Danny McPherson Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
ダニー・マクファーソンベリサイン社21345 Ridgetopサークルダレス、VA USA 20166電話：+1 703.948.3200
EMail: dmcpherson@verisign.com
メールアドレス：dmcpherson@verisign.com
Ryan Donnelly Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
ライアン・ドネリーベリサイン社21345 Ridgetopサークルダレス、VA USA 20166電話：+1 703.948.3200
EMail: rdonnelly@verisign.com
メールアドレス：rdonnelly@verisign.com
Frank Scalzo Verisign, Inc. 21345 Ridgetop Circle Dulles, VA USA 20166 Phone: +1 703.948.3200
フランクScalzoベリサイン社21345 Ridgetopサークルダレス、VA USA 20166電話：+1 703.948.3200
EMail: fscalzo@verisign.com
メールアドレス：fscalzo@verisign.com