Network Working Group M. Richardson
Request for Comments: 4322 SSW
Category: Informational D.H. Redelmeier
Mimosa
December 2005
Opportunistic Encryption using the Internet Key Exchange (IKE)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
この文書では、設計されており、Linuxのは、FreeS / WANプロジェクトによって実装される日和見暗号化（OE）について説明します。 OEは、インターネット鍵交換（IKE）およびIPsecプロトコルを使用しています。目的は、関連するシステムの対に固有の事前配置することなく、安全な通信のための暗号化を可能にすることです。 DNSは、関係する各システムの公開鍵を配布するために使用されます。これは、受動的攻撃に耐性があります。 DNSセキュリティ（DNSSEC）の使用は、同様にアクティブな攻撃者に対して、このシステムを保護します。
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance.
その結果、管理オーバーヘッドが線形依存するシステムの数の平方から減少し、それはパートナーが事前に知られていなくても、デフォルトのセキュアな通信を行うことが可能となっています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of systems involved. Each system administrator adds public key information to DNS records to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once this is done, any two such nodes can communicate securely.
日和見暗号化の目的は、関連するシステムのペアに固有の事前配置せずに暗号化を可能にすることです。各システム管理者は、日和見暗号化をサポートするために、DNSレコードに公開鍵情報を追加し、ノードのIPsecスタックでこの機能を有効にします。これが行われると、任意の二つのこのようなノードは、安全に通信することができます。
This document describes opportunistic encryption as designed and implemented by the Linux FreeS/WAN project in revisions up and including 2.00. Note that 2.01 and beyond implements [RFC3445] in a backward compatible way. A future document [IPSECKEY] will describe a variation that complies with RFC 3445. For project information, see http://www.freeswan.org.
この文書では、設計されており、改訂アップや2.00などでのLinuxは、FreeS / WANプロジェクトによって実装された日和見暗号化について説明します。なお、2.01という、後方互換性のある方法で実装[RFC3445]を超えました。将来の文書では、[IPSECKEY] http://www.freeswan.orgを参照して、プロジェクトの情報については、RFC 3445.に準拠変動を説明します。
The Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [RFC1984]. The Linux FreeS/WAN project attempts to provide a practical means to implement this policy.
インターネットアーキテクチャ委員会（IAB）とインターネットエンジニアリング運営グループ（IESG）は、インターネットのセキュリティとプライバシー[RFC1984]を提供するために、強力な暗号化を使用する必要があり、強力な立場をとっています。 Linuxのは、FreeS / WANプロジェクトは、このポリシーを実装するための実用的な手段を提供しようとします。
The project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols because they are standardized, widely available, and can often be deployed very easily without changing hardware or software, or retraining users.
このプロジェクトは、彼らが標準化されているので、広く利用可能、IPsecの、ISAKMP / IKE、DNS、およびDNSSECプロトコルを使用しており、多くの場合、ハードウェアまたはソフトウェアの変更、またはユーザーを再教育することなく、非常に簡単に導入することができます。
The extensions to support opportunistic encryption are simple. No changes to any on-the-wire formats are needed. The only changes are to the policy decision making system. This means that opportunistic encryption can be implemented with very minimal changes to an existing IPsec implementation.
日和見暗号化をサポートするための拡張機能はシンプルです。任意のオン・ワイヤー形式を変更する必要はありません。唯一の変更は、政策の意思決定システムにあります。これは日和見暗号化は、既存のIPsec実装に非常に最小限の変更で実現できることを意味します。
Opportunistic encryption creates a "fax effect". The proliferation of the fax machine was possible because it did not require that everyone buy one overnight. Instead, as each person installed one, the value of having one increased because there were more people that could receive faxes. Once opportunistic encryption is installed, it automatically recognizes other boxes using opportunistic encryption, without any further configuration by the network administrator. So, as opportunistic encryption software is installed on more boxes, its value as a tool increases.
日和見暗号化は、「ファックス効果」を作成します。それは誰もが1晩を購入する必要はありませんでしたので、ファックス機の増殖が可能でした。各人が1をインストールしてファクスを受信でき、より多くの人々があったので、代わりに、1つを有するの値が増加しました。日和見暗号化がインストールされると、自動的にネットワーク管理者によって、他の設定を行わなくても、日和見暗号化を使用して他のボックスを認識しています。だから、日和見暗号化ソフトウェアのようなツールが増加するにつれて、より多くの箱、その値にインストールされています。
This document describes the infrastructure to permit deployment of Opportunistic Encryption.
この文書では、日和見暗号化の展開を可能にするためのインフラストラクチャを説明しています。
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
用語S / WANは、RSAデータシステムズの商標であり、このプロジェクトの許可によって使用されています。
To aid in understanding the relationship between security processing and IPsec, we divide policies controlling network traffic into four categories. The traffic is categorized by destination address using longest prefix match. Therefore, each category is enumerated by a set of network prefixes. The categories are mutually exclusive; a particular prefix should only occur in one category.
セキュリティ処理とIPsecとの間の関係の理解を助けるために、我々は4つのカテゴリにネットワークトラフィックを制御するポリシーを分けます。トラフィックは、最長プレフィックス一致を使用して、宛先アドレスによって分類されます。したがって、各カテゴリは、ネットワークプレフィックスの組によって列挙されています。カテゴリは相互に排他的です。特定の接頭辞は、唯一のカテゴリに発生する必要があります。
* Deny: network prefixes to which traffic is always forbidden. * Permit: network prefixes to which traffic in the clear is permitted. * Opportunistic tunnel: network prefixes to which traffic is encrypted if possible, when it otherwise might be sent in the clear. * Configured tunnel: network prefixes to which traffic must be encrypted, and traffic in the clear is never permitted. A traditionally defined Virtual Private Network (VPN) is a form of configured tunnel.
*拒否：トラフィックは常に禁止されているネットワークプレフィックスを。 *許可：明確でトラフィックが許可されているネットワークプレフィックス。 *日和見トンネル：可能な場合、それはそうでない平文で送信されるかもしれないとき、トラフィックが、暗号化されているネットワークプレフィックス。 *設定トンネル：ネットワークプレフィックスは、トラフィックを暗号化する必要があるために、クリアでトラフィックが許可されることはありません。伝統的に定義された仮想プライベートネットワーク（VPN）が設定されたトンネルの形です。
Traditional firewall devices handle the first two categories. No authentication is required. The permit policy is currently the default on the Internet.
従来のファイアウォールデバイスは、最初の2つのカテゴリーを扱います。認証は必要ありません。許可ポリシーは、現在、インターネット上のデフォルトです。
This document describes the third category: opportunistic tunnel, which is proposed as the new default for the Internet.
日和見トンネル、インターネットの新しいデフォルトとして提案されます。この文書では、第三のカテゴリーについて説明します。
Category four's policy is a very strict "encrypt it or drop it" policy, which requires authentication of the endpoints. As the number of endpoints is typically bounded and is typically under a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology. The mechanism described here, however, does provides an additional way to distribute the authentication materials; it is a public key method that does not require deployment of an X.509 based infrastructure.
カテゴリー4の方針は、「それを暗号化するか、それをドロップする」エンドポイントの認証を要求するポリシー、非常に厳格です。エンドポイントの数は、一般的に有界であると、認証材の分布の手配、単一の権限の下で、一般的であるため難しい一方で、新たな技術を必要としません。ここで説明されたメカニズムは、しかしながら、認証の材料を分配するための追加の方法を提供しません。それはX.509ベースのインフラストラクチャの展開を必要としない公開鍵方式です。
Opportunistic encryption creates tunnels between nodes that are essentially strangers. This is done without any prior bilateral arrangement. Therefore, there is the difficult question of how one knows to whom one is talking.
日和見暗号化は、本質的に見知らぬ世界では、ノード間のトンネルを作成します。これは、任意の前の二国間の配置せずに行われます。したがって、1は1が話している人に知っているかの困難な問題があります。
One possible answer is that since no useful authentication can be done, none should be tried. This mode of operation is named "anonymous encryption". An active man-in-the-middle attack can be used to thwart the privacy of this type of communication. Without peer authentication, there is no way to prevent this kind of attack.
一つの可能な答えはノー便利な認証は行われないことができるので、何も試されてはならないということです。この動作モードは、「匿名の暗号化」と命名されます。アクティブなman-in-the-middle攻撃は、このタイプの通信のプライバシーを阻止するために使用することができます。ピア認証がなければ、この種の攻撃を防ぐ方法はありません。
Although it is a useful mode, anonymous encryption is not the goal of this project. Simpler methods are available that can achieve anonymous encryption only, but authentication of the peer is a desirable goal. Authentication of the peer is achieved through key distribution in DNS, leveraging upon the authentication of the DNS in DNSSEC.
それは便利なモードですが、匿名の暗号化は、このプロジェクトの目標ではありません。より簡単な方法は、匿名の暗号化を実現することができる利用可能ですが、ピアの認証が望ましい目標です。ピアの認証は、DNSSECにおけるDNSの認証時に利用する、DNSにキー配布によって達成されます。
Peers are, therefore, authenticated with DNSSEC when available. Local policy determines how much trust to extend when DNSSEC is not available.
ピアは、それゆえ、ときDNSSECで利用できる認証されます。ローカルポリシーは、DNSSECが利用できない場合に拡張するためにどのくらいの信頼を決定します。
An essential premise of building private connections with strangers is that datagrams received through opportunistic tunnels are no more special than datagrams that arrive in the clear. Unlike in a VPN, these datagrams should not be given any special exceptions when it comes to auditing, further authentication, or firewalling.
見知らぬ人とのプライベート接続を構築するための基本的な前提は、日和見のトンネルを介して受信したデータグラムは、これ以上の特別な明確に到着したデータグラムよりもあることではありません。それは、監査、さらに認証、またはファイアウォールに来るときVPNとは異なり、これらのデータグラムは、特別な例外を与えられるべきではありません。
When initiating outbound opportunistic encryption, local configuration determines what happens if tunnel setup fails. The packet may go out in the clear, or it may be dropped.
アウトバウンド日和見暗号化を開始すると、ローカル設定は、トンネルセットアップが失敗した場合に何が起こるかを決定します。パケットは明確に出て行くこと、またはそれが破棄される可能性があり。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]
キーワードはMUST、MUST NOT、REQUIREDは、、NOT SHALL、彼らは、この文書に表示されたときに、[RFC2119]で説明したように解釈されるべきである、MAY、推奨、オプション、すべきでないものと
The following network diagram is used in the rest of this document as the canonical diagram:
次のネットワーク図は標準的な図として、この文書の残りの部分で使用されます。
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
Figure 1: Reference Network Diagram
図1：リファレンスネットワークダイアグラム
In this diagram, there are four end-nodes: A, B, C, and D. There are three security gateways, SG-A, SG-B, SG-D. A, D, SG-A, and SG-D are part of the same administrative authority, AS1. SG-A and SG-D are on two different exit paths from organization 1. SG-B and B are part of an independent organization, AS2. Nodes Q and R are nodes on the Internet. PI is the Public Internet ("The Wild").
A、B、C、及びDの3つのセキュリティゲートウェイがあり、SG-A、SG-B、SG-D：この図には、4つのエンドノードが存在します。 、D、SG-A、およびSG-Dは、同一の管理権限、AS1の一部です。 SG-AおよびSG-D組織1. SG-BとBからの二つの異なる出口経路上に存在する独立した組織の一部、AS2です。ノードQとRは、インターネット上のノードです。 PIは、公衆インターネット（「ワイルド」）です。
Note: The network numbers used in this document are for illustrative purposes only. This document could not use the reserved example network numbers of [RFC3330] because multiple address ranges were needed.
注：このドキュメントで使用されているネットワーク番号は、説明のみを目的としたものです。複数のアドレス範囲が必要であったため、この文書では、[RFC3330]の予約された例のネットワーク番号を使用することができませんでした。
The following terminology is used in this document:
以下の用語は、本書で使用されます。
Security gateway (or simply gateway): a system that performs IPsec tunnel mode encapsulation/decapsulation. [SG-x] in the diagram.
セキュリティゲートウェイ（又は単にゲートウェイ）：IPsecトンネルモードカプセル化/デカプセル化を行うシステム。図中の[SG-X]。
Alice: node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.
アリス：図中のノード[A]。 IPアドレスが必要になったとき、これは192.1.0.65です。
Bob: node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.
ボブ：図中のノード[B]。 IPアドレスが必要になったとき、これは192.2.0.66です。
Carol: node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.
キャロル：図中のノード[C]。 IPアドレスが必要になったとき、これは192.1.1.67です。
Dave: node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.
デイブ：図中のノード[D]。 IPアドレスが必要になったとき、これは192.3.0.68です。
SG-A: Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.
SG-A：アリスのセキュリティゲートウェイ。内部的には、外部からそれは192.1.1.4で、192.1.0.1です。
SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
SG-B：ボブのセキュリティゲートウェイ。内部的には、外部からそれは192.1.1.5で、192.2.0.1です。
SG-D: Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.
SG-D：Daveのセキュリティゲートウェイ。また、アリスのバックアップセキュリティゲートウェイ。内部的には、外部からそれは192.1.1.6で、192.3.0.1です。
Configured tunnel: a tunnel that is directly and deliberately hand-configured on participating gateways. Configured tunnels are typically given a higher level of trust than opportunistic tunnels.
構成トンネル：直接故意参加ゲートウェイに手が設定されたトンネル。構成されたトンネルは、一般的に日和見トンネルより信頼の高いレベルを与えられています。
Road warrior tunnel: a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed node cannot know the current address for the road warrior.
道路戦士トンネル：固定IPアドレスと可変IPアドレスを持つノードと一つのノードとを接続するように構成トンネル。固定ノードは、道路の戦士のための現在のアドレスを知ることができないので、道路戦士（RW）接続は、変数ノードによって開始されなければなりません。
Anonymous encryption: the process of encrypting a session without any knowledge of who the other parties are. No authentication of identities is done.
匿名の暗号化：他の当事者が誰であるかのいずれかの知識がなくてもセッションを暗号化するプロセス。アイデンティティの認証は行われません。
Opportunistic encryption: the process of encrypting a session with authenticated knowledge of who the other party is without prearrangement.
日和見暗号化：相手が前準備なしに誰であるかの認証された知識とのセッションを暗号化するプロセス。
Lifetime: the period in seconds (bytes or datagrams) for which a security association will remain alive before rekeying is needed.
生涯：鍵の再生成が必要とされる前にセキュリティアソシエーションが生き残るれる秒（バイトまたはデータグラム）で期間。
Lifespan: the effective time for which a security association remains useful. A security association with a lifespan shorter than its lifetime would be removed when no longer needed. A security association with a lifespan longer than its lifetime would need to be re-keyed one or more times.
寿命：セキュリティアソシエーションは便利なままであるために効果的な時間。不要になったときにその寿命より短い寿命を持つセキュリティアソシエーションが削除されます。長い寿命よりも寿命とのセキュリティアソシエーションを1回以上再キーイングする必要があります。
Phase 1 SA: an ISAKMP/IKE security association sometimes referred to as a keying channel.
フェーズ1 SA：ISAKMP / IKEセキュリティアソシエーションは時々キーイングチャネルと呼びます。
Phase 2 SA: an IPsec security association.
フェーズ2 SA：IPsecセキュリティ協会。
Tunnel: another term for a set of phase 2 SA (one in each direction).
トンネル：フェーズ2 SAのセットのための別の用語（各方向に1つずつ）。
NAT: Network Address Translation (see [RFC2663]).
NAT：ネットワークアドレス変換（[RFC2663]を参照）。
NAPT: Network Address and Port Translation (see [RFC2663]).
NAPT：ネットワークアドレスとポート変換（[RFC2663]を参照）。
AS: an autonomous system.
AS：自律システム。
FQDN: Fully-Qualified Domain Name
FQDN：完全修飾ドメイン名
Default-free zone: a set of routers that maintain a complete set of routes to all currently reachable destinations. Having such a list, these routers never make use of a default route. A datagram with a destination address not matching any route will be dropped by such a router.
デフォルトフリーゾーン：すべての現在到達可能な目的地へのルートの完全なセットを維持するルータのセット。そのようなリストを持って、これらのルータは、デフォルトルートを利用することはありません。任意の経路に合致しない宛先アドレスを持つデータグラムは、ルータによって廃棄されるであろう。
The opportunistic encryption security gateway (OE gateway) is a regular gateway node, as described in [RFC0791] section 2.4 and [RFC1812], with the additional capabilities described here and in [RFC2401]. The algorithm described here provides a way to determine, for each datagram, whether or not to encrypt and tunnel the datagram. Two important things that must be determined are whether or not to encrypt and tunnel and, if so, the destination address or name of the tunnel endpoint that should be used.
日和見暗号化セキュリティゲートウェイ（OEゲートウェイ）は、ここで説明する追加の機能を持つと[RFC2401]で、[RFC0791]セクション2.4および[RFC1812]に記載されているように、定期的なゲートウェイノードです。ここで説明するアルゴリズムは、データグラムを暗号化してトンネルすべきか否かを、各データグラムのために、決定するための方法を提供します。決定されなければならない二つの重要なことは、暗号化とトンネルと、そうならば、使用すべきであるトンネルエンドポイントの宛先アドレスまたは名前にするかどうかです。
The OE gateway determines whether or not to create a tunnel based on the destination address of each packet. Upon receiving a packet with a destination address not recently seen, the OE gateway performs a lookup in DNS for an authorization resource record (see Section 5.2). The record is located using the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization record is found, the OE gateway interprets this as a request for a tunnel to be formed.
OEゲートウェイは、各パケットの宛先アドレスに基づいて、トンネルを作成するか否かを判断します。最近見ていない宛先アドレスを持つパケットを受信すると、OEゲートウェイは（5.2節を参照）の認可リソースレコードをDNSで検索を実行します。レコードはin-addr.arpa（IPv4）のまたはip6.arpa（IPv6）のマップで検索を実行するためにIPアドレスを使用して配置されます。許可レコードが見つかった場合、OEゲートウェイはトンネルを形成するための要求としてこれを解釈します。
The authorization resource record also provides the address or name of the tunnel endpoint that should be used.
承認リソースレコードも使用すべきであるトンネルエンドポイントのアドレスまたは名前を提供します。
The record may also provide the public RSA key of the tunnel end point itself. This is provided for efficiency only. If the public RSA key is not present, the OE gateway performs a second lookup to find a KEY resource record for the endpoint address or name.
レコードはまた、トンネルエンドポイント自体の公開RSA鍵を提供することができます。これは、効率だけのために提供されます。 RSA公開鍵が存在しない場合、OEゲートウェイは、エンドポイントのアドレスまたは名前のためのKEYリソースレコードを見つけるために、第2のルックアップを実行します。
Origin and integrity protection of the resource records is provided by DNSSEC (see [RFC4033]). Section 3.2.4.1 documents an optional restriction on the tunnel endpoint if DNSSEC signatures are not available for the relevant records.
リソースレコードの起源と完全性保護は、DNSSEC（[RFC4033]を参照）によって提供されます。 DNSSECの署名が、関連レコードに利用できない場合、セクション3.2.4.1は、トンネルエンドポイント上の任意の制限を説明します。
The OE gateway maintains a cache, in the forwarding plane, of source/destination pairs for which opportunistic encryption has been attempted. This cache maintains a record of whether or not OE was successful so that subsequent datagrams can be forwarded properly without additional delay.
OEゲートウェイは、便宜主義的な暗号化が試行された送信元/宛先ペアの、転送プレーンにおいて、キャッシュを維持します。このキャッシュは、後続のデータグラムが追加遅滞なく適切に転送することができるように、OEが成功したかどうかの記録を保持します。
Successful negotiation of OE instantiates a new security association. Failure to negotiate OE results in creation of a forwarding policy entry either to deny or permit transmission in the clear future datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking up the same information.
OEの成功した交渉は、新しいセキュリティアソシエーションをインスタンス化します。明確な将来のデータグラムの送信を拒否または許可するか転送ポリシーエントリの作成にOE結果を交渉に失敗しました。この負のキャッシュは、繰り返し同じ情報を検索する可能性の長いプロセスを回避する必要があります。
The cache is timed out periodically, as described in Section 3.4. This removes entries that are no longer being used and permits the discovery of changes in authorization policy.
3.4節で説明したようにキャッシュは、定期的にタイムアウトしています。これはもはや使用されているエントリを削除し、認可ポリシーの変更の発見が可能になります。
The OE gateway is modeled to have a forwarding plane and a control plane. A control channel, such as PF_KEY [RFC2367], connects the two planes.
OEゲートウェイは、転送プレーンと制御プレーンを有するようにモデル化されます。そのようなPF_KEY [RFC2367]などの制御チャネルは、二つの面を接続します。
The forwarding plane performs per-datagram operations. The control plane contains a keying daemon, such as ISAKMP/IKE, and performs all authorization, peer authentication, and key derivation functions.
転送プレーンごとのデータグラムの動作を行います。制御プレーンは、ISAKMP / IKEなどのキーイングデーモンを含み、すべての許可、ピア認証、鍵導出機能を実行します。
Let the OE gateway maintain a collection of objects -- a superset of the security policy database (SPD) specified in [RFC2401]. For each combination of source and destination address, an SPD object exists in one of five following states. Prior to forwarding each datagram, the responder uses the source and destination addresses to pick an entry from the SPD. The SPD then determines if and how the packet is forwarded.
[RFC2401]で指定されたセキュリティポリシーデータベース（SPD）のスーパーセットを - OEゲートウェイは、オブジェクトのコレクションを維持しましょう。送信元および宛先アドレスの組み合わせ毎に、SPDの目的は、5つの以下のいずれかの状態で存在します。各データグラムを転送する前に、応答は、SPDからエントリを選択するために、ソースおよび宛先アドレスを使用します。 SPDは、そのパケットを転送する場合、どのように決定されます。
.--------------.
| nonexistent |
| policy |
`--------------'
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--'
| |--.
`--------------' \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--'
IPsec | | `-------------'
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------' \ | | discard
\ V | packet
.-------------. |
| deny policy |--'
`-------------'
If the gateway does not find an entry, then this policy applies. The gateway creates an entry with an initial state of "hold policy" and requests keying material from the keying daemon. The gateway does not forward the datagram; rather, it SHOULD attach the datagram to the SPD entry as the "first" datagram and retain it for eventual transmission in a new state.
ゲートウェイは、エントリが見つからない場合は、このポリシーが適用されます。ゲートウェイは、「ポリシーを保持する」の初期状態にエントリを作成し、キーデーモンからの鍵材料要求します。ゲートウェイは、データグラムを転送しません。むしろ、それは「最初」のデータグラムとしてSPDエントリにデータグラムを添付し、新しい状態で最終的な伝送のためにそれを保持しなければなりません。
The gateway requests keying material. If the interface to the keying system is lossy (PF_KEY, for instance, can be), the implementation SHOULD include a mechanism to retransmit the keying request at a rate limited to less than 1 request per second. The gateway does not forward the datagram. The gateway SHOULD attach the datagram to the SPD entry as the "last" datagram, where it is retained for eventual transmission. If there is a datagram already stored in this way, then that already-stored datagram is discarded.
鍵材料をゲートウェイ要求。キーシステムへのインタフェースは、（PF_KEYは、例えば、であることができる）、非可逆である場合、実装は、毎秒1未満の要求に限ら速度でキーイング要求を再送信するためのメカニズムを含むべきです。ゲートウェイは、データグラムを転送しません。ゲートウェイは、それが最終的な送信のために保持される「最後の」データグラムとしてSPDエントリにデータグラムを添付してください。すでにこのように保存されたデータグラムがある場合は、その既に保存されたデータグラムは破棄されます。
The rationale behind saving the "first" and "last" datagrams are as follows: The "first" datagram is probably a TCP SYN packet. Once there is keying established, the gateway will release this datagram, avoiding the need for the endpoint to retransmit the datagram. In the case where the connection was not a TCP connection, but was instead a streaming protocol or a DNS request, the "last" datagram that was retained is likely the most recent data. The difference between "first" and "last" may also help the endpoints determine which data was dropped while negotiation took place.
以下のように「最初」と「最後」のデータグラムを保存の理論的根拠は以下のとおりです。「最初」のデータグラムは、おそらくTCP SYNパケットです。そこに確立キーイングされると、ゲートウェイは、データグラムを再送信するエンドポイントの必要性を回避する、このデータグラムをリリースする予定。接続は、TCP接続はありませんでしたが、代わりにストリーミングプロトコルまたはDNS要求した場合には、保持された「最後」のデータグラムは、おそらく最新のデータです。 「最初」と「最後」の違いはまた、エンドポイントが、交渉が行われた一方で落とされたデータを判断するのに役立つことがあります。
The gateway forwards the datagram using the normal forwarding table. The gateway enters this state only by command from the keying daemon, and upon entering this state, also forwards the "first" and "last" datagrams.
ゲートウェイは、通常の転送テーブルを使用してデータグラムを転送します。ゲートウェイは、キーイングデーモンからのみ命令によってこの状態に入り、この状態に入ると、「第1」及び「最後」データグラムを転送します。
The gateway discards the datagram. The gateway enters this state only by command from the keying daemon, and upon entering this state, discards the "first" and "last" datagrams. An implementation MAY provide the administrator with a control to determine if further datagrams cause ICMP messages to be generated (i.e., ICMP Destination Unreachable, Communication Administratively Prohibited. type=3, code=13).
ゲートウェイは、データグラムを廃棄します。ゲートウェイは、キーイングデーモンからのみ命令によってこの状態に入り、この状態に入ると、「第一」および「最後」データグラムを廃棄します。さらに、データグラムがICMPメッセージを発生させる場合に実装が決定する制御を管理者に提供する（すなわち、ICMP宛先到達不能、通信管理上禁止。タイプ= 3、コード= 13）。
The gateway encrypts the datagram using the indicated security association database (SAD) entry. The gateway enters this state only by command from the keying daemon, and upon entering this state, releases and forwards the "first" and "last" datagrams using the new encrypt policy.
ゲートウェイは、示されたセキュリティアソシエーションデータベース（SAD）エントリを使用してデータグラムを暗号化します。ゲートウェイは、キーイングデーモンから、この状態に入ったときにのみコマンドによってこの状態に入り、リリースおよび「第一」及び新たな暗号化ポリシーを使用して「最後の」データグラムを転送します。
If the associated SAD entry expires because of byte, packet or time limits, then the entry returns to the Hold policy, and an expire message is sent to the keying daemon.
関連SADエントリがあるため、バイト、パケット、又は時間制限を満了した場合、エントリは保留ポリシーに戻り、メッセージを期限切れキーイングデーモンに送られます。
All states may be created directly by the keying daemon while acting as a gateway.
ゲートウェイとして動作しながら、すべての状態は合わせるデーモンによって直接作成することができます。
Let the keying daemon maintain a collection of objects. Let them be called "connections" or "conn"s. There are two categories of connection objects: classes and instances. A class represents an abstract policy (i.e., what could be). An instance represents an actual connection (i.e., what is running at the time).
合わせるデーモンは、オブジェクトのコレクションを維持しましょう。それらを「接続」または「connの」Sと呼ばれてみましょう。クラスとインスタンス：接続オブジェクトの2つのカテゴリがあります。クラスは抽象ポリシー（すなわち、何があってもよい）を表します。インスタンスは、実際の接続（すなわち、同時に実行されているもの）を表します。
Let there be two further subtypes of connections: keying channels (Phase 1 SAs) and data channels (Phase 2 SAs). Each data channel object may have a corresponding SPD and SAD entry maintained by the datagram state machine.
キーイングチャネル（フェーズ1のSA）とデータチャネル（フェーズ2のSA）接続の2つの別のサブタイプであることができます。各データ・チャネル・オブジェクトは、対応するSPDデータグラム状態マシンによって維持SADエントリを有していてもよいです。
For the purposes of opportunistic encryption, there MUST, at least, be connection classes known as "deny", "always-clear-text", "OE-permissive", and "OE-paranoid". The latter two connection classes define a set of destination prefixes for which opportunistic encryption will be attempted. The administrator MAY set policy options in a number of additional places. An implementation MAY create additional connection classes to further refine these policies.
日和見暗号化の目的のためには、少なくとも、接続「拒否」として知られているクラス、「常にクリアテキスト」、「OE-許容」、および「OE-パラノイア」があるに違いありません。後者の二つの接続クラスは、便宜主義的な暗号化が試行されるため、宛先プレフィクスのセットを定義します。管理者は、追加の多くの場所で政策オプションを設定することができます。実装は、さらに、これらのポリシーを絞り込むために追加の接続クラスを作成することもできます。
The simplest system may need only the "OE-permissive" connection, and would list its own (single) IP address as the source address of this policy and the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the simplest policy is to try opportunistic encryption with all destinations.
最も単純なシステムでは、唯一の「OE-許容」の接続が必要な場合があり、このポリシーの送信元アドレスと宛先IPv4アドレスとしてワイルドカードアドレス0.0.0.0/0として、独自の（シングル）IPアドレスをリストします。これは最も単純なポリシーは、すべての宛先と日和見暗号化をしようとすることにあります。
This simplest policy SHOULD be offered as a preconfigured default.
この最も単純なポリシーは、事前設定済みのデフォルトとして提供されるべきです。
The distinction between permissive and paranoid Opportunistic Encryption ("OE-paranoid" below) use will become clear in the state transition differences.
許容と被害妄想日和見暗号化の区別（以下「OE-パラノイア」）を使用するには、状態遷移の違いで明らかになるだろう。
In brief, an OE-permissive policy means to permit traffic to flow in the clear when there is a failure to find and/or use the encryption keys. OE-permissive permits the network to function, even if in an insecure manner.
検索および/または暗号化キーを使用するには、障害がある場合に簡単で、OE-許容ポリシーが明確に流れるトラフィックを許可することを意味します。安全でない方法であれば、機能するOE許容許可ネットワーク。
On failure, a paranoid OE ("OE-paranoid") will install a drop policy. OE-paranoid permits traffic to flow only when appropriate security is available.
失敗した場合、被害妄想OE（「OE-パラノイア」）は、ドロップポリシーをインストールします。 OE-偏執許可トラフィックが適切なセキュリティが利用可能であるときにのみ流れます。
In this description of the keying machine's state transitions, the states associated with the keying system itself are omitted because they are best documented in the keying system ([RFC2407], [RFC2408], and [RFC2409] for ISAKMP/IKE), and the details are keying system specific. Opportunistic encryption is not dependent upon any specific keying protocol, but this document does provide requirements for those using ISAKMP/IKE to assure that implementations inter-operate.
キーイング・マシンの状態遷移のこの説明では、キーシステム自体に関連付けられた状態は、それらが最良キーイングシステム（ISAKMP / IKEのために[RFC2407]、[RFC2408]及び[RFC2409]）に記載されているので省略されており、詳細は、システムの特定のキーイングされています。日和見暗号化は、任意の特定のキーイングプロトコルに依存しないが、この文書では、実装が相互動作することを保証するために、ISAKMP / IKEを使用してそれらのための要件を提供します。
The state transitions that may be involved in communicating with the forwarding plane are omitted. PF_KEY and similar protocols have their own set of states required for message sends and completion notifications.
転送プレーンとの通信に関与している可能性がある状態遷移を省略しています。 PF_KEYと同様のプロトコルは、メッセージが送信すると完了通知のために必要な状態の独自のセットを持っています。
Finally, the retransmits and recursive lookups that are normal for DNS are not included in this description of the state machine.
最後に、DNSのために正常で再送信し、再帰的な検索は、ステートマシンのこの説明に含まれていません。
|
| PF_ACQUIRE
|
V
.---------------.
| nonexistent |
| connection |
`---------------'
| | |
send , | \
expired pass / | \ send
conn. msg / | \ deny
^ / | \ msg
| V | do \
.---------------. | DNS \ .---------------.
| clear-text | | lookup `->| deny |--->expired
| connection | | for | connection | connection
`---------------' | destination `---------------'
^ ^ | ^
| | no record | |
| | OE-permissive V | no record
| | .---------------. | OE-paranoid
| `------------| potential OE |---------'
| | connection | ^
| `---------------' |
| | |
| | got TXT record | DNSSEC failure
| | reply |
| V | wrong
| .---------------. | failure
| | authenticate |---------'
| | & parse TXT RR| ^
| repeated `---------------' |
| ICMP | |
| failures | initiate IKE to |
| (short timeout) | responder |
| V |
| phase-2 .---------------. | failure
| failure | pending |---------'
| (normal | OE | ^
| timeout) | |invalid | phase-2 fail (normal
| | |<--.SPI | timeout)
| | | | | ICMP failures (short
| | +=======+ |---' | timeout)
| | | IKE | | ^ |
`----------------| states|---------------'
| +=======+ | |
`---------------' |
| IPsec SA | invalid SPI
| established |
V | rekey time
.--------------. |
| keyed |<---|------------------------------.
| connection |----' |
`--------------' |
| timer |
| |
V |
.--------------. connection still active |
clear-text----->| expired |-----------------------------------'
deny----->| connection |
`--------------'
| dead connection - deleted
V
There is no connection instance for a given source/destination address pair. Upon receipt of a request for keying material for this source/destination pair, the initiator searches through the connection classes to determine the most appropriate policy. Upon determining an appropriate connection class, an instance object is created of that type. Both of the OE types result in a potential OE connection.
特定の送信元/宛先アドレスのペアのための接続インスタンスはありません。このソース/宛先ペアのための材料を合わせるための要求を受信すると、イニシエータは、最も適切なポリシーを決定するために、接続クラスを検索します。適切な接続クラスを決定する際に、インスタンスオブジェクトは、そのタイプの作成されています。 OEタイプの両方が潜在的OE接続につながります。
Failure to find an appropriate connection class results in an administrator-defined default.
管理者が定義したデフォルトで適切な接続クラスの結果を見つけることに失敗します。
In each case, when the initiator finds an appropriate class for the new flow, an instance connection is made of the class that matched.
イニシエータは新たなフローのために適切なクラスを見つけ、それぞれの場合において、インスタンス接続が一致したクラスで構成されています。
The nonexistent connection makes a transition to this state when an always-clear-text class is instantiated, or when an OE-permissive connection fails. During the transition, the initiator creates a pass-through policy object in the forwarding plane for the appropriate flow.
常にクリアテキストのクラスをインスタンス化するとき、またはOE-許容接続が失敗したとき。実在しない接続は、この状態に遷移します移行中に、開始剤は、適切なフローの転送プレーンにおいてパススルーポリシーオブジェクトを作成します。
Timing out is the only way to leave this state (see Section 3.2.7).
タイムアウト（セクション3.2.7を参照）、この状態のままにする唯一の方法です。
The empty connection makes a transition to this state when a deny class is instantiated, or when an OE-paranoid connection fails. During the transition, the initiator creates a deny policy object in the forwarding plane for the appropriate flow.
否定するクラスをインスタンス化するとき、またはOE-偏執接続が失敗したとき。空の接続は、この状態に遷移します移行中に、開始剤は、適切なフローの転送プレーンにおいて拒否ポリシー・オブジェクトを作成します。
Timing out is the only way to leave this state (see Section 3.2.7).
タイムアウト（セクション3.2.7を参照）、この状態のままにする唯一の方法です。
The empty connection makes a transition to this state when one of either OE class is instantiated. During the transition to this state, the initiator creates a hold policy object in the forwarding plane for the appropriate flow.
いずれかOEクラスの一つがインスタンス化されるとき、空の接続は、この状態に遷移します。この状態への遷移時に、イニシエータは、適切なフローの転送プレーンにおいて保持ポリシーオブジェクトを作成します。
In addition, when making a transition into this state, DNS lookup is done in the reverse-map for a TXT delegation resource record (see Section 5.2). The lookup key is the destination address of the flow.
この状態に移行する際に加えて、DNSルックアップはTXT委譲リソースレコードの逆マップで行われます（5.2節を参照してください）。検索キーは、フローの宛先アドレスです。
There are three ways to exit this state:
この状態を終了するには3つの方法があります。
Based upon the results of the DNS lookup, the potential OE connection makes a transition to the pending OE connection state. The conditions for a successful DNS look are:
DNSルックアップの結果に基づいて、潜在的OE接続が保留中のOE接続状態に遷移します。 successful DNSルックのための条件は次のとおりです。
Note that if the initiator does not find the public key present in the TXT delegation record, then the public key must be looked up as a sub-state. Only successful completion of all the DNS lookups is considered a success.
イニシエータはTXT委譲レコード内の公開鍵存在を見つけることができなかった場合は、公開鍵は、サブ状態として見上げなければならないことに注意してください。すべてのDNSルックアップのだけが正常に完了したが、成功とみなされます。
If DNS lookup does not find a resource record or if DNS times out, then the initiator considers the receiver not OE capable. If this is an OE-paranoid instance, then the potential OE connection makes a transition to the deny connection state. If this is an OE-permissive instance, then the potential OE connection makes a transition to the clear-text connection state.
DNSルックアップは、DNSの時間をリソースレコードを見つけた場合、またはしない場合には、イニシエータは、受信機が対応OEではないと考えています。これはOE-妄想インスタンスである場合、潜在的OE接続は拒否接続状態に遷移します。これはOE-許容インスタンスである場合、潜在的OE接続はクリアテキスト接続状態に遷移します。
If the initiator finds a resource record, but it is not properly formatted, or if DNSSEC is enabled and reports a failure to authenticate, then the potential OE connection makes a transition to the deny connection state. This action SHOULD be logged. If the administrator wishes to override this transition between states, then an always-clear class can be installed for this flow. An implementation MAY make this situation a new class.
イニシエータは、リソースレコードを発見し、それが適切にフォーマットされていない、またはDNSSECを有効にして認証に失敗したことを報告している場合、潜在的なOE接続は、接続を拒否する状態に遷移する場合。このアクションは、ログインする必要があります。管理者は、状態間のこの移行を無効にしたい場合は、常に明確なクラスは、この流れのためにインストールすることができます。実装は、このような状況新しいクラス作成することができます。
An implementation SHOULD also provide an additional administrative control on delegation records and DNSSEC. This control would apply to delegation records (the TXT records in the reverse-map) that are not protected by DNSSEC. Records of this type are only permitted to delegate to their own address as a gateway. When this option is enabled, an active attack on DNS will be unable to redirect packets to other than the original destination.
実装は、委任レコードとDNSSECに関する追加管理制御を提供する必要があります。このコントロールは、DNSSECで保護されていない委任レコード（逆マップ内のTXTレコード）に適用されます。このタイプのレコードは唯一のゲートウェイとして、自分のアドレスに委任することが許可されています。このオプションを有効にすると、DNSへの積極的な攻撃は、元の宛先以外にパケットをリダイレクトすることができません。
The potential OE connection makes a transition to this state when the initiator determines that all the information required from the DNS lookup is present. Upon entering this state, the initiator attempts to initiate keying to the gateway provided.
イニシエータは、DNSルックアップに必要なすべての情報が存在すると判断した場合の潜在的OE接続は、この状態に遷移します。この状態に入ると、イニシエータが提供ゲートウェイにキーイングを開始しようとします。
Exit from this state occurs with either a successfully created IPsec SA or a failure of some kind. Successful SA creation results in a transition to the key connection state.
この状態からの出口が正常に作成されたIPsec SAまたはいくつかの種類の失敗のいずれかで発生します。キー接続状態への遷移で成功したSAの作成結果。
Three failures have caused significant problems. They are clearly not the only possible failures from keying.
三つの障害が重大な問題を引き起こしています。彼らは明らかにキーイングからのみ可能故障ではありません。
Note that if there are multiple gateways available in the TXT delegation records, then a failure can only be declared after all of them have been tried. Further, creation of a phase 1 SA does not constitute success. A set of phase 2 SAs (a tunnel) is considered success.
TXTの委任レコードで利用可能な複数のゲートウェイがある場合、それらのすべてが試された後、その後、障害が唯一宣言することができることに注意してください。さらに、フェーズ1 SAの作成は成功するものではありません。フェーズ2つのSA（トンネル）のセットが成功であると考えられます。
The first failure occurs when an ICMP port unreachable is consistently received without any other communication, or when there is silence from the remote end. This usually means that either the gateway is not alive, or the keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition to the clear-text connection, but with a low lifespan. For an OE-pessimistic connection, the initiator makes a transition to the deny connection again with a low lifespan. The lifespan in both cases is kept low because the remote gateway may be in the process of rebooting or be otherwise temporarily unavailable.
到達不能ICMPポートが一貫して、他の通信なしで受信されたときに最初の故障が発生し、又はリモートエンドからの沈黙が存在する場合。これは通常どちらかのゲートウェイが生きていない、または合わせるデーモンが機能していないことを意味します。 OE-許容接続のために、開始剤は、クリアテキスト接続に遷移するが、低寿命を有します。 OE-悲観的な接続のために、開始剤は低寿命と再び否定接続に遷移します。リモートゲートウェイがリブートのプロセスであっても、またはそうでなければ一時的に利用できないかもしれないので、両方の場合に寿命が低く保たれます。
The length of time to wait for the remote keying daemon to wake up is a matter of some debate. If there is a routing failure, 5 minutes is usually long enough for the network to re-converge. Many systems can reboot in that amount of time as well. However, 5 minutes is far too long for most users to wait to hear that they can not connect using OE. Implementations SHOULD make this a tunable parameter.
目を覚ますために、リモート合わせるデーモンを待機する時間の長さは、いくつかの議論の問題です。ルーティングの失敗、5分がある場合は、再収束するネットワークのために十分な長さは通常です。多くのシステムは、同様にその時間に再起動することができます。しかし、5分は、ほとんどのユーザーは、彼らがOEを使用して接続できないことを聞いて待つためにあまりにも長いです。実装は、この調整可能なパラメータを行う必要があります。
The second failure occurs after a phase 1 SA has been created, but there is either no response to the phase 2 proposal, or the initiator receives a negative notify (the notify must be authenticated). The remote gateway is not prepared to do OE at this time. As before, the initiator makes a transition to the clear-text or the deny connection based upon connection class, but this time with a normal lifespan.
フェーズ1 SAが作成された後、第2障害が発生し、そこフェーズ2の提案への応答のいずれかではなく、又は開始剤が負（通知する認証されなければならない）通知を受信します。リモートゲートウェイは、この時点でOEを行うことは準備ができていないです。前と同じように、イニシエータは、クリアテキストまたは接続クラスに基づいて拒否し、接続が、通常の寿命を持つこの時間に移行します。
The third failure occurs when there is signature failure while authenticating the remote gateway. This can occur when there has been a key roll-over, but DNS has not caught up. In this case again, the initiator makes a transition to the clear-text or the deny connection based upon the connection class. However, the lifespan depends upon the remaining time to live in the DNS. (Note that DNSSEC signed resource records have a different expiry time from non-signed records.)
リモートゲートウェイを認証しながら、署名障害がある場合に第三の障害が発生します。キーロールオーバーがあった場合に発生することがありますが、DNSは追いついていません。再びこの場合、開始剤は、クリアテキストまたは接続クラスに基づいて拒否接続に遷移します。しかし、寿命はDNSに生きるための残り時間に依存します。 （DNSSEC非署名レコード異なる満了時間を有するリソースレコードに署名したことに注意してください。）
The pending OE connection makes a transition to this state when session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt policy in the forwarding plane for this flow.
セッション鍵材料（フェーズ2のSA）が導出される際に、保留中のOE接続は、この状態に遷移します。開始剤は、このフローの転送プレーンにおいて暗号化ポリシーを作成します。
There are three ways to exit this state. The first is by receipt of an authenticated delete message (via the keying channel) from the peer. This is normal teardown and results in a transition to the expired connection state.
この状態を終了するには、3つの方法があります。最初のピアから（キーイングチャネルを介して）認証された削除メッセージを受信したことによるものです。これは、通常のティアダウンし、期限切れの接続状態への遷移をもたらすです。
The second exit is by expiry of the forwarding plane keying material. This starts a re-key operation with a transition back to pending OE connection. In general, the soft expiry occurs with sufficient time left to continue using the keys. A re-key can fail, which may result in the connection failing to clear-text or deny as appropriate. In the event of a failure, the forwarding plane policy does not change until the phase 2 SA (IPsec SA) reaches its hard expiry.
第二の出口は転送面キーイング材料の満了によるものです。これは、バックOE接続を保留への移行で再キー操作を開始します。一般に、ソフト有効期限は、鍵の使用を継続したまま十分な時間で起こります。再キーがテキストをクリアするか、などの適切な拒否に失敗接続をもたらす可能性がある、失敗する可能性があります。フェーズ2 SA（のIPsec SA）は、そのハード有効期限に達するまで、障害が発生した場合に、転送プレーンポリシーは変化しません。
The third exit is in response to a negotiation from a remote gateway. If the forwarding plane signals the control plane that it has received an unknown SPI from the remote gateway, or an ICMP is received from the remote gateway indicating an unknown SPI, the initiator should consider that the remote gateway has rebooted or restarted. Since these indications are easily forged, the implementation must exercise care. The initiator should make a cautious (rate-limited) attempt to re-key the connection.
第三の出口が、リモートゲートウェイからの交渉に応答します。転送プレーンは、リモートゲートウェイから未知のSPIを受信した制御プレーン信号を送る、またはICMP未知SPIを示す遠隔ゲートウェイから受信された場合、イニシエータは、リモートゲートウェイが再起動または再起動したことを考慮すべきです。これらの表示は容易に偽造されているので、実装は注意を払わなければなりません。イニシエータは、再度キー接続に慎重（レート制限）の試行を行う必要があります。
The initiator will periodically place each of the deny, clear-text, and keyed connections into this sub-state. See Section 3.4 for more details of how often this occurs. The initiator queries the forwarding plane for last use time of the appropriate policy. If the last use time is relatively recent, then the connection returns to the previous deny, clear-text or keyed connection state. If not, then the connection enters the expired connection state.
イニシエータは、定期的にこのサブ状態に拒否、クリアテキスト、およびキー付き接続の各々を配置します。これが発生する頻度の詳細は、3.4節を参照してください。イニシエータは、適切な政策の最後の使用時間のためのフォワーディングプレーンを照会します。最後に、使用時間が比較的最近のものである場合、接続は、前の拒否、クリアテキストまたはキー付き接続状態に戻ります。いない場合、接続は期限切れの接続状態に入ります。
The DNS query and answer that lead to the expiring connection state are also examined. The DNS query may become stale. (A negative, i.e., no such record, answer is valid for the period of time given by the MINIMUM field in an attached SOA record. See [RFC1034] section 4.3.4.) If the DNS query is stale, then a new query is made. If the results change, then the connection makes a transition to a new state as described in potential OE connection state.
期限切れの接続状態を引き起こすDNSクエリと答えも検討されています。 DNSクエリが古くなる可能性があります。 （負、すなわち、そのようなレコードは、答えは添付のSOAレコードの最小フィールドで与えられた時間の期間有効である。参照[RFC1034]セクション4.3.4。）DNSクエリが古くなっている場合、新しいクエリ行われます。結果が変更された場合、その接続は、潜在的OE接続状態に記載されているように、新しい状態に遷移します。
Note that when considering how stale a connection is, both outgoing SPD and incoming SAD must be queried as some flows may be unidirectional for some time.
接続がどのように失効と判断する場合、いくつかのフローがいくつかの時間のために一方向のかもしれとして、出て行くSPD着信SADの両方を照会しなければならないことに注意してください。
Also note that the policy at the forwarding plane is not updated unless there is a conclusion that there should be a change.
また、変更がなければならないという結論がない限り、転送プレーンでのポリシーが更新されないことに注意してください。
Entry to this state occurs when no datagrams have been forwarded recently via the appropriate SPD and SAD objects. The objects in the forwarding plane are removed (logging any final byte and packet counts, if appropriate) and the connection instance in the keying plane is deleted.
何のデータグラムが適切なSPDとSADのオブジェクトを経由して、最近転送されていない場合は、この状態にエントリが発生します。転送プレーン内のオブジェクトは、（適切であれば、任意の最後のバイトおよびパケットカウントをロギング）除去され、キーイング平面における接続インスタンスが削除されます。
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in Section 3.4.
イニシエータは、3.4節で説明したようにISAKMP / IKEのフェーズ2つのSAをクリーンアップするために削除し送信します。
Whether or not to delete the phase 1 SAs at this time is left as a local implementation issue. Implementations that do delete the phase 1 SAs MUST send authenticated delete messages to indicate that they are doing so. There is an advantage to keeping the phase 1 SAs until they expire: they may prove useful again in the near future.
この時点ではフェーズ1つのSAを削除するかどうかは、ローカルの導入問題として残されています。フェーズ1 SAを削除しない実装は、彼らがそうしていることを示すために、メッセージを削除し、認証送らなければなりません。有効期限が切れるまで、フェーズ1つのSAを維持する利点があります：彼らは、近い将来に再び有用であろう。
The responder has a set of objects identical to those of the initiator.
レスポンダは、イニシエータと同一のオブジェクトのセットを有しています。
The responder receives an invitation to create a keying channel from an initiator.
レスポンダはイニシエータからのキーイングチャネルを作成するための招待状を受け取ります。
|
| IKE main mode
| phase 1
V
.-----------------.
| unauthenticated |
| OE peer |
`-----------------'
|
| lookup KEY RR in in-addr.arpa
| (if ID_IPV4_ADDR)
| lookup KEY RR in forward
| (if ID_FQDN)
V
.-----------------. RR not found
| received DNS |---------------> log failure
| reply |
`----+--------+---'
phase 2 | \ misformatted
proposal | `------------------> log failure
V
.----------------.
| authenticated | identical initiator
| OE peer |--------------------> initiator
`----------------' connection found state machine
|
| look for TXT record for initiator
|
V
.---------------.
| authorized |---------------------> log failure
| OE peer |
`---------------'
|
|
V
potential OE
connection in
initiator state
machine
Upon entering this state, the responder starts a DNS lookup for a KEY record for the initiator. The responder looks in the reverse-map for a KEY record for the initiator if the initiator has offered an ID_IPV4_ADDR, and in the forward map if the initiator has offered an ID_FQDN type. (See [RFC2407] section 4.6.2.1.)
この状態に入ると、レスポンダはイニシエータのKEYレコードをDNSルックアップを開始します。イニシエータがID_IPV4_ADDRを提供している場合、フォワードマップにイニシエータがID_FQDNの種類を提供している場合、レスポンダはイニシエータのKEYレコードの逆マップで検索します。 （[RFC2407]セクション4.6.2.1を参照）。
The responder exits this state upon successful receipt of a KEY from DNS, and use of the key to verify the signature of the initiator.
成功したDNSからのKEYの領収書、およびキーの使用時に応答が終了する。この状態では、開始剤の署名を検証します。
Successful authentication of the peer results in a transition to the authenticated OE Peer state.
認証OEピア状態への遷移におけるピア結果の認証が成功。
Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation protocol. It is really a form of pseudo-state.
認証されていないOEピア状態は、一般にキー交渉プロトコルの途中で発生することに注意してください。それは本当に疑似状態の形です。
The peer will eventually propose one or more phase 2 SAs. The responder uses the source and destination address in the proposal to finish instantiating the connection state using the connection class table. The responder MUST search for an identical connection object at this point.
ピアは、最終的には一つ以上のフェーズ2 SAを提案します。レスポンダは、接続クラステーブルを使用して接続状態をインスタンス化を完了するために提案して送信元と送信先アドレスを使用しています。応答者は、この時点では、同一の接続オブジェクトを検索する必要があります。
If an identical connection is found, then the responder deletes the old instance, and the new object makes a transition to the pending OE connection state. This means that new ISAKMP connections with a given peer will always use the latest instance, which is the correct one if the peer has rebooted in the interim.
同じ接続が見つかった場合、応答者は、古いインスタンスを削除し、新しいオブジェクトは、保留中のOE接続状態に遷移します。これは、指定したピアとの新しいISAKMP接続は常にピアが暫定的に再起動した場合は正しいものである最新のインスタンスを、使用することを意味します。
If an identical connection is not found, then the responder makes the transition according to the rules given for the initiator: it installs appropriate policy: clear, drop, or OE.
同一の接続が検出されない場合、次いでレスポンダは、イニシエータに与えられた規則に従って遷移する：明確な、ドロップ、またはOE：それが適切なポリシーをインストールします。
If OE, and the phase 2 ID (source IP) is different than the phase 1 ID, then additional authorization is required. A TXT record associated with the proposed phase 2 source IP is requested. This is used to confirm authorization for the phase 1 identity to encrypt on behalf of the phase 2. Successful retrieval results in a transition to "Authorized OE Peer".
OE、およびフェーズ2 ID（送信元IP）はフェーズ1のIDと異なる場合は、追加の許可が必要です。提案されたフェーズ2のソースIPに関連したTXTレコードが要求されています。これは、「許可OEピア」への移行にフェーズ2成功した検索結果に代わって暗号化するために、フェーズ1のアイデンティティの承認を確認するために使用されます。
Note that if the initiator is in OE-paranoid mode and the responder is in either always-clear-text or deny, then no communication is possible according to policy. An implementation is permitted to create new types of policies such as "accept OE but do not initiate it". This is a local matter.
イニシエータは、OE-妄想モードであり、レスポンダは常にクリアテキストまたは拒否のいずれかである場合、全く通信がポリシーに従って可能ではないことに留意されたいです。実装は、このような「OEを受け入れ、それを開始していない」として、政策の新しいタイプを作成することが許可されています。これはローカルの問題です。
This state is entered from the Authenticated OE Peer state, upon successful retrieval of the TXT record. The contents of the record are confirmed -- any failures lead to errors, as indicated in Section 3.2.4.
この状態は、TXTレコードの正常な取得すると、認証されたOEピア状態から入力されます。 3.2.4項に示されているように、任意の失敗がエラーにつながる - レコードの内容が確認されています。
A potentially unlimited number of tunnels may exist. In practice, only a few tunnels are used during a period of time. Unused tunnels MUST, therefore, be torn down. Detecting when tunnels are no longer in use is the subject of this section.
トンネルの潜在的に無制限の数が存在してもよいです。実際には、ほんのわずかのトンネルは、一定期間中に使用されています。未使用のトンネルは、そのため、取り壊さなければなりません。トンネルが使用されなくなったときを検出しないことは、このセクションの主題です。
There are two methods for removing tunnels: explicit deletion or expiry.
明示的な削除や有効期限：トンネルを除去するための2つの方法があります。
Explicit deletion requires an IKE delete message. The deletes MUST be authenticated, so both ends of the tunnel must maintain the keying channel (phase 1 ISAKMP SA). An implementation that refuses to either maintain or recreate the keying channel SA will be unable to use this method.
明示的な削除は、IKEメッセージを削除が必要です。削除は、認証されなければならないので、トンネルの両端は、キーイングチャネル（フェーズ1 ISAKMP SA）を維持しなければなりません。キーイングチャンネルSAを維持するか、または再作成するか拒否する実装は、このメソッドを使用することができません。
The tunnel expiry method simply allows the IKE daemon to expire normally without attempting to re-key it.
トンネル満了方法は、単に、IKEデーモンはそれを再度キーを試みることなく、正常に期限切れにすることを可能にします。
Regardless of which method is used to remove tunnels, the implementation MUST use a method to determine if the tunnel is still in use. The specifics are a local matter, but the FreeS/WAN project uses the following criteria. These criteria are currently implemented in the key management daemon, but could also be implemented at the SPD layer using an idle timer.
関係なく、トンネルを除去するために使用される方法の実装は、トンネルがまだ使用中であるかどうかを決定するための方法を使用しなければなりません。詳細はローカルの問題ですが、は、FreeS / WANプロジェクトは、以下の基準を使用しています。これらの基準は、現在の鍵管理デーモンに実装されている、だけでなく、アイドルタイマーを使用してSPD層で実施することができます。
Set a short initial (soft) lifespan of 1 minute since many net flows last only a few seconds.
多くのネットフローはほんの数秒続くので、1分の短い初期（ソフト）の寿命を設定してください。
At the end of the lifespan, check to see if the tunnel was used by traffic in either direction during the last 30 seconds. If so, assign a longer tentative lifespan of 20 minutes, after which, look again. If the tunnel is not in use, then close the tunnel.
寿命の終わりには、トンネルが最後の30秒の間に、いずれかの方向にトラフィックによって使用されたかどうかを確認します。その場合は、その後、再び見て、20分の長い仮寿命を割り当てます。トンネルが使用されていない場合は、トンネルを閉じます。
The expiring state in the key management system (see Section 3.2.7) implements these timeouts. The timer above may be in the forwarding plane, but then it must be resettable.
鍵管理システムで期限切れ状態（3.2.7項を参照）は、これらのタイムアウトを実装します。上記タイマーは、転送プレーンであってもよいが、それはリセット可能でなければなりません。
The tentative lifespan is independent of re-keying; it is just the time when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) Unlike re-keying, this tunnel use check is not costly and should happen reasonably frequently.
暫定的な寿命は、再キーイングとは無関係です。ちょうどトンネルの将来を次回考えられている時間です。 （用語の寿命がなく、この理由のために寿命よりここで使用される。）、再キーイングとは異なり、このトンネルの利用チェックは高価ではなく、合理的に頻繁に起こるべきです。
A multi-step back-off algorithm is not considered worth the effort here.
マルチステップバックオフアルゴリズムは、ここでは努力の価値とはみなされません。
If the security gateway and the client host are the same, and not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel teardown decisions MAY pay attention to TCP connection status as reported by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is expected. Closing of the only TCP connection through a tunnel is a strong hint that no more traffic is expected.
セキュリティゲートウェイとクライアントホストが同じである、といないで、スタックバンプまたはBump-In-The-Wire方式の実装と、ローカルTCP層によって報告されるように、トンネルティアダウンの決定は、TCPコネクションの状態に注意を支払ってもよいです。まだオープンTCP接続がより多くのトラフィックが予想されることはほぼ保証されます。トンネルを通してのみTCPコネクションを閉じても、何もより多くのトラフィックが予想されていないという強いヒントです。
Teardown should always be coordinated between the two ends of the tunnel by interpreting and sending delete notifications. There is a detailed sub-state in the expired connection state of the key manager that relates to retransmits of the delete notifications, but this is considered to be a keying system detail.
ティアダウンは常に解釈し、削除通知を送信することにより、トンネルの両端の間で調整されるべきです。そこに詳細なサブ状態は、削除通知の再送に関する鍵管理の有効期限が切れた接続状態にあるが、これはキーイングシステム詳細であると考えられます。
On receiving a delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones also and notify the remote end with a delete. If the local system receives a delete for a tunnel that is no longer in existence, then two delete messages have crossed paths. Ignore the delete. The operation has already been completed. Do not generate any messages in this situation.
トンネル（またはそれらのサブセット）のアウトバウンドSAの削除を受信し、また受信ものを取り壊すと削除とリモートエンドに通知します。ローカルシステムが存在しなくなったトンネルの削除を受信した場合、2つの削除メッセージは、経路を横断しています。削除を無視します。操作がすでに完了しています。このような状況のいずれかのメッセージを生成しません。
Tunnels are to be considered as bidirectional entities, even though the low-level protocols don't treat them this way.
トンネルは、低レベルのプロトコルは、それらをこのように扱うことはありませんが、双方向のエンティティとして考慮されるべきです。
When the deletion is initiated locally, rather than as a response to a received delete, send a delete for (all) the inbound SAs of a tunnel. If the local system does not receive a responding delete for the outbound SAs, try re-sending the original delete. Three tries spaced 10 seconds apart seems a reasonable level of effort. A failure of the other end to respond after 3 attempts indicates that the possibility of further communication is unlikely. Remove the outgoing SAs. (The remote system may be a mobile node that is no longer present or powered on.)
削除がローカルではなく、受信した削除に対する応答として開始されると、トンネルの（すべての）インバウンドSAの削除を送信します。ローカルシステムが応答アウトバウンドSAの削除を受信しない場合、元の削除再送信してみてください。 10秒間隔の3回の試行は離れて努力の合理的なレベルです。 3回の試行後に対応する他方の端部の故障は、通信の可能性はそうであることを示しています。送信SAを削除します。 （リモートシステムはもはや存在または電源が投入されていないモバイルノードであってもよいです。）
After re-keying, transmission should switch to using the new outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs should be cleared out promptly (delete should be sent for the outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics.
再キーイングした後、送信は、新たな送信SAをすぐに（ISAKMPやIPsec）、および古い残りの発信SAを使用するように切り替える必要がありますが（削除、発信SAのために送られるべきである）のではなく、それらの期限が切れるのを待って速やかにクリアする必要があります。これは混乱を軽減し、診断を行うオペレータの混乱を最小限に抑えることができます。
The IKE wire protocol needs no modifications. The major changes are implementation issues relating to how the proposals are interpreted, and from whom they may come.
IKEワイヤプロトコルには変更を必要としません。主な変更点は、提案がどのように解釈されるかに関する実装上の問題であり、誰から彼らが来るかもしれません。
As opportunistic encryption is designed to be useful between peers without prior operator configuration, an IKE daemon must be prepared to negotiate phase 1 SAs with any node. This may require a large amount of resources to maintain cookie state, as well as large amounts of entropy for nonces, cookies, and so on.
日和見暗号化は、従来オペレータ構成なしピア間で有用であるように設計されているように、IKEデーモンは、任意のノードと位相1つのSAをネゴシエートするために準備されなければなりません。これには、クッキーの状態を維持するために大量のリソースだけでなく、ナンスのためのエントロピーの大量、クッキー、および必要な場合があります。
The major changes to support opportunistic encryption are at the IKE daemon level. These changes relate to handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be co-resident on the same gateway.
日和見暗号化をサポートするための主な変更点は、IKEデーモンレベルです。これらの変更は、ファイアウォールと同じゲートウェイ上で共存し得る他のセキュリティ設備を備えた鍵取得要求を、公開鍵とTXTレコードの検索、および相互作用の取り扱いに関連しています。
In a typical configured tunnel, the address of SG-B is provided via configuration. Furthermore, the mapping of an SPD entry to a gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then the mapping to a gateway is determined by the reverse DNS records.
典型的な構成トンネル内、SG-Bのアドレスは、構成を介して提供されます。 1マッピング：また、ゲートウェイにSPDエントリのマッピングは、典型的には1です。 0.0.0.0/0 SPDエントリの技術が使用される場合、ゲートウェイへのマッピングは、逆DNSレコードによって決定されます。
The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. Although a synchronous DNS request can be implemented for proof of concept, experience is that it can cause very high latencies when a queue of queries must all timeout in series.
DNSルックアップを行い、応答を待つ必要は通常、IKEに新しい状態と新しいイベントソース（DNS応答）をご紹介します。同期DNS要求がコンセプトの証明のために実装することができますが、経験はそれが非常に高いレイテンシを引き起こす可能性があることであるとき、クエリのキューシリーズのすべてのタイムアウトがなければなりません。
Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with some of the protocol steps.
非同期DNSルックアップを使用すると、プロトコル手順の一部でDNSルックアップの重複を可能にします。
SG-A will have to establish its identity. Use an IPv4 (IPv6) ID in phase 1.
SG-Aは、そのアイデンティティを確立する必要があります。フェーズ1でのIPv4（IPv6）のIDを使用します。
There are many situations where the administrator of SG-A may not be able to control the reverse DNS records for SG-A's public IP address. Typical situations include dialup connections and most residential- type broadband Internet access (ADSL, cable-modem) connections. In these situations, a fully qualified domain name that is under the control of SG-A's administrator may be used when acting as an initiator only. The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions.
SG-Aの管理者は、SG-AのパブリックIPアドレスの逆引きDNSレコードを制御することができないかもしれない多くの状況があります。典型的な状況では、ダイヤルアップ接続と最もresidential-タイプのブロードバンドインターネット接続（ADSL、ケーブルモデム）接続が含まれます。唯一のイニシエータとして動作する場合、これらの状況では、SG-Aの管理者の管理下にある完全修飾ドメイン名を使用することができます。 FQDN IDは、より多くの詳細と制限については、フェーズ1節を参照してください5.3で使用する必要があります。
Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or an FQDN ID, an IKE daemon needs to examine local caches and configuration files to determine if this is part of a configured tunnel. If no configured tunnels are found, then the implementation should attempt to retrieve a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or from the forward DNS in the case of FQDN ID.
IPv4の（IPv6）のID又はFQDN IDのいずれかとのフェーズ1 SAの提案を受信すると、IKEデーモンは、これが設定されたトンネルの一部であるかどうかを決定するためにローカルキャッシュおよび構成ファイルを検査する必要があります。いかなる構成トンネルが見つからない場合、実装は、IPv4 / IPv6のIDの場合には逆DNSから、またはFQDN IDの場合にフォワードDNSからキーレコードを取得しようとしなければなりません。
It is reasonable that if other non-local sources of policy are used (COPS, LDAP), they be consulted concurrently, but that some clear ordering of policy be provided. Note that due to variances in latency, implementations must wait for positive or negative replies from all sources of policy before making any decisions.
ポリシーの他の非ローカルソースは（COPS、LDAP）を使用している場合、彼らは同時に相談することが合理的であるが、政策のいくつかの明確な順序を提供すること。レイテンシーのばらつきに起因して、実装はどんな決定を下す前に、ポリシーのすべてのソースからの正または負の応答を待たなければならないことに注意してください。
The implementation described (FreeS/WAN 1.98) neither uses DNSSEC directly to explicitly verify the authenticity of zone information, nor uses the NSEC records to provide authentication of the absence of a TXT or KEY record. Rather, this implementation uses a trusted path to a DNSSEC-capable caching resolver.
実装は、明示的にゾーン情報の信憑性を検証するために、直接DNSSECを使用しない、またTXTまたはKEYレコードの不在の認証を提供するために、NSECレコードを使用して、どちらも（は、FreeS / WAN 1.98）を説明しました。むしろ、この実装はDNSSEC対応キャッシングリゾルバへの信頼されたパスを使用しています。
To distinguish between an authenticated and an unauthenticated DNS resource record, a stub resolver capable of returning DNSSEC information MUST be used.
認証され、認証されていないDNSリソースレコードを区別するために、DNSSEC情報を返すことが可能なスタブリゾルバを使用しなければなりません。
Main mode MUST be used.
メインモードを使用しなければなりません。
The initiator MUST offer at least one proposal using some combination of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be proposed first. (See [RFC3526])
3DES、HMAC-MD5またはHMAC-SHA1、DHグループ2または5族5最初に提案されるべきである。開始剤は、いくつかの組み合わせを使用して、少なくとも1つの提案を提供しなければなりません。 （[RFC3526]を参照）。
The initiator MAY offer additional proposals, but the cipher MUST not be weaker than 3DES. The initiator SHOULD limit the number of proposals such that the IKE datagrams do not need to be fragmented.
イニシエータは、追加の提案を提供することがありますが、暗号は3DESよりも弱くしてはいけません。イニシエータは、IKEデータグラムを断片化する必要がないことをそのような提案の数を制限する必要があります。
The responder MUST accept one of the proposals. If any configuration of the responder is required, then the responder is not acting in an opportunistic way.
応答者は、提案の1を受け入れなければなりません。レスポンダの任意の構成が必要な場合は、応答者は日和見な方法で行動していません。
The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external interface of the initiator for phase 1. (There is an exception, see Section 5.3.) The authentication method MUST be RSA public key signatures. The RSA key for the initiator SHOULD be placed into a DNS KEY record in the reverse space of the initiator (i.e., using in-addr.arpa or ip6.arpa).
イニシエータは、認証方式がRSA公開鍵署名する必要があります（例外があり、セクション5.3を参照。）フェーズ1のための開始剤の外部インタフェースのID_IPV4_ADDR（IPv6のID_IPV6_ADDR）を使用してください。イニシエータのためのRSAキー（即ち、またはin-addr.arpa使用ip6.arpa）イニシエータの逆空間のDNS KEYレコードに置かれるべきです。
The initiator MUST propose a tunnel between the ultimate sender ("Alice" or "A") and ultimate recipient ("Bob" or "B") using 3DES-CBC mode, MD5, or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
開始剤は、3DES-CBCモード、MD5またはSHA1認証を使用して、究極の送信者（「アリス」または「A」）と、最終的な受信者（「ボブ」又は「B」）との間のトンネルを提案しなければなりません。完全転送秘密を指定する必要があります。
Tunnel mode MUST be used.
トンネルモードを使用しなければなりません。
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
アイデンティティは、マスク/ 32であるとID_IPV4_ADDR_SUBNETなければなりません。
Authorization for the initiator to act on Alice's behalf is determined by looking for a TXT record in the reverse-map at Alice's IP address.
アリスの代理として行動するイニシエータの許可は、アリスのIPアドレスの逆マップでTXTレコードを探すことで決定されます。
Compression SHOULD NOT be mandatory. It MAY be offered as an option.
圧縮は必須べきではありません。これは、オプションとして提供されることがあります。
In order to establish their own identities, security gateways SHOULD publish their public keys in their reverse DNS via DNSSEC's KEY record. See section 3 of RFC 2535 [RFC2535].
自分のアイデンティティを確立するために、セキュリティゲートウェイは、DNSSECのキーレコードを経由して自分のDNS逆に自分の公開鍵を公開する必要があります。 RFC 2535のセクション3 [RFC2535]を参照してください。
For example:
例えば：
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
KEY 0x4200 4 1 AQNJjkKlIk9 ... nYyUkKK8
0x4200: The flag bits, indicating that this key is prohibited for confidentiality use (it authenticates the peer only, a separate Diffie-Hellman exchange is used for confidentiality), and that this key is associated with the non-zone entity whose name is the RR owner name. No other flags are set.
0x4200：このキーは、機密性の使用のために禁止されていることを示すフラグビットは、（それだけで、別のDiffie-Hellman交換が機密保持のために使用されるピアを認証する）、このキーは、その名前非ゾーンエンティティに関連付けられていることRRの所有者名。他のフラグが設定されていません。
4: This indicates that this key is for use by IPsec.
4：これは、このキーはIPSecで使用するためであることを示しています。
1: An RSA key is present.
1：RSAキーが存在しています。
AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in [RFC3110].
AQNJjkKlIk9 ... nYyUkKK8：[RFC3110]で説明したようにホストの公開鍵。
Use of several KEY records allows for key roll-over. The SIG Payload in IKE phase 1 SHOULD be accepted if the public key, given by any KEY RR, validates it.
いくつかのキーレコードの使用は、キーロールオーバーすることができます。任意のキーのRRによって与えられた公開鍵が、それを検証した場合に、IKEフェーズ1におけるSIGペイロードが受け入れられるべきです。
If, for example, machine Alice wishes SG-A to act on her behalf, then she publishes a TXT record to provide authorization for SG-A to act on Alice's behalf. This is done similarly for Bob and SG-B.
例えば、機械アリスが彼女のために行動するSG-Aを希望する場合は、その後、彼女はアリスのために行動するSG-Aの認可を提供するために、TXTレコードを発行しています。これは、ボブとSG-Bについても同様に行われます。
These records are located in the reverse DNS (in-addr.arpa or ip6.arpa) for their respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC. DNSSEC is required to defend against active attacks.
これらのレコードは、それぞれのIPアドレスの逆引きDNS（in-addr.arpaまたはip6.arpa）に位置しています。リバースDNSは、DNSSECで保護する必要があります。 DNSSECは、アクティブな攻撃を防御するために必要とされます。
If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at:
アリスのアドレスがP.Q.R.Sであれば、彼女はでレコードを公開することによって、彼女に代わって行動するために別のノードを承認することができます：
S.R.Q.P.in-addr.arpa
Ｓ。Ｒ。Ｑ。Ｐ。いんーあっｄｒ。あｒぱ
The contents of the resource record are expected to be a string that uses the following syntax, as suggested in RFC1464 [RFC1464]. (Note that the reply to query may include other TXT resource records used by other applications.)
RFC1464 [RFC1464]で提案されているようにリソースレコードの内容は、次の構文を使用して文字列であることが予想されます。 （クエリに対する応答は、他のアプリケーションによって使用される他のTXTリソースレコードを含んでいてもよいことに留意されたいです。）
X-IPsec-Server(P)=A.B.C.D public-key
X-のIPsec-サーバー（P）= A.B.C.D公開鍵
Figure 2: Format of reverse delegation record
図2：逆引きレコードのフォーマット
P: Specifies a precedence for this record. This is similar to MX record preferences. Lower numbers have stronger preference.
P：このレコードの優先順位を指定します。これは、MXレコードの設定に似ています。下の数字は強い好みを持っています。
A.B.C.D: Specifies the IP address of the Security Gateway for this client machine.
A.B.C.D：このクライアントマシンのセキュリティゲートウェイのIPアドレスを指定します。
public-key: Is the encoded RSA Public key of the Security Gateway. The public-key is provided here to avoid a second DNS lookup. If this field is absent, then a KEY resource record should be looked up in the reverse-map of A.B.C.D. The key is transmitted in base64 format.
公開鍵は：セキュリティゲートウェイのエンコードされたRSA公開鍵です。公開鍵は、第二DNSルックアップを避けるために、ここで提供されます。このフィールドが存在しない場合は、KEYリソースレコードは、A.B.C.Dの逆マップで検索しなければなりませんキーはbase64形式で送信されます。
The fields of the record MUST be separated by whitespace. This MAY be: space, tab, newline, or carriage return. A space is preferred.
レコードのフィールドは空白で区切らなければなりません。これは次のようになります。スペース、タブ、改行、またはキャリッジリターン。スペースが好ましいです。
In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse-map), then Alice may delegate to a public key by domain name.
アリスは、決まったアドレス（またはその逆マップ上制御なし）を有していない、セキュリティゲートウェイの背後のパブリックアドレスに配置されている場合に、アリスは、ドメイン名で公開鍵に委任することができます。
X-IPsec-Server(P)=@FQDN public-key
X-のIPsec-サーバー（P）= FQDN公開鍵@
Figure 3: Format of reverse delegation record (FQDN version)
図3：逆引きレコードのフォーマット（FQDN版）
P: Is as above. FQDN: Specifies the FQDN that the Security Gateway will identify itself with. public-key: Is the encoded RSA Public key of the Security Gateway.
P：上記のようです。 FQDNは：セキュリティゲートウェイはで自身を特定するFQDNを指定します。公開鍵は：セキュリティゲートウェイのエンコードされたRSA公開鍵です。
If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records.
最強（最も小さい番号）の優先順位を持つ複数のそのようTXTレコードがある場合は、1セキュリティゲートウェイは、最強の嗜好レコードに指定されたものの中から任意に選択されます。
When packed into wire-format, TXT records that are longer than 255 characters are divided into smaller <character-strings>. (See [RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored.
ワイヤー形式にパックすると、255文字より長いですTXTレコードが小さい、<文字列>に分かれています。 （[RFC1035]セクション3.3および3.3.14を参照）。これらは、処理のために単一の文字列に再構築されなければなりません。 base64エンコードでの空白文字は無視されることになります。
It has been suggested to use the KEY, OPT, CERT, or KX records instead of a TXT record. None is satisfactory.
代わりにTXTレコードのKEY、OPT、CERT、またはKXレコードを使用することが提案されています。どれも満足のいくものではありません。
The KEY RR has a protocol field that could be used to indicate a new protocol, and an algorithm field that could be used to indicate different contents in the key data. However, the KEY record is clearly not intended for storing what are really authorizations, it is just for identities. Other uses have been discouraged.
KEY RRは、新しいプロトコルを示すために使用され得るプロトコルフィールド、および鍵データの異なるコンテンツを示すために使用され得るアルゴリズムのフィールドを有しています。しかし、KEYレコードは明確に本当に権限が何であるか格納するためのものではありません、それだけでアイデンティティのためです。他の用途には落胆されています。
OPT resource records, as defined in [RFC2671], are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are, therefore, inappropriate for use here.
OPTリソースレコードは、[RFC2671]で定義されるように、情報の記憶のために使用されることを意図するものではありません。彼らは、ロードされたキャッシュまたは転送することはありません。彼らは、それゆえ、ここでの使用には不適切です。
CERT records [RFC2538] can encode almost any set of information. A custom type code could be used permitting any suitable encoding to be stored, not just X.509. According to the RFC, the certificate RRs are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers.
CERTレコード[RFC2538]は情報のほとんどすべてのセットをコードすることができます。カスタム・タイプ・コードが格納される任意の適切な符号化だけでなく、X.509を可能に使用することができます。 RFCによれば、証明書のRRは、望ましくない、不必要なバルクを追加することができる、内部で署名されます。大きなDNSレコードは、TCPではなくUDP転送を必要とするかもしれません。
At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be investigated, and may be proposed in a future revision of this document.
プロトコルの設計時には、CERT RRは広く展開されていなかったとすると、カウントすることができませんでした。 CERTレコードの使用が調査されており、この文書の将来の改正に提案することができます。
KX records are ideally suited for use instead of TXT records, but had not been deployed at the time of implementation.
KXレコードは、理想的には代わりにTXTレコードの使用に適しているが、実装時には配備されていませんでした。
Unfortunately, not every administrator has control over the contents of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the authorization record present in the reverse-map of Alice may refer to a FQDN instead of an IP address.
残念ながら、ないすべての管理者は、逆マップの内容を制御しています。開始剤（SG-A）がNOの適切な逆マップを有していない場合、アリスの逆マップで許可レコードの存在は、FQDNの代わりにIPアドレスを参照することができます。
In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A forward lookup for a KEY record on the FQDN must yield the initiator's public key.
この場合、クライアントのTXTレコードは、そのセキュリティゲートウェイのIPアドレスの代わりに、完全修飾ドメイン名（FQDN）を与えます。イニシエータは、イニシエータの公開鍵を生成しなければなりませんFQDNのKEYレコードのフェーズ1正引きでID_FQDNのIDペイロードを使用する必要があります。
This method can also be used when the external address of SG-A is dynamic.
SG-Aの外部アドレスが動的である場合、この方法を使用することもできます。
If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse-map. When Alice and SG-A are one and the same (i.e., Alice is acting as an end-node) then there is no need for this when initiating only.
SG-Aがアリスの代わりに動作されている場合、アリスはまだ彼女の逆マップでそうするSG-Aの権限を委任する必要があります。アリスとSG-Aが同一である場合（すなわち、アリスは、エンドノードとして動作している）のみを開始この必要はありません。
However, Alice must still delegate to herself if she wishes others to initiate OE to her. See Figure 3.
彼女は彼女にOEを開始するために他人を希望する場合は、アリスはまだ自分自身に委任する必要があります。図3を参照してください。
Good cryptographic hygiene says that one should replace public/private key pairs periodically. Some administrators may wish to do this as often as daily. Typical DNS propagation delays are determined by the SOA Resource Record MINIMUM parameter, which controls how long DNS replies may be cached. For reasonable operation of DNS servers, administrators usually want this value to be at least several hours, sometimes as a long as a day. This presents a problem: a new key MUST not be used prior to its propagation through DNS.
グッド暗号衛生は1つが定期的に公開鍵/秘密鍵のペアを交換する必要があることを述べています。一部の管理者は、毎日のように、頻繁にこれを実行することもできます。典型的なDNSの伝播遅延は、長いDNS応答がキャッシュされる方法を制御SOAリソースレコードの最小パラメータによって決定されます。 DNSサーバの合理的な動作のために、管理者は通常、この値は、時には一日限り、少なくとも数時間、なりたいです。これは、問題を提示：新しいキーがDNSを通じて前にその伝播に使用することはできません。
This problem is dealt with by having the Security Gateway generate a new public/private key pair, at least MINIMUM seconds in advance of using it. It then adds this key to the DNS (both as a second KEY record and in additional TXT delegation records) at key generation time. Note: only one key is allowed in each TXT record.
この問題は、最小秒、少なくとも、それを使用する前に、セキュリティゲートウェイは、新しい公開鍵/秘密鍵のペアを生成することによって取り扱われます。その後、（第2 KEYレコードとして、追加のTXTの委任レコードの両方で）鍵生成時にDNSにこのキーを追加します。注意：1つのキーだけでは、各TXTレコードで許可されています。
When authenticating, all gateways MUST have available all public keys that are found in DNS for this entity. This permits the authenticating end to check both the key for "today" and the key for "tomorrow". Note that it is the end which is creating the signature (possesses the private key) that determines which key is to be used.
認証する場合は、すべてのゲートウェイは、このエンティティのためにDNSで発見された利用可能なすべての公開鍵を持っていなければなりません。これは、「今日」や「明日」のためのキーのキーの両方をチェックするために認証終了を許可します。それが使用されるキーを判定する署名（秘密鍵を所有する）を作成している端部であることに留意されたいです。
There are no fundamentally new issues for implementing opportunistic encryption in the presence of network address translation. Rather, there are only the regular IPsec issues with NAT traversal.
ネットワークアドレス変換の存在下での日和見暗号化を実装するための新たな課題には基本的にありません。むしろ、NATトラバーサルを持つ唯一の正規のIPsec問題があります。
There are several situations to consider for NAT.
NATのために考慮すべきいくつかの状況があります。
If a security gateway is also performing network address translation on behalf of an end-system, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typically configured tunnels, which often exist to bridge islands of private network address space. The security gateway will use the translated source address for phase 2, and so the responding security gateway will look up that address to confirm SG-A's authorization.
セキュリティゲートウェイは、エンド・システムに代わってネットワークアドレス変換を実行している場合、パケットは前日和見暗号化が施されたに変換する必要があります。これは、多くの場合、プライベートネットワークアドレス空間の島々を埋めるために存在し、通常設定されたトンネルとは対照的です。セキュリティゲートウェイは、フェーズ2の変換された送信元アドレスを使用し、その応答セキュリティゲートウェイは、SG-Aの認可を確認するために、そのアドレスを検索します。
In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and control over the reverse-map is assumed. Placing of TXT records is possible.
NATの場合には（1：1）、変換が行われているにアドレス空間は、グローバルに一意でなければなりません、そして逆マップの制御を想定しています。 TXTレコードの配置が可能です。
In the case of NAPT (m:1), the address will be the security gateway itself. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse-map. This is identical to situations involving a single host acting on behalf of itself. For initiators (but not responders), an FQDN-style ID can be used to get around a lack of a reverse-map.
NAPTの場合（M：1）、アドレスはセキュリティゲートウェイ自体であろう。場所にKEYとTXTレコードを取得する機能は、再び逆マップに対する管理制御があるかどうかに依存します。これは、自分自身のために行動する単一のホストを伴う状況と同じです。イニシエータ（ただし、応答）のために、FQDN形式のIDは、逆マップの不足を回避するために使用することができます。
If there is a NAT or NAPT between the security gateways, then normal IPsec NAT traversal problems occur. In addition to the transport problem, which may be solved by other mechanisms, there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for the security gateway, there is no appropriate ID for phase 2. Due to the NAT, the end systems live in different IP address spaces.
セキュリティゲートウェイ間のNATまたはNAPTがある場合、通常のIPsec NATトラバーサルの問題が発生します。他のメカニズムによって解決することができる輸送の問題に加えて、1とフェーズ2のIDを使用するどのような位相の問題があります。 FQDNは、セキュリティゲートウェイのためのフェーズ1の間に使用することができますが、原因NATへのフェーズ2のための適切なIDが存在しない、エンド・システムは、異なるIPアドレス空間に住んでいます。
If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for another end system to address a packet to this end system. Not only is opportunistic encryption impossible, but it is also impossible for any communication to be initiated to the end system. It may be possible for this end system to initiate such communication. This creates an asymmetry, but this is common for NAPT.
エンドシステムがNAT（おそらくSG-B）の背後にある場合、このエンドシステムにパケットに対処する別のエンド・システムのための方法は、実際には存在しません。だけでなく、日和見暗号化は不可能であるが、任意の通信はエンドシステムに開始することも不可能です。このエンドシステムは、通信を開始することが可能であってもよいです。これは、非対称性を作成しますが、これはNAPTのために一般的です。
When Alice and SG-A are components of the same system, they are considered to be a host implementation. The packet sequence scenario remains unchanged.
アリスとSG-Aは、同じシステムの構成要素である場合、それらはホストの実装であると考えられます。パケットシーケンスのシナリオは変更されません。
Components marked Alice are the upper layers (TCP, UDP, the application), and SG-A is the IP layer.
コンポーネントは、アリスが上位層（TCP、UDP、アプリケーション）であり、SG-Aは、IP層であるマーク。
Note that tunnel mode is still required.
トンネルモードがまだ必要であることに注意してください。
As Alice and SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice to initiate. She can rely on FQDN in a forward map. This is particularly attractive to mobile nodes such as notebook computers at conferences. To respond, Alice/SG-A will still need an entry in Alice's reverse-map.
アリスとSG-Aは、自身の代わりに動作しているようアリスが開始するために、何のTXTベースの委任レコードは必要ありません。彼女は前方マップ内のFQDNに依存することができます。これは、このような会議でノート型パソコンなどのモバイルノードに特に魅力的です。対応するために、アリス/ SG-Aはまだアリスの逆マップ内のエントリが必要になります。
If there are multiple paths between Alice and Bob (as illustrated in the diagram with SG-D), then additional DNS records are required to establish authorization.
アリスとボブ（SG-Dと図に示すように）との間に複数のパスが存在する場合、追加のDNSレコードは認可を確立するために必要とされます。
In Figure 1, Alice has two ways to exit her network: SG-A and SG-D. Previously, SG-D has been ignored. Postulate that there are routers between Alice and her set of security gateways (denoted by the + signs and the marking of an autonomous system number for Alice's network). Datagrams may, therefore, travel to either SG-A or SG-D en route to Bob.
SG-AおよびSG-D：図1では、アリスは彼女のネットワークを終了するための2つの方法を持っています。以前は、SG-Dは無視されてきました。アリスとセキュリティゲートウェイの彼女のセット（+記号で示され、アリスのネットワークのための自律システム番号のマーキング）との間にルータがあると仮定しています。データグラムは、従って、ボブへの途中SG-A又はSG-Dのいずれかに移動することができます。
As long as all network connections are in good order, it does not matter how datagrams exit Alice's network. When they reach either security gateway, the security gateway will find the TXT delegation record in Bob's reverse-map, and establish an SA with SG-B.
限り、すべてのネットワーク接続が良い順になっているように、終了アリスのネットワークをデータグラムかは問題ではありません。彼らはどちらかのセキュリティゲートウェイに到達すると、セキュリティゲートウェイは、ボブの逆マップでTXT委譲レコードを検索し、SG-BとSAを確立します。
SG-B has no problem establishing that either of SG-A or SG-D may speak for Alice, because Alice has published two equally weighted TXT delegation records:
SG-Bは、アリスが2つの等しく加重TXTの委任レコードを公開していますので、SG-AまたはSG-Dのいずれかが、アリスのために話すことを確立する問題がありません。
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
X-のIPsec-サーバー（10）= 192.1.1.5 AQMM ... 3s1Q == X-のIPsec-サーバー（10）= 192.1.1.6 AAJN ... j8r9 ==
Figure 4: Multiple gateway delegation example for Alice
図4：アリスのための複数のゲートウェイ委任例
Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through their tunnel to SG-B.
アリスのルータは今、必要な負荷分散のいずれかの種類を行うことができます。 SG-AおよびSG-Dの両方は、データグラムを送信SG-Bへのトンネルを介してボブ宛。
Alice's use of non-equal weight delegation records to show preference of one gateway over another, has relevance only when SG-B is initiating to Alice.
別の上の1つのゲートウェイの優先性を示すために、非同重量の委任レコードのアリスの使用は、SG-Bは、アリスに開始しているだけ関連性を持っています。
If the precedences are the same, then SG-B has a more difficult time. It must decide which of the two tunnels to use. SG-B has no information about which link is less loaded, nor which security gateway has more cryptographic resources available. SG-B, in fact, has no knowledge of whether both gateways are even reachable.
優先順位が同じである場合には、SG-Bは、より多くの困難な時期を持っています。これは、2つのトンネルのどちらを使用することを決定する必要があります。 SG-Bは、リンクが少ないロードされ、また複数の暗号リソースが利用可能持つセキュリティゲートウェイかについての情報がありません。 SG-Bは、実際には、両方のゲートウェイがあっても到達可能であるかどうかの知識を持ちません。
The Public Internet's default-free zone may well know a good route to Alice, but the datagrams that SG-B creates must be addressed to either SG-A or SG-D; they can not be addressed to Alice directly.
公衆インターネットのデフォルトフリーゾーンはよくアリスに良いルートを知っているかもしれませんが、SG-Bが作成したデータグラムは、SG-AまたはSG-Dのいずれかに対処する必要があります。彼らは直接アリス宛することはできません。
SG-B may make a number of choices:
SG-Bは、選択肢の数をすることがあります。
1. It can ignore the problem and round robin among the tunnels. This causes losses during times when one or the other security gateway is unreachable. If this worries Alice, she can change the weights in her TXT delegation records. 2. It can send to the gateway from which it most recently received datagrams. This assumes that routing and reachability are symmetrical. 3. It can listen to BGP information from the Internet to decide which system is currently up. This is clearly much more complicated, but if SG-B is already participating in the BGP peering system to announce Bob, the results data may already be available to it. 4. It can refuse to negotiate the second tunnel. (It is unclear whether or not this is even an option.) 5. It can silently replace the outgoing portion of the first tunnel with the second one while still retaining the incoming portions of both. Thus, SG-B can accept datagrams from either SG-A or SG-D, but send only to the gateway that most recently re-keyed with it.
1.これは、トンネルの中で問題とラウンドロビンを無視することができます。これは、1つまたは他のセキュリティゲートウェイが到達不能である時間の間に損失が発生します。これはアリスが心配ならば、彼女は彼女のTXT委譲記録の重みを変更することができます。 2.それは、最近のデータグラムを受け、そこからゲートウェイに送信することができます。これは、ルーティングと到達可能性が対称であることを前提としています。 3.それはアップし、現在あるシステムを決定するために、インターネットからBGP情報を聞くことができます。これは明らかにはるかに複雑ですが、SG-Bが既にボブを発表するBGPピアリングシステムに参加している場合、結果のデータは、すでにそれに利用できます。 4.これは、第2のトンネルを交渉することを拒否することができます。 （もオプションであるか否かは不明である。）5.まだ両方の着信部分を保持しながら、静かに第1と第一トンネルの出射部を置き換えることができます。したがって、SG-Bは、SG-A又はSG-Dのいずれかからデータグラムを受け入れることができるが、最も最近に再キーイングゲートウェイにのみ送ります。
Local policy determines which choice SG-B makes. Note that even if SG-B has perfect knowledge about the reachability of SG-A and SG-D, Alice may not be reachable from either of these security gateways because of internal reachability issues.
ローカルポリシーは、選択SG-Bが行うかを決定します。 SG-Bは、SG-AおよびSG-Dの到達可能性に関する完全な知識を持っている場合でも、アリスが原因で内部到達可能性の問題のこれらのセキュリティゲートウェイのいずれかから到達可能ではないかもしれないことに注意してください。
FreeS/WAN implements option 5. Implementing a different option is being considered. The multi-homing aspects of OE are not well developed and may be the subject of a future document.
FreeS / WANオプション5.検討されている別のオプションを実装を実装しています。 OEのマルチホーミング側面は十分に開発されておらず、将来の文書の主題とすることができます。
If a DNS server fails to respond, local policy decides whether or not to permit communication in the clear as embodied in the connection classes in Section 3.2. It is easy to mount a denial of service attack on the DNS server responsible for a particular network's reverse-map. Such an attack may cause all communication with that network to go in the clear if the policy is permissive, or fail completely if the policy is paranoid. Please note that this is an active attack.
DNSサーバーが応答しない場合は、ローカルポリシーは、3.2節での接続クラスで具体化として、平文で通信を許可するか否かを決定します。特定のネットワークの逆マップを担当するDNSサーバー上のサービス拒否攻撃をマウントすることは容易です。このような攻撃は、そのネットワークとのすべての通信は、ポリシーが許容するならば明らかで行く、またはポリシーが偏執的であれば完全に失敗する可能性があります。これはアクティブな攻撃であることに注意してください。
There are still many networks that do not have properly configured reverse-maps. Further, if the policy is not to communicate, the above denial of service attack isolates the target network. Therefore, the decision of whether or not to permit communication in the clear MUST be a matter of local policy.
適切に構成された逆のマップを持っていない多くのネットワークがまだあります。ポリシーが通信するためにされていない場合はさらに、サービス攻撃の上の拒否は、ターゲットネットワークを分離します。そのため、平文で通信を許可するか否かの決定は、ローカルポリシーの問題でなければなりません。
DNS records claim that opportunistic encryption should occur, but the target gateway either does not respond on port 500, or refuses the proposal. This may be because of a crash or reboot, a faulty configuration, or a firewall filtering port 500.
DNSレコードは日和見暗号化を行うべきと主張するが、ターゲットゲートウェイは、いずれかのポート500で応答し、または提案を拒否していません。これは、クラッシュやリブート、誤った設定、またはファイアウォールのフィルタリングポート500であってもよいです。
The receipt of ICMP port, host or network unreachable messages indicates a potential problem, but MUST NOT cause communication to fail immediately. ICMP messages are easily forged by attackers. If such a forgery caused immediate failure, then an active attacker could easily prevent any encryption from ever occurring, possibly preventing all communication.
ICMPポート、ホストまたはネットワーク到達不能メッセージの受信は、潜在的な問題があることを示しますが、通信がすぐに失敗することがあってはなりません。 ICMPメッセージは簡単に攻撃者によって偽造されています。こうした偽造が即時失敗の原因となった場合は、アクティブな攻撃者は簡単に、おそらくすべての通信を防止すること、これまでの発生から任意の暗号化を防ぐことができます。
In these situations a log should be produced and local policy should dictate if communication is then permitted in the clear.
このような状況では、ログが生成されなければならないとの通信は、クリアで許可されている場合は、ローカルポリシーが指示する必要があります。
Tunnels sometimes go down because the remote end crashes, disconnects, or has a network link break. In general there is no notification of this. Even in the event of a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has specific reason to talk to them immediately. Over-quick response to temporary network outages is undesirable. Note that a tunnel can be torn down and then re-established without any effect visible to the user except a pause in traffic. On the other hand, if one end reboots, the other end can't get datagrams to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms.
トンネルは時々あるため、リモートエンドのクラッシュ、切断、または持っているネットワークリンクブレークダウンして行きます。一般に、この通知されません。再起動SGはすぐに彼らに話をする特別な理由がない限りでもクラッシュと再起動を成功した場合に、他のSGはそれについて聞いていません。一時的なネットワーク停止に過迅速な対応は望ましくありません。トンネルが解体した後、トラフィックの一時停止を除くユーザに見える任意の効果なしに再確立することができることに留意されたいです。状況が認められるまで一方、一端が再起動した場合、もう一方の端は（IKE経由を除く）すべてでそれにデータグラムを取得することはできません。だから、迅速な対応に向けたバイアスが時折誤警報のコストで、適切です。
A mechanism for recovery after reboot is a topic of current research and is not specified in this document.
再起動後に回復するためのメカニズムは、現在の研究のテーマであり、この文書で指定されていません。
A deliberate shutdown should include an attempt, using delete messages, to notify all other SGs currently connected by phase 1 SAs that communication is about to fail. Again, a remote SG will assume this is a teardown. Attempts by the remote SGs to negotiate new tunnels as replacements should be ignored. When possible, SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previously established connections.
意図的なシャットダウンは、現在の通信が失敗しようとしていることにより、位相1つのSAを接続しているすべての他のSGを通知するために、メッセージを削除使用して、試みを含める必要があります。ここでも、リモートSGはこれがティアダウンであると仮定します。代替品として新しいトンネルを交渉するために、リモートのSGによって試みは無視されるべきです。可能な場合は、SGSがクラッシュした後、初期 - 連絡先は、すべての以前に確立された接続の損失を示すために、以前のパートナーに送信することができるように、不揮発性ストレージに現在接続のSGについての情報を保存しようとしなければなりません。
The method of obtaining information by reverse DNS lookup causes problems for people who cannot control their reverse DNS bindings. This is an unresolved problem in this version, and is out of scope.
DNSの逆引きによって情報を得る方法は、その逆DNSバインディングを制御できない人のための問題を引き起こします。これは、このバージョンで未解決の問題であり、範囲外です。
Two example scenarios follow. In the first example, GW-A (Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE policy. The clear-text policy serves as a reference for what occurs in TCP/IP in the absence of Opportunistic Encryption.
二つのシナリオの例を以下に示します。最初の例では、GW-A（ゲートウェイA）とGW-B（ゲートウェイB）は常にクリアテキストポリシーを有し、そして第二の例では、それらはOEポリシーを持っています。クリアテキストのポリシーは、日和見暗号化が存在しない場合にTCP / IPで何が起こるかの基準となります。
Alice wants to communicate with Bob. Perhaps she wants to retrieve a web page from Bob's web server. In the absence of opportunistic encryptors, the following events occur:
アリスはボブと通信したいです。おそらく、彼女はボブのWebサーバからWebページを取得したいと考えています。日和見暗号が存在しない場合には、次のイベントが発生します。
Alice SG-A DNS SG-B Bob Human or application 'clicks' with a name. (1)
アリスSG-DNS SG-Bボブヒトまたはアプリケーションが名前で「クリック」。 （1）
------(2)-------------->
Application looks up
name in DNS to get
IP address.
<-----(3)---------------
Resolver returns "A" RR
to application with IP
address.
(4) Application starts a TCP session or UDP session and OS sends first datagram
（4）アプリケーションはTCPセッションやUDPセッションを開始し、OSは最初のデータグラムを送信します
Alice SG-A DNS SG-B Bob
----(5)----->
Datagram is seen at first gateway
from Alice (SG-A).
----------(6)------>
Datagram traverses
network.
------(7)----->
Datagram arrives
at Bob, is provided
to TCP.
<------(8)------
A reply is sent.
<----------(9)------
Datagram traverses
network.
<----(10)-----
Alice receives
answer.
Alice SG-A DNS SG-B Bob
(11)----------->
A second exchange
occurs.
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
Figure 5: Timing of regular transaction
図5：普通取引のタイミング
In the presence of properly configured opportunistic encryptors, the event list is extended. Only changes are annotated.
適切に構成さ日和見暗号の存在下で、イベントのリストが拡張されます。変更のみが注釈を付けています。
The following symbols are used in the time-sequence diagram:
以下の記号は、時系列図で使用されています。
- A single dash represents clear-text datagrams. = An equals sign represents phase 2 (IPsec) cipher-text datagrams. ~ A single tilde represents clear-text phase 1 datagrams. # A hash sign represents phase 1 (IKE) cipher-text datagrams.
- 単一のダッシュはクリアテキストデータグラムを表します。 = Anが符号がフェーズ2（IPsec）の暗号文データグラムを表しているに等しいです。 〜シングルチルダはクリアテキストのフェーズ1つのデータグラムを表します。 ＃ハッシュ記号は、フェーズ1（IKE）暗号文データグラムを表します。
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E)~~~~
~~~~~~~~~~~~~(5F)~~~>
<~~~~~~~~~~~~(5G)~~~~
#############(5H)###>
<----(5I)---
-----(5J)-->
<############(5K)####
#############(5L)###>
<----(5M)---
-----(5N)-->
<############(5O)####
#############(5P)###>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
Figure 6: Timing of opportunistic encryption transaction
図6：日和見暗号化取引のタイミング
For the purposes of this section, we will describe only the changes that occur between Figure 5 and Figure 6. This corresponds to time points 5, 6, 7, 9, and 10 on the list above.
このセクションの目的のために、我々は、これは、上記のリスト上の時間点5、6、7、9、および10に対応する図5と図6との間に起こる変化だけを説明します。
At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy (the nonexistent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon.
このソース/宛先ペアがポリシー（存在しないポリシー状態）を欠いているので、ポイント（5）で、SG-Aは、データグラムを傍受します。 SG-Aは保留ポリシーを作成し、データグラムをバッファリング。 SG-Aは合わせるデーモンからキーを要求します。
(5B) DNS query for TXT record. (5C) DNS response for TXT record. (5D) Initial IKE message to responder. (5E) Message 2 of phase 1 exchange. SG-B receives the message. A new connection instance is created in the unauthenticated OE peer state. (5F) Message 3 of phase 1 exchange. SG-A sends a Diffie-Hellman exponent. This is an internal state of the keying daemon. (5G) Message 4 of phase 1 exchange. SG-B responds with a Diffie-Hellman exponent. This is an internal state of the keying protocol. (5H) Message 5 of phase 1 exchange. SG-A uses the phase 1 SA to send its identity under encryption. The choice of identity is discussed in Section 4.6.1. This is an internal state of the keying protocol. (5I) Responder lookup of initiator key. SG-B asks DNS for the public key of the initiator. DNS looks for a KEY record by IP address in the reverse-map. That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa (recall that SG-A's external address is 192.1.1.4). SG-B uses the resulting public key to authenticate the initiator. See Section 5.1 for further details. (5J) DNS replies with public key of initiator. Upon successfully authenticating the peer, the connection instance makes a transition to authenticated OE peer on SG-B. The format of the TXT record returned is described in Section 5.2. Responder replies with ID and authentication. SG-B sends its ID along with authentication material, completing the phase 1 negotiation. (5L) IKE phase 2 negotiation. Having established mutually agreeable authentications (via KEY) and authorizations (via TXT), SG-A proposes to create an IPsec tunnel for datagrams transiting from Alice to Bob. This tunnel is established only for the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B.
（5B）TXTレコードのDNSクエリ。 （5C）TXTレコードのDNS応答。 （5D）レスポンダに初期IKEメッセージ。 （5E）フェーズ1交換のメッセージ2。 SG-Bは、メッセージを受信します。新しい接続インスタンスは、認証されていないOEピア状態で作成されます。 （5F）フェーズ1交換のメッセージ3。 SG-AのDiffie-Hellman指数を送信します。これは合わせるデーモンの内部状態です。フェーズ1交換（5G）メッセージ4。 SG-Bは、のDiffie-Hellman指数で応答します。これは、キーイングプロトコルの内部状態です。フェーズ1交換（5H）メッセージ5。 SG-Aは、暗号化の下でそのIDを送信するためにフェーズ1 SAを使用しています。アイデンティティの選択は、セクション4.6.1で説明されています。これは、キーイングプロトコルの内部状態です。イニシエータキーの（5I）レスポンダ検索。 SG-Bは、イニシエータの公開鍵のためのDNSを要求します。 DNSは逆マップ内のIPアドレスでKEYレコードを探します。これは、KEYリソースレコードは（つまりSG-Aの外部アドレスを思い出すである192.1.1.4）4.1.1.192.in-addr.arpaのために照会されます。 SG-Bは、イニシエータを認証するために、結果の公開鍵を使用しています。詳細については、セクション5.1を参照してください。 （5J）DNSは、イニシエータの公開鍵で応答します。正常ピアを認証する際に、接続インスタンスは、SG-B上のOEピアを認証するために遷移します。 TXTレコードの形式は、5.2節で説明されて返されます。レスポンダは、IDと認証で応答します。 SG-Bフェーズ1ネゴシエーションを完了し、認証材料と一緒にそのIDを送信します。 （5L）IKEフェーズ2ネゴシエーション。 （TXTを介して）確立された相互に快い（KEYを介して）認証および権限を有する、SG-Aは、アリスからボブへの遷移データグラムのためのIPsecトンネルを作成することを提案します。このトンネルはないSG-AおよびSG-Bの背後にあってもよい任意のサブネットのために、唯一のアリス/ボブの組み合わせのために確立されています。
(5M) Authorization for SG-A to speak for Alice. While the identity of SG-A has been established, its authority to speak for Alice has not yet been confirmed. SG-B does a reverse lookup on Alice's address for a TXT record. (5N) Responder determines initiator's authority. A TXT record is returned. It confirms that SG-A is authorized to speak for Alice. Upon receiving this specific proposal, SG-B's connection instance makes a transition into the potential OE connection state. SG-B may already have an instance, and the check is made as described above. (5O) Responder agrees to proposal. SG-B, satisfied that SG-A is authorized, proceeds with the phase 2 exchange. The responder MUST setup the inbound IPsec SAs before sending its reply. (5P) Final acknowledgement from initiator. The initiator agrees with the responder's choice of proposal and sets up the tunnel. The initiator sets up the inbound and outbound IPsec SAs. Upon receipt of this message, the responder may now setup the outbound IPsec SAs. (6) IPsec succeeds and sets up a tunnel for communication between Alice and Bob.
アリスのために発言するSG-A用（5M）の認可。 SG-Aのアイデンティティが確立されてきたが、アリスを代弁する権限は、まだ確認されていません。 SG-Bは、TXTレコードのアリスのアドレスの逆引き参照を行います。 （5N）レスポンダは、イニシエータの権限を決定します。 TXTレコードが返されます。これは、SG-Aがアリスを代弁する権限があることを確認します。この特定の提案を受信すると、SG-Bの接続インスタンスは、潜在的OE接続状態に遷移します。 SG-Bは既にインスタンスを有していてもよく、上記のようにチェックが行われます。 （50）Responderは提案に同意します。 SG-Aが許可されていることに満足SG-Bは、フェーズ2交換で進行します。レスポンダーMUSTセットアップその応答を送信する前に、インバウンドのIPsec SAを。 （5P）イニシエータから最終確認応答。イニシエータは、提案の応答者の好みと一致し、トンネルを設定します。イニシエータは、インバウンドとアウトバウンドのIPsec SAを設定します。このメッセージを受信すると、レスポンダー今セットアップアウトバウンドのIPsec SAのかもしれません。 （6）IPsecは成功し、アリスとボブの間の通信のためのトンネルを設定します。
SG-A sends the datagram saved at step (5) through the newly created tunnel to SG-B, where it gets decrypted and forwarded. Bob receives it at (7) and replies at (8). SG-B already has a tunnel up with G1 and uses it. At (9), SG-B has already established an SPD entry mapping Bob->Alice via a tunnel, so this tunnel is simply applied. The datagram is encrypted to SG-A, decrypted by SG-A, and passed to Alice at (10).
SG-Aが解読され、転送されますSG-Bに新しく作成されたトンネルを介してステップ（5）に保存されたデータグラムを送信します。ボブは、（7）でそれを受信し、（8）で応答します。 SG-Bは既にG1とトンネルアップを持っており、それを使用します。 （9）では、SG-Bは既にトンネルを介してSPDエントリマッピングBob->アリスを確立しているので、このトンネルは単に適用されます。データグラムは、SG-Aに暗号化されたSG-Aで復号、及び（10）でアリスに渡されます。
Configured tunnels are setup using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that are in known places (distinguished name from LDAP, DNS). These keys are then used to configure a specific tunnel.
（DNS、LDAPから識別名）の公開鍵（生のRSA、DSA、PKIX）、事前共有秘密を交換、または既知の場所にあるキーを参照することにより：設定されたトンネルは、二国間メカニズムを使用して設定されています。これらのキーは、特定のトンネルを設定するために使用されます。
A pre-configured tunnel may be on all the time, or may be keyed only when needed. The endpoints of the tunnel are not necessarily static; many mobile applications (road warrior) are considered to be configured tunnels.
予め設定されたトンネルは、すべての時間であってもよいし、必要な場合にのみキー入力してもよいです。トンネルのエンドポイントは、必ずしも静的ではありません。多くのモバイルアプリケーション（道路戦士）が構成されたトンネルであると考えられています。
The primary characteristic is that configured tunnels are assigned specific security properties. They may be trusted in different ways relating to exceptions to firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions.
主要特性は、設定されたトンネルは、特定のセキュリティプロパティを割り当てられていることです。彼らは、ファイアウォールルールの例外に関連するさまざまな方法、NAT処理の例外で信頼できる、および帯域幅やサービスの制限の他の品質のために。
Opportunistic tunnels are not inherently trusted in any strong way. They are created without prior arrangement. As the two parties are strangers, there MUST be no confusion of datagrams that arrive from opportunistic peers and those that arrive from configured tunnels. A security gateway MUST take care that an opportunistic peer cannot impersonate a configured peer.
日和見トンネルは、本質的に任意の強力な方法で信頼されていません。これらは、事前の手配なしで作成されます。 2つの当事者は見知らぬ人であるため、日和見ピアと設定されたトンネルから到着するものから到着データグラムの混乱があってはなりません。セキュリティゲートウェイは、日和見ピアが設定されたピアになりすますことができないことを注意しなければなりません。
Ingress filtering MUST be used to make sure that only datagrams authorized by negotiation (and the concomitant authentication and authorization) are accepted from a tunnel. This is to prevent one peer from impersonating another.
イングレスフィルタリングは、ネゴシエーション（および付随する認証および承認）によって認可のみデータグラムがトンネルから受け入れていることを確認するために使用しなければなりません。これは、別の偽装から1つのピアを防ぐためです。
An implementation suggestion is to treat opportunistic tunnel datagrams as if they arrive on a logical interface distinct from other configured tunnels. As the number of opportunistic tunnels that may be created automatically on a system is potentially very high, careful attention to scaling should be taken into account.
実装の提案は、他の構成トンネルは異なる論理インターフェイスに到達しているかのよう日和見トンネルデータグラムを処理することです。システム上で自動的に作成することができる日和見トンネルの数は、潜在的に非常に高いため、スケーリングに細心の注意を考慮すべきです。
As with any IKE negotiation, opportunistic encryption cannot be secure without authentication. Opportunistic encryption relies on DNS for its authentication information and, therefore, cannot be fully secure without a secure DNS. Without secure DNS, opportunistic encryption can protect against passive eavesdropping but not against active man-in-the-middle attacks.
すべてのIKEネゴシエーションと同じように、日和見暗号化は認証なしで、セキュアにすることはできません。日和見暗号化はそのため、セキュアなDNSせずに、完全に安全ではないことができ、その認証情報をDNSに依存していると。セキュアなDNSがなければ、日和見暗号化は、受動的な盗聴に対してではなく、アクティブman-in-the-middle攻撃から保護することができます。
Typical usage of per datagram access control lists is to implement various kinds of security gateways. These are typically called "firewalls".
データグラムあたりのアクセス制御リストの一般的な使用方法は、セキュリティゲートウェイの様々な種類を実装することです。これらは、典型的には、「ファイアウォール」と呼ばれています。
Typical usage of a virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to datagrams that arrive in the VPN.
ファイアウォール内の仮想プライベートネットワーク（VPN）の一般的な使用は、2つのネットワーク間のアクセス制御の全部または一部をバイパスすることです。付加的な信頼は（前のセクションで概説したように）VPNに到着するデータグラムに与えられます。
Datagrams that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a datagram arriving in the clear SHOULD also be applied to datagrams arriving opportunistically.
日和見構成されたトンネルを経由して到着したデータグラムは信頼されてはいけません。明確に到着したデータグラムに適用される任意のセキュリティポリシーは、また日和見到着したデータグラムに適用されるべきです。
There are several different forms of denial of service that an implementor should be concerned with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors).
実装者が関係する必要があるサービス拒否のいくつかの異なる形式があります。これらの問題のほとんどは、モバイル・ピア（外回り）の数が多いセキュリティゲートウェイで共有されています。
The design of ISAKMP/IKE, and its use of cookies, defend against many kinds of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is possible to form phase 1 SAs with any machine on the Internet.
ISAKMP / IKEの設計、およびクッキーの使用は、サービス拒否の多くの種類を防御します。日和見主義のフェーズ1（ISAKMP）SAが認証された場合、それは価値が作成していたことがあるという仮定を変更します。ゲートウェイは任意のマシンと通信するため、インターネット上の任意のマシンとのフェーズ1つのSAを形成することが可能です。
Substantive portions of this document are based upon previous work by Henry Spencer. [OEspec]
この文書の実質的な部分はヘンリー・スペンサーによって前の仕事に基づいています。 [OEspec]
Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore, and John Denker for their comments and constructive criticism.
彼らのコメントや建設的な批判のためのTERO Kivinen、サンディ・ハリス、ウェスHardarker、ロバート・モスコウィッツ、ヤコブSchlyter、ビルゾンマーフェルト、ジョン・ギルモア、ジョンDenkerに感謝します。
Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
サンドラ・ホフマンとビル・ディッキーは、詳細な校正と編集を行いました。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]モーガン、D.、シュナイダー、M.、およびM. Schertler、 "インターネットセキュリティ協会とキー管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]イーストレーク、D.、 "ドメインネームシステムにおけるRSA / SHA-1のSIGとRSA鍵（DNS）"、RFC 3110、2001年5月。
[IPSECKEY] Richardson, M., "A Method for Storing IPsec keying Material in DNS", RFC 4025, March 2005.
[IPSECKEY]リチャードソン、M.、 "DNSでのIPsec鍵素材を格納する方法"、RFC 4025、2005年3月。
[OEspec] H. Spencer and Redelmeier, D., "Opportunistic Encryption", paper, http://www.freeswan.org/ oeid/opportunism-spec.txt, May 2001.
[OEspec] H.スペンサーとRedelmeier、D.、 "日和見暗号化"、紙、http://www.freeswan.org/ oeid /日和見主義-spec.txt、2001年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1464]ローゼンバウム、R.、「任意の文字列は、属性を格納するためにドメインネームシステムを使用する」、RFC 1464、1993年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.
[RFC1984] IAB、IESG、大工、B.、および、RFC 1984 F.ベイカー、 "暗号技術とインターネット上のIABとIESG声明"、1996年8月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367]マクドナルド、D.、メッツ、C.およびB. Phanさん、 "PF_KEY鍵管理API、バージョン2"、RFC 2367、1998年7月。
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538]、RFC 2538イーストレイク、D.およびO.グドムンソン、 "ドメインネームシステム（DNS）での保管証明書"、1999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]マッセイ、D.とS.ローズ、RFC 3445 "KEYリソースレコード（RR）の範囲を制限"、2002年12月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
Authors' Addresses
著者のアドレス
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
K1Z 5V7 CA ONマイケル・C.・リチャードソンSandelmanソフトウェア作品470ドーソンアベニューオタワ、
EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/
電子メール：mcr@sandelman.ottawa.on.ca URI：http://www.sandelman.ottawa.on.ca/
D. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Avenue Toronto, ON M4N 2W6 CA
D.ヒューRedelmeierミモザシステムズ社M4N 2W6 CA ON 29 Doninoアベニュートロント、
EMail: hugh@mimosa.com
メールアドレス：hugh@mimosa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びwww.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。