[要約] RFC 6837は、NERD（Not-so-novel Endpoint ID to Routing Locator Database）に関するものであり、エンドポイントID（EID）とルーティングロケータ（RLOC）のデータベースを扱っています。このRFCの目的は、EIDとRLOCのマッピング情報を効率的に管理し、ネットワークのルーティングを改善することです。
Independent Submission E. Lear
Request for Comments: 6837 Cisco Systems GmbH
Category: Experimental January 2013
ISSN: 2070-1721
NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
NERD：ルーティングロケータ（RLOC）データベースへのそれほど新しいエンドポイントID（EID）
Abstract
概要
The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries.
Locator / ID Separation Protocol（LISP）は、IPパケットをカプセル化して、インターネットの一端から別の端にルートを挿入することなく、エンドサイトを互いにルーティングできるようにするプロトコルです。このメモは、実験的なデータベースと、エンドポイントID（EID）からルーティングロケータ（RLOC）へのマッピングを、信頼性が高く、スケーラブルで安全な方法でルーターに転送する方法について説明しています。私たちの分析によると、EIDからRLOCへのすべてのマッピングの転送は、少なくとも10 ^ 8エントリまで適切にスケーリングされます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6837.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6837で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 4
1.3. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 7
2.2. Communications between ITR and ETR . . . . . . . . . . . . 8
2.3. Who are database authorities? . . . . . . . . . . . . . . 8
3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 11
3.2. Database Update Format . . . . . . . . . . . . . . . . . . 12
4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 12
4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 12
4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 12
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Router Throughput versus Time . . . . . . . . . . . . . . 16
5.3. Number of Servers Required . . . . . . . . . . . . . . . . 16
5.4. Security Considerations . . . . . . . . . . . . . . . . . 18
5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 19
5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 21
6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 21
7. Other Distribution Mechanisms . . . . . . . . . . . . . . . . 22
7.1. What about DNS as a mapping retrieval model? . . . . . . . 22
7.2. Use of BGP and LISP+ALT . . . . . . . . . . . . . . . . . 24
7.3. Perhaps use a hybrid model? . . . . . . . . . . . . . . . 24
8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 24
8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Generating and Verifying the Database Signature
with OpenSSL . . . . . . . . . . . . . . . . . . . . 30
The Locator/ID Separation Protocol (LISP) [RFC6830] separates an IP address used by a host and local routing system from the Locators advertised by BGP participants on the Internet in general, and in the Default-Free Zone (DFZ) in particular. It accomplishes this by establishing a mapping between globally unique Endpoint IDs (EIDs) and Routing Locators (RLOCs). This reduces the amount of state change that occurs on routers within the DFZ on the Internet, while enabling end sites to be multihomed.
Locator / ID Separation Protocol（LISP）[RFC6830]は、ホストおよびローカルルーティングシステムが使用するIPアドレスを、インターネット上のBGP参加者が一般にアドバタイズするロケーター、特にデフォルトフリーゾーン（DFZ）から分離します。これは、グローバルに一意のエンドポイントID（EID）とルーティングロケーター（RLOC）の間のマッピングを確立することによってこれを実現します。これにより、インターネット上のDFZ内のルーターで発生する状態変更の量が削減され、エンドサイトをマルチホーム化できます。
In some mapping distribution approaches to LISP, the mapping is learned via data-triggered control messages between Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) through an alternate routing topology [RFC6836]. In other approaches of LISP, the mapping from EIDs to RLOCs is instead learned through some other means. This memo addresses different approaches to the problem, and specifies a Not-so-novel EID-to-RLOC Database (NERD) and methods to both receive the database and to receive updates.
LISPへの一部のマッピング配布アプローチでは、代替ルーティングトポロジ[RFC6836]を通じて、入力トンネルルータ（ITR）と出力トンネルルータ（ETR）の間のデータトリガー制御メッセージを介してマッピングが学習されます。 LISPの他のアプローチでは、EIDからRLOCへのマッピングは他の方法で学習されます。このメモは、問題へのさまざまなアプローチを扱い、Not-so-novel EID-to-RLOC Database（NERD）と、データベースの受信と更新の受信の両方の方法を指定します。
NERD is offered primarily as a way to avoid dropping packets, the underlying assumption being that dropping packets is bad for applications and end users. Those who do not agree with this underlying assumption may find that other approaches make more sense.
NERDは、主にパケットのドロップを回避する方法として提供され、パケットのドロップはアプリケーションとエンドユーザーにとって悪いことであるという基本的な前提があります。この根本的な仮定に同意しない人は、他のアプローチがより理にかなっていることに気付くかもしれません。
NERD is specified in such a way that the methods used to distribute or retrieve it may vary over time. Multiple databases are supported in order to allow for multiple data sources. An effort has been made to divorce the database from access methods so that both can evolve independently through experimentation and operational validation.
NERDは、それを配布または取得するために使用される方法が時間とともに変化するように指定されています。複数のデータソースを可能にするために、複数のデータベースがサポートされています。データベースをアクセス方法から離して、実験と運用の検証を通じて両方が独立して進化できるようにする努力が行われました。
This memo is based on experiments performed in the 2007-2009 time frame. At the time of its publication, the author is unaware of operational use of NERD. Those wishing to pursue NERD should consider the substantial amount of work left for the future. See Section 10 for more details.
このメモは、2007年から2009年にかけて行われた実験に基づいています。その発行時点では、著者はNERDの運用上の使用に気づいていません。 NERDを追求したい人は、将来のために残された相当な量の作業を検討する必要があります。詳細については、セクション10を参照してください。
In order to specify a mapping, it is important to understand how it will be used, and the nature of the data being mapped. In the case of LISP, the following assumptions are pertinent:
マッピングを指定するには、それがどのように使用されるか、およびマッピングされるデータの性質を理解することが重要です。 LISPの場合、次の仮定が適切です。
o The data contained within the mapping changes only on provisioning or configuration operations, and is not intended to change when a link either fails or is restored. Some other mechanism, such as the use of LISP Reachability Bits with mapping replies, handles healing operations, particularly when a tail circuit within a service provider's aggregate goes down. NERD can be used as a verification method to ensure that whatever operational mapping changes an ITR receives are authorized.
oマッピング内に含まれるデータは、プロビジョニングまたは構成操作でのみ変更され、リンクに障害が発生したり、リンクが復元されたりしたときに変更されることを意図していません。特にサービスプロバイダーの集約内のテール回線がダウンした場合、マッピング応答でのLISP到達可能性ビットの使用など、他のメカニズムが修復処理を処理します。 NERDは、ITRが受け取る運用上のマッピングの変更が許可されていることを確認するための検証方法として使用できます。
o While weight and priority are defined, these are not hop-by-hop metrics. Hence, the information contained within the mapping does not change based on where one sits within the topology.
o 重みと優先度は定義されていますが、これらはホップバイホップのメトリックではありません。したがって、マッピング内に含まれる情報は、トポロジ内のどこにあるかに基づいて変化しません。
o Because a purpose of LISP is to reduce control-plane overhead by reducing "rate X state" complexity, updates to the mapping will be relatively rare.
o LISPの目的は、「レートX状態」の複雑さを減らすことによってコントロールプレーンのオーバーヘッドを減らすことなので、マッピングの更新は比較的まれです。
o Because NERD is designed to ease interdomain routing, its use is intended within the inter-domain environment. That is, NERD is best implemented at either the customer edge or provider edge, and there will be on the order of as many ITRs and EID-Prefixes as there are connections to Internet service providers by end customers.
o NERDはドメイン間ルーティングを容易にするように設計されているため、その使用はドメイン間環境内での使用を目的としています。つまり、NERDはカスタマーエッジまたはプロバイダーエッジで実装するのが最適であり、エンドカスタマーによるインターネットサービスプロバイダーへの接続と同じ数のITRおよびEIDプレフィックスが存在します。
o As such, NERD cannot be the sole means to implement host mobility, although NERD may be in used in conjunction with other mechanisms.
o そのため、NERDは他のメカニズムと組み合わせて使用される場合がありますが、ホストモビリティを実装する唯一の手段にはなりません。
NERD is a Not-so-novel EID-to-RLOC Database. It consists of the following components:
NERDは、それほど新しいEIDからRLOCへのデータベースです。次のコンポーネントで構成されています。
1. a network database format;
1. ネットワークデータベース形式。
2. a change distribution format;
2. 変更配布フォーマット。
3. a database retrieval/bootstrapping method; and
3. データベースの取得/ブートストラップ方法。そして
4. a change distribution method.
4. 変更の配布方法。
The network database format is compressible. However, at this time, we specify no compression method. NERD will make use of potentially several transport methods, but most notably HTTP [RFC2616]. HTTP has restart and compression capabilities. It is also widely deployed.
ネットワークデータベースの形式は圧縮可能です。ただし、現時点では圧縮方法は指定していません。 NERDは潜在的にいくつかの転送方法を利用しますが、最も顕著なのはHTTP [RFC2616]です。 HTTPには再起動および圧縮機能があります。また、広く展開されています。
There exist many methods to show differences between two versions of a database or a file, UNIX's "diff" being the classic example. In this case, because the data is well structured and easily keyed, we can make use of a very simple format for version differences that simply provides a list of EID-to-RLOC mappings that have changed using the same record format as the database, and a list of EIDs that are to be removed.
データベースまたはファイルの2つのバージョンの違いを示す方法は数多くありますが、UNIXの「diff」が典型的な例です。この場合、データは適切に構造化され、簡単にキー設定できるため、データベースと同じレコード形式を使用して変更されたEIDからRLOCへのマッピングのリストを提供する、バージョンの違いに非常に単純な形式を利用できます。削除するEIDのリスト。
The reader is once again referred to [RFC6830] for a general glossary of terms related to LISP. The following terms are specific to this memo.
読者は、LISPに関連する用語の一般的な用語集について、[RFC6830]を再び参照されます。以下の用語は、このメモに固有のものです。
Base Distribution URI: An Absolute-URI as defined in Section 4.3 of [RFC3986] from which other references are relative. The base distribution URI is used to construct a URI to an EID-to-RLOC mapping database. If more than one NERD is known, then there will be one or more base distribution URIs associated with each (although each such base distribution URI may have the same value).
ベース配布URI：他の参照が相対的である[RFC3986]のセクション4.3で定義されているAbsolute-URI。ベース配布URIは、EIDからRLOCへのマッピングデータベースへのURIを構築するために使用されます。複数のNERDがわかっている場合、それぞれに関連付けられた1つ以上のベース配布URIがあります（ただし、そのような各ベース配布URIは同じ値を持つ場合があります）。
EID Database Authority: The authority that will sign database files and updates. It is the source of both.
EIDデータベース機関：データベースファイルと更新に署名する機関。両方のソースです。
The Authority: Shorthand for the EID Database Authority.
Authority：EIDデータベース機関の省略形。
NERD: Not-so-novel EID-to-RLOC Database.
NERD：それほど新しいEIDからRLOCへのデータベース。
AFI Address Family Identifier.
AFIアドレスファミリ識別子。
Pull Model: An architecture where clients pull only the information they need at any given time, such as when a packet arrives for forwarding.
プルモデル：転送のためにパケットが到着したときなど、クライアントが常に必要な情報のみをプルするアーキテクチャ。
Push Model: An architecture in which clients receive an entire dataset, containing data they may or may not require, such as mappings for EIDs that no host served is attempting to send to.
プッシュモデル：クライアントがデータセット全体を受信するアーキテクチャー。ホストがサービスを提供していないEIDへのマッピングなど、必要または不必要なデータが含まれています。
Hybrid Model: An architecture in which some information is pushed toward the receiver from a source and some information is pulled by the receiver.
ハイブリッドモデル：一部の情報がソースからレシーバーにプッシュされ、一部の情報がレシーバーによってプルされるアーキテクチャー。
Operational functions are split into two components: database updates and state exchange between ITR and ETR during a communication.
運用機能は、データベースの更新と、通信中のITRとETR間の状態交換の2つのコンポーネントに分かれています。
What follows is a summary of how NERDs are generated and updated. Specifics can be found in Section 3. The general way in which NERD works is as follows:
以下は、NERDが生成および更新される方法の概要です。詳細はセクション3を参照してください。NERDの一般的な動作方法は次のとおりです。
1. A NERD is generated by an authority that allocates Provider-Independent (PI) addresses (e.g., IANA or a Regional Internet Registry (RIR)) that are used by sites as EIDs. As part of this process, the authority generates a digest for the database and signs it with a private key whose public key is part of an X.509 certificate. [ITU.X509.2000] That signature along with a copy of the authority's public key is included in the NERD.
1. NERDは、サイトがEIDとして使用するプロバイダー非依存（PI）アドレス（IANAやRegional Internet Registry（RIR）など）を割り当てる機関によって生成されます。このプロセスの一部として、認証局はデータベースのダイジェストを生成し、公開鍵がX.509証明書の一部である秘密鍵でそれに署名します。 [ITU.X509.2000]その署名と当局の公開鍵のコピーがNERDに含まれています。
2. The NERD is distributed to a group of well-known servers.
2. NERDは、よく知られたサーバーのグループに配布されます。
3. ITRs retrieve an initial copy of the NERD via HTTP when they come into service.
3. ITRは、サービスに入るときにHTTP経由でNERDの初期コピーを取得します。
4. ITRs are preconfigured with a group of certificates whose private keys are used by database authorities to sign the NERD. This list of certificates should be configurable by administrators.
4. ITRは証明書のグループで事前設定されており、その秘密鍵はデータベース権限者がNERDに署名するために使用されます。この証明書のリストは、管理者が設定できるようにする必要があります。
5. ITRs next verify both the validity of the public key and the signed digest. If either fail validation, the ITR attempts to retrieve the NERD from a different source. The process iterates until either a valid database is found or the list of sources is exhausted.
5. 次に、ITRは公開鍵と署名済みダイジェストの有効性の両方を検証します。いずれかの検証に失敗した場合、ITRは別のソースからNERDを取得しようとします。このプロセスは、有効なデータベースが見つかるか、ソースのリストがなくなるまで繰り返されます。
6. Once a valid NERD is retrieved, the ITR installs it into both non-volatile and local memory.
6. 有効なNERDが取得されると、ITRはそれを不揮発性メモリとローカルメモリの両方にインストールします。
7. At some point, the authority updates the NERD and increments the database version counter. At the same time, it generates a list of changes, which it also signs, as it does with the original database.
7. ある時点で、オーソリティはNERDを更新し、データベースバージョンカウンターをインクリメントします。同時に、元のデータベースと同様に、変更のリストが生成され、それに署名も行われます。
8. Periodically, ITRs will poll from their list of servers to determine if a new version of the database exists. When a new version is found, an ITR will attempt to retrieve a change file, using its list of preconfigured servers.
8. ITRは定期的にサーバーのリストをポーリングして、データベースの新しいバージョンが存在するかどうかを判断します。新しいバージョンが見つかると、ITRは事前設定されたサーバーのリストを使用して、変更ファイルを取得しようとします。
9. The ITR validates a change file just as it does the original database. Assuming the change file passes validation, the ITR installs new entries, overwrites existing ones, and removes empty entries, based on the content of the change file.
9. ITRは、元のデータベースと同じように変更ファイルを検証します。変更ファイルが検証に合格すると、ITRは変更ファイルの内容に基づいて、新しいエントリをインストールし、既存のエントリを上書きし、空のエントリを削除します。
As time goes on, it is quite possible that an ITR may probe a list of configured peers for a database or change file copy. It is equally possible that peers might advertise to each other the version number of their database. Such methods are not explored in depth in this memo but are mentioned for future consideration.
時間が経つにつれ、ITRがデータベース用に構成されたピアのリストを調査したり、ファイルのコピーを変更したりする可能性があります。同様に、ピアがデータベースのバージョン番号を相互にアドバタイズする可能性もあります。そのような方法は、このメモでは詳細に探求されていませんが、将来の検討のために言及されています。
[RFC6830] describes the basic approach to what happens when a packet arrives at an ITR, and what communications between the ITR and ETR take place. NERD provides an optimistic approach to establishing communications with an ETR that is responsible for a given EID-Prefix. State must be kept, however, on an ITR to determine whether that ETR is in fact reachable. It is expected that this is a common requirement across LISP mapping systems, and will be handled in the core LISP architecture.
[RFC6830]は、パケットがITRに到着したときに何が起こるか、およびITRとETRの間でどのような通信が行われるかについての基本的なアプローチを説明しています。 NERDは、特定のEIDプレフィックスを担当するETRとの通信を確立するための楽観的なアプローチを提供します。ただし、ETRが実際に到達可能かどうかを判断するには、ITRの状態を維持する必要があります。これはLISPマッピングシステム全体で共通の要件であり、コアLISPアーキテクチャで処理されることが予想されます。
This memo does not specify who the database authority is. That is because there are several possible operational models. In each case, the number of database authorities is meant to be small so that ITRs need only keep a small list of authorities, similar to the way a name server might cache a list of root servers.
このメモは、データベース権限が誰であるかを指定していません。これは、いくつかの可能な運用モデルがあるためです。いずれの場合も、ネームサーバーがルートサーバーのリストをキャッシュするのと同じように、ITRが保持できる権限のリストは少なくて済むように、データベース権限の数は少なくする必要があります。
o A single database authority exists. In this case, all entries in the database are registered to a single entity, and that entity distributes the database. Because the EID space is provider-independent address space, there is no architectural requirement that address space be hierarchically distributed to anyone, as there is with provider-assigned address space. Hence, there is a natural affinity between the IANA function and the database authority function.
o 単一のデータベース権限が存在します。この場合、データベース内のすべてのエントリが単一のエンティティに登録され、そのエンティティがデータベースを配布します。 EIDスペースはプロバイダーに依存しないアドレススペースであるため、プロバイダーが割り当てたアドレススペースのように、アドレススペースを階層的に誰にでも配布するというアーキテクチャ上の要件はありません。したがって、IANA機能とデータベース権限機能の間には自然な親和性があります。
o Each region runs a database authority. In this case, provider-independent address space is allocated to either RIRs or to affiliates of such organizations of network operations guilds (NOGs). The benefit of this approach is that there is no single organization that controls the database. It allows one database authority to back up another. One could envision as many as ten database authorities in this scenario. One drawback to this approach, however, is that any reference to a region imposes a notion of locality, thus potentially diminishing the split between Locator and identifier.
o各リージョンはデータベース権限を実行します。この場合、プロバイダーに依存しないアドレススペースは、RIRまたはそのようなネットワークオペレーションギルド（NOG）の組織の関連会社に割り当てられます。このアプローチの利点は、データベースを制御する単一の組織が存在しないことです。これにより、あるデータベース権限が別のデータベース権限をバックアップできるようになります。このシナリオでは、10ものデータベース権限を想定できます。ただし、このアプローチの1つの欠点は、領域への参照は局所性の概念を課すため、LocatorとIDの間の分割が潜在的に減少することです。
o Each country runs a database authority. This could occur should countries decide to regulate this function. While limiting the scope of any single database authority as the previous scenario describes, this approach would introduce some overhead as the list of database authorities would grow to as many as 200, and possibly more if jurisdictions within countries attempted to regulate the function. There are two drawbacks to this approach. First, as distribution of EIDs is driven to more local jurisdictions, an EID-Prefix is tied even more tightly to a location. Second, a large number of database authorities will demand some sort of discovery mechanism.
o 各国はデータベース機関を運営しています。これは、国がこの機能を規制することを決定した場合に発生する可能性があります。前のシナリオで説明したように、単一のデータベース権限の範囲を制限する一方で、このアプローチでは、データベース権限のリストが200に増え、場合によっては国内の管轄区域が機能を規制しようとするとさらに多くなるため、オーバーヘッドが発生します。このアプローチには2つの欠点があります。第1に、EIDの配布がより多くの地方管轄区に向けられるようになると、EIDプレフィックスは場所により密接に結び付けられます。第2に、多数のデータベース権限は、ある種の検出メカニズムを要求します。
o Independent operators manage database authorities. This has the appeals of being location independent and enabling competition for good performance. This method has the drawback of potentially requiring a discovery mechanism.
o 独立したオペレーターがデータベース権限を管理します。これは、場所に依存せず、優れたパフォーマンスを競うことができるという魅力があります。この方法には、検出メカニズムが必要になる可能性があるという欠点があります。
The latter two approaches are not mutually exclusive. While this specification allows for multiple databases, discovery mechanisms are left as future work.
後者の2つのアプローチは相互に排他的ではありません。この仕様では複数のデータベースが許可されていますが、ディスカバリメカニズムは将来の作業として残されています。
The NERD consists of a header that contains a database version and a signature that is generated by ignoring the signature field and setting the authentication block length to 0 (NULL). The authentication block itself consists of a signature and a certificate whose private-key counterpart was used to generate the signature.
NERDは、データベースバージョンを含むヘッダーと、署名フィールドを無視して認証ブロック長を0（NULL）に設定することによって生成される署名で構成されます。認証ブロック自体は、署名と、署名の生成に使用された秘密鍵の対応する証明書で構成されています。
Records are kept sorted in numeric order with AFI plus EID as primary key and prefix length as secondary. This is so that after a database update it should be possible to reconstruct the database to verify the digest signature, which may be retrieved separately from the database for verification purposes.
レコードは、AFIとEIDを主キー、プレフィックス長を副キーとして、数値順にソートされたままになります。これは、データベースの更新後にデータベースを再構築して、検証目的でデータベースとは別に取得できるダイジェスト署名を検証できるようにするためです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Schema Vers=1 | DB Code | Database Name Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Database Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old Database Version or 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Database Name |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Block Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PKCS#7 Block Containing Certificate and Signature |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Database Header
データベースヘッダー
The 'DB Code' field indicates 0 if what follows is an entire database or 1 if what follows is an update. The 'Database Version' field holds the database file version, which is incremented each time the complete database is generated by the authority. In the case of an update, the field indicates the new database file version, and the old database file version is indicated in the 'Old Database Version' field. The database file version is used by routers to determine whether or not they have the most current database.
「DBコード」フィールドは、データベース全体の場合は0を示し、更新の場合は1を示します。 「データベースバージョン」フィールドには、データベースファイルのバージョンが保持されます。これは、完全なデータベースがオーソリティによって生成されるたびに増分されます。更新の場合、フィールドは新しいデータベースファイルのバージョンを示し、古いデータベースファイルのバージョンは[古いデータベースのバージョン]フィールドに示されます。データベースファイルのバージョンは、ルーターが最新のデータベースを持っているかどうかを判断するために使用されます。
The 'Database Name' field holds a DNS-ID, as specified in [RFC6125]. This is the name that will appear in the Subject field of the certificate used to verify the database. The purpose of the database name is to allow for more than one database. Such databases would be merged by the router. It is important that an EID-to-RLOC mapping be listed in no more than one database, lest inconsistencies arise. However, it may be possible to transition a mapping from one database to another. During the transition period, the mappings would be identical. When they are not, the resultant behavior will be undefined. The database name is padded with NULLs to the nearest fourth byte.
[データベース名]フィールドは、[RFC6125]で指定されているDNS-IDを保持します。これは、データベースの検証に使用される証明書の[件名]フィールドに表示される名前です。データベース名の目的は、複数のデータベースを許可することです。このようなデータベースは、ルーターによってマージされます。 EIDからRLOCへのマッピングは、不整合が生じないように、1つのデータベースのみにリストすることが重要です。ただし、マッピングを1つのデータベースから別のデータベースに移行できる場合があります。移行期間中、マッピングは同じになります。そうでない場合、結果の動作は未定義になります。データベース名には、最も近い4番目のバイトまでNULLが埋め込まれます。
The PKCS#7 [RFC2315] authentication block contains a DER-encoded [ITU.X509.2000] signature and associated public key. For the purposes of this experiment, all implementations will support the RSA encryption signature algorithm and SHA1 digest algorithm, and the standard attributes are expected to be present.
PKCS＃7 [RFC2315]認証ブロックには、DERエンコードされた[ITU.X509.2000]署名と関連する公開鍵が含まれています。この実験では、すべての実装でRSA暗号化署名アルゴリズムとSHA1ダイジェストアルゴリズムがサポートされ、標準属性が存在することが期待されます。
N.B., it has been suggested that the Cryptographic Message Syntax (CMS) [RFC5652] be used instead of PKCS#7. At the time this experiment was performed, CMS was not yet widely deployed. However, it is certainly the correct direction and should be strongly considered in future related work.
注：PKCS＃7の代わりに暗号化メッセージ構文（CMS）[RFC5652]を使用することが推奨されています。この実験が行われた時点では、CMSはまだ広く展開されていませんでした。ただし、これは確かに正しい方向であり、将来の関連作業で強く検討する必要があります。
As distributed over the network, NERD records appear as follows:
ネットワークを介して配布されると、NERDレコードは次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num. RLOCs | EID Pref. Len | EID AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 1 | Weight 1 | AFI 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 2 | Weight 2 | AFI 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority 3 | Weight 3 | AFI 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Locator 3... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EID AFI is the AFI of the EID. Priority N, Weight N, and AFI N are associated with Routing Locator N. There will always be at least one RLOC. The minimum record size for IPv4 is 16 bytes. Each additional IPv4 RLOC increases the record size by 8 bytes. The purpose of this format is to keep the database compact, but somewhat easily read. The meaning of weight and priority are described in [RFC6830]. The format of the AFI is specified by IANA in the "Address Family Numbers" registry, with the exception of how IPv6 EID-Prefixes are stored.
EID AFIはEIDのAFIです。優先度N、重みN、およびAFI NはルーティングロケータNに関連付けられています。常に少なくとも1つのRLOCがあります。 IPv4の最小レコードサイズは16バイトです。 IPv4 RLOCを追加するたびに、レコードサイズが8バイト増加します。このフォーマットの目的は、データベースをコンパクトに保つことですが、多少読みやすいです。重みと優先度の意味は[RFC6830]で説明されています。 AFIの形式は、IPv6 EIDプレフィックスの格納方法を除いて、IANAの「Address Family Numbers」レジストリで指定されています。
NERD assumes that EIDs stored in the database are prefixes, and therefore are accompanied with prefix lengths. In order to reduce storage and transmission amounts for IPv6, only the necessary number of bytes of an EID as specified by the prefix length are kept in the record, rounded to the nearest 4-byte (word) boundary. For instance, if the prefix length is /49, the nearest 4-byte word boundary would require that 8 bytes are stored. IPv6 RLOCs are represented as normal 128-bit IPv6 addresses.
NERDは、データベースに格納されているEIDがプレフィックスであることを前提としているため、プレフィックス長が付いています。 IPv6のストレージと伝送の量を減らすために、接頭辞の長さで指定されたEIDの必要なバイト数のみがレコードに保持され、最も近い4バイト（ワード）境界に丸められます。たとえば、プレフィックス長が/ 49の場合、最も近い4バイトのワード境界では8バイトを格納する必要があります。 IPv6 RLOCは、通常の128ビットIPv6アドレスとして表されます。
A database update contains a set of changes to an existing database. Each {AFI, EID, mask-length} tuple may have zero or more RLOCs associated with it. In the case where there are no RLOCs, the EID entry is removed from the database. Records that contain EIDs and prefix lengths that were not previously listed are simply added. Otherwise, the old record for the EID and prefix length is replaced by the more current information. The record format used by the database update is the same as described in Section 3.1.
データベースの更新には、既存のデータベースに対する一連の変更が含まれます。各{AFI、EID、マスク長}タプルには、0個以上のRLOCが関連付けられている場合があります。 RLOCがない場合、EIDエントリはデータベースから削除されます。以前にリストされていなかったEIDとプレフィックス長を含むレコードは、単に追加されます。それ以外の場合、EIDとプレフィックス長の古いレコードは、最新の情報に置き換えられます。データベース更新で使用されるレコード形式は、セクション3.1で説明したものと同じです。
Bootstrap occurs when a router needs to retrieve the entire database. It knows it needs to retrieve the entire database because either it has none or it has an update too substantial to process, as might be the case if a router has been out of service for a substantially lengthy period of time.
ブートストラップは、ルーターがデータベース全体を取得する必要がある場合に発生します。ルーターが非常に長い期間サービスを停止していた場合のように、データベースがまったくないか、更新内容が大きすぎて処理できないため、データベース全体を取得する必要があることを認識しています。
To bootstrap, the ITR appends the database name plus "/current/ entiredb" to a base distribution URI and retrieves the file via HTTP. More formally (using ABNF from [RFC5234]):
ブートストラップするために、ITRはデータベース名と「/ current / holedb」をベース配布URIに追加し、HTTP経由でファイルを取得します。より正式に（[RFC5234]のABNFを使用）：
entire-db = base-uri dbname "/current/entiredb"
base-uri = uri ; from RFC 3986
dbname = DNS-ID ; from RFC 6125
For example, if the base distribution URI is "http://www.example.com/eiddb/", and assuming a database name of "nerd.arin.net", the ITR would request "http://www.example.com/eiddb/nerd.arin.net/current/entiredb". Routers check the signature on the database prior to installing it, and they check that the database schema matches a schema they understand. Once a router has a valid database, it stores that database in some sort of non-volatile memory (e.g., disk, flash memory, etc).
たとえば、ベース配布URIが「http://www.example.com/eiddb/」で、データベース名が「nerd.arin.net」であるとすると、ITRは「http：//www.example .com / eiddb / nerd.arin.net / current / entiredb」。ルーターは、インストールする前にデータベースの署名をチェックし、データベーススキーマが理解しているスキーマと一致することを確認します。ルーターは、有効なデータベースを取得すると、そのデータベースをある種の不揮発性メモリ（ディスク、フラッシュメモリなど）に保存します。
N.B., the host component for such URIs should not resolve to a LISP EID, lest a circular dependency be created.
N.B.、循環依存関係が作成されないように、このようなURIのホストコンポーネントはLISP EIDに解決しないでください。
In order to retrieve a set of database changes, an ITR will have previously retrieved the entire database. Hence, it knows the current version of the database it has. Its first step for retrieving changes is to retrieve the current version number of the database. It does so by appending "/current/version" to the base distribution URI and database name and retrieving the file. Its format is text, and it contains the integer value of the current database version.
一連のデータベース変更を取得するために、ITRは以前にデータベース全体を取得しています。したがって、データベースの現在のバージョンを認識しています。変更を取得するための最初のステップは、データベースの現在のバージョン番号を取得することです。これは、ベース配布URIとデータベース名に「/ current / version」を追加し、ファイルを取得することによって行われます。形式はテキストで、現在のデータベースバージョンの整数値が含まれます。
Once an ITR has retrieved the current version, it compares the version of its local copy. If there is no difference, then the router is up to date and need take no further actions until it next checks.
ITRが現在のバージョンを取得すると、ローカルコピーのバージョンを比較します。違いがない場合、ルータは最新であり、次にチェックするまで、それ以上のアクションを実行する必要はありません。
If the versions differ, the router next sends a request for the appropriate change file by appending "current/changes/" and the textual representation of the version of its local copy of the database to the base distribution URI. More formally:
バージョンが異なる場合、ルーターは次に、「current / changes /」とデータベースのローカルコピーのバージョンのテキスト表現をベース配布URIに追加して、適切な変更ファイルのリクエストを送信します。より正式には：
db-version = base-uri dbname "/current/version"
db-curupdate = base-uri dbname "/current/changes/" old-version
old-version = 1*DIGIT
For example, if the current version of the database is 1105503, the router's version is 1105500, and the base URI and database name are the same as above, the router would first request "http://www.example.com/eiddb/nerd.arin.net/current/version" to determine that it is out of date, and also to learn the current version. It would then attempt to retrieve "http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500".
たとえば、データベースの現在のバージョンが1105503で、ルーターのバージョンが1105500で、ベースURIとデータベース名が上記と同じである場合、ルーターは最初に "http://www.example.com/eiddb/ nerd.arin.net/current/version "が古いことを確認し、現在のバージョンを確認します。次に、「http://www.example.com/eiddb/nerd.arin.net/current/changes/1105500」の取得を試みます。
The server may not have that change file, either because there are too many versions between what the router has and what is current or because no such change file was generated. If the server has changes from the router's version to any later version, the server issues an HTTP redirect to that change file, and the router retrieves and processes it. More formally:
ルーターのバージョンと現在のバージョンの間にバージョンが多すぎるか、そのような変更ファイルが生成されなかったため、サーバーにその変更ファイルがない可能性があります。サーバーにルーターのバージョンからそれ以降のバージョンへの変更がある場合、サーバーはその変更ファイルにHTTPリダイレクトを発行し、ルーターはそれを取得して処理します。より正式には：
db-incupdate = base-uri dbname "/" newer-version
"/changes/" old-version
newer-version = 1*DIGIT
For example:
例えば：
"http://www.example.com/eiddb/nerd.arin.net/1105450/changes/1105401" would update a router from version 1105401 to 1105450. Once it has done so, the router should then repeat the process until it has brought itself up to date.
"http://www.example.com/eiddb/nerd.arin.net/1105450/changes/1105401"は、ルーターをバージョン1105401から1105450に更新します。更新が完了すると、ルーターはそれまでプロセスを繰り返します。最新の状態にしています。
This begs the question: how does a router know to retrieve version 1105450 in our example above? It cannot. A redirect must be given by the server to that URI when the router attempts to retrieve differences from the current version, say, 1105503.
これは疑問を投げかけます：上記の例では、ルーターはどのようにしてバージョン1105450を取得するのですか？できない。ルーターが現在のバージョン（1105503など）との違いを取得しようとする場合、サーバーからそのURIにリダイレクトする必要があります。
While it is unlikely that database versions would wrap, as they consist of 32-bit integers, should the event occur, ITRs should attempt first to retrieve a change file when their current version number is within 10,000 of 2^32 and they see a version available that is less than 10,000. Barring the availability of a change file, the ITR can still assume that the database version has wrapped and retrieve a new copy. It may be safer in future work to include additional wrap information or a larger field to avoid having to use any heuristics.
イベントが発生した場合、32ビット整数で構成されるため、データベースバージョンがラップする可能性は低いですが、ITRは、現在のバージョン番号が2 ^ 32の10,000以内であり、バージョンが表示されている場合、最初に変更ファイルを取得しようとします。 10,000未満です。変更ファイルが利用できない場合でも、ITRはデータベースバージョンがラップされていると想定して、新しいコピーを取得できます。ヒューリスティックを使用する必要がないように、追加のラップ情報またはより大きなフィールドを含めることは、将来の作業でより安全になる可能性があります。
We will start our analysis by looking at how much data will be transferred to a router during bootstrap conditions. We will then look at the bandwidth required. Next, we will turn our concerns to servers. Finally, we will ponder the effect of providing only changes.
ブートストラップ状態中にルーターに転送されるデータの量を調べることから、分析を開始します。次に、必要な帯域幅を確認します。次に、懸念をサーバーに向けます。最後に、変更のみを提供する効果について考察します。
In the analysis below, we treat the overhead of the database header as insignificant (because it is). The analysis should be similar, whether a single database or multiple databases are employed, as we would assume that no entry would appear more than once.
以下の分析では、データベースヘッダーのオーバーヘッドを重要でないものとして扱います（それが重要であるため）。単一のデータベースを使用する場合でも、複数のデータベースを使用する場合でも、分析は類似しているはずです。
By its very nature, the information to be transported is relatively static and is specifically designed to be topologically insensitive. That is, every ITR is intended to have the same set of RLOCs for a given EID. While some processing power will be necessary to install a table, the amount required should be far less than that of a routing information database because the level of entropy is intended to be lower.
その性質上、転送される情報は比較的静的であり、トポロジーの影響を受けないように特別に設計されています。つまり、すべてのITRは、特定のEIDに対して同じセットのRLOCを持つことを目的としています。テーブルをインストールするにはある程度の処理能力が必要ですが、エントロピーのレベルを低くすることを目的としているため、必要な量はルーティング情報データベースの場合よりはるかに少なくする必要があります。
For purposes of this analysis, we will assume that the world has migrated to IPv6, as this increases the size of the database, which would be our primary concern. However, to mitigate the size increase, we have limited the size of the prefix transmitted. For purposes of this analysis, we shall assume an average prefix length of 64 bits.
この分析の目的上、データベースのサイズが増加するため、世界がIPv6に移行したと想定します。これは私たちの主な関心事です。ただし、サイズの増加を軽減するために、送信されるプレフィックスのサイズを制限しています。この分析のために、平均プレフィックス長を64ビットと仮定します。
Based on that assumption, Section 3.1 states that mapping information for each EID/prefix includes a group of RLOCs, each with an associated priority and weight, and that a minimum record size with IPv6 EIDs with at least one RLOC is 30 bytes uncompressed. Each additional IPv6 RLOC costs 20 bytes.
その仮定に基づいて、セクション3.1では、各EID /プレフィックスのマッピング情報には、それぞれに優先度と重みが関連付けられたRLOCのグループが含まれ、少なくとも1つのRLOCを持つIPv6 EIDの最小レコードサイズは圧縮されていない30バイトであると述べています。追加のIPv6 RLOCごとに20バイトのコストがかかります。
+-----------+--------+--------+---------+
| 10^n EIDs | 2 RLOC | 4 RLOC | 8 RLOC |
+-----------+--------+--------+---------+
| 4 | 500 KB | 900 KB | 1.70 MB |
| 5 | 5.0 MB | 9.0 MB | 17.0 MB |
| 6 | 50 MB | 90 MB | 170 MB |
| 7 | 500 MB | 900 MB | 1.70 GB |
| 8 | 5.0 GB | 9.0 GB | 17.0 GB |
+-----------+--------+--------+---------+
Table 1: Database size for IPv6 routes with average prefix length of 64 bits
表1：平均プレフィックス長が64ビットのIPv6ルートのデータベースサイズ
Entries in the above table are derived as follows:
上記の表のエントリは、次のように導出されます。
E * (30 + 20 * (R - 1 ))
where E = number of EIDs (10^n), R = number of RLOCs per EID.
ここで、E = EIDの数（10 ^ n）、R = EIDあたりのRLOCの数。
Our scaling target is to accommodate 10^8 multihomed systems, which is one order of magnitude greater than what is discussed in [CARP07]. At 10^8 entries, a device could be expected to use between 5 and 17 GB of RAM for the mapping. No matter the method of distribution, any router that sits in the core of the Internet would require near this amount of memory in order to perform the ITR function. Large-enterprise ETRs would be similarly strained, simply due to the diversity of sites that communicate with one another. The good news is that this is not our starting point, but rather our scaling target, a number that we intend to reach by the year 2050. Our starting point is more likely in the neighborhood of 10^4 or 10^5 EIDs, thus requiring between 500 KB and 17 MB.
私たちのスケーリングの目標は、[CARP07]で説明されているものよりも1桁大きい10 ^ 8マルチホームシステムに対応することです。 10 ^ 8エントリの場合、デバイスは5〜17 GBのRAMをマッピングに使用することが期待できます。配布方法に関係なく、インターネットのコアにあるルーターは、ITR機能を実行するために、この量のメモリの近くを必要とします。大企業のETRも、互いに通信するサイトの多様性のために、同様に負担になります。これは私たちの出発点ではなく、スケーリング目標であり、2050年までに到達する予定の数値です。この開始点は、10 ^ 4または10 ^ 5 EID付近にある可能性が高いため、 500 KB〜17 MBが必要です。
+-------------------+---------+---------+----------+--------+
| Table Size (10^n) | 1 MB/s | 10 MB/s | 100 MB/s | 1 GB/s |
+-------------------+---------+---------+----------+--------+
| 6 | 8 | 0.8 | 0.08 | 0.008 |
| 7 | 80 | 8 | 0.8 | 0.08 |
| 8 | 800 | 80 | 8 | 0.8 |
| 9 | 8,000 | 800 | 80 | 8 |
| 10 | 80,000 | 8,000 | 800 | 80 |
| 11 | 800,000 | 80,000 | 8,000 | 800 |
+-------------------+---------+---------+----------+--------+
Table 2: Number of seconds to process NERD
表2：NERDを処理する秒数
The length of time it takes to receive the database is significant in models where the device acquires the entire table. During this period of time, either the router will be unable to route packets using LISP or it must use some sort of query mechanism for specific EIDs as it populates the rest of its table through the transfer. Table 2 shows us that at our scaling target, the length of time it would take for a router using 1 MB/s of bandwidth is about 80 seconds. We can measure the processing rate in small numbers of hours for any transfer speed greater than that. The fastest processing time shows us as taking 8 seconds to process an entire table of 10^9 bytes and 80 seconds for 10^10 bytes.
データベースの受信にかかる時間は、デバイスがテーブル全体を取得するモデルでは重要です。この期間中、ルータはLISPを使用してパケットをルーティングできなくなるか、転送を通じてテーブルの残りの部分を入力するため、特定のEIDに対して何らかのクエリメカニズムを使用する必要があります。表2は、スケーリングの目標で、1 MB /秒の帯域幅を使用するルーターにかかる時間は約80秒であることを示しています。それ以上の転送速度では、処理時間を数時間で測定できます。最速の処理時間は、10 ^ 9バイトのテーブル全体を処理するのに8秒、10 ^ 10バイトの場合は80秒かかることを示しています。
As easy as it may be for a router to retrieve, the aggregate information may be difficult for servers to transmit, assuming the information is transmitted in aggregate (we'll revisit that assumption later).
ルーターが取得するのと同じくらい簡単に、情報が集約して送信されると仮定すると、サーバーが集約情報を送信するのは難しい場合があります（この仮定は後で再検討します）。
+----------------+------------+-----------+------------+------------+
| # Simultaneous | 10 Servers | 100 | 1,000 | 10,000 |
| Requests | | Servers | Servers | Servers |
+----------------+------------+-----------+------------+------------+
| 100 | 720 | 72 | 72 | 72 |
| 1,000 | 7,200 | 720 | 72 | 72 |
| 10,000 | 72,000 | 7,200 | 720 | 72 |
| 100,000 | 720,000 | 72,000 | 7,200 | 720 |
| 1,000,000 | 7,200,000 | 720,000 | 72,000 | 7,200 |
| 10,000,000 | 72,000,000 | 7,200,000 | 720,000 | 72,000 |
+----------------+------------+-----------+------------+------------+
Table 3: Retrieval time per number of servers in seconds
表3：サーバー数あたりの取得時間（秒）
This assumes an average of 10^8 entries with 4 RLOCs per EID and that each server has access to 1 GB/s, 100% efficient use of that bandwidth, and no compression.
これは、EIDごとに4つのRLOCを持つ平均10 ^ 8エントリを想定し、各サーバーは1 GB / sにアクセスでき、その帯域幅を100％効率的に使用でき、圧縮されていません。
Entries in the above table were generated using the following method:
上記の表のエントリは、次の方法を使用して生成されました。
For 10^8 entries with four RLOCs per EID, the table size is 9.0 GB, per our previous table. Assume 1 GB/s transfer rates and 100% utilization. Protocol overhead is ignored for this exercise. Hence, a single transfer X takes 48 seconds and can get no faster.
EIDごとに4つのRLOCを持つ10 ^ 8エントリの場合、テーブルサイズは前のテーブルごとに9.0 GBです。 1 GB /秒の転送速度と100％の使用率を想定しています。この演習では、プロトコルのオーバーヘッドは無視されます。したがって、1回の転送Xには48秒かかり、それ以上速くなることはありません。
With this in mind, each entry is as follows:
これを念頭に置いて、各エントリは次のとおりです。
max(1X,N*X/S)
where N = number of transfers, X = 72 seconds, and S = number of servers.
ここで、N =転送数、X = 72秒、S =サーバー数。
If we have a distribution model in which every device must retrieve the mapping information upon start, Table 3 shows the length of time in seconds it will take for a given number of servers to complete a transfer to a given number of devices. This table says, as an example, that it would take 72,000 seconds (20 hours) for 1,000,000 ITRs to simultaneously retrieve the database from 1,000 servers, assuming equal load distribution. Should a cold-start scenario occur, this number should be of some concern. Hence, it is important to take some measures both to avoid such a scenario and to ease the load should it occur. The primary defense should be for ITRs to first attempt to retrieve their databases from their peers or upstream providers. Secondary defenses could include data sanity checks within ITRs, with agreed norms for how much the database should change in any given update or over any given period of time. As we will see below, dissemination of changes is considerably less volume.
すべてのデバイスが起動時にマッピング情報を取得する必要がある分散モデルがある場合、表3は、特定の数のサーバーが特定の数のデバイスへの転送を完了するまでにかかる時間（秒）を示しています。この表は、例として、負荷分散が等しいと仮定すると、1,000,000のITRが1,000台のサーバーからデータベースを同時に取得するのに72,000秒（20時間）かかることを示しています。コールドスタートシナリオが発生した場合、この数はいくつかの問題になります。したがって、このようなシナリオを回避し、負荷が発生した場合に負荷を軽減するために、いくつかの対策を講じることが重要です。主な防御策は、ITRが最初にピアまたはアップストリームプロバイダーからデータベースを取得しようとすることです。二次防御には、ITR内のデータ健全性チェックを含めることができ、特定の更新または特定の期間中にデータベースがどれだけ変更する必要があるかについての合意された基準があります。以下で見るように、変更の普及はかなり少ない量です。
+----------------+-------------+---------------+----------------+
| % Daily Change | 100 Servers | 1,000 Servers | 10,000 Servers |
+----------------+-------------+---------------+----------------+
| 0.1% | 300 | 30 | 3 |
| 0.5% | 1,500 | 150 | 15 |
| 1% | 3,000 | 300 | 30 |
| 5% | 15,000 | 1,500 | 150 |
| 10% | 30,000 | 3,000 | 300 |
+----------------+-------------+---------------+----------------+
Table 4: Transfer times for hourly updates, shown in seconds
表4：時間単位の更新の転送時間（秒単位）
Assuming 10 million routers and a database size of 9 GB, resulting transfer times for hourly updates are shown in seconds, given number of servers and daily rate of change. Note that when insufficient resources are devoted to servers, an unsustainable situation arises where updates for the next batch would begin prior to the completion of the current batch.
1000万のルーターと9 GBのデータベースサイズを想定すると、サーバーの数と1日の変更率を考慮して、1時間ごとの更新の転送時間は秒単位で表示されます。サーバーに十分なリソースが割り当てられていない場合、現在のバッチが完了する前に次のバッチの更新が始まるという、持続不可能な状況が発生することに注意してください。
This table shows us that with 10,000 servers the average transfer time with 1 GB/s links for 10,000,000 routers will be 300 seconds with 10% daily change spread over 24 hourly updates. For a 0.1% daily change, that number is 3 seconds for a database of size 9.0 GB.
この表は、10,000台のサーバーで、10,000,000台のルーターの1 GB / sリンクでの平均転送時間が300秒であり、24時間ごとの更新に10％の毎日の変更が分散していることを示しています。毎日0.1％の変更の場合、9.0 GBのデータベースの場合、この数値は3秒です。
The amount of change goes to the purpose of LISP. If its purpose is to provide effective multihoming support to end customers, then we might anticipate relatively few changes. If, on the other hand, service providers attempt to make use of LISP to provide some form of traffic engineering, we can expect the same data to change more often. We cannot conclude much in this regard without additional operational experience. The one thing we can say is that different applications of LISP may require new and different distribution mechanisms. Such optimization is left for another day.
変更の量はLISPの目的に依存します。その目的がエンドユーザーに効果的なマルチホーミングサポートを提供することである場合、比較的少ない変更が予想されます。一方、サービスプロバイダーがLISPを利用して何らかの形のトラフィックエンジニアリングを提供しようとすると、同じデータがより頻繁に変更されることが予想されます。追加の運用経験がなければ、この点について多くを結論付けることはできません。私たちが言えることの1つは、LISPの異なるアプリケーションには、新しい異なる配布メカニズムが必要になる可能性があるということです。そのような最適化は別の日に残されます。
If an attacker can forge an update or tamper with the database, he can in effect redirect traffic to end sites. Hence, integrity and authenticity of the NERD is critical. In addition, a means is required to determine whether a source is authorized to modify a given database. No data privacy is required. Quite to the contrary, this information will be necessary for any ITR.
攻撃者が更新を偽造したり、データベースを改ざんしたりできる場合、攻撃者は事実上、トラフィックをエンドサイトにリダイレクトできます。したがって、NERDの整合性と信頼性は重要です。さらに、特定のデータベースを変更する権限がソースにあるかどうかを判断する手段が必要です。データのプライバシーは必要ありません。まったく逆に、この情報はどのITRにも必要です。
The first question one must ask is who to trust to provide the ITR a mapping. Ultimately, the owner of the EID-Prefix is most authoritative for the mapping to RLOCs. However, were all owners to sign all such mappings, ITRs would need to know which owner is authorized to modify which mapping, creating a problem of O(N^2) complexity.
最初に尋ねなければならない質問は、ITRにマッピングを提供することを信頼する人です。最終的に、EIDプレフィックスの所有者は、RLOCへのマッピングに対して最も権威があります。ただし、すべての所有者がそのようなすべてのマッピングに署名した場合、ITRはどの所有者がどのマッピングを変更することを許可されているかを知る必要があり、O（N ^ 2）の複雑さの問題が発生します。
We can reduce this problem substantially by investing some trust in a small number of entities that are allowed to sign entries. If an authority manages EIDs much the same way a domain name registrar handles domains, then the owner of the EID would choose a database authority she or he trusts, and ITRs must trust each such authority in order to map the EIDs listed by that authority to RLOCs. This reduces the amount of management complexity on the ETR to retaining knowledge of O(# authorities), but does require that each authority establish procedures for authenticating the owner of an EID. Those procedures needn't be the same.
エントリへの署名が許可されている少数のエンティティへの信頼に投資することで、この問題を大幅に減らすことができます。機関がドメイン名レジストラがドメインを処理するのとほぼ同じ方法でEIDを管理する場合、EIDの所有者は信頼するデータベース機関を選択し、ITRはその機関がリストするEIDをマッピングするためにそのような各機関を信頼する必要があります。 RLOC。これにより、ETRの管理の複雑さが軽減され、O（＃機関）の知識が保持されますが、各機関がEIDの所有者を認証するための手順を確立する必要があります。これらの手順は同じである必要はありません。
There are two classic methods to ensure integrity of data:
データの整合性を保証するには、2つの古典的な方法があります。
o secure transport of the source of the data to the consumer, such as Transport Layer Security (TLS) [RFC5246]; and
o トランスポート層セキュリティ（TLS）[RFC5246]など、データのソースをコンシューマに安全に転送します。そして
o provide object-level security.
o オブジェクトレベルのセキュリティを提供します。
These methods are not mutually exclusive, although one can argue about the need for the former, given the latter.
これらの方法は相互に排他的ではありませんが、後者の場合、前者の必要性について議論することができます。
In the case of TLS, when it is properly implemented, the objects being transported cannot easily be modified by interlopers or so-called men in the middle. When data objects are distributed to multiple servers, each of those servers must be trusted. As we have seen above, we could have quite a large number of servers, thus providing an attacker a large number of targets. We conclude that some form of object-level security is required.
TLSの場合、適切に実装されていると、転送されるオブジェクトは侵入者や途中のいわゆる男性によって簡単に変更できません。データオブジェクトが複数のサーバーに配布される場合、それらの各サーバーは信頼されている必要があります。上記で見たように、サーバーが非常に多数になる可能性があるため、攻撃者に多数のターゲットが提供されます。何らかの形のオブジェクトレベルのセキュリティが必要であると結論付けます。
Object-level security involves an authority signing an object in a way that can easily be verified by a consumer, e.g., a router. In this case, we would want the mapping table and any incremental update to be signed by the originator of the update. This implies that we cannot simply make use of a tool like CVS [CVS]. Instead, the originator will want to generate diffs, sign them, and make them available either directly or through some sort of content distribution or peer to peer network.
オブジェクトレベルのセキュリティには、ルーターなどのコンシューマが簡単に確認できる方法でオブジェクトに署名する権限が含まれます。この場合、マッピングテーブルと増分更新には、更新の発信者が署名する必要があります。これは、CVS [CVS]のようなツールを単純に利用できないことを意味します。代わりに、発信者は差分を生成して署名し、直接または何らかのコンテンツ配信またはピアツーピアネットワークを介して利用できるようにします。
X.509 provides a certificate hierarchy that has scaled to the size of the Internet. The system is most manageable when there are few certificates to manage. The model proposed in this memo makes use of one current certificate per database authority. The two pieces of information necessary to verify a signature, therefore, are as follows:
X.509は、インターネットのサイズに合わせて調整された証明書階層を提供します。管理する証明書が少ない場合、システムは最も管理しやすくなります。このメモで提案されているモデルは、データベース機関ごとに1つの現在の証明書を使用します。したがって、署名の検証に必要な2つの情報は次のとおりです。
o the certificate of the database authority, which can be provided along with the database; and
o データベースと共に提供できるデータベース機関の証明書。そして
o the certificate authority's certificate.
o 認証局の証明書。
The latter two pieces of information must be very well known and must be configured on each ITR. It is expected that both would change very rarely, and it would not be unreasonable for such updates to occur as part of a normal OS release process.
後者の2つの情報は非常によく知られており、各ITRで設定する必要があります。どちらもめったに変更されないことが予想され、そのような更新が通常のOSリリースプロセスの一部として発生することは不合理ではありません。
The tools for both signing and verifying are readily available. OpenSSL (http://www.openssl.org) provides tools and libraries for both signing and verifying. Other tools commonly exist.
署名と検証の両方のツールがすぐに利用できます。 OpenSSL（http://www.openssl.org）は、署名と検証の両方のためのツールとライブラリを提供します。他のツールが一般的に存在します。
Use of PKIs is not without implementation complexity, operational complexity, or risk. The following risks and mitigations are identified with NERD's use of PKIs:
PKIの使用には、実装の複雑さ、運用の複雑さ、またはリスクがないわけではありません。 NERDのPKIの使用により、次のリスクと軽減策が特定されます。
The private key of a NERD authority is exposed: In this case, an attacker could sign a false database update, either redirecting traffic or otherwise causing havoc. The NERD administrator must revoke its existing key and issue a new one. The certificate is added to a certificate revocation list (CRL), which may be distributed with both this and other databases, as well as through other channels. Because this event is expected to be rare, and the number of database authorities is expected to be small, a CRL will be small. When a router receives a revocation, it checks it against its existing databases, and attempts to update the one that is revoked. This implies that prior to issuing the revocation, the database authority would sign an update with the new key. Routers would discard updates they have already received that were signed after the revocation was generated. If a router cannot confirm whether the authority's certificate was revoked before or after a particular update, it will retrieve a fresh new copy of the database with a valid signature.
NERD権限の秘密鍵が公開されます。この場合、攻撃者は、トラフィックをリダイレクトするか、または他の方法で大混乱を引き起こして、誤ったデータベース更新に署名する可能性があります。 NERD管理者は、既存のキーを取り消して、新しいキーを発行する必要があります。証明書は証明書失効リスト（CRL）に追加されます。CRLは、このデータベースと他のデータベースの両方、および他のチャネルを通じて配布できます。このイベントはまれであると予想され、データベース権限の数は少ないと予想されるため、CRLは小さくなります。ルーターは失効を受信すると、既存のデータベースと照合して、失効したデータベースの更新を試みます。これは、失効を発行する前に、データベース権限が新しいキーで更新に署名することを意味します。ルーターは、失効の生成後に署名された、既に受け取った更新を破棄します。ルーターが特定の更新の前または後に取り消されたかどうかを確認できない場合、ルーターは有効な署名を持つデータベースの新しい新しいコピーを取得します。
The private key associated with a CA in the chain of trust of the Authority's certificate is compromised: In this case, it becomes possible for an attacker to masquerade as the database authority. To ameliorate damage, the database authority revokes its certificate and get a new certificate issued from a CA that is not compromised. Once it has done so, the previous procedure is followed. The compromised certificate can be removed during the normal OS upgrade cycle. In the case of the root authority, the situation could be more serious. Updates to the OS in the ITR need to be validated prior to installation. One possible method of doing this is provided in [RFC4108]. Trust anchors are assumed to be updated as part of an OS update; implementors should consider using a key other than the trust anchor for validating OS updates.
機関の証明書の信頼チェーン内のCAに関連付けられた秘密鍵が危険にさらされています。この場合、攻撃者がデータベース機関を装うことが可能になります。被害を改善するために、データベース機関は証明書を取り消し、侵害されていないCAから発行された新しい証明書を取得します。その後、前の手順に従います。侵害された証明書は、通常のOSアップグレードサイクル中に削除できます。ルート権限の場合、状況はさらに深刻になる可能性があります。 ITRのOSのアップデートは、インストール前に検証する必要があります。これを行う1つの可能な方法は[RFC4108]で提供されています。トラストアンカーは、OS更新の一部として更新されると想定されています。実装者は、OSの更新を検証するために、トラストアンカー以外のキーの使用を検討する必要があります。
An algorithm used if either the certificate or the signature is cracked: This is a catastrophic failure and the above forms of attack become possible. The only mitigation is to make use of a new algorithm. In theory, this should be possible, but in practice it has proved very difficult. For this reason, additional work is recommended to make alternative algorithms available.
証明書または署名のいずれかがクラックされた場合に使用されるアルゴリズム：これは壊滅的な障害であり、上記の形式の攻撃が可能になります。唯一の緩和策は、新しいアルゴリズムを利用することです。理論的にはこれは可能ですが、実際には非常に困難であることが判明しています。このため、別のアルゴリズムを使用できるようにするために、追加の作業が推奨されます。
The NERD authority loses its key or disappears: In this case, nobody can update the existing database. There are few programmatic mitigations. If the database authority places its private keys and suitable amounts of information in escrow, under agreed upon circumstances (for example, no updates for three days), the escrow agent would release the information to a party competent of generating a database update.
NERD権限がそのキーを失うか、消えます。この場合、誰も既存のデータベースを更新できません。プログラムによる緩和策はほとんどありません。データベース当局が、秘密鍵と適切な量の情報をエスクローに配置する場合、合意された状況（たとえば、3日間更新がない）の場合、エスクローエージェントは、データベースの更新を生成できる当事者に情報を公開します。
Because this specification does not require secure transport, if an attacker prevents updates to an ITR for the purposes of having that ITR continue to use a compromised ETR, the ITR could continue to use an old version of the database without realizing a new version has been made available. If one is worried about such an attack, a secure channel (such as SSL) to a secure chain back to the database authority should be used. It is possible that, after some operational experience, later versions of this format will contain additional semantics to address this attack. SSL would also prevent attempts to spoof false database versions on the server.
この仕様は安全な転送を必要としないため、攻撃者がITRが危険にさらされたETRを引き続き使用する目的でITRの更新を阻止した場合、ITRは新しいバージョンが認識されずに古いバージョンのデータベースを引き続き使用する可能性があります利用可能になりました。このような攻撃が心配な場合は、データベース機関への安全なチェーンへの安全なチャネル（SSLなど）を使用する必要があります。ある程度の運用経験の後、このフォーマットの新しいバージョンには、この攻撃に対処するための追加のセマンティクスが含まれる可能性があります。 SSLは、サーバー上の偽のデータベースバージョンを偽装する試みも防止します。
As discussed above, substantial risk would be a cold-start scenario. If an attacker found a bug in a common OS that allowed it to erase an ITR's database, and was able to disseminate that bug, the collective ability of ITRs to retrieve new copies of the database could be taxed by collective demand. The remedy to this is for devices to share copies of the database with their peers, thus making each potential requester a potential service.
上記のように、かなりのリスクはコールドスタートのシナリオです。攻撃者がITRのデータベースを消去することを可能にする一般的なOSのバグを発見し、そのバグを広めることができた場合、ITRがデータベースの新しいコピーを取得する集団的能力は、集団的要求によって課税される可能性があります。これに対する解決策は、デバイスがデータベースのコピーをピアと共有することです。これにより、潜在的な各リクエスターが潜在的なサービスになります。
Many objects these days are distributed as either XML pages or something derived as XML [W3C.REC-xml11-20040204], such as SOAP [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]. Use of such well-known standards allows for high-level tools and library reuse. XML's strength is extensibility. Without a doubt XML would be more extensible than a fixed field database. Why not, then, use these standards in this case? The greatest concern the author had was compactness of the data stream. In as much as this mechanism is used at all in the future, so long as that concern could be addressed, and so long as signatures of the database can be verified, XML probably should be considered.
最近の多くのオブジェクトは、XMLページとして、またはSOAP [W3C.REC-soap12-part1-20070427] [W3C.REC-soap12-part2-20070427]など、XML [W3C.REC-xml11-20040204]として派生したものとして配布されています。 。このようなよく知られた標準を使用すると、高レベルのツールとライブラリの再利用が可能になります。 XMLの強みは拡張性です。間違いなく、XMLは固定フィールドデータベースよりも拡張性が高いでしょう。では、なぜこの場合にこれらの標準を使用しないのですか？著者が最も懸念していたのは、データストリームのコンパクトさでした。このメカニズムが将来的にまったく使用される限り、その懸念に対処でき、データベースの署名を検証できる限り、XMLを検討する必要があります。
We now consider various different mechanisms. The problem of distributing changes in various databases is as old as databases. The author is aware of two obvious approaches that have been well used in the past. One approach would be the wide distribution of CVS repositories. However, for reasons mentioned in Section 5.4, CVS is insufficient to the task.
次に、さまざまなメカニズムについて検討します。さまざまなデータベースに変更を配布するという問題は、データベースと同じくらい古いものです。著者は、過去によく使用されてきた2つの明白なアプローチを認識しています。 1つのアプローチは、CVSリポジトリーの広範な配布です。しかし、5.4節で述べた理由により、CVSはこのタスクには不十分です。
The other tried and true approach is the use of periodic updates in the form of messages. The good old Network News Transfer Protocol (NNTP) [RFC3977] itself provides two separate mechanisms (one push and another pull) to provide a coherent update process. This was in fact used to update molecular biology databases [gb91] in the early 1990s. Netnews offers a way to determine whether articles with specified Article-Ids have been received. In the case where the mapping file source of authority wishes to transmit updates, it can sign a change file and then post it into the network. Routers merely need to keep a record of article ids that it has received. Netnews systems have years ago handled far greater volume of traffic than we envision [Usenet]. Initially this is probably overkill, but it may not be so later in this process. Some consideration should be given to a mechanism known to widely distribute vast amounts of data, as instantaneously as either the sender or the receiver wishes.
もう1つの試みられた真のアプローチは、メッセージの形式で定期的な更新を使用することです。古き良きネットワークニュース転送プロトコル（NNTP）[RFC3977]自体は、一貫した更新プロセスを提供するために、2つの個別のメカニズム（1つはプッシュ、もう1つはプル）を提供します。これは実際、1990年代初頭に分子生物学データベース[gb91]を更新するために使用されました。 Netnewsは、指定されたArticle-Idを持つ記事が受信されたかどうかを判断する方法を提供します。権限のマッピングファイルソースが更新を送信する場合は、変更ファイルに署名して、ネットワークに投稿できます。ルーターは、受信した記事IDの記録を保持するだけで済みます。 Netnewsシステムは、何年も前に、[Usenet]が想定するよりもはるかに大量のトラフィックを処理してきました。最初はおそらくやり過ぎですが、このプロセスの後半ではそうではないかもしれません。膨大な量のデータを瞬時に、送信者または受信者のどちらかが即座に配布することが知られているメカニズムを考慮に入れるべきです。
To attain an additional level of hierarchy in the distribution network, service providers could retrieve information to their own local servers and configure their routers with the host portion of the above URI.
配信ネットワークで追加の階層レベルを実現するために、サービスプロバイダーは独自のローカルサーバーに情報を取得し、上記のURIのホスト部分を使用してルーターを構成できます。
Another possibility would be for providers to establish an agreement on a small set of anycast addresses for use for this purpose. There are limitations to the use of anycast, particularly with TCP. In the midst of a routing flap, an anycast address can become all but unusable. Careful study of such a use as well as appropriate use of HTTP redirects is expected.
別の可能性は、プロバイダーがこの目的で使用するエニーキャストアドレスの小さなセットについて合意を確立することです。特にTCPでのエニーキャストの使用には制限があります。ルーティングフラップの最中は、エニーキャストアドレスがほとんど使用できなくなる可能性があります。このような使用とHTTPリダイレクトの適切な使用については、慎重に検討する必要があります。
It has been proposed that a query/response mechanism be used for this information and specifically that the Domain Name System (DNS) [RFC1034] be used. The previous models do not preclude DNS. DNS has the advantage that the administrative lines are well drawn, and that the ID-to-RLOC mapping is likely to appear very close to these boundaries. DNS also has the added benefit that an entire distribution infrastructure already exists. There are, however, some problems that could impact end hosts when intermediate routers make queries, some of which were first pointed out in [RFC1383]:
この情報にはクエリ/応答メカニズムを使用すること、特にドメインネームシステム（DNS）[RFC1034]を使用することが提案されています。以前のモデルはDNSを排除していません。 DNSには、管理線が適切に描画され、IDからRLOCへのマッピングがこれらの境界に非常に近いように見えるという利点があります。 DNSには、配布インフラストラクチャ全体が既に存在するという追加の利点もあります。ただし、中間ルーターがクエリを行うときにエンドホストに影響を与える可能性のあるいくつかの問題があり、その一部は[RFC1383]で最初に指摘されていました。
o Any query mechanism offers an opportunity for a resource attack if an attacker can force the ITR to query for information. In this case, all that would be necessary would be for a "botnet" (a group of computers that have been compromised and used as vehicles to attack others) to ping or otherwise contact via some normal service hosts that sit behind the ETR. If the botnet hosts themselves are behind ETRs, the victim's ITR will need to query for each and every one of them, thus becoming part of a classic reflector attack.
o 攻撃者がITRに情報を照会させることができる場合、どのクエリメカニズムでもリソース攻撃の機会を提供します。この場合、ETRの背後にある通常のサービスホストを介してpingまたはその他の方法で連絡する「ボットネット」（侵害されて他のユーザーを攻撃する手段として使用されたコンピューターのグループ）に必要なのは、すべてです。ボットネットホスト自体がETRの背後にある場合、被害者のITRはそれらすべてに対してクエリを実行する必要があるため、古典的なリフレクター攻撃の一部になります。
o Packets will be delayed at the very least, and probably dropped in the process of a mapping query. This could be at the beginning of a communication, but it will be impossible for a router to conclude with certainty that this is the case.
o パケットは少なくとも遅延され、おそらくマッピングクエリの処理中にドロップされます。これは通信の開始時である可能性がありますが、これが事実であるとルーターが確信を持って結論付けることは不可能です。
o The DNS has a backoff algorithm that presumes that applications are making queries prior to the beginning of a communication. This is appropriate for end hosts who know in fact when a communication begins. An end user may not enjoy that a router is waiting seconds for a retry.
o DNSには、アプリケーションが通信の開始前にクエリを行うことを前提とするバックオフアルゴリズムがあります。これは、通信がいつ始まるかを実際に知っているエンドホストに適しています。エンドユーザーは、ルーターが再試行を数秒間待機していることを楽しんでいない可能性があります。
o While the administrative lines may appear to be correct, the location of name servers may not be. If name servers sit within PI address space, thus requiring LISP to reach, a circular dependency is created. This is precisely where many enterprise name servers sit. The LISP experiment should not predicate its success on relocation of such name servers.
o 管理行は正しいように見えても、ネームサーバーの場所が正しくない場合があります。ネームサーバーがPIアドレススペース内にあり、LISPに到達する必要がある場合、循環依存関係が作成されます。これは、多くのエンタープライズネームサーバーが置かれている場所です。 LISPの実験は、そのようなネームサーバーの再配置での成功を予測するものであってはなりません。
Nevertheless, DNS may be able to play a role in providing the enterprise control over the mapping of its EIDs to RLOCs. Posit a new DNS record "EID2RLOC". This record is used by the authority to collect and aggregate mapping information so that it may be distributed through one of the other mechanisms. As an example:
それにもかかわらず、DNSは、そのEIDからRLOCへのマッピングを企業が制御する上で役割を果たすことができる場合があります。新しいDNSレコード「EID2RLOC」を配置します。このレコードは、他のメカニズムのいずれかを通じて配布できるように、マッピング情報を収集および集約するために当局によって使用されます。例として：
$ORIGIN 0.10.PI-SPACE. 128 EID2RLOC mask 23 priority 10 weight 5 172.16.5.60 EID2RLOC mask 23 priority 15 weight 5 192.168.1.5
$ ORIGIN 0.10.PI-SPACE。 128 EID2RLOCマスク23優先度10重み5 172.16.5.60 EID2RLOCマスク23優先度15重み5 192.168.1.5
In the above figure, network 10.0.128/23 would delegated to some end system, say, EXAMPLE.COM. They would manage the above zone information. This would allow a DNS mechanism to work, but it would also allow someone to aggregate the information and distribute a table.
上の図では、ネットワーク10.0.128 / 23は、EXAMPLE.COMなどのエンドシステムに委任されます。上記のゾーン情報を管理します。これによりDNSメカニズムが機能しますが、誰かが情報を集約してテーブルを配布することもできます。
The Border Gateway Protocol (BGP) [RFC4271] is currently used to distribute inter-domain routing throughout the Internet. Why not, then, use BGP to distribute mapping entries, or provide a rendezvous mechanism to initialize mapping entries? In fact, this is precisely what LISP Alternative Topology (LISP+ALT) [RFC6836] accomplishes, using a completely separate topology from the normal DFZ. It does so using existing code paths and expertise. The alternative topology also provides an extremely accurate control path from ITRs to ETRs, whereas NERD's operational model requires an optimistic assumption and control-plane functionality to cycle through unresponsive ETRs in an EID-Prefix's mapping entry. The memory-scaling characteristics of LISP+ALT are extremely attractive because of expected strong aggregation, whereas NERD makes almost no attempt at aggregation.
ボーダーゲートウェイプロトコル（BGP）[RFC4271]は、現在、インターネット全体にドメイン間ルーティングを配信するために使用されています。では、BGPを使用してマッピングエントリを配布したり、ランデブーメカニズムを提供してマッピングエントリを初期化したりしないのはなぜですか。実際、これはまさにLISP代替トポロジ（LISP + ALT）[RFC6836]が、通常のDFZとは完全に別のトポロジを使用して実現することです。これは、既存のコードパスと専門知識を使用して行われます。代替トポロジでは、ITRからETRへの非常に正確な制御パスも提供されますが、NERDの運用モデルでは、EIDプレフィックスのマッピングエントリで応答しないETRを循環するために、楽観的な仮定とコントロールプレーン機能が必要です。 LISP + ALTのメモリスケーリング特性は、強力な集約が期待されるため非常に魅力的ですが、NERDは集約をほとんど試みません。
A number of key deployment issues are left open. The principle issue is whether it is deemed acceptable for routers to drop packets occasionally while mapping information is being gathered. This should be the subject of future research for ALT, as it was a key design goal of NERD to avoid such a situation.
いくつかの主要な導入問題は未解決のままです。主要な問題は、マッピング情報が収集されている間にルーターがパケットをドロップすることが許容できると見なされるかどうかです。これは、そのような状況を回避することがNERDの主要な設計目標であったため、ALTの今後の調査の対象となるはずです。
Perhaps it would be useful to use both a prepopulated database such as NERD and a query mechanism (perhaps LISP+ALT, LISP-CONS [LISP-CONS], or DNS) to determine an EID-to-RLOC mapping. One idea would be to receive a subset of the mappings, say, by taking only the NERD for certain regions. This alleviates the need to drop packets for some subset of destinations under the assumption that one's business is localized to a particular region. If one did not have a local entry for a particular EID, one would then make a query.
おそらく、NRDなどの事前入力されたデータベースとクエリメカニズム（おそらくLISP + ALT、LISP-CONS [LISP-CONS]、またはDNS）の両方を使用して、EIDからRLOCへのマッピングを決定すると便利です。 1つのアイデアは、たとえば、特定の地域のNERDのみを取得することによって、マッピングのサブセットを受け取ることです。これにより、ビジネスが特定の地域にローカライズされているという前提の下で、宛先の一部のサブセットのパケットをドロップする必要がなくなります。特定のEIDのローカルエントリがない場合は、クエリを実行します。
One approach to using DNS to query live would be to periodically walk "interesting" portions of the network, in search of relevant records, and to cache them to non-volatile storage. While preventing resource attacks, the walk itself could be viewed as an attack, if the algorithm was not selective enough about what it thought was interesting. A similar approach could be applied to LISP+ALT or LISP-CONS by forcing a data-driven Map Reply for certain sites.
DNSを使用してライブクエリを行う1つの方法は、関連するレコードを検索してネットワークの「興味深い」部分を定期的に調査し、それらを不揮発性ストレージにキャッシュすることです。リソースの攻撃を防止する一方で、アルゴリズムが興味深いと思うものについて十分に選択的でない場合、ウォーク自体を攻撃と見なすことができます。特定のサイトに対してデータ駆動型のマップ応答を強制することにより、LISP + ALTまたはLISP-CONSに同様のアプローチを適用できます。
While LISP and NERD are intended as experiments at this point, it is already obvious one must give serious consideration to circular dependencies with regard to the protocols used and the elements within them.
LISPとNERDはこの時点での実験を目的としていますが、使用するプロトコルとその中の要素に関して循環依存関係を真剣に検討する必要があることはすでに明らかです。
In as much as HTTP depends on DNS, either due to the authority section of a URI or to the configured base distribution URI, these same concerns apply. In addition, any HTTP server that itself makes use of Provider-Independent addresses would be a poor choice to distribute the database for these exact same reasons.
HTTPはDNSに依存しているため、URIの権限セクションまたは設定されたベース配布URIにより、同じ懸念事項が適用されます。さらに、それ自体がプロバイダーに依存しないアドレスを使用する任意のHTTPサーバーは、これらとまったく同じ理由でデータベースを分散するための適切な選択ではありません。
One issue with using HTTP is that it is possible that a middlebox of some form, such as a cache, may intercept and process requests. In some cases, this might be a good thing. For instance, if a cache correctly returns a database, some amount of bandwidth is conserved. On the other hand, if the cache itself fails to function properly for whatever reason, end-to-end connectivity could be impaired. For example, if the cache itself depended on the mapping being in place and functional, a cold-start scenario might leave the cache functioning improperly, in turn providing routers no means to update their databases. Some care must be given to avoid such circumstances.
HTTPの使用に関する1つの問題は、キャッシュなどの何らかの形式のミドルボックスが要求を傍受して処理する可能性があることです。場合によっては、これは良いことかもしれません。たとえば、キャッシュがデータベースを正しく返す場合、ある程度の帯域幅が節約されます。一方、何らかの理由でキャッシュ自体が適切に機能しない場合、エンドツーエンドの接続が損なわれる可能性があります。たとえば、キャッシュ自体が適切に機能しているマッピングに依存している場合、コールドスタートシナリオではキャッシュが正しく機能せず、ルーターがデータベースを更新する手段が提供されない可能性があります。このような状況を回避するために、いくつかの注意を払う必要があります。
Do we need to discuss reachability in more detail? This was clearly an issue at the IST-RING (Information Science Technologies - Routing in Next Generation) workshop. There are two key issues. First, what is the appropriate architectural separation between the data plane and the control plane? Second, is there some specific way in which NERD impacts the data plane?
到達可能性についてさらに詳しく説明する必要がありますか？これは明らかにIST-RING（情報科学技術-次世代のルーティング）ワークショップの問題でした。 2つの重要な問題があります。まず、データプレーンとコントロールプレーンの間の適切なアーキテクチャ上の分離は何ですか？次に、NERDがデータプレーンに影響を与える特定の方法はありますか？
Should we specify a (perhaps compressed) tarball that treads a middle ground for the last question, where each update tarball contains both a signature for the update and for the entire database, once the update is applied?
更新が適用されると、各更新のtarballには、更新のシグネチャとデータベース全体の両方のシグネチャが含まれる、最後の質問の中間点を踏む（おそらく圧縮された）tarballを指定する必要がありますか？
Should we compress? In some initial testing of databases with 1, 5, and 10 million IPv4 EIDs and a random distribution of IPv4 RLOCs, the current format in this document compresses down by a factor of between 35% and 36%, using Burrows-Wheeler block sorting text compression algorithm (bzip2). The NERD used random EIDs with prefix lengths varying from 19-29 bits, with probability weighted toward the smaller masks. This only very roughly reflects reality. A better test would be to start with the existing prefixes found in the DFZ.
圧縮する必要がありますか？ 100万、500万、1000万のIPv4 EIDとIPv4 RLOCのランダムな分布を持つデータベースの初期テストでは、このドキュメントの現在の形式は、Burrows-Wheelerブロックソートテキストを使用して、35％から36％の間で圧縮されます圧縮アルゴリズム（bzip2）。 NERDは、プレフィックス長が19〜29ビットのランダムなEIDを使用し、確率は小さいマスクに向かって重み付けされました。これは非常に大まかに現実を反映しています。より適切なテストは、DFZにある既存のプレフィックスから始めることです。
This memo has specified a database format, an update format, a URI convention, an update method, and a validation method for EID-to-RLOC mappings. We have shown that beyond the predictions of 10^8 EID-prefix entries, the aggregate database size would likely be at most 17 GB. We have considered the amount of servers to distribute that information, and we have demonstrated the limitations of a simple content distribution network and other well-known mechanisms. The effort required to retrieve a database change amounts to between 3 and 30 seconds of processing time per hour at today's gigabit speeds. We conclude that there is no need for an off-box query mechanism today and that there are distinct disadvantages for having such a mechanism in the control plane.
このメモは、EIDからRLOCへのマッピングのデータベース形式、更新形式、URI規則、更新メソッド、および検証メソッドを指定しています。 10 ^ 8 EIDプレフィックスエントリの予測を超えると、データベースの合計サイズは最大で17 GBになる可能性があることを示しました。その情報を配信するサーバーの数を検討し、単純なコンテンツ配信ネットワークやその他のよく知られたメカニズムの制限を実証しました。データベースの変更を取得するために必要な労力は、今日のギガビット速度で1時間あたり3〜30秒の処理時間になります。今日、オフボックスクエリメカニズムは不要であり、そのようなメカニズムをコントロールプレーンに配置することには明確な欠点があると結論付けています。
Beyond this, we have examined alternatives that allow for hybrid models that do use query mechanisms, should our operating assumptions prove overly optimistic. Use of NERD today does not foreclose use of such models in the future, and in fact both models can happily coexist.
これを超えて、私たちの操作上の仮定が過度に楽観的であることが判明した場合に、クエリメカニズムを使用するハイブリッドモデルを可能にする代替案を検討しました。現在のNERDの使用は、将来的にそのようなモデルの使用を排除するものではなく、実際には両方のモデルが共存できます。
Since the first draft of this document in 2007, portions of this work have been implemented. Future work should consider the size of fields, such as the version field, as well as key roll-over and revocation issues. As previously noted, CMS is now widely deployed. Current work on DNS-based authentication of named entities [RFC6698] may provide a means to test authorization of a NERD provider to carry a specific prefix.
2007年のこのドキュメントの最初のドラフト以降、この作業の一部が実装されています。今後の作業では、バージョンフィールドなどのフィールドのサイズ、およびキーのロールオーバーと失効の問題を考慮する必要があります。前述のとおり、CMSは現在広く展開されています。名前付きエンティティのDNSベースの認証[RFC6698]に関する現在の研究は、特定のプレフィックスを運ぶためのNERDプロバイダーの承認をテストする手段を提供するかもしれません。
We leave to future work how the list of databases is distributed, how BGP can play a role in distributing knowledge of the databases, and how DNS can play a role in aggregating information into these databases.
データベースのリストがどのように配布されるか、BGPがデータベースの知識を配布する上でどのように役割を果たすことができるか、およびDNSがこれらのデータベースに情報を集約する上でどのように役割を果たすことができるかについては、今後の作業に委ねます。
We also leave to future work whether HTTP is the best protocol for the job, and whether the scheme described in this document is the most efficient. One could easily envision that when applied in high-delay or high-loss environments, a broadcast or multicast method may prove more effective.
また、HTTPがジョブに最適なプロトコルであるかどうか、およびこのドキュメントで説明されているスキームが最も効率的であるかどうかは、今後の作業に委ねます。高遅延または高損失の環境に適用すると、ブロードキャストまたはマルチキャストの方法がより効果的であることが容易に想像できるでしょう。
Speaking of multicast, we also leave to future work how multicast is implemented, if at all, either in conjunction or as an extension to this model.
マルチキャストといえば、このモデルと組み合わせて、またはこのモデルの拡張として、マルチキャストが実装されているとすれば、将来の作業にまかせます。
Finally, perhaps the most interesting future work would be to understand if and how NERD could be integrated with the LISP mapping server [RFC6833].
最後に、おそらく最も興味深い将来の作業は、NERDをLISPマッピングサーバー[RFC6833]と統合できるかどうか、またどのように統合できるかを理解することでしょう。
Dino Farinacci, Patrik Faltstrom, Dave Meyer, Joel Halpern, Jim Schaad, Dave Thaler, Mohamed Boucadair, Robin Whittle, Max Pritikin, Scott Brim, S. Moonesamy, and Stephen Farrel were very helpful with their reviews of this work. Thanks also to the participants of the Routing Research Group and the IST-RING workshop held in Madrid in December of 2007 for their incisive comments. The astute will notice a lengthy References section. This work stands on the shoulders of many others' efforts.
Dino Farinacci、Patrik Faltstrom、Dave Meyer、Joel Halpern、Jim Schaad、Dave Thaler、Mohamed Boucadair、Robin Whittle、Max Pritikin、Scott Brim、S。Moonesamy、Stephen Farrelは、この作品のレビューに非常に役立ちました。また、ルーティングリサーチグループの参加者、および2007年12月にマドリードで開催されたIST-RINGワークショップの鋭いコメントに感謝します。鋭敏な人は、長い参照セクションに気づくでしょう。この作品は、他の多くの努力の肩に立っています。
[ITU.X509.2000] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.
[ITU.X509.2000] International Telecommunications Union、「Information technology-Open Systems Interconnection-the Directory：Public-key and attribute certificate frameworks」、ITU-T Recommendation X.509、ISO Standard 9594-8、March 2000。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月。
[CARP07] Carpenter, B., "IETF Plenary Presentation: Routing and Addressing: Where we are today", March 2007.
[CARP07]カーペンター、B。、「IETFプレナリープレゼンテーション：ルーティングとアドレス指定：現在の場所」、2007年3月。
[CVS] Grune, R., Baalbergen, E., Waage, M., Berliner, B., and J. Polk, "CVS: Concurrent Versions System", November 1985.
[CVS] Grune、R.、Baalbergen、E.、Waage、M.、Berliner、B。、およびJ. Polk、「CVS：Concurrent Versions System」、1985年11月。
[LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
[LISP-CONS] Farinacci、D.、Fuller、V。、およびD. Meyer、「LISP-CONS：A Content distribution Overlay Network Service for LISP」、Work in Progress、2008年4月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1383] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, December 1992.
[RFC1383] Huitema、C。、「DNSベースのIPルーティングの実験」、RFC 1383、1992年12月。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315] Kaliski、B。、「PKCS＃7：Cryptographic Message Syntax Version 1.5」、RFC 2315、1998年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977] Feather、C。、「Network News Transfer Protocol（NNTP）」、RFC 3977、2006年10月。
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
[RFC4108] Housley、R。、「Cryptographic Message Syntax（CMS）to Protect Firmware Packages」、RFC 4108、2005年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティの認証（DANE）トランスポート層セキュリティ（TLS）プロトコル：TLSA」、RFC 6698、2012年8月。
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013.
[RFC6833] Farinacci、D。およびV. Fuller、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、RFC 6833、2013年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（LISP + ALT）」、RFC 6836、2013年1月。
[Usenet] Wikipedia, "Usenet", January 2013, <http://en.wikipedia.org/w/index.php? title=Usenet&oldid=531545312>.
[Usenet]ウィキペディア、「Usenet」、2013年1月、<http://en.wikipedia.org/w/index.php？タイトル= Usenet＆oldid = 531545312>。
[W3C.REC-soap12-part1-20070427] Gudgin, M., Lafon, Y., Moreau, J., Hadley, M., Karmarkar, A., Mendelsohn, N., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part1-20070427>.
[W3C.REC-soap12-part1-20070427] Gudgin、M.、Lafon、Y.、Moreau、J.、Hadley、M.、Karmarkar、A.、Mendelsohn、N.、and H. Nielsen、 "SOAP Version 1.2パート1：メッセージングフレームワーク（第2版）」、World Wide Web Consortium Recommendation REC-soap12-part1-20070427、2007年4月、<http://www.w3.org/TR/2007/REC-soap12-part1-20070427> 。
[W3C.REC-soap12-part2-20070427] Karmarkar, A., Hadley, M., Mendelsohn, N., Nielsen, H., Lafon, Y., Gudgin, M., and J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part2-20070427, April 2007, <http://www.w3.org/TR/2007/REC-soap12-part2-20070427>.
[W3C.REC-soap12-part2-20070427] Karmarkar、A.、Hadley、M.、Mendelsohn、N.、Nielsen、H.、Lafon、Y.、Gudgin、M.、and J. Moreau、 "SOAP Version 1.2 Part 2：Adjuncts（Second Edition）」、World Wide Web Consortium Recommendation REC-soap12-part2-20070427、2007年4月、<http://www.w3.org/TR/2007/REC-soap12-part2-20070427>。
[W3C.REC-xml11-20040204] Cowan, J., Maler, E., Sperberg-McQueen, C., Paoli, J., Bray, T., and F. Yergeau, "Extensible Markup Language (XML) 1.1", World Wide Web Consortium First Edition REC-xml11-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml11-20040204>.
[W3C.REC-xml11-20040204] Cowan、J.、Maler、E.、Sperberg-McQueen、C.、Paoli、J.、Bray、T。、およびF. Yergeau、「Extensible Markup Language（XML）1.1」 、World Wide Web Consortium First Edition REC-xml11-20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml11-20040204>。
[gb91] Smith, R., Gottesman, Y., Hobbs, B., Lear, E., Kristofferson, D., Benton, D., and P. Smith, "A mechanism for maintaining an up-to-date GenBank database via Usenet", Computer Applications in the Biosciences (CABIOS), April 1991.
[gb91] Smith、R.、Gottesman、Y.、Hobbs、B.、Lear、E.、Kristofferson、D.、Benton、D。、およびP. Smith、「最新のGenBankを維持するためのメカニズムUsenet経由のデータベース」、1991年4月、バイオサイエンスのコンピュータアプリケーション（CABIOS）。
Appendix A. Generating and Verifying the Database Signature with OpenSSL
付録A. OpenSSLを使用したデータベース署名の生成と検証
As previously mentioned, one goal of NERD was to use off-the-shelf tools to both generate and retrieve the database. To many, PKI is magic. This section is meant to provide at least some clarification as to both the generation and verification process, complete with command-line examples. Not included is how you get the entries themselves. We'll assume they exist and that you're just trying to sign the database.
前述のように、NERDの1つの目標は、既成のツールを使用してデータベースを生成および取得することでした。多くの人にとって、PKIは魔法です。このセクションでは、生成プロセスと検証プロセスの両方について、コマンドラインの例を使用して、少なくともいくつかの説明を提供することを目的としています。エントリを取得する方法は含まれていません。それらが存在し、データベースに署名しようとしているだけであると想定します。
To sign the database, to start with, you need a database file that has a database header described in Section 3. Block size should be zero, and there should be no PKCS#7 block at this point. You also need a certificate and its private key with which you will sign the database.
データベースに署名するには、まず、セクション3で説明されているデータベースヘッダーを持つデータベースファイルが必要です。ブロックサイズはゼロであり、この時点ではPKCS＃7ブロックが存在しないはずです。また、データベースへの署名に使用する証明書とその秘密鍵も必要です。
The OpenSSL "smime" command contains all the functions we need from this point forth. To sign the database, issue the following command:
OpenSSLの「smime」コマンドには、これから必要なすべての機能が含まれています。データベースに署名するには、次のコマンドを発行します。
openssl smime -binary -sign -outform DER -signer yourcert.crt \
-inkey yourcert.key -in database-file -out signature
-binary states that no MIME canonicalization should be performed. -sign indicates that you are signing the file that was given as the argument to -in. The output format (-outform) is binary DER, and your public certificate is provided with -signer along with your key with -inkey. The signature itself is specified with -out.
-binaryは、MIME正規化を実行してはならないことを示しています。 -signは、-inの引数として指定されたファイルに署名することを示します。出力形式（-outform）はバイナリDERであり、公開証明書には-signerと-inkeyを使用した鍵が提供されます。署名自体は-outで指定されます。
The resulting file "signature" is then copied into to PKCS#7 block in the database header, its size in bytes is recorded in the PKCS#7 block size field, and the resulting file is ready for distribution to ITRs.
次に、結果のファイル「署名」がデータベースヘッダーのPKCS＃7ブロックにコピーされ、そのサイズ（バイト）がPKCS＃7ブロックサイズフィールドに記録され、結果のファイルはITRに配布できるようになります。
To verify a database file, first retrieve the PKCS#7 block from the file by copying the appropriate number of bytes into another file, say, "signature". Next, zero this field, and set the block size field to 0. Next use the "smime" command to verify the signature as follows:
データベースファイルを確認するには、まず、適切なバイト数を別のファイル、たとえば「署名」にコピーして、ファイルからPKCS＃7ブロックを取得します。次に、このフィールドをゼロにし、ブロックサイズフィールドを0に設定します。次に、「smime」コマンドを使用して、次のように署名を確認します。
openssl smime -binary -verify -inform DER -content database-file
-out /dev/null -in signature
OpenSSL will return "Verification OK" if the signature is correct. OpenSSL provides sufficiently rich libraries to accomplish the above within the C programming language with a single pass.
署名が正しい場合、OpenSSLは「Verification OK」を返します。 OpenSSLは、Cプログラミング言語内で上記を単一のパスで実現するのに十分な豊富なライブラリを提供します。
Author's Address
著者のアドレス
Eliot Lear Cisco Systems GmbH Richtistrasse 7 Wallisellen CH-8304 Switzerland
Eliot Lear Cisco Systems GmbH Richtistrasse 7 Wallisellen CH-8304スイス
Phone: +41 44 878 9200
EMail: lear@cisco.com