[要約] RFC 8886は、セキュアなデバイスのインストール手順を定義するための規格です。このRFCの目的は、デバイスのセキュリティを確保し、信頼性の高いインストールプロセスを提供することです。セキュアなデバイスの展開や管理に役立つ標準化された手順を提供します。
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 8886 Google
Category: Informational C. Doyle
ISSN: 2070-1721 Juniper Networks
September 2020
Secure Device Install
セキュアデバイスのインストール
Abstract
概要
Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support. In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.
オペレータが独自のスタッフがいない場所に新しいネットワークデバイスを展開することは、「リモートハンド」（または類似の）サポートを持つ共有設備でも、最初のインストールと構成を実行するための場所への物理的に移動することを必要とします。。多くの場合、設定の機密性を維持しながら、初期設定を新しいデバイスに転送する簡単な方法がある場合はこれを回避できます。
This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.
このドキュメントは、デバイスのブートストラップ中に初期設定に限定的な機密性を提供するために既存のベンダー独自の自動インストールを拡張します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8886.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8886で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Overview
2.1. Example Scenario
3. Vendor Role
3.1. Device Key Generation
3.2. Directory Server
4. Operator Role
4.1. Administrative
4.2. Technical
4.3. Example Initial Customer Boot
5. Additional Considerations
5.1. Key Storage
5.2. Key Replacement
5.3. Device Reinstall
6. IANA Considerations
7. Security Considerations
8. Informative References
Appendix A. Proof of Concept
A.1. Step 1: Generating the Certificate
A.1.1. Step 1.1: Generate the Private Key
A.1.2. Step 1.2: Generate the Certificate Signing Request
A.1.3. Step 1.3: Generate the (Self-Signed) Certificate Itself
A.2. Step 2: Generating the Encrypted Configuration
A.2.1. Step 2.1: Fetch the Certificate
A.2.2. Step 2.2: Encrypt the Configuration File
A.2.3. Step 2.3: Copy Configuration to the Configuration
Server
A.3. Step 3: Decrypting and Using the Configuration
A.3.1. Step 3.1: Fetch Encrypted Configuration File from
Configuration Server
A.3.2. Step 3.2: Decrypt and Use the Configuration
Acknowledgments
Authors' Addresses
In a growing, global network, significant amounts of time and money are spent deploying new devices and "forklift" upgrading existing devices. In many cases, these devices are in shared facilities (for example, Internet Exchange Points (IXP) or "carrier-neutral data centers"), which have staff on hand that can be contracted to perform tasks including physical installs, device reboots, loading initial configurations, etc. There are also a number of (often proprietary) protocols to perform initial device installs and configurations. For example, many network devices will attempt to use DHCP [RFC2131] or DHCPv6 [RFC8415] to get an IP address and configuration server and then fetch and install a configuration when they are first powered on.
成長しているグローバルネットワークでは、かなりの時間とお金は、新しいデバイスと既存のデバイスのアップグレードを展開するための新しいデバイスと「Forklift」を展開しています。多くの場合、これらのデバイスは、物理インストール、デバイスの再起動、ロードなどのタスクを実行するために契約することができるスタッフが契約することができるスタッフが契約することができる共有機能（例えば、インターネット交換ポイント（IXP）または「キャリアニュートラルデータセンター」）にあります。初期設定など、初期デバイスのインストールと構成を実行するための（多くの場合独自の）プロトコルもあります。たとえば、多くのネットワークデバイスは、IPアドレスと構成サーバーを取得してから、最初に電源が入ったときに設定を取り出してインストールするために、多くのネットワークデバイスがDHCP [RFC2131]またはDHCPv6 [RFC8415]を使用しようとします。
The configurations of network devices contain a significant amount of security-related and proprietary information (for example, RADIUS [RFC2865] or TACACS+ [TACACS] secrets). Exposing these to a third party to load onto a new device (or using an auto-install technique that fetches an unencrypted configuration file via TFTP [RFC1350]) or something similar is an unacceptable security risk for many operators, and so they send employees to remote locations to perform the initial configuration work; this costs time and money.
ネットワークデバイスの構成には、かなりの量のセキュリティ関連および独自の情報が含まれています（例えば、RADIUS [RFC2865]またはTACACS [TACACS]秘密）。新しいデバイスにロードする（または、TFTP [RFC1350]を介して暗号化されていない設定ファイルを取得する自動インストール手法）または同様のものは、多くの演算子にとって許容できないセキュリティリスクがあります。初期設定作業を実行するための遠隔地。これは時間とお金がかかります。
There are some workarounds to this, such as asking the vendor to preconfigure the device before shipping it; asking the remote support to install a terminal server; providing a minimal, unsecured configuration and using that to bootstrap to a complete configuration; etc. However, these are often clumsy and have security issues. As an example, in the terminal server case, the console port connection could be easily snooped.
それを出荷する前に装置を事前設定するためにベンダーに尋ねるなど、これにはいくつかの回避策があります。リモートサポートにターミナルサーバーをインストールするように依頼します。最小限の無担保構成を提供し、それを使用して完全な構成にそれを使用します。しかし、これらはしばしば不器用でセキュリティ上の問題を抱えています。例として、ターミナルサーバーの場合、コンソールポート接続を簡単にスヌーピングできます。
An ideal solution in this space would protect both the confidentiality of device configuration in transit and the authenticity (and authorization status) of configuration to be used by the device. The mechanism described in this document only addresses the former and makes no effort to do the latter, with the device accepting any configuration file that comes its way and is encrypted to the device's key (or not encrypted, as the case may be). Other solutions (such as Secure Zero Touch Provisioning (SZTP) [RFC8572], Bootstrapping Remote Secure Key Infrastructures (BRSKI) [BRSKI], and other voucher-based methods) are more fully featured but also require more complicated machinery. This document describes something much simpler, at the cost of only providing limited protection.
このスペース内の理想的な解決策は、輸送中のデバイス構成の機密性と、デバイスによって使用される構成の信頼性（および許可ステータス）の両方を保護します。この文書に記載されているメカニズムは、前者のアドレスに対処し、デバイスがその方法になる構成ファイルを受け入れ、デバイスのキー（ケースがある場合があります）に暗号化されている（または暗号化されています）。その他の解決策（セキュアゼロタッチプロビジョニング（SZTP）[RFC8572]、リモートセキュアキーインフラストラクチャ（BRSKI）[BRSKI]、およびその他のバウチャーベースの方法など、より完全に機能していますが、より複雑な機械も必要です。この文書では、保護が限られているだけのコストでは、はるかに簡単なことが記載されています。
This document layers security onto existing auto-install solutions (one example of which is [Cisco_AutoInstall]) to provide a method to initially configure new devices while maintaining (limited) confidentiality of the initial configuration. It is optimized for simplicity, for both the implementor and the operator. It is explicitly not intended to be a fully featured system for managing installed devices nor is it intended to solve all use cases; rather, it is a simple targeted solution to solve a common operational issue where the network device has been delivered, fiber has been laid (as appropriate), and there is no trusted member of the operator's staff to perform the initial configuration. This solution is only intended to increase confidentiality of the information in the configuration file and does not protect the device itself from loading a malicious configuration.
この文書レイヤーは、初期設定の機密性を維持しながら新しいデバイスを最初に設定する方法を提供するためのメソッドを提供するための既存の自動インストールソリューション（Cisco_AutoInstall]）へのセキュリティを参照してください。実装者とオペレータの両方に対して、簡単にするために最適化されています。これは、インストールされたデバイスを管理するための完全に特徴付けられたシステムでもなく、すべてのユースケースを解決することを目的としていません。むしろ、ネットワークデバイスが配信されている共通の運用上の問題を解決するための簡単なターゲット解決策であり、ファイバは（必要に応じて）遅れており、初期構成を実行するためにオペレータのスタッフの信頼できるメンバーはありません。この解決策は、構成ファイル内の情報の機密性を高めることを目的としており、悪意のある設定をロードすることからデバイス自体を保護しません。
This document describes a concept and some example ways of implementing this concept. As devices have different capabilities and use different configuration paradigms, one method will not suit all, and so it is expected that vendors will differ in exactly how they implement this.
この文書では、この概念を実装する概念といくつかの例の方法について説明します。デバイスが異なる機能を持ち、異なる構成パラダイムを使用すると、1つのメソッドがすべて合致しません。
This solution is specifically designed to be a simple method on top of exiting device functionality. If devices do not support this new method, they can continue to use the existing functionality. In addition, operators can choose to use this to protect their configuration information or can continue to use the existing functionality.
この解決策は、existingデバイス機能の上に簡単な方法であるように特別に設計されています。デバイスがこの新しいメソッドをサポートしていない場合は、既存の機能を使用し続けることができます。さらに、オペレータは設定情報を保護するためにこれを使用することを選択したり、既存の機能を使用できます。
The issue of securely installing devices is in no way a new issue nor is it limited to network devices; it occurs when deploying servers, PCs, Internet of Things (IoT) devices, and in many other situations. While the solution described in this document is obvious (encrypt the config, then decrypt it with a device key), this document only discusses the use for network devices, such as routers and switches.
デバイスを安全にインストールするという問題は、新しい課題もネットワークデバイスに限定されていません。サーバー、PC、インターネットのインターネット（IOT）デバイスを展開するとき、そして他の多くの状況で発生します。この文書に記載されているソリューションは明らかですが（Configを暗号化してからデバイスキーで復号化されている）、この文書はルーターやスイッチなどのネットワークデバイスの使用のみについて説明します。
Most network devices already include some sort of initial bootstrapping logic (sometimes called 'autoboot' or 'autoinstall'). This generally works by having a newly installed, unconfigured device obtain an IP address for itself and discover the address of a configuration server (often called 'next-server', 'siaddr', or 'tftp-server-name') using DHCP or DHCPv6 (see [RFC2131] and [RFC8415]). The device then contacts this configuration server to download its initial configuration, which is often identified using the device's serial number, Media Access Control (MAC) address, or similar. This document extends this (vendor-specific) paradigm by allowing the configuration file to be encrypted.
ほとんどのネットワークデバイスにはすでにいくつかの初期ブートストラップロジック（ 'autoboot'または 'autoinstall'と呼ばれる）が含まれています。これは一般に、新しくインストールされていないデバイスがそれ自身のIPアドレスを取得し、DHCPを使用して構成サーバー（しばしば 'next-server'、 'siaddr'、または 'tftp-server-name'と呼ばれる）のアドレスを検出します。DHCPv6（[RFC2131]と[RFC8415]を参照）。次にデバイスはこの設定サーバに連絡して初期設定をダウンロードします。これは、デバイスのシリアル番号、メディアアクセス制御（MAC）アドレスなどを使用して識別されることがよくあります。この文書は、構成ファイルを暗号化できるようにすることで、この（ベンダー固有の）PARADIGMを拡張します。
This document uses the serial number of the device as a unique device identifier for simplicity; some vendors may not want to implement the system using the serial number as the identifier for business reasons (a competitor or similar could enumerate the serial numbers and determine how many devices have been manufactured). Implementors are free to choose some other way of generating identifiers (e.g., a Universally Unique Identifier (UUID) [RFC4122]), but this will likely make it somewhat harder for operators to use (the serial number is usually easy to find on a device).
この文書は、単純さのために固有のデバイス識別子としてデバイスのシリアル番号を使用します。ビジネス上の理由からの識別子としてシリアル番号を使用してシステムを実装したくない場合があります（競合他社または類似）、シリアル番号を列挙し、デバイスの製造されたデバイスを決定する可能性がある）。実装者は識別子を生成する他の方法（例えば、普遍的に一意の識別子（UUID）[RFC4122]）を選択することができますが、これはオペレータの使用に多少困難になる可能性があります（シリアル番号は通常デバイス上で見つけるのは簡単です。）。
Operator_A needs another peering router, and so they order another router from Vendor_B to be drop-shipped to the facility. Vendor_B begins assembling the new device and tells Operator_A what the new device's serial number will be (SN:17894321). When Vendor_B first installs the firmware on the device and boots it, the device generates a public-private key pair, and Vendor_B publishes the public key on its key server (in a public key certificate, for ease of use).
operator_aは別のピアリングルータを必要とします。Vendor_Bは新しいデバイスの組み立てを開始し、新しいデバイスのシリアル番号がどのようになるのかをoperator_aに伝えます（SN：17894321）。Vendor_Bが最初にデバイス上にファームウェアをインストールして起動すると、デバイスはパブリック秘密鍵ペアを生成し、Vendor_Bはそのキーサーバー上の公開鍵を（使いやすさのために公開鍵証明書）を公開します。
While the device is being shipped, Operator_A generates the initial device configuration and fetches the certificate from Vendor_B key servers by providing the serial number of the new device. Operator_A then encrypts the device configuration and puts this encrypted configuration on a (local) TFTP server.
デバイスが出荷されている間、operator_aは初期デバイス設定を生成し、新しいデバイスのシリアル番号を提供することによってVendor_Bキーサーバーから証明書を取り出します。その後、operator_aはデバイス構成を暗号化し、この暗号化構成を（ローカル）TFTPサーバに入れます。
When the device arrives at the Point of Presence (POP), it gets installed in Operator_A's rack and cabled as instructed. The new device powers up and discovers that it has not yet been configured. It enters its autoboot state and begins the DHCP process. Operator_A's DHCP server provides it with an IP address and the address of the configuration server. The router uses TFTP to fetch its configuration file. Note that all of this is existing functionality. The device attempts to load the configuration file. As an added step, if the configuration file cannot be parsed, the device tries to use its private key to decrypt the file and, assuming it validates, proceeds to install the new, decrypted configuration.
デバイスがプレゼンスのポイント（POP）に到着すると、Operator_Aのラックにインストールされ、指示されたようにケーブル接続されます。新しいデバイスは起動し、まだ設定されていないことを発見します。自動起動状態に入り、DHCPプロセスを開始します。operator_aのDHCPサーバーはIPアドレスとコンフィギュレーションサーバーのアドレスを提供します。ルータはTFTPを使用して設定ファイルを取得します。これはすべて既存の機能です。デバイスは設定ファイルをロードしようとします。追加されたステップとして、構成ファイルを解析できない場合、そのデバイスはその秘密鍵を使用してファイルを復号化し、検証されたと仮定して、新しい復号化された構成をインストールします。
Only the "correct" device will have the required private key and be able to decrypt and use the configuration file (see Security Considerations (Section 7)). An attacker would be able to connect to the network and get an IP address. They would also be able to retrieve (encrypted) configuration files by guessing serial numbers (or perhaps the server would allow directory listing), but without the private keys, an attacker will not be able to decrypt the files.
「正しい」デバイスだけが必要な秘密鍵を持ち、設定ファイルを復号化して使用することができます（セキュリティ上の考慮事項（セクション7）を参照）。攻撃者はネットワークに接続してIPアドレスを取得することができます。シリアル番号を推測（またはおそらくディレクトリリストを許可する）を推測（暗号化されている）設定ファイルを取得（暗号化）することができますが、秘密鍵がないと、攻撃者はファイルを復号化できなくなります。
This section describes the vendor's roles and provides an overview of what the device needs to do.
このセクションでは、ベンダーの役割について説明し、デバイスがする必要があるものの概要を説明します。
Each device requires a public-private key pair and for the public part to be published and retrievable by the operator. The cryptographic algorithm and key lengths to be used are out of the scope of this document. This section illustrates one method, but, as with much of this document, the exact mechanism may vary by vendor. Enrollment over Secure Transport [RFC7030] and possibly the Simple Certificate Enrollment Protocol [RFC8894] are methods that vendors may want to consider.
各デバイスには、公開鍵のペアと公開部分がオペレータによって公開され検索可能に必要です。使用される暗号化アルゴリズムとキー長はこの文書の範囲外です。このセクションは1つの方法を示していますが、この文書の大部分と同様に、正確なメカニズムはベンダーによって異なります。セキュアトランスポートでの登録[RFC7030]および場合によっては単純な証明書登録プロトコル[RFC8894]は、ベンダーが検討したいメソッドです。
During the manufacturing stage, when the device is initially powered on, it will generate a public-private key pair. It will send its unique device identifier and the public key to the vendor's directory server [RFC5280] to be published. The vendor's directory server should only accept certificates that are from the manufacturing facility and that match vendor-defined policies (for example, extended key usage and extensions). Note that some devices may be constrained and so may send the raw public key and unique device identifier to the certificate publication server, while more capable devices may generate and send self-signed certificates. This communication with the directory server should be integrity protected and should occur in a controlled environment.
製造段階では、デバイスが最初に電源を入れると、公開専用のキーペアが生成されます。それは公開されるべき固有のデバイス識別子と公開鍵をベンダーのディレクトリサーバー[RFC5280]に送ります。Vendorのディレクトリサーバーは、製造施設からの証明書とそれがベンダー定義のポリシーを一致させるための証明書のみを受け入れる必要があります（たとえば、拡張キー使用法と拡張機能など）。いくつかのデバイスは制約されている可能性があり、生の公開鍵と固有のデバイス識別子を証明書公開サーバーに送信してもよいが、より有能なデバイスは自己署名証明書を生成して送信することができます。ディレクトリサーバーとのこの通信は、整合性保護されており、管理された環境で発生するはずです。
This reference architecture needs a serialization format for the key material. Due to the prevalence of tooling support for it on network devices, X.509 certificates are a convenient format to exchange public keys. However, most of the metadata that would be used for revocation and aging will not be used and should be ignored by both the client and server. In such cases, the signature on the certificate conveys no value, and the consumer of the certificate is expected to pin the end-entity key fingerprint (versus using a PKI and signature chain).
この基準アーキテクチャは、キー素材のシリアル化フォーマットを必要とします。ネットワークデバイス上でのツーリングサポートの有病率により、X.509証明書は公開鍵を交換するのに便利なフォーマットです。ただし、失効とエージングに使用されるメタデータのほとんどは使用されません。クライアントとサーバーの両方によって無視されるはずです。そのような場合、証明書の署名は価値を合わせず、証明書の消費者はエンドエンティティキーの指紋（PKIとシグネチャチェーンを使用して）を固定することが予想されます。
The directory server contains a database of certificates. If newly manufactured devices upload certificates, the directory server can simply publish these; if the devices provide the raw public keys and unique device identifier, the directory server will need to wrap these in a certificate.
Directory Serverには証明書のデータベースが含まれています。新しく製造されたデバイスが証明書をアップロードする場合、ディレクトリサーバーは単にこれらを公開できます。デバイスが生の公開鍵と固有のデバイス識別子を提供する場合、ディレクトリサーバーはこれらを証明書に包み込む必要があります。
The customers (e.g., Operator_A) query this server with the serial number (or other provided unique identifier) of a device and retrieve the associated certificate. It is expected that operators will receive the unique device identifier (serial number) of devices when they purchase them and will download and store the certificate. This means that there is not a hard requirement on the reachability of the directory server.
顧客（例えば、演算子_a）は、デバイスのシリアル番号（または他の提供された一意の識別子）を使用してこのサーバーを照会し、関連する証明書を取得します。オペレータが購入したときにデバイスの固有のデバイス識別子（シリアル番号）を受信し、その証明書をダウンロードして保存することが予想されます。これは、ディレクトリサーバーの到達可能性に難しい要件がないことを意味します。
+------------+
+------+ | |
|Device| | Directory |
+------+ | Server |
+------------+
+----------------+ +--------------+
| +---------+ | | |
| | Initial | | | |
| | boot? | | | |
| +----+----+ | | |
| | | | |
| +------v-----+ | | |
| | Generate | | | |
| |Self-signed | | | |
| |Certificate | | | |
| +------------+ | | |
| | | | +-------+ |
| +-------|---|-->|Receive| |
| | | +---+---+ |
| | | | |
| | | +---v---+ |
| | | |Publish| |
| | | +-------+ |
| | | |
+----------------+ +--------------+
Figure 1: Initial Certificate Generation and Publication
図1：最初の証明書の生成と出版物
When purchasing a new device, the accounting department will need to get the unique device identifier (e.g., serial number) of the new device and communicate it to the operations group.
新しいデバイスを購入するとき、アカウンティング部門は新しいデバイスの固有のデバイス識別子（例えば、シリアル番号）を取得し、それを運用グループに伝達する必要があります。
The operator will contact the vendor's publication server and download the certificate (by providing the unique device identifier of the device). The operator fetches the certificate using a secure transport that authenticates the source of the certificate, such as HTTPS (confidentiality protection can provide some privacy and metadata-leakage benefit but is not key to the primary mechanism of this document). The operator will then encrypt the initial configuration (for example, using S/MIME [RFC8551]) using the key in the certificate and place it on their configuration server.
オペレータはベンダーのパブリケーションサーバーに連絡して、証明書をダウンロードします（デバイスの固有のデバイス識別子を指定して）。HTTPSなどの証明書のソースを認証するセキュアトランスポートを使用して、オペレータは証明書を取得します（機密保持保護、この文書の主なメカニズムには鍵はありません）。その後、証明書の鍵を使用して（たとえば、S / MIME [RFC8551]を使用）、それをコンフィギュレーションサーバーに配置します。
See Appendix A for examples.
例については付録Aを参照してください。
+------------+
+--------+ | |
|Operator| | Directory |
+--------+ | Server |
+------------+
+----------------+ +----------------+
| +-----------+ | | +-----------+ |
| | Fetch | | | | | |
| | Device |<------>|Certificate| |
| |Certificate| | | | | |
| +-----+-----+ | | +-----------+ |
| | | | |
| +-----v------+ | | |
| | Encrypt | | | |
| | Device | | | |
| | Config | | | |
| +-----+------+ | | |
| | | | |
| +-----v------+ | | |
| | Publish | | | |
| | TFTP | | | |
| | Server | | | |
| +------------+ | | |
| | | |
+----------------+ +----------------+
Figure 2: Fetching the Certificate, Encrypting the Configuration, and Publishing the Encrypted Configuration
図2：証明書の取得、構成の暗号化、および暗号化された構成の公開
When the device is first booted by the customer (and on subsequent boots), if the device does not have a valid configuration, it will use existing auto-install functionality. As an example, it performs DHCP Discovery until it gets a DHCP offer including DHCP option 66 (Server-Name) or 150 (TFTP server address), contacts the server listed in these DHCP options, and downloads its configuration file. Note that this is existing functionality (for example, Cisco devices fetch the config file named by the Bootfile-Name DHCP option (67)).
デバイスが最初に（および後続のブーツ）によって最初に起動されると、デバイスに有効な設定がない場合は、既存の自動インストール機能を使用します。例として、DHCPオプション66（サーバ名）または150（TFTPサーバアドレス）を含むDHCPオファーが取得されるまで、DHCPディスカバリを実行し、これらのDHCPオプションに記載されているサーバに連絡して、その構成ファイルをダウンロードします。これは既存の機能です（たとえば、Ciscoデバイスは、bootfile-name dhcpオプション（67）によって指定された設定ファイルを取得）します。
After retrieving the configuration file, the device needs to determine if it is encrypted or not. If it is not encrypted, the existing behavior is used. If the configuration is encrypted, the process continues as described in this document. If the device has been configured to only support encrypted configuration and determines that the configuration file is not encrypted, it should abort. The method used to determine if the configuration is encrypted or not is implementation dependent; there are a number of (obvious) options, including having a magic string in the file header, using a file name extension (e.g., config.enc), or using specific DHCP options.
構成ファイルを取得した後、デバイスは暗号化されているかどうかを判断する必要があります。暗号化されていない場合は、既存の動作が使用されます。構成が暗号化されている場合、プロセスはこのドキュメントで説明されています。デバイスが暗号化された構成のみをサポートし、構成ファイルが暗号化されていないことを決定するように設定されている場合は、中止する必要があります。構成が暗号化されているかどうかを判断するために使用される方法は実装に依存しています。ファイル名拡張子（例えば、config.enc）を使用して、または特定のDHCPオプションを使用して、ファイルヘッダーにマジックストリングを持つことを含む、（明白な）オプションがいくつかあります。
If the file is encrypted, the device will attempt to decrypt and parse the file. If able, it will install the configuration and start using it. If it cannot decrypt the file or if parsing the configuration fails, the device will either abort the auto-install process or repeat this process until it succeeds. When retrying, care should be taken to not overwhelm the server hosting the encrypted configuration files. It is suggested that the device retry every 5 minutes for the first hour and then every hour after that. As it is expected that devices may be installed well before the configuration file is ready, a maximum number of retries is not specified.
ファイルが暗号化されている場合、デバイスはファイルの復号化および解析を試みます。可能であれば、設定をインストールしてそれを使い始めます。ファイルを復号化できない場合、または構成の解析が失敗した場合、デバイスは自動インストールプロセスを中止したり、このプロセスが成功するまでこのプロセスを繰り返します。再試行するときは、暗号化された構成ファイルをホストしているサーバーが圧倒されないように注意する必要があります。デバイスが最初の1時間の間5分ごとに再試行し、その後その後毎時再試行することが示唆されています。設定ファイルの準備ができている前にデバイスをうまくインストールできると予想されるので、最大再試行回数は指定されていません。
Note that the device only needs to be able to download the configuration file; after the initial power on in the factory, it never needs to access the Internet, vendor, or directory server. The device (and only the device) has the private key and so has the ability to decrypt the configuration file.
デバイスは設定ファイルをダウンロードできるだけでよいことに注意してください。工場で初期電源投入後、インターネット、ベンダー、またはディレクトリサーバーにアクセスする必要はありません。デバイス（およびデバイスのみ）は秘密鍵を持ち、構成ファイルを復号化する機能があります。
+--------+ +--------------+
| Device | |Config server |
+--------+ |(e.g., TFTP) |
+--------------+
+---------------------------+ +------------------+
| +-----------+ | | |
| | | | | |
| | DHCP | | | |
| | | | | |
| +-----+-----+ | | |
| | | | |
| +-----v------+ | | +-----------+ |
| | | | | | Encrypted | |
| |Fetch config|<------------------>| config | |
| | | | | | file | |
| +-----+------+ | | +-----------+ |
| | | | |
| X | | |
| / \ | | |
| / \ N +--------+ | | |
| | Enc?|---->|Install,| | | |
| \ / | Boot | | | |
| \ / +--------+ | | |
| V | | |
| |Y | | |
| | | | |
| +-----v------+ | | |
| |Decrypt with| | | |
| |private key | | | |
| +-----+------+ | | |
| | | | |
| v | | |
| / \ | | |
| / \ Y +--------+ | | |
| |Sane?|---->|Install,| | | |
| \ / | Boot | | | |
| \ / +--------+ | | |
| V | | |
| |N | | |
| | | | |
| +----v---+ | | |
| |Retry or| | | |
| | abort | | | |
| +--------+ | | |
| | | |
+---------------------------+ +------------------+
Figure 3: Device Boot, Fetch, and Install Configuration File
図3：デバイスの起動、フェッチ、およびインストール設定ファイル
Ideally, the key pair would be stored in a Trusted Platform Module (TPM) on something that is identified as the "router" -- for example, the chassis/backplane. This is so that a key pair is bound to what humans think of as the "device" and not, for example, (redundant) routing engines. Devices that implement IEEE 802.1AR [IEEE802-1AR] could choose to use the Initial Device Identifier (IDevID) for this purpose.
理想的には、キーペアは、「ルータ」として識別されたもの（たとえば、シャーシ/バックプレーン）の信頼できるプラットフォームモジュール（TPM）に格納されます。これは、例えば（冗長）ルーティングエンジンなど、「デバイス」と考えているものに拘束されるようなものです。IEEE 802.1AR [IEEE802-1AR]を実装するデバイスは、この目的のために初期デバイス識別子（IDEVID）を使用することを選択できます。
It is anticipated that some operator may want to replace the (vendor-provided) keys after installing the device. There are two options when implementing this: a vendor could allow the operator's key to completely replace the initial device-generated key (which means that, if the device is ever sold, the new owner couldn't use this technique to install the device), or the device could prefer the operator's installed key. This is an implementation decision left to the vendor.
デバイスをインストールした後に（ベンダー提供）キーを一部のオペレータに置き換えることがあると予想されます。これを実装するときは2つのオプションがあります。ベンダーは、オペレータのキーが初期デバイス生成キーを完全に置き換えることができます（デバイスが販売されている場合、新しい所有者はこのテクニックを使用してデバイスをインストールできませんでした）またはデバイスはオペレータのインストールキーを好むことができます。これはベンダーに残された実装決定です。
Increasingly, operations are moving towards an automated model of device management, whereby portions of the configuration (or the entire configuration) are programmatically generated. This means that operators may want to generate an entire configuration after the device has been initially installed and ask the device to load and use this new configuration. It is expected (but not defined in this document, as it is vendor specific) that vendors will allow the operator to copy a new, encrypted configuration (or part of a configuration) onto a device and then request that the device decrypt and install it (e.g., 'load replace <filename> encrypted'). The operator could also choose to reset the device to factory defaults and allow the device to act as though it were the initial boot (see Section 4.3).
ますます、運用は機器管理の自動モデルに向かって移動しており、それによって構成（または構成全体）の一部がプログラム的に生成されています。つまり、デバイスが最初にインストールされた後にオペレータが全体の設定を生成し、この新しい設定をロードして使用するように要求することを意味します。ベンダーがオペレータがデバイスに新しい、暗号化された構成（または構成の一部）をコピーしてから、デバイスが復号化してインストールすることを要求することが想定されていることが予想されます（このドキュメントでは定義されていません）。（例えば、「ロード置換<filename>暗号化」）。オペレータは、デバイスを工場出荷時のデフォルトにリセットして、デバイスが最初の起動であるかのように機能することを選択できます（セクション4.3を参照）。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This reference architecture is intended to incrementally improve upon commonly accepted "auto-install" practices used today that may transmit configurations unencrypted (e.g., unencrypted configuration files that can be downloaded connecting to unprotected ports in data centers, mailing initial configuration files on flash drives, or emailing configuration files and asking a third party to copy and paste them over a serial terminal) or allow unrestricted access to these configurations.
このリファレンスアーキテクチャは、一般に使用されている一般的に使用されている一般的に使用されている「自動インストール」の練習を逐次的に改善することを目的としています。または設定ファイルを電子メールで送信し、サードパーティをシリアル端末にコピーして貼り付けるためのサードパーティに依頼するか、またはこれらの構成への無制限アクセスを許可します。
This document describes an object-level security design to provide confidentiality assurances for the configuration stored at rest on the configuration server and for configuration while it is in transit between the configuration server and the unprovisioned device, even if the underlying transport does not provide this security service.
このドキュメントでは、コンフィギュレーションサーバー上で保存されている構成およびコンフィギュレーションがこのセキュリティが提供されなくても、コンフィギュレーションサーバー上で保存されている構成の機密保証の保証を提供するオブジェクトレベルのセキュリティ設計について説明します。サービス。
The architecture provides no assurances about the source of the encrypted configuration or protect against theft and reuse of devices.
アーキテクチャは、暗号化された構成の発生源についての保証を提供しないか、デバイスの盗難や再利用から保護します。
An attacker (e.g., a malicious data center employee, person in the supply chain, etc.) who has physical access to the device before it is connected to the network or who manages to exploit it once installed may be able to extract the device private key (especially if it is not stored in a TPM), pretend to be the device when connecting to the network, and download and extract the (encrypted) configuration file.
ネットワークに接続される前にデバイスに物理的にアクセスできるか、またはインストールされた後にエクスプロイトを管理する前にデバイスに物理的にアクセスできる攻撃者（例えば、悪意のあるデータセンターの従業員、サプライチェーン内の人など）がデバイスプライベートを抽出できる可能性があります。キー（特にTPMに格納されていない場合）、ネットワークに接続しているときにデバイスになるのをやめて、（暗号化された）設定ファイルをダウンロードして抽出します。
An attacker with access to the configuration server (or the ability to route traffic to configuration server under their control) and the device's public key could return a configuration of the attacker's choosing to the unprovisioned device.
コンフィギュレーションサーバーにアクセスできる攻撃者（または自分のコントロールの下でConfiguration Serverにトラフィックをルーティングする機能）とデバイスの公開鍵は、攻撃者のプライオビジョンのデバイスを選択した設定を返す可能性があります。
This mechanism does not protect against a malicious vendor. While the key pair should be generated on the device and the private key should be securely stored, the mechanism cannot detect or protect against a vendor who claims to do this but instead generates the key pair off device and keeps a copy of the private key. It is largely understood in the operator community that a malicious vendor or attacker with physical access to the device is largely a "Game Over" situation.
このメカニズムは悪意のあるベンダーに対して保護しません。キーペアはデバイス上で生成され、秘密鍵を安全に保存する必要がありますが、このメカニズムはこれを行うと主張するベンダーに対して検出または保護することはできませんが、その代わりに鍵ペアをオフにして秘密鍵のコピーを保持します。これは、デバイスへの物理的アクセスを持つ悪意のあるベンダーまたは攻撃者が主に「ゲームオーバー」の状況であることが主に理解されています。
Even when using a secure bootstrap mechanism, security-conscious operators may wish to bootstrap devices with a minimal or less-sensitive configuration and then replace this with a more complete one after install.
安全なブートストラップメカニズムを使用している場合でも、セキュリティを配慮したオペレータはデバイスを最小限または敏感な構成でブートアップすることをお勧めし、次にインストール後より完全なものに置き換えます。
[BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-bootstrapping-keyinfra-44, 21 September 2020, <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-44>.
[Brski] Pritikin、M.、Richardson、M.、Eckert、T.、Behringer、M.、K。Watsen、「ブートストラップリモートセキュリティキーインフラストラクチャ（Brski）」、進行中の作業、インターネットドラフト、ドラフトIETF-anima-bootstrappy-keyinfra-44,20 2020、<https：//tools.ietf.org/html/draft-ietf-anima-bootstrapp-keyinfra-44>。
[Cisco_AutoInstall] Cisco Systems, Inc., "Using AutoInstall to Remotely Configure Cisco Networking Devices", Configuration Fundamentals Configuration Guide, Cisco IOS Release 15M&T, January 2018, <https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/fundamentals/configuration/15mt/fundamentals-15- mt-book/cf-autoinstall.html>.
[Cisco_AutoInstall] Cisco Systems、Inc。、「Cisco Networking Devicesのリモコンのリモコンの使用」、Cisco IOSリリース15M＆T、2018年1月、<https：//www.cisco.com/c/en/us/TD / DOCS / IOS-XML / IOS / FUNDAMANTRALES /構成/ 15MT / FUNDANTARS-15 - MT-Book / CF-AUTOINSTALL.HTML>。
[IEEE802-1AR] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE Std 802-1AR, June 2018, <https://standards.ieee.org/standard/802_1AR-2018.html>.
[IEEE802-1AR] IEEE、「地元の地域と首都圏のネットワーク - Secure Device Identity」、IEEE STD 802-1AR、2018年6月、<https://standards.ieee.org/standard/802_1ar-2018.html>。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, DOI 10.17487/RFC1350, July 1992, <https://www.rfc-editor.org/info/rfc1350>.
[RFC1350] Sollins、K.、「TFTPプロトコル（リビジョン2）」、STD 33、RFC 1350、DOI 10.17487 / RFC1350、1992年7月、<https：//www.rfc-editor.org/info/rfc1350>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] DROMS、R.、「動的ホスト構成プロトコル」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https：//www.rfc-editor.org/info/rfc2131>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.、およびW.Simpson、「ユーザーサービス内のリモート認証ダイヤル（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：//www.rfc-editor.org/info/rfc2865>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122]リーチ、P.、Mealling、M.、およびR.Salz、「普遍的にユニークな識別子（UUID）URN名前空間」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：//www.rfc-editor.org/info/rfc4122>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030] Pritikin、M。、ED。、Yee、P.、Ed。、D. Harkins、Ed。、「セキュアトランスポートの登録」、RFC 7030、DOI 10.17487 / RFC7030、2013年10月、<https：//www.rfc-editor.org/info/rfc7030>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B.、およびS。ターナー、「セキュア/多目的インターネットメール拡張（S / MIME /多目的インターネットメール拡張」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https：//www.rfc-editor.org/info/rfc8551>。
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, <https://www.rfc-editor.org/info/rfc8572>.
[RFC8572] Watsen、K.、Farrer、I.、およびM.Abrahamsson、「Secure The Touch Provisioning（SZTP）」、RFC 8572、DOI 10.17487 / RFC8572、2019年4月、<https：//www.rfc-編集者。ORG / INFO / RFC8572>。
[RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol", RFC 8894, DOI 10.17487/RFC8894, September 2020, <https://www.rfc-editor.org/info/rfc8894>.
[RFC8894] Gutmann、P.、「単純な証明書登録プロトコル」、RFC 8894、DOI 10.17487 / RFC8894、2020年9月、<https://www.rfc-editor.org/info/rfc8894>。
[TACACS] Dahm, T., Ota, A., Medway Gash, D., Carrel, D., and L. Grant, "The TACACS+ Protocol", Work in Progress, Internet-Draft, draft-ietf-opsawg-tacacs-18, 20 March 2020, <https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-18>.
[TACACS] DAHM、T.、OTA、A.、Medway Gash、D.、D.、Carrele、D.、L. GRANT、「TACACSプロトコル」、進行中の作業、インターネットドラフト、ドラフトIETF-Opsawg-TACACS-18,20 3月20日、<https：//tools.ietf.org/html/draft-ietf-opsawg-tacacs-18>。
This section contains a proof of concept of the system. It is only intended for illustration and is not intended to be used in production.
このセクションには、システムの概念の証明が含まれています。それはイラストを目的としており、生産に使用されることを意図していません。
It uses OpenSSL from the command line. In production, something more automated would be used. In this example, the unique device identifier is the serial number of the router, SN19842256.
コマンドラインからOpenSSLを使用します。生産では、より自動化されたものが使用されます。この例では、固有のデバイス識別子は、ルータのシリアル番号SN19842256です。
This step is performed by the router. It generates a key, then a Certificate Signing Request (CSR), and then a self-signed certificate.
このステップはルータによって実行されます。それはキーを生成し、その後証明書署名要求（CSR）、そして自己署名証明書を生成します。
$ openssl ecparam -out privatekey.key -name prime256v1 -genkey $
$ OpenSSL ECPARAM-OUT PRIVINTKEY.KEY -NAME PRIME256V1-Geney $
$ openssl req -new -key key.pem -out SN19842256.csr
Common Name (e.g., server FQDN or YOUR name) []:SN19842256
$ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr
-out SN19842256.crt
The router then sends the key to the vendor's key server for publication (not shown).
その後、ルータは出版物（図示せず）のベンダーのキーサーバにキーを送信します。
The operator now wants to deploy the new router.
オペレータは新しいルータをデプロイしたいと考えています。
They generate the initial configuration (using whatever magic tool generates router configs!), fetch the router's certificate, and encrypt the configuration file to that key. This is done by the operator.
（Router Config！）、ルータの証明書を取得し、そのキーに設定ファイルを暗号化して、初期設定を生成します。これはオペレータによって行われます。
$ wget http://keyserv.example.net/certificates/SN19842256.crt
S/MIME is used here because it is simple to demonstrate. This is almost definitely not the best way to do this.
S / MIMEは説明が簡単であるため、ここで使用されています。これはほとんど間違いなくこれを行うための最良の方法ではありません。
$ openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg\
-out SN19842256.enc -outform PEM SN19842256.crt
$ more SN19842256.enc
-----BEGIN PKCS7-----
MIICigYJKoZIhvcNAQcDoIICezCCAncCAQAxggE+MIIBOgIBADAiMBUxEzARBgNV
BAMMClNOMTk4NDIyNTYCCQDJVuBlaTOb1DANBgkqhkiG9w0BAQEFAASCAQBABvM3
...
LZoq08jqlWhZZWhTKs4XPGHUdmnZRYIP8KXyEtHt
-----END PKCS7-----
$ scp SN19842256.enc config.example.com:/tftpboot
$ scp sn19842256.enc config.example.com:/tftpboot.
When the router connects to the operator's network, it will detect that it does not have a valid configuration file and will start the "autoboot" process. This is a well-documented process, but the high-level overview is that it will use DHCP to obtain an IP address and configuration server. It will then use TFTP to download a configuration file, based upon its serial number (this document modifies the solution to fetch an encrypted configuration file (ending in .enc)). It will then decrypt the configuration file and install it.
ルータがオペレータのネットワークに接続すると、有効な構成ファイルがないことを検出し、「AutoBoot」プロセスを開始します。これはよく文書化されたプロセスですが、高レベルの概要は、DHCPを使用してIPアドレスと構成サーバーを取得することです。その後、そのシリアル番号に基づいて、TFTPを使用して設定ファイルをダウンロードします（このドキュメントは、暗号化された構成ファイル（エンディング）を取得するためのソリューションを変更します）。その後、構成ファイルを復号化してインストールします。
A.3.1. Step 3.1: Fetch Encrypted Configuration File from Configuration Server
A.3.1. ステップ3.1：Configuration Serverから暗号化設定ファイルを取得する
$ tftp 2001:0db8::23 -c get SN19842256.enc
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
-out config.cfg -inkey key.pem
If an attacker does not have the correct key, they will not be able to decrypt the configuration file:
攻撃者が正しいキーを持っていない場合、それらは設定ファイルを復号化することはできません。
$ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
-out config.cfg -inkey wrongkey.pem
Error decrypting PKCS#7 structure
140352450692760:error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:592:
$ echo $?
4
Acknowledgments
謝辞
The authors wish to thank everyone who contributed, including Benoit Claise, Francis Dupont, Mirja Kuehlewind, Sam Ribeiro, Michael Richardson, Sean Turner, and Kent Watsen. Joe Clarke also provided significant comments and review, and Tom Petch provided significant editorial contributions to better describe the use cases and clarify the scope.
著者らは、Benoit Claise、Francis Dupont、Mirja Kuehlewind、Sam Ribeiro、Michael Richardson、Sean Turner、およびKent Watsenを含む皆さんに貢献してくれてありがとうございました。Joe Clarkeはまた重要なコメントとレビューを提供し、トムペッチはユースケースをよりよく説明し、範囲を明確にするために重要な編集の貢献を提供しました。
Roman Danyliw and Benjamin Kaduk also provided helpful text, especially around the certificate usage and security considerations.
Roman DanyliwとBenjamin Kadukには、特に証明書の使用とセキュリティ上の考慮事項についても、役立つテキスト、特に役立ちました。
Authors' Addresses
著者の住所
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net
Colin Doyle Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
コリンドイルジュニパーネットワークス1133イノベーションウェイSunnyvale、CA 94089アメリカ
Email: cdoyle@juniper.net