[要約] RFC 4322は、IKEを使用した機会主義的暗号化についての要約です。その目的は、インターネット上でのセキュアな通信を実現するために、暗号化の機会を最大化することです。
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)
インターネットキーエクスチェンジ（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).
Copyright（c）The Internet Society（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スタックでこの機能を有効にします。これが完了すると、そのような2つのノードは安全に通信できます。
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]では、RFC 3445に準拠するバリエーションについて説明します。プロジェクト情報については、http：//www.freeswan.orgを参照してください。
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つをインストールすると、ファックスを受け取ることができる人が増えたために増加することの価値が増加しました。日和見的な暗号化がインストールされると、ネットワーク管理者によるさらなる構成なしで、日和見暗号化を使用して他のボックスを自動的に認識します。したがって、日和見的な暗号化ソフトウェアがより多くのボックスにインストールされると、ツールが増加するにつれてその価値が増加します。
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つのカテゴリに分割します。トラフィックは、最長のプレフィックスマッチを使用して宛先アドレスによって分類されます。したがって、各カテゴリは、ネットワークプレフィックスのセットによって列挙されます。カテゴリは相互に排他的です。特定のプレフィックスは、1つのカテゴリでのみ発生する必要があります。
* 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.
このドキュメントでは、インターネットの新しいデフォルトとして提案されている3番目のカテゴリ：日和見トンネルについて説明します。
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.
日和見的な暗号化は、本質的に見知らぬ人であるノード間にトンネルを作成します。これは、以前の二国間配置なしで行われます。したがって、誰が話しているのかをどのように知っているかという難しい質問があります。
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.
考えられる答えの1つは、有用な認証を行うことができないため、試すべきではないということです。この操作モードは、「匿名暗号化」と呼ばれます。中間の積極的な攻撃を使用して、このタイプのコミュニケーションのプライバシーを阻止できます。ピア認証がなければ、この種の攻撃を防ぐ方法はありません。
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.
有用なモードですが、匿名の暗号化はこのプロジェクトの目標ではありません。匿名の暗号化のみを達成できるよりシンプルな方法が利用可能ですが、ピアの認証は望ましい目標です。ピアの認証は、DNSの主要な分布を通じて達成され、DNSSECの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]
キーワードは、このドキュメントに表示される場合、[RFC2119]に記載されているように解釈される場合、必要であり、要求されてはならない、必要ではなく、推奨されない、そうでなければ、推奨することは、推奨されてはならない、そうでなければ、推奨することはできません。
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の4つのエンドノードがあります。SG-A、SG-B、SG-Dの3つのセキュリティゲートウェイがあります。A、D、SG-A、およびSG-Dは、同じ管理当局AS1の一部です。SG-AとSG-Dは、組織1から2つの異なる出口パスにあります。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.
Dave：図のノード[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.0.1で、外部的には192.1.1.4です。
SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
SG-B：ボブのセキュリティゲートウェイ。内部的には192.2.0.1で、外部的には192.1.1.5です。
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：デイブのセキュリティゲートウェイ。また、アリスのバックアップセキュリティゲートウェイ。内部的には192.3.0.1で、外部的には192.1.1.6です。
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.
Road Warriorトンネル：固定IPアドレスを持つ1つのノードと、可変IPアドレスを持つ1つのノードを接続する構成されたトンネル。固定ノードはロードウォリアーの現在のアドレスを知ることができないため、可変ノードでロードウォリアー（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.
Lifetime：セキュリティアソシエーションが必要となる前に、セキュリティ協会が生き続ける秒（バイトまたはデータグラム）の期間。
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ゲートウェイ）は、[RFC0791]セクション2.4および[RFC1812]で説明されているように、通常のゲートウェイノードであり、追加の機能はここおよび[RFC2401]で説明されています。ここで説明するアルゴリズムは、各データグラムについて、データグラムを暗号化およびトンネルするかどうかを決定する方法を提供します。決定する必要がある2つの重要なことは、暗号化とトンネルのかどうか、もしそうなら、使用する必要があるトンネルエンドポイントの宛先アドレスまたは名前です。
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ゲートウェイは承認リソースレコードのDNSのルックアップを実行します（セクション5.2を参照）。レコードは、IPアドレスを使用して配置され、In-Addr.Arpa（IPv4）またはIP6.ARPA（IPv6）マップで検索を実行します。承認記録が見つかった場合、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ゲートウェイは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]を参照）。セクション3.2.4.1は、DNSSECの署名が関連するレコードに利用できない場合、トンネルエンドポイントのオプションの制限を文書化します。
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]などの制御チャネルは、2つの平面を接続します。
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.
OEゲートウェイは、[RFC2401]で指定されたセキュリティポリシーデータベース（SPD）のスーパーセットであるオブジェクトのコレクションを維持します。ソースアドレスと宛先アドレスの組み合わせごとに、SPDオブジェクトは次の5つの状態のいずれかに存在します。各データグラムを転送する前に、Responderはソースアドレスと宛先アドレスを使用して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秒あたり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.
ゲートウェイは、通常の転送テーブルを使用してデータグラムを転送します。ゲートウェイは、キーイングデーモンからのコマンドによってのみこの状態に入り、この状態に入ると、「最初」と「最後の」データグラムも転送します。
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」と呼びます。接続オブジェクトには、クラスとインスタンスの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 SAS）とデータチャネル（フェーズ2 SAS）の2つのサブタイプが2つあります。各データチャネルオブジェクトには、Datagram Stateマシンが維持する対応する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-Permissive」、「OE-Paranoid」として知られる接続クラスがなければなりません。後者の2つの接続クラスは、日和見暗号化が試行される宛先プレフィックスのセットを定義します。管理者は、多くの追加の場所でポリシーオプションを設定する場合があります。実装により、これらのポリシーをさらに絞り込むための追加の接続クラスが作成される場合があります。
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-Permissive」接続のみを必要とする場合があり、独自の（単一の）IPアドレスをこのポリシーのソースアドレスとしてリストし、ワイルドカードアドレスは宛先IPv4アドレスとして0.0.0.0/0をリストします。つまり、最も単純なポリシーは、すべての目的地で日和見的な暗号化を試すことです。
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-Paranoid」）の使用の区別は、州の移行の違いで明らかになります。
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-Permissiveは、たとえ不安定な方法であっても、ネットワークを機能させることを許可します。
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-Paranoid」）がドロップポリシーをインストールします。OE-Paranoidは、適切なセキュリティが利用可能な場合にのみ、トラフィックが流れることができます。
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.
キーイングマシンの状態遷移のこの説明では、キーイングシステムに関連する状態は、キーイングシステム（[RFC2407]、[RFC2408]、および[RFC2409]がISAKMP/IKEの[RFC2409]、および[RFC2409]、および[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-Paranoid接続が失敗したときにこの状態に移行します。遷移中、イニシエーターは、適切なフローのために転送面に拒否ポリシーオブジェクトを作成します。
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つの方法があります。
1. DNS lookup finds a TXT delegation resource record.
1. DNS Lookupは、TXT委任リソースレコードを見つけます。
2. DNS lookup does not find a TXT delegation resource record.
2. DNSルックアップでは、TXT委任リソースレコードは見つかりません。
3. DNS lookup times out.
3. DNSルックアップタイムズ。
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接続状態に移行します。DNSの外観が成功する条件は次のとおりです。
1. DNS finds an appropriate resource record.
1. DNSは適切なリソースレコードを見つけます。
2. It is properly formatted according to Section 5.2.
2. セクション5.2に従って適切にフォーマットされています。
3. If DNSSEC is enabled, then the signature has been vouched for.
3. DNSSECが有効になっている場合、署名は保証されています。
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 Lookupがリソースレコードを見つけられない場合、またはDNSがタイムタイムになった場合、イニシエーターは受信機がOEが能力を持っていないと見なします。これがOE-Paranoidインスタンスである場合、潜在的な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.
潜在的なOE接続は、イニシエーターがDNSルックアップから必要なすべての情報が存在すると判断したときにこの状態に移行します。この状態に入ると、イニシエーターは、提供されたゲートウェイへのキーイングを開始しようとします。
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.
3つの障害は重大な問題を引き起こしました。キーイングによる障害は明らかに唯一の障害ではありません。
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 SAS（トンネル）のセットは成功と見なされます。
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-pessimistic接続の場合、イニシエーターは、低寿命で再び拒否接続に移行します。両方の場合の寿命は、リモートゲートウェイが再起動の過程にあるか、それ以外の場合は一時的に利用できない可能性があるため、低く抑えられます。
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分です。多くのシステムは、その時間でも再起動できます。ただし、ほとんどのユーザーがOEを使用して接続できないと聞くのを待つには5分が長すぎます。実装はこれを調整可能なパラメーターにする必要があります。
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.
2番目の障害は、フェーズ1 SAが作成された後に発生しますが、フェーズ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.)
3番目の障害は、リモートゲートウェイを認証しながら署名障害がある場合に発生します。これは、キーロールオーバーがあったときに発生する可能性がありますが、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.
保留中のOE接続は、セッションキーイング素材（フェーズ2 SAS）が導出されると、この状態に移行します。イニシエーターは、このフローの転送面に暗号化ポリシーを作成します。
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つの方法があります。1つ目は、ピアから認証された削除メッセージ（キーイングチャネル経由）を受信することです。これは通常の断骨で、有効期限が切れた接続状態に移行します。
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.
2番目の出口は、転送面のキーイング材料の有効期限です。これにより、保留中の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.
3番目の出口は、リモートゲートウェイからのネゴシエーションに対応しています。転送面がリモートゲートウェイから未知のSPIを受け取ったことを制御プレーンに通知する場合、または不明なSPIを示すリモートゲートウェイからICMPが受信された場合、イニシエーターはリモートゲートウェイが再起動または再起動されたことを考慮する必要があります。これらの適応症は簡単に偽造されるため、実装はケアを行使する必要があります。イニシエーターは、接続を再キーするために慎重な（レート制限された）試みを行う必要があります。
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 DELETEを送信してフェーズ2 SASをクリーンアップします。
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 SASを削除するかどうかは、ローカル実装の問題として残されています。フェーズ1 SASを削除する実装は、認証された削除メッセージを送信して、そうしていることを示す必要があります。フェーズ1 SASが期限切れになるまで維持することには利点があります。近い将来に再び有用であることが証明される可能性があります。
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.)
この状態に入ると、レスポンダーはイニシエーターの重要なレコードのDNS検索を開始します。Responderは、イニシエーターがID_IPv4_Addrを提供した場合、イニシエーターのキーレコードのリバースマップで、およびイニシエーターがID_FQDNタイプを提供している場合はフォワードマップに表示されます。（[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.
Responderは、DNSからキーを受け取ったこととキーの使用を成功させると、この状態を終了し、イニシエーターの署名を検証します。
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.
ピアは最終的に1つ以上のフェーズ2 SASを提案します。Responderは、提案のソースと宛先アドレスを使用して、接続クラステーブルを使用して接続状態のインスタンス化を完了します。レスポンダーは、この時点で同一の接続オブジェクトを検索する必要があります。
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レコードが要求されます。これは、フェーズ1のアイデンティティがフェーズ2に代わって暗号化する許可を確認するために使用されます。
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-Paranoidモードであり、レスポンダーが常にクリアテキストまたは拒否されている場合、ポリシーに応じて通信が不可能であることに注意してください。実装は、「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.
セキュリティゲートウェイとクライアントホストが同じであり、スタックの衝突やワイヤの実装ではない場合、トンネルの断層決定は、ローカル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.
トンネルのアウトバウンドSAS（またはそれらの一部のサブセット）の削除を受信すると、インバウンドのサブセットを取り壊し、リモートエンドに削除を通知します。ローカルシステムが存在しなくなったトンネルの削除を受信した場合、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.)
削除が受信した削除への応答としてではなく、ローカルで開始されたら、トンネルのインバウンドSASの（すべて）の削除を送信します。ローカルシステムがアウトバウンドSASの応答削除を受信しない場合は、元の削除を再配置してみてください。10秒間隔で3回の試行が合理的なレベルの努力のようです。3回の試行後に反対側の反応が失敗すると、さらなるコミュニケーションの可能性がありそうにないことが示されています。発信SASを削除します。（リモートシステムは、もはや存在していない、または電源を入れていないモバイルノードである場合があります。）
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.
再キーリングした後、トランスミッションはすぐに新しい発信SAS（ISAKMPまたはIPSEC）の使用に切り替える必要があります。また、古い残りの発信SASをすぐにクリアする必要があります（発信SASの削除を送信する必要があります）。これにより、クラッターが軽減され、診断を行うオペレーターの混乱が最小限に抑えられます。
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 SASをネゴシエートする準備をする必要があります。これには、Cookie状態を維持するために大量のリソースが必要になる場合があります。また、Nonce、Cookieなどの大量のエントロピーが必要です。
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のアドレスが構成によって提供されます。さらに、GatewayへのSPDエントリのマッピングは、通常1：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検索を行い、返信を待つ必要性は、通常、新しい状態と新しいイベントソース（DNS応答）をIKEに導入します。同期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レコードを制御できない場合がある多くの状況があります。一般的な状況には、ダイヤルアップ接続とほとんどの住宅型ブロードバンドインターネットアクセス（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の場合、FQDN IDの場合のフォワードDNSから逆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.
説明（Frees/WAN 1.98）は、DNSSECを直接使用してゾーン情報の信頼性を明示的に検証することも、NSECレコードを使用してTXTまたはキーレコードがないことの認証を提供することもありません。むしろ、この実装は、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])
イニシエーターは、3DE、HMAC-MD5またはHMAC-SHA1、DHグループ2または5の何らかの組み合わせを使用して、少なくとも1つの提案を提供する必要があります。グループ5を最初に提案する必要があります。（[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.
イニシエーターは追加の提案を提供する場合がありますが、暗号は3DEよりも弱くなければなりません。イニシエーターは、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).
イニシエーターは、フェーズ1のイニシエーターの外部インターフェイスのID_IPV4_ADDR（IPv6のID_IPV6_ADDR）を使用する必要があります（例外があります。セクション5.3を参照してください。）認証方法はRSA公開署名でなければなりません。イニシエーターのRSAキーは、イニシエーターの逆スペース（つまり、in-addr.arpaまたはip6.arpaを使用）のDNSキーレコードに配置する必要があります。
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.
アイデンティティはID_IPV4_ADDR_SUBNETである必要があります。マスクは /32です。
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].
独自のアイデンティティを確立するために、Security Gatewaysは、DNSSECのキーレコードを介して逆DNSにパブリックキーを公開する必要があります。RFC 2535 [RFC2535]のセクション3を参照してください。
For example:
例えば：
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
キー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.
いくつかのキーレコードを使用すると、キーロールオーバーが可能になります。IKEフェーズ1のSIGペイロードは、キーRRによって与えられた公開キーが検証する場合、受け入れる必要があります。
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.
たとえば、Machine AliceがSG-Aに彼女に代わって行動することを望んでいる場合、彼女はTXTレコードを公開し、SG-Aがアリスに代わって行動する許可を提供します。これは、ボブと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-SERVER（P）= A.B.C.D Public-Key
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.
Public-Key：セキュリティゲートウェイのエンコードされたRSA公開キーです。ここでは、2回目のDNSルックアップを避けるために公開キーが提供されています。このフィールドがない場合、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.
レコードのフィールドは、Whitespaceで分離する必要があります。これは、スペース、タブ、新しいライン、またはキャリッジリターンです。スペースが望ましい。
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
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を指定します。Public-Key：セキュリティゲートウェイのエンコードされた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つのセキュリティゲートウェイが、最も強力なプレーファレンスレコードで指定されたものからarbitrarily意的に選択されます。
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エンコーディングのWhitespace文字は無視されます。
It has been suggested to use the KEY, OPT, CERT, or KX records instead of a TXT record. None is satisfactory.
TXTレコードの代わりに、キー、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.
キーRRには、新しいプロトコルを示すために使用できるプロトコルフィールドと、キーデータの異なる内容を示すために使用できるアルゴリズムフィールドがあります。ただし、キーレコードは明らかに、実際に認可されたものを保存するためのものではなく、アイデンティティのためだけです。他の用途は落胆しています。
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.
[RFC2671]で定義されているOPTリソースレコードは、情報の保存に使用することを意図していません。それらは、装填されたり、キャッシュされたり、転送されたりする必要はありません。したがって、これらはここで使用するのに不適切です。
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によると、証明書RRSは内部的に署名され、望ましくない不必要なバルクを追加する可能性があります。DNSレコードを大きくすると、UDP転送の代わりにTCPが必要になる場合があります。
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）には適切なリバースマップがない場合、Aliceのリバースマップに表示される承認レコードは、IPアドレスの代わりにFQDNを指す場合があります。
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）を提供します。イニシエーターは、フェーズ1でID_FQDN ID-Payloadを使用する必要があります。FQDNのキーレコードの前方検索では、イニシエーターの公開キーを生成する必要があります。
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.
優れた暗号化衛生は、定期的にパブリック/秘密鍵のペアを置き換えるべきだと言います。一部の管理者は、毎日同じ頻度でこれを行うことをお勧めします。典型的なDNS伝播遅延は、SOAリソースレコードの最小パラメーターによって決定されます。これは、DNS応答がキャッシュされる可能性がある期間を制御します。DNSサーバーの妥当な操作のために、管理者は通常、この値を少なくとも数時間、時には1日ほど長くすることを望んでいます。これには問題があります。新しいキーを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番目のキーレコードとして、および追加のTXT委任記録の両方）にこのキーを追加します。注：各TXTレコードで許可されているキーは1つだけです。
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）の場合、アドレスはセキュリティゲートウェイ自体になります。キーと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で使用できますが、フェーズ2に適切なIDはありません。NATのため、ENDシステムは異なる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.
Aliceと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に頼ることができます。これは、会議でのノートブックコンピューターなどのモバイルノードにとって特に魅力的です。応答するには、Alice/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.
図1には、アリスにはネットワークを終了する2つの方法があります：SG-AとSG-D。以前は、SG-Dは無視されていました。アリスと彼女のセキュリティゲートウェイのセットの間にルーターがあることを仮定します（アリスのネットワークの自律システム番号の標識とマーキングで示されています）。したがって、データグラムは、BOBへの途中で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は、SG-AまたはSG-Dのいずれかがアリスについて話す可能性があることを確立するのに問題はありません。
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(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.
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. 問題を無視し、トンネルの間でロビンを丸くすることができます。これにより、いずれかのセキュリティゲートウェイが到達できない場合に損失が発生します。これがアリスを心配している場合、彼女は彼女のTXT代表団の記録の重みを変更することができます。2.最近データグラムを受け取ったゲートウェイに送信できます。これは、ルーティングと到達可能性が対称であることを前提としています。3.インターネットからBGP情報を聞いて、現在どのシステムがアップしているかを決定できます。これは明らかにはるかに複雑ですが、SG-BがBOBを発表するためにBGPピアリングシステムにすでに参加している場合、結果データはすでに利用可能である可能性があります。4. 2番目のトンネルの交渉を拒否できます。（これがオプションでさえあるかどうかは不明です。）5。最初のトンネルの発信部分を静かに2番目のトンネルに置き換えることができ、両方の入っている部分を保持しています。したがって、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.
意図的なシャットダウンには、削除メッセージを使用して、現在接続されている他のすべてのSGSに通信が故障していることを通知する試みを含める必要があります。繰り返しになりますが、リモートSGはこれが分解であると仮定します。リモートSGが交換を無視するために新しいトンネルを交渉しようとする試みは無視する必要があります。可能であれば、SGSは、不揮発性ストレージで現在接続されているSGSに関する情報を保存しようとする必要があります。これにより、クラッシュ後、以前のパートナーに初期接触を送信して、以前に確立されたすべての接続の損失を示すことができます。
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.
2つの例のシナリオが続きます。最初の例では、GW-A（ゲートウェイA）とGW-B（ゲートウェイB）には常にクリアテキストポリシーがあり、2番目の例では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:
アリスはボブとコミュニケーションを取りたいと思っています。おそらく、彼女はBobのWebサーバーからWebページを取得したいのでしょう。日和見的な暗殺者がいない場合、次のイベントが発生します。
Alice SG-A DNS SG-B Bob Human or application 'clicks' with a name. (1)
Alice SG-A DNS SG-B BOB HumanまたはApplication 'Clicks' with name。（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.
- 単一のダッシュは、クリアテキストデータグラムを表します。=等しい符号は、フェーズ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の間に発生する変更のみを説明します。これは、上記のリストの時点5、6、7、9、および10に対応します。
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）Responderへの初期IKEメッセージ。（5e）フェーズ1交換のメッセージ2。SG-Bはメッセージを受け取ります。新しい接続インスタンスは、認められていないOEピアステートに作成されます。（5F）フェーズ1交換のメッセージ3。SG-AはDiffie-Hellman Exponentを送信します。これはキーイングデーモンの内部状態です。（5G）フェーズ1交換のメッセージ4。SG-Bは、Diffie-Hellman Exponentで応答します。これは、キーイングプロトコルの内部状態です。（5H）フェーズ1交換のメッセージ5。SG-Aは、フェーズ1 SAを使用して、暗号化の下でアイデンティティを送信します。アイデンティティの選択については、セクション4.6.1で説明します。これは、キーイングプロトコルの内部状態です。（5i）イニシエーターキーのレスポンダー検索。SG-Bは、イニシエーターの公開鍵をDNSに尋ねます。DNSは、リバースマップでIPアドレスによるキーレコードを探します。つまり、4.1.1.1.192.in-addr.arpa（SG-Aの外部アドレスが192.1.1.4であることを思い出してください）の場合、重要なリソースレコードが照会されます。SG-Bは、結果の公開キーを使用して、イニシエーターを認証します。詳細については、セクション5.1を参照してください。（5J）DNSは、イニシエーターの公開鍵で応答します。ピアを正常に認証すると、接続インスタンスはSG-Bで認証されたOEピアに移行します。返されたTXTレコードの形式については、セクション5.2で説明しています。レスポンダーはIDと認証で返信します。SG-Bは、認証資料とともにIDを送信し、フェーズ1交渉を完了します。（5L）IKEフェーズ2交渉。SG-Aは、相互に快適な認証（キー経由）と承認（TXT経由）を確立したため、アリスからボブに通うデータグラムの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.
（5M）SG-Aがアリスの代表者を告げる許可。SG-Aのアイデンティティが確立されていますが、アリスのために話す権限はまだ確認されていません。SG-Bは、TXTレコードのアリスのアドレスを逆検索します。（5N）レスポンダーがイニシエーターの権限を決定します。TXTレコードが返されます。SG-Aがアリスの話をすることを許可されていることを確認しています。この特定の提案を受け取ると、SG-Bの接続インスタンスは、潜在的なOE接続状態に移行します。SG-Bには既にインスタンスがある場合があり、チェックは上記のように作成されています。（5o）レスポンダーは提案に同意します。SG-Bは、SG-Aが承認されていることに満足しており、フェーズ2の交換を進めています。応答者は、返信を送信する前に、インバウンドIPSEC SASをセットアップする必要があります。（5P）イニシエーターからの最終的な承認。イニシエーターは、レスポンダーの提案の選択に同意し、トンネルを設定します。イニシエーターは、インバウンドおよびアウトバウンドIPSEC SASを設定します。このメッセージを受け取ると、レスポンダーはアウトバウンドIPSEC SASをセットアップできるようになりました。（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に保存されたデータグラムをSG-Bに送信します。ボブは（7）でそれを受け取り、（8）で返信します。SG-BにはすでにG1を使用してトンネルがあり、使用しています。（9）で、SG-Bはすでにトンネルを介してBob-> AliceをマッピングするSPDエントリを確立しているため、このトンネルは単純に適用されます。データグラムは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.
構成されたトンネルは、パブリックキー（生RSA、DSA、PKIX）の交換、事前に共有された秘密、または既知の場所（LDAP、DNSの区別名）のキーを参照することにより、両側メカニズムを使用してセットアップされます。これらのキーは、特定のトンネルを構成するために使用されます。
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.
事前に構成されたトンネルは常にある場合があります。または、必要な場合にのみ鍵をかけている場合があります。トンネルのエンドポイントは必ずしも静的ではありません。多くのモバイルアプリケーション（Road Warrior）は、構成されたトンネルと見なされています。
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.
イングレスフィルタリングを使用して、交渉（および付随する認証と承認）によって承認されたデータグラムのみがトンネルから受け入れられることを確認する必要があります。これは、あるピアが別のピアになりすましないようにするためです。
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がなければ、日和見的な暗号化は、受動的な盗聴から保護することができますが、中間の攻撃攻撃に対してではありません。
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の設計とCookieの使用は、多くの種類のサービス拒否に対して防御します。日和見主義は、フェーズ1（ISAKMP）SAが認証されている場合、それが作成される価値があるという仮定を変えます。ゲートウェイは任意のマシンと通信するため、インターネット上の任意のマシンとフェーズ1 SASを形成することができます。
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、Sandy Harris、Wes Hardarker、Robert Moskowitz、Jakob Schlyter、Bill Sommerfeld、John Gilmore、およびJohn 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、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] Maughan、D.、Schneider、M。、およびM. Schertler、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、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] EastLake、D。、「ドメイン名システム（DNS）のRSA/SHA-1 SIGSおよびRSAキー」、RFC 3110、2001年5月。
[IPSECKEY] Richardson, M., "A Method for Storing IPsec keying Material in DNS", RFC 4025, March 2005.
[Ipseckey] Richardson、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. Spencer and Redelmeier、D。、「日和見的な暗号化」、紙、http：//www.freeswan.org/ oeid/日和見spec.txt、2001年5月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Rosenbaum、R。、「ドメイン名システムを使用して任意の文字列属性を保存する」、RFC 1464、1993年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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。、およびF.ベイカー、「暗号化技術とインターネットに関するIABおよびIESGステートメント」、RFC 1984、1996年8月。
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998.
[RFC2367] McDonald、D.、Metz、C。およびB. Phan、「PF_KEY Key Management 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] Eastlake、D。およびO. Gudmundsson、「ドメイン名システム（DNS）に証明書の保存」、RFC 2538、1999年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「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] Massey、D。およびS. Rose、「主要なリソースレコード（RR）の範囲の制限」、RFC 3445、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. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
Authors' Addresses
著者のアドレス
Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA
マイケル・C・リチャードソン・サンデルマン・ソフトウェアは470ドーソン・アベニュー・オタワ、k1z5v7ca
EMail: 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. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Avenue Toronto、M4N 2W6 CA
EMail: hugh@mimosa.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。