[要約] RFC 5660は、IPsecチャネルの接続を確立するための手法である「Connection Latching」について説明しています。このRFCの目的は、IPsecチャネルの接続を効率的かつ信頼性の高い方法で確立することです。
Network Working Group N. Williams
Request for Comments: 5660 Sun
Category: Standards Track October 2009
IPsec Channels: Connection Latching
IPSECチャネル：接続ラッチ
Abstract
概要
This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
このドキュメントは、抽象的に、アプリケーションとインターフェイスプロトコルをIPSECとインターフェースし、「接続」（パケットフロー）をラッチングすることにより「チャネル」を作成する方法を指定し、接続の寿命のために特定のIPSECセキュリティアソシエーション（SA）パラメーターに合わせます。接続ラッチはIPSECの上に階層化されており、基礎となるIPSECアーキテクチャを変更しません。
Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.
接続ラッチは、IPSECの再構成の結果として、または弱いピアアイデンティティをピアアドレスの関連付けに使用した結果として、意図しないピアに誤ってライブパケットフローを暴露することからアプリケーションを保護するために使用できます。ピアIDとピアアドレスの弱い関連性は、より良いセキュリティ（BTNS）よりも優れたコアにあります。したがって、接続ラッチは、BTNS IPSECノードに大幅な保護を追加することができます。
Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels.
最後に、IPSECチャネルの可用性により、IPSECチャネルへのチャネルバインディングを使用することが可能になります。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Connection Latching .............................................4
2.1. Latching of Quality-of-Protection Parameters ...............8
2.2. Connection Latch State Machine .............................9
2.3. Normative Model: ULP Interfaces to the Key Manager ........12
2.3.1. Race Conditions and Corner Cases ...................17
2.3.2. Example ............................................18
2.4. Informative Model: Local Packet Tagging ...................19
2.5. Non-Native Mode IPsec .....................................21
2.6. Implementation Note Regarding Peer IDs ....................22
3. Optional Features ..............................................22
3.1. Optional Protection .......................................22
4. Simultaneous Latch Establishment ...............................23
5. Connection Latching to IPsec for Various ULPs ..................23
5.1. Connection Latching to IPsec for TCP ......................24
5.2. Connection Latching to IPsec for UDP with
Simulated Connections .....................................24
5.3. Connection Latching to IPsec for UDP with
Datagram-Tagging APIs .....................................25
5.4. Connection Latching to IPsec for SCTP .....................25
5.5. Handling of BROKEN State for TCP and SCTP .................26
6. Security Considerations ........................................27
6.1. Impact on IPsec ...........................................27
6.2. Impact on IPsec of Optional Features ......................28
6.3. Security Considerations for Applications ..................28
6.4. Channel Binding and IPsec APIs ............................29
6.5. Denial-of-Service Attacks .................................29
7. Acknowledgements ...............................................30
8. References .....................................................30
8.1. Normative References ......................................30
8.2. Informative References ....................................30
IPsec protects packets with little or no regard for stateful packet flows associated with upper-layer protocols (ULPs). This exposes applications that rely on IPsec for session protection to risks associated with changing IPsec configurations, configurations that allow multiple peers access to the same addresses, and/or weak association of peer IDs and their addresses. The latter can occur as a result of "wildcard" matching in the IPsec Peer Authorization Database (PAD), particularly when Better Than Nothing Security (BTNS) [RFC5387] is used.
IPSECは、上層層プロトコル（ULPS）に関連するステートフルパケットフローをほとんどまたはまったく考慮してパケットを保護します。これにより、IPSECの保護のためにIPSECに依存しているアプリケーションは、IPSEC構成の変更、同じアドレスへの複数のピアアクセスを可能にする構成、および/またはピアIDとそのアドレスの弱い関連付けに関連するリスクに公開します。後者は、IPSEC PEER Authorizationデータベース（PAD）で「ワイルドカード」マッチングの結果として発生する可能性があります。
Applications that wish to use IPsec may have to ensure that local policy on the various end-points is configured appropriately [RFC5406] [USING-IPSEC]. There are no standard Application Programming Interfaces (APIs) to do this (though there are non-standard APIs, such as [IP_SEC_OPT.man]) -- a major consequence of which, for example, is that applications must still use hostnames (and, e.g., the Domain Name System [RFC1034]) and IP addresses in existing APIs and must depend on an IPsec configuration that they may not be able to verify. In addition to specifying aspects of required Security Policy Database (SPD) configuration, application specifications must also address PAD/SPD configuration to strongly bind individual addresses to individual IPsec identities and credentials (certificates, public keys, etc.).
IPSECを使用したいアプリケーションは、さまざまなエンドポイントに関するローカルポリシーが適切に構成されていることを確認する必要がある場合があります[RFC5406] [IPSECを使用]。これを行うための標準アプリケーションプログラミングインターフェイス（API）はありません（[IP_SEC_OPT.MAN]など、非標準のAPIがありますが） - たとえば、アプリケーションがホスト名を使用する必要があることです（およびアプリケーションはまだ使用する必要があります。、例えば、ドメイン名システム[RFC1034]）および既存のAPIのIPアドレスは、確認できないIPSEC構成に依存する必要があります。必要なセキュリティポリシーデータベース（SPD）構成の側面を指定することに加えて、アプリケーション仕様はPAD/SPD構成をアドレス指定して、個々のIPSEC IDと資格情報（証明書、パブリックキーなど）に強くバインドする必要があります。
IPsec is, then, quite cumbersome for use by applications. To address this, we need APIs to IPsec. Not merely APIs for configuring IPsec, but also APIs that are similar to the existing IP APIs (e.g., "BSD Sockets"), so that typical applications making use of UDP [RFC0768], TCP [RFC0793], and Stream Control Transmission Protocol (SCTP) [RFC4960] can make use of IPsec with minimal changes.
Ipsecは、アプリケーションで使用するために非常に面倒です。これに対処するには、IPSECにAPIが必要です。IPSECを構成するためのAPIだけでなく、既存のIP API（例：「BSDソケット」）に類似したAPIであるため、UDP [RFC0768]、TCP [RFC0793]、およびストリーム制御伝送プロトコルを使用する典型的なアプリケーションがSCTP）[RFC4960]は、最小限の変更でIPSECを使用できます。
This document describes the foundation for IPsec APIs that UDP and TCP applications can use: a way to bind the traffic flows for, e.g., TCP connections to security properties desired by the application. We call these "connection latches" (and, in some contexts, "IPsec channels"). The methods outlined below achieve this by interfacing ULPs and applications to IPsec.
このドキュメントでは、UDPおよびTCPアプリケーションが使用できるIPSEC APIの基礎について説明します。たとえば、アプリケーションが望むセキュリティプロパティへのTCP接続のトラフィックフローを結合する方法。これらを「接続ラッチ」と呼びます（そして、一部のコンテキストでは、「IPSECチャネル」）。以下に概説する方法は、ULPとIPSECへのアプリケーションをインターフェースすることにより、これを達成します。
If widely adopted, connection latching could make application use of IPsec much simpler, at least for certain classes of applications.
広く採用されている場合、接続ラッチは、少なくとも特定のクラスのアプリケーションで、IPSECのアプリケーションをより簡単に使用できます。
Connection latching, as specified herein, is primarily about watching updates to the SPD and Security Association Database (SAD) to detect changes that are adverse to an application's requirements for any given packet flow, and to react accordingly (such as by synchronously alerting the ULP and application before packets can be sent or received under the new policy). Under no circumstance are IPsec policy databases to be modified by connection latching in any way that can persist beyond the lifetime of the related packet flows, nor reboots. Under no circumstance is the PAD to be modified at all by connection latching. If all optional features of connection latching are excluded, then connection latching can be implemented as a monitor of SPD and SAD changes that intrudes in their workings no more than is needed to provide synchronous alerts to ULPs and applications.
本明細書で指定されているように、接続ラッチは主にSPDおよびセキュリティ協会データベース（SAD）の更新を監視して、特定のパケットフローのアプリケーションの要件に不利な変更を検出し、それに応じて（ULPを同期的に警告するなど）パケットの前のアプリケーションは、新しいポリシーの下で送信または受信できます）。いかなる状況でも、関連するパケットフローの寿命を超えて持続することも再起動したり、再起動したりすることができる、接続ラッチによって変更されるIPSECポリシーデータベースは変更されます。いかなる状況でも、接続ラッチによってまったく変更されるパッドはありません。接続ラッチのすべてのオプション機能が除外されている場合、接続ラッチは、ULPSおよびアプリケーションに同期アラートを提供するために必要なこと以上に、作業に侵入するSPDおよびSAD変更のモニターとして実装できます。
We assume the reader is familiar with the IPsec architecture [RFC4301] and Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306].
読者は、IPSECアーキテクチャ[RFC4301]およびインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）[RFC4306]に精通していると仮定します。
Note: the terms "connection latch" and "IPsec channel" are used interchangeably below. The latter term relates to "channel binding" [RFC5056]. Connection latching is suitable for use in channel binding applications, or will be, at any rate, when the channel bindings for IPsec channels are defined (the specification of IPsec channel bindings is out of scope for this document).
注：「接続ラッチ」と「IPSECチャネル」という用語は、以下で同じ意味で使用されます。後者の用語は、「チャネル結合」[RFC5056]に関連しています。接続ラッチングは、チャネル結合アプリケーションでの使用に適しています。または、いずれにせよ、IPSECチャネルのチャネルバインディングが定義されている場合（IPSECチャネルバインディングの仕様はこのドキュメントの範囲外です）。
Note: where this document mentions IPsec peer "ID" it refers to the Internet Key Exchange (IKE) peer ID (e.g., the ID derived from a peer's cert, as well as the cert), not the peer's IP address.
注：このドキュメントがIPSec Peer "ID"を指定している場合、ピアのIPアドレスではなく、インターネットキーエクスチェンジ（IKE）ピアID（たとえば、ピアの証明書や証明書から派生したID）を指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Abstract function names are all capitalized and denoted by a pair of parentheses. In their descriptions, the arguments appear within the parentheses, with optional arguments surrounded by square brackets. Return values, if any, are indicated by following the function argument list with "->" and a description of the return value. For example, "FOO(3-tuple, [message])" would be a function named "FOO" with two arguments, one of them optional, and returning nothing, whereas "FOOBAR(handle) -> state" would be a function with a single, required argument that returns a value. The values' types are described in the surrounding text.
抽象関数名はすべて大文字になり、括弧で囲まれています。その説明では、括弧内に引数が表示され、四角い括弧に囲まれたオプションの引数があります。return値は、「 - >」とreturn値の説明を含む関数引数リストに従うことによって示されます。たとえば、「foo（3 -tuple、[message]）」は2つの引数を持つ「foo」という名前の関数であり、そのうちの1つはオプションで、何も返しませんが、「foobar（handle） - > state」は関数です値を返す単一の必要な引数で。値のタイプは、周囲のテキストで説明されています。
An "IPsec channel" is a packet flow associated with a ULP control block, such as a TCP connection, where all the packets are protected by IPsec SAs such that: o the peer's identity is the same for the lifetime of the packet flow;
「IPSECチャネル」は、TCP接続などのULP制御ブロックに関連付けられたパケットフローです。すべてのパケットは、次のようなIPSEC SASによって保護されています。
o the quality of IPsec protection used for the packet flow's individual packets is the same for all of them for the lifetime of the packet flow.
o パケットフローの個々のパケットに使用されるIPSEC保護の品質は、パケットフローの寿命についてそれらすべてについて同じです。
An IPsec channel is created when the associated packet flow is created. This can be the result of a local operation (e.g., a connect()) that causes the initial outgoing packet for that flow to be sent, or it can be the result of receiving the first/initiating packet for that flow (e.g., a TCP SYN packet).
関連するパケットフローが作成されると、IPSECチャネルが作成されます。これは、そのフローの最初の発信パケットを引き起こすローカル操作（例：接続（））の結果であるか、またはそのフローの最初の/開始パケットを受信した結果である可能性があります（例：TCP synパケット）。
An IPsec channel is destroyed when the associated packet flow ends. An IPsec channel can also be "broken" when the connection latch cannot be maintained for some reason (see below), in which case the ULP and application are informed.
関連するパケットフローが終了すると、IPSECチャネルが破壊されます。IPSECチャネルは、何らかの理由で接続ラッチを維持できない場合（以下を参照）、「壊れている」こともあります（以下を参照）。その場合、ULPとアプリケーションに通知されます。
IPsec channels are created by "latching" various parameters listed below to a ULP connection when the connections are created. The REQUIRED set of parameters bound in IPsec channels is:
IPSECチャネルは、接続が作成されたときに以下にリストされているさまざまなパラメーターをULP接続に「ラッチ」することによって作成されます。IPSECチャネルでバインドされたパラメーターの必要なセットは、次のとおりです。
o Type of protection: confidentiality and/or integrity protection;
o 保護の種類：機密性および/または整合性保護。
o Transport mode versus tunnel mode;
o トランスポートモードvsトンネルモード。
o Quality of protection (QoP): cryptographic algorithm suites, key lengths, and replay protection (see Section 2.1);
o 保護品質（QOP）：暗号化アルゴリズムスイート、キー長、およびリプレイ保護（セクション2.1を参照）。
o Local identity: the local ID asserted to the peer, as per the IPsec processing model [RFC4301] and BTNS [RFC5386];
o ローカルアイデンティティ：IPSEC処理モデル[RFC4301]およびBTNS [RFC5386]に従って、ローカルIDがピアにアサートされました。
o Peer identity: the peer's asserted and authorized IDs, as per the IPsec processing model [RFC4301] and BTNS [RFC5386].
o ピアアイデンティティ：IPSEC処理モデル[RFC4301]およびBTNS [RFC5386]に従って、ピアの主張および承認されたID。
The SAs that protect a given IPsec channel's packets may change over time in that they may expire and be replaced with equivalent SAs, or they may be re-keyed. The set of SAs that protect an IPsec channel's packets need not be related by anything other than the fact that they must be congruent to the channel (i.e., the SAs' parameters must match those that are latched into the channel). In particular, it is desirable that IPsec channels survive the expiration of IKE_SAs and child SAs because operational considerations of the various key exchange protocols then cannot affect the design and features of connection latching.
特定のIPSECチャネルのパケットを保護するSASは、期限切れになり、同等のSASに置き換える可能性があるという点で時間とともに変化する可能性があります。IPSECチャネルのパケットを保護するSASのセットは、チャネルと一致しなければならないという事実以外のものと関連する必要はありません（つまり、SASのパラメーターはチャネルにラッチされたものと一致する必要があります）。特に、IPSECチャンネルは、さまざまなキー交換プロトコルの運用上の考慮事項が接続ラッチの設計と特徴に影響を与えることができないため、IKE_SASとチャイルドSASの有効期限に耐えることが望ましいです。
When a situation arises in which the SPD is modified, or an SA is added to the SAD, such that the new policy and/or SA are not congruent to an established channel (see previous paragraph), then we consider this a conflict. Conflict resolution is addressed below.
SPDが変更された状況が発生した場合、またはSAがSADに追加され、新しいポリシーおよび/またはSAが確立されたチャネルと一致しないようにすると（前の段落を参照）、これは競合だと考えます。紛争解決を以下に説明します。
Requirements and recommendations:
要件と推奨事項：
o If an IPsec channel is desired, then packets for a given connection MUST NOT be sent until the channel is established.
o IPSECチャネルが必要な場合、チャネルが確立されるまで、特定の接続のパケットを送信しないでください。
o If an IPsec channel is desired, then inbound packets for a given connection MUST NOT be accepted until the channel is established. That is, inbound packets for a given connection arriving prior to the establishment of the corresponding IPsec channel must be dropped or the channel establishment must fail.
o IPSECチャネルが必要な場合、チャネルが確立されるまで、特定の接続のインバウンドパケットを受け入れないでください。つまり、対応するIPSECチャネルの確立前に到着する特定の接続のインバウンドパケットをドロップする必要があります。そうしないと、チャネル確立が故障する必要があります。
o Once an IPsec channel is established, packets for the latched connection MUST NOT be sent unprotected nor protected by an SA that does not match the latched parameters.
o IPSECチャネルが確立されると、ラッチされた接続用のパケットを保護されていない場合も、ラッチされたパラメーターと一致しないSAによって保護されたりすることはできません。
o Once an IPsec channel is established, packets for the latched connection MUST NOT be accepted unprotected nor protected by an SA that does not match the latched parameters. That is, such packets must either be dropped or cause the channel to be terminated and the application to be informed before data from such a packet can be delivered to the application.
o IPSECチャネルが確立されると、ラッチされた接続のパケットを保護されていないことも、ラッチされたパラメーターと一致しないSAによって保護されてはなりません。つまり、そのようなパケットをドロップするか、チャネルを終了し、そのようなパケットからのデータをアプリケーションに配信する前にアプリケーションを通知する必要があります。
o Implementations SHOULD provide programming interfaces for inquiring the values of the parameters latched in a connection.
o 実装は、接続でラッチされたパラメーターの値を調査するためのプログラミングインターフェイスを提供する必要があります。
o Implementations that provide such programming interfaces MUST make available to applications all relevant and available information about a peer's ID, including authentication information. This includes the peer certificate, when one is used, and the trust anchor to which it was validated (but not necessarily the whole certificate validation chain).
o このようなプログラミングインターフェイスを提供する実装は、認証情報を含むピアのIDに関するすべての関連性のある利用可能な情報をアプリケーションに利用できるようにする必要があります。これには、ピア証明書、使用されたときのピア証明書、および検証された信頼アンカーが含まれます（必ずしも証明書検証チェーン全体ではありません）。
o Implementations that provide such programming interfaces SHOULD make available to applications any information about local and/or remote public and private IP addresses, in the case of NAT-traversal.
o このようなプログラミングインターフェイスを提供する実装は、NATトラバーサルの場合、ローカルおよび/またはリモートのパブリックおよびプライベートIPアドレスに関する情報をアプリケーションに利用できるようにする必要があります。
o Implementations that provide such programming interfaces SHOULD make available to applications the inner and outer local and peer addresses whenever the latched connection uses tunnel-mode SAs.
o このようなプログラミングインターフェイスを提供する実装は、ラッチされた接続がトンネルモードSASを使用するたびに、内側と外側のローカルおよびピアアドレスをアプリケーションに利用できるようにする必要があります。
o Implementations SHOULD provide programming interfaces for setting the values of the parameters to be latched in a connection that will be initiated or accepted, but these interfaces MUST limit what values applications may request according to system policy (i.e., the IPsec PAD and SPD) and the application's local privileges.
o 実装は、開始または受け入れられる接続でラッチされるパラメーターの値を設定するためのプログラミングインターフェイスを提供する必要がありますが、これらのインターフェイスは、システムポリシー（つまり、IPSEC PADとSPD）とシステムポリシーに従って要求できる値を制限する必要があります。アプリケーションのローカル特権。
(Typical system policy may not allow applications any choices here. Policy extensions allowing for optional protection are described in Section 3.1.)
（典型的なシステムポリシーは、ここでの選択肢をアプリケーションに許可しない場合があります。オプションの保護を許可するポリシー拡張は、セクション3.1で説明されています。）
o Implementations SHOULD create IPsec channels automatically by default when the application does not explicitly request an IPsec channel. Implementations MAY provide a way to disable automatic creation of connection latches.
o アプリケーションがIPSECチャネルを明示的に要求しない場合、実装はデフォルトで自動的にIPSECチャネルを作成する必要があります。実装は、接続ラッチの自動作成を無効にする方法を提供する場合があります。
o The parameters latched in an IPsec channel MUST remain unchanged once the channel is established.
o IPSECチャネルでラッチされたパラメーターは、チャネルが確立されていれば変更されておく必要があります。
o Timeouts while establishing child SAs with parameters that match those latched into an IPsec channel MUST be treated as packet loss (as happens, for example, when a network partitions); normal ULP and/or application timeout handling and retransmission considerations apply.
o タイムアウトIPSECチャネルにラッチされたものと一致するパラメーターを使用して子SASを確立しながら、パケット損失として扱う必要があります（たとえば、ネットワークパーティションの場合）。通常のULPおよび/またはアプリケーションのタイムアウト処理と再送信の考慮事項が適用されます。
o Implementations that have a restartable key management process (or "daemon") MUST arrange for existing latched connections to either be broken and disconnected, or for them to survive the restart of key exchange processes. (This is implied by the above requirements.) For example, if such an implementation relies on keeping some aspects of connection latch state in the restartable key management process (e.g., values that potentially have large representations, such as BTNS peer IDs), then either such state must be restored on restart of such a process, or outstanding connection latches must be transitioned to the CLOSED state.
o 再起動可能な主要な管理プロセス（または「デーモン」）を備えた実装は、既存のラッチされた接続を壊して切断するか、キー交換プロセスの再起動に耐えるために手配する必要があります。（これは上記の要件で暗示されています。）たとえば、そのような実装が再起動可能なキー管理プロセスに接続ラッチ状態のいくつかの側面を維持することに依存している場合（たとえば、BTNSピアIDなどの大きな表現を潜在的に持つ値）、次に、そのような状態は、そのようなプロセスの再起動時に復元する必要があるか、未解決の接続ラッチを閉じた状態に移行する必要があります。
o Dynamic IPsec policy (see Section 3.1) related to connection latches, if any, MUST be torn down when latched connections are torn down, and MUST NOT survive reboots.
o 接続ラッチに関連する動的IPSECポリシー（セクション3.1を参照）は、ラッチされた接続が取り壊されたときに取り壊され、再起動に耐えてはなりません。
o When IKE dead-peer detection (DPD) concludes that the remote peer is dead or has rebooted, then the system SHOULD consider all connection latches with that peer to be irremediably broken.
o Ike Dead-Peer Detection（DPD）が、リモートピアが死んでいるか、再起動していると結論付けると、システムはそのピアを伴うすべての接続ラッチを取り返しなく壊れていると考える必要があります。
We describe two models, one of them normative, of IPsec channels for native IPsec implementations. The normative model is based on abstract programming interfaces in the form of function calls between ULPs and the key management component of IPsec (basically, the SAD, augmented with a Latch Database (LD)). The second model is based on abstract programming interfaces between ULPs and the IPsec (Encapsulating Security Payload / Authentication Header (ESP/AH)) layer in the form of meta-data tagging of packets within the IP stack.
ネイティブIPSEC実装のためのIPSECチャネルの2つのモデル（そのうちの1つは規範的なもの）について説明します。規範モデルは、ULPSとIPSECの主要な管理コンポーネントとの間の関数呼び出しの形式の抽象プログラミングインターフェイスに基づいています（基本的には、ラッチデータベース（LD）で拡張されたSAD）。2番目のモデルは、ULPSとIPSECの間の抽象プログラミングインターフェイス（セキュリティペイロード /認証ヘッダー（ESP / AH））レイヤーの間のインターフェイスに基づいています。IPスタック内のパケットのメタデータタグ付けの形式です。
The two models given below are not, however, entirely equivalent. One model cannot be implemented with Network Interface cards (NICs) that offload ESP/AH but that do not tag incoming packets passed to the host processor with SA information, nor allow the host processor to so tag outgoing packets. That same model can be easily extended to support connection latching with unconnected datagram "sockets", while the other model is rigidly tied to a notion of "connections" and cannot be so extended. There may be other minor differences between the two models. Rather than seek to establish equivalency for some set of security guarantees, we instead choose one model to be the normative one.
ただし、以下に示す2つのモデルは、完全に同等ではありません。1つのモデルは、ESP/AHをオフロードするネットワークインターフェイスカード（NICS）で実装することはできませんが、SA情報でホストプロセッサに渡された着信パケットにタグを付けたり、ホストプロセッサが発信パケットにタグを付けることもできません。その同じモデルを簡単に拡張して、接続されていないデータグラム「ソケット」で接続ラッチをサポートすることができますが、他のモデルは「接続」の概念に厳密に結び付けられており、それほど拡張することはできません。2つのモデルの間に他の小さな違いがあるかもしれません。セキュリティ保証の一部の同等性を確立しようとするのではなく、代わりに1つのモデルを規範的なモデルにすることを選択します。
We also provide a model for non-native implementations, such as bump-in-the-stack (BITS) and Security Gateway (SG) implementations. The connection latching model for non-native implementations is not full-featured as it depends on estimating packet flow state, which may not always be possible. Nor can non-native IPsec implementations be expected to provide APIs related to connection latching (implementations that do could be said to be native). As such, this third model is not suitable for channel binding applications [RFC5056].
また、Bump-in-the-Stack（BITS）やSecurity Gateway（SG）の実装など、非ネイティブの実装のモデルも提供します。非ネイティブの実装の接続ラッチモデルは、パケットフロー状態の推定に依存するため、完全に機能していません。これは常に可能であるとは限りません。また、非ネイティブのIPSEC実装は、接続ラッチングに関連するAPIを提供することも期待できません（これは、ネイティブと言えます）。そのため、この3番目のモデルは、チャネル結合アプリケーション[RFC5056]には適していません。
In IPsec, the assumption of IKE initiator/responder roles is non-deterministic. That is, sometimes an IKE SA and child SAs will be initiated by the "client" (e.g., the caller of the connect() BSD sockets function) and sometimes by the "server" (e.g., the caller of the accept() BSD Sockets function). This means that the negotiation of quality of protection is also non-deterministic unless one of the peers offers a single cryptographic suite in the IKE negotiation.
IPSECでは、IKEイニシエーター/レスポンダーの役割の仮定は非決定的です。つまり、IKE SAとチャイルドSASが「クライアント」（例：CONNECT（）BSDソケット機能の呼び出し元）、時には「サーバー」（eccept（）BSDの呼び出し者によって開始される場合があります。ソケット機能）。これは、ピアの1人がIKE交渉で単一の暗号化スイートを提供しない限り、保護の質の交渉も非決定的であることを意味します。
When creating narrow child SAs with traffic selectors matching the connection latch's 5-tuple, it is possible to constrain the IKE Quality-of-Protection negotiation to a single cryptographic suite. Therefore, implementations SHOULD provide an API for requesting the use of such child SAs. Implementors SHOULD consider an application request for a specific QoP to imply a request for narrow child SAs.
Connection Latchの5タプルに一致するトラフィックセレクターを使用して狭い子供SASを作成する場合、IKEの保護の質の交渉を単一の暗号化スイートに制限することができます。したがって、実装は、そのような子SASの使用を要求するためのAPIを提供する必要があります。実装者は、特定のQOPの申請要求を検討して、狭い子供SASのリクエストを暗示する必要があります。
When using SAs with traffic selectors encompassing more than just a single flow, then the system may only be able to latch a set of cryptographic suites, rather than a single cryptographic suite. In such a case, an implementation MUST report the QoP being used as indeterminate.
単一のフロー以上のトラフィックセレクターを使用してSASを使用する場合、システムは単一の暗号化スイートではなく、暗号スイートのセットしかラッチできない場合があります。そのような場合、実装は不確定として使用されているQOPを報告する必要があります。
Connection latches can exist in any of the following five states:
接続ラッチは、次の5つの状態のいずれかに存在する可能性があります。
o LISTENER
o リスナー
o ESTABLISHED
o 設立
o BROKEN (there exist SAs that conflict with the given connection latch, conflicting SPD changes have been made, or DPD has been triggered and the peer is considered dead or restarted)
o 壊れた（与えられた接続ラッチと競合する、矛盾するSPDの変更が行われた、またはDPDがトリガーされ、ピアが死亡または再起動されていると見なされるというSASが存在します）
o CLOSED (by the ULP, the application or administratively)
o 閉じた（ULP、アプリケーション、または管理上）
and always have an associated owner, or holder, such as a ULP transmission control block (TCB).
また、ULP透過制御ブロック（TCB）など、関連する所有者または所有者が常にいます。
A connection latch can be born in the LISTENER state, which can transition only to the CLOSED state. The LISTENER state corresponds to LISTEN state of TCP (and other ULPs) and is associated with IP 3-tuples, and can give rise to new connection latches in the ESTABLISHED state.
接続ラッチは、リスナー状態で生まれ、閉じた状態にのみ移行できます。リスナー状態は、TCP（およびその他のULP）のリッスン状態に対応し、IP 3タプルに関連付けられており、確立された状態で新しい接続ラッチを引き起こす可能性があります。
A connection latch can also be born in the ESTABLISHED and BROKEN states, either through the direct initiative of a ULP or when an event occurs that causes a LISTENER latch to create a new latch (in either ESTABLISHED or BROKEN states). These states represent an active connection latch for a traffic flow's 5-tuple. Connection latches in these two states can transition to the other of the two states, as well as to the CLOSED state.
ULPの直接的なイニシアチブを通じて、またはリスナーラッチが新しいラッチを作成するイベント（確立された状態または壊れた状態）を作成する場合、接続ラッチは、確立された壊れた状態で生まれることもできます。これらの状態は、トラフィックフローの5タプルのアクティブな接続ラッチを表しています。これら2つの状態の接続ラッチは、2つの状態の他の状態と閉じた状態に移行できます。
Connection latches remain in the CLOSED state until their owners are informed except where the owner caused the transition, in which case this state is fleeting. Transitions from ESTABLISHED or BROKEN states to the CLOSED state should typically be initiated by latch owners, but implementations SHOULD provide administrative interfaces through which to close active latches.
所有者が移行を引き起こした場合を除き、所有者が通知されるまで、接続ラッチは閉じた状態のままです。その場合、この状態はつかの間です。確立された状態または壊れた状態から閉鎖状態への移行は通常、ラッチ所有者が開始する必要がありますが、実装はアクティブなラッチを閉じるための管理インターフェイスを提供する必要があります。
Connection latches transition to the BROKEN state when there exist SAs in the SAD whose traffic selectors encompass the 5-tuple bound by the latch, and whose peer and/or parameters conflict with those bound by the latch. Transitions to the BROKEN state also take place when SPD changes occur that would cause the latched connection's packets to be sent or received with different protection parameters than those that were latched. Transitions to the BROKEN state are also allowed when IKEv2 DPD concludes that the remote peer is dead or has rebooted. Transitions to the BROKEN state always cause the associated owner to be informed. Connection latches in the BROKEN state transition back to ESTABLISHED when all SA and/or SPD conflicts are cleared.
接続ラッチは、トラフィックセレクターがラッチに縛られている5タプルを包含するSASにSASが存在する場合、壊れた状態に移行し、ピアおよび/またはパラメーターがラッチに縛られたものと矛盾します。壊れた状態への遷移は、Latched Connectionのパケットがラッチされたものとは異なる保護パラメーターで送信または受信されるSPDの変更が発生したときにも行われます。IKEV2 DPDがリモートピアが死んでいるか、再起動していると結論付けている場合、壊れた状態への遷移も許可されます。壊れた状態への移行により、関連する所有者に常に通知されます。すべてのSAおよび/またはSPDの競合がクリアされた場合、壊れた状態の移行の接続ラッチは確立されます。
Most state transitions are the result of local actions of the latch owners (ULPs). The only exceptions are: birth into the ESTABLISHED state from latches in the LISTENER state, transitions to the BROKEN state, transitions from the BROKEN state to ESTABLISHED, and administrative transitions to the CLOSED state. (Additionally, see the implementation note about restartable key management processes in Section 2.) The state diagram below makes use of conventions described in Section 1.1 and state transition events described in Section 2.3.
ほとんどの州の移行は、ラッチ所有者（ULPS）のローカルアクションの結果です。唯一の例外は、リスナー状態のラッチからの確立された状態への誕生、壊れた状態への移行、壊れた状態から確立された状態への移行、および行政移行の閉鎖状態への移行です。（さらに、セクション2の再起動可能な主要管理プロセスに関する実装メモを参照してください。）以下の状態図は、セクション1.1で説明されている規則とセクション2.3で説明されている状態遷移イベントを使用しています。
<CREATE_LISTENER_LATCH(3-tuple, ...)>
:
v <CREATE_CONNECTION_LATCH(5-tuple, ...)>
/--------\ : :
+------|LISTENER|...... : :
| \--------/ : : : +--------------------+
| : : : : |Legend: |
| : : : : | dotted lines denote|
| <conn. trigger event> : : | latch creation |
| (e.g., TCP SYN : : : | |
| received, : : : | solid lines denote |
| connect() : : : | state transition|
| called, ...) v v : | |
| : /-----------\ : | semi-solid lines |
| : |ESTABLISHED| : | denote async |
| <conflict> \-----------/ : | notification |
| : ^ | : +--------------------+
| : | <conflict
| : <conflict or DPD>
| : cleared> | :
| : | | :
| : | v v
| : /----------------\
| :.....>| BROKEN |.-.-.-.-.-> <ALERT()>
| \----------------/
| |
<RELEASE_LATCH()> <RELEASE_LATCH()>
| |
| v
| /------\
+------------------->|CLOSED|
\------/
Figure 1: Connection Latching State Machine
図1：接続ラッチステートマシン
The details of the transitions depend on the model of connection latching followed by any given implementation. See the following sections.
遷移の詳細は、接続ラッチングのモデルと、特定の実装のモデルによって異なります。次のセクションを参照してください。
This section describes the NORMATIVE model of connection latching.
このセクションでは、接続ラッチの規範モデルについて説明します。
In this section, we describe connection latching in terms of a function-call interface between ULPs and the "key manager" component of a native IPsec implementation. Abstract interfaces for creating, inquiring about, and releasing IPsec channels are described.
このセクションでは、ULPSとネイティブIPSEC実装の「キーマネージャー」コンポーネントとの間の関数コールインターフェイスに関して、接続ラッチングについて説明します。IPSECチャネルを作成、問い合わせ、リリースするための抽象インターフェイスについて説明します。
This model adds a service to the IPsec key manager (i.e., the component that manages the SAD and interfaces with separate implementations of, or directly implements, key exchange protocols): management of connection latches. There is also a new IPsec database, the Latch Database (LD), that contains all connection latch objects. The LD does not persist across system reboots.
このモデルは、IPSECキーマネージャーにサービスを追加します（つまり、キーエクスチェンジプロトコルの個別の実装または直接実装を使用して、SADおよびインターフェイスを管理するコンポーネント）：接続ラッチの管理。また、すべての接続ラッチオブジェクトを含む新しいIPSECデータベース、ラッチデータベース（LD）もあります。LDは、システムの再起動全体で持続しません。
The traditional IPsec processing model allows the concurrent existence of SAs with different peers but overlapping traffic selectors. Such behavior, in this model, directly violates the requirements for connection latching (see Section 2). We address this problem by requiring that connection latches be broken (and holders informed) when such conflicts arise.
従来のIPSEC処理モデルにより、さまざまなピアを持つSASの同時存在が可能になりますが、トラフィックセレクターが重なります。このような動作は、このモデルでは、接続ラッチの要件に直接違反します（セクション2を参照）。そのような競合が発生したときに接続ラッチを破壊する（および保有者が通知される）ことを要求することにより、この問題に対処します。
The following INFORMATIVE figure illustrates this model and API in terms that are familiar to many implementors, though not applicable to all:
次の有益な図は、多くの実装者に馴染みのある用語でこのモデルとAPIを示していますが、すべてには適用されません。
+--------------------------------------------+
| +--------------+ |
| |Administrator | |
| |apps | |
| +--------------+ |
| ^ ^ |
| | | | user mode
| v v |
| +--------------+ +-------++--------+ |
| |App | |IKEv2 || | |
| | | | +---+ || +----+ | |
| | | | |PAD| || |SPD | | |
| | | | +---+ || +--^-+ | |
| +--------------+ +-+-----++----+---+ |
| ^ | | |
+---|---------------------|-----------|------+ user/kernel mode
| |syscalls | PF_KEY | | interface
| | | [RFC2367] | |
+---|---------------------|-----------|------+
| v | | |
|+-------+ +------------|-----------|-----+|
||ULP | | IPsec key|manager | ||
|+-------+ | | +--------v----+||
| ^ ^ | | | Logical SPD |||
| | | | | +-----------^-+||
| | | | +-------+ | || kernel mode
| | | | | | ||
| | | | +----------+ +--v--+ | ||
| | +-------->| Latch DB |<-->| SAD | | ||
| | | +----------+ +--^--+ | ||
| | +--------------------|------|--+|
+-|-------------------------------v------v---+
| | IPsec Layer (ESP/AH) |
| | |
+-v------------------------------------------+
| IP Layer |
+--------------------------------------------+
Figure 2: Informative Implementation Architecture Diagram
図2：有益な実装アーキテクチャ図
The ULP interfaces to the IPsec LD are as follows:
IPSEC LDへのULPインターフェイスは次のとおりです。
o CREATE_LISTENER_LATCH(3-tuple, [type and quality-of-protection parameters]) -> latch handle | error
o create_listener_latch（3-tuple、[タイプと保護の質のパラメーター]） - > latchハンドル|エラー
If there is no conflicting connection latch object in the LISTENER state for the given 3-tuple (local address, protocol, and local port number), and local policy permits it, then this operation atomically creates a connection latch object in the LISTENER state for the given 3-tuple.
指定された3タプル（ローカルアドレス、プロトコル、およびローカルポート番号）のリスナー状態に矛盾する接続ラッチオブジェクトがない場合、ローカルポリシーが許可されている場合、この操作はリスナー状態の接続ラッチオブジェクトを原子的に作成します。与えられた3タプル。
When a child SA is created that matches a listener latch's 3-tuple, but not any ESTABLISHED connection latch's 5-tuple (local address, remote address, protocol, local port number, and remote port number), then the key manager creates a new connection latch object in the ESTABLISHED state. The key manager MUST inform the holder of the listener latch of connection latches created as a result of the listener latch; see the "ALERT()" interface below.
リスナーラッチの3タプルに一致するが、確立された接続ラッチの5タプル（ローカルアドレス、リモートアドレス、プロトコル、ローカルポート番号、およびリモートポート番号）に一致する子供SAが作成されると、キーマネージャーは新しいものを作成します確立された状態の接続ラッチオブジェクト。キーマネージャーは、リスナーラッチの結果として作成された接続ラッチのリスナーラッチを保有者に通知する必要があります。以下の「alert（）」インターフェイスを参照してください。
o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID]) -> latch handle | error
o create_connection_latch（5-tuple、[Type and oftotection-oftection-oftection-oftection-oftection-oftection-oftection-oftection-oftection-oftection-oftection-oftection-decly id]、[local id]） - > latchハンドル|エラー
If a) the requested latch does not exist (or exists, but is in the CLOSED state), b) all the latch parameters are provided, or if suitable SAs exist in the SAD from which to derive them, and c) if there are no conflicts with the SPD and SAD, then this creates a connection latch in the ESTABLISHED state. If the latch parameters are not provided and no suitable SAs exist in the SAD from which to derive those parameters, then the key manager MUST initiate child SAs, and if need be, IKE_SA, from which to derive those parameters.
a）要求されたラッチが存在しない（または存在するが、閉じた状態にある）、b）すべてのラッチパラメーターが提供される、またはそれらを導出する悲しい人に適したSAが存在する場合、c）SPDとSADとの矛盾はありません。これにより、確立された状態に接続ラッチが作成されます。ラッチパラメーターが提供されておらず、それらのパラメーターを導出するためにSADに適切なSAが存在しない場合、キーマネージャーは子SASを開始する必要があります。
The key manager MAY delay the child SA setup and return immediately after the policy check, knowing that the ULP that requested the latch will subsequently output a packet that will trigger the SA establishment. Such an implementation may require an additional, fleeting state in the connection latch state machine, a "LARVAL" state, so to speak, that is not described herein.
キーマネージャーは、ポリシーチェックの直後にチャイルドSAのセットアップを遅らせて戻ってくる場合があり、ラッチを要求したULPがその後SA施設をトリガーするパケットを出力することを知っています。このような実装には、接続ラッチ状態マシン、「幼虫」状態にある追加のつかの間の状態が必要になる場合があります。
If the connection latch ultimately cannot be established, either because of conflicts or because no SAs can be established with the peer at the destination address, then an error is returned to the ULP. (If the key manager delayed SA establishment, and SA establishment ultimately fails, then the key manager has to inform the ULP, possibly asynchronously. This is one of several details that implementors who use a LARVAL state must take care of.)
競合のため、または宛先アドレスのピアでSASを確立できないため、最終的に接続ラッチを確立できない場合、エラーがULPに戻ります。（キーマネージャーがSAの施設を遅らせ、SA施設が最終的に失敗した場合、キーマネージャーはULPに非同期に通知する必要があります。これは、幼虫の状態を使用する実装者が世話をしなければならないいくつかの詳細の1つです。）
o RELEASE_LATCH(latch object handle)
o release_latch（ラッチオブジェクトハンドル）
Changes the state of the given connection latch to CLOSED; the connection latch is then deleted.
指定された接続ラッチの状態を閉じて変更します。次に、接続ラッチが削除されます。
The key manager MAY delete any existing child SAs that match the given latch if it had been in the ESTABLISHED states. If the key manager does delete such SAs, then it SHOULD inform the peer with an informational Delete payload (see IKEv2 [RFC4306]).
キーマネージャーは、確立された状態にあった場合、指定されたラッチに一致する既存の子SASを削除できます。キーマネージャーがそのようなSASを削除する場合、情報削除ペイロードでピアに通知する必要があります（IKEV2 [RFC4306]を参照）。
o FIND_LATCH(5-tuple) -> latch handle | error
o find_latch（5 -tuple） - >ラッチハンドル|エラー
Given a 5-tuple returns a latch handle (or an error).
5タプルがラッチハンドル（またはエラー）を返します。
o INQUIRE_LATCH(latch object handle) -> {latch state, latched parameters} | error
o quire_latch（latch object handle） - > {latch state、latched parameters} |エラー
Returns all available information about the given latch, including its current state (or an error).
現在の状態（またはエラー）を含む、指定されたラッチに関する利用可能なすべての情報を返します。
The IPsec LD interface to the ULP is as follows:
ULPへのIPSEC LDインターフェイスは次のとおりです。
o ALERT(latch object handle, 5-tuple, new state, [reason])
o アラート（ラッチオブジェクトハンドル、5タプル、新しい状態、[理由]）
Alerts a ULP as to an asynchronous state change for the given connection latch and, optionally, provides a reason for the change.
特定の接続ラッチの非同期状態の変化についてULPに警告し、オプションでは、変更の理由を提供します。
This interface is to be provided by each ULP to the key manager. The specific details of how this interface is provided are implementation details, thus not specified here (for example, this could be a "callback" function or "closure" registered as part of the CREATE_LISTENER_LATCH() interface, or it could be provided when the ULP is loaded onto the running system via a registration interface provided by the key manager).
このインターフェイスは、各ULPによってキーマネージャーに提供されます。このインターフェイスの提供方法の具体的な詳細は実装の詳細であるため、ここでは指定されていません（たとえば、これはcreate_listener_latch（）インターフェイスの一部として登録されている「コールバック」関数または「クロージャー」であるか、またはそれを提供する場合、または提供できます。ULPは、キーマネージャーが提供する登録インターフェイスを介して実行システムにロードされます）。
Needless to say, the LD is updated whenever a connection latch object is created, deleted, or broken.
言うまでもなく、接続ラッチオブジェクトが作成、削除、または破損するたびにLDは更新されます。
The API described above is a new service of the IPsec key manager. In particular, the IPsec key manager MUST prevent conflicts amongst latches, and it MUST prevent conflicts between any latch and existing or proposed child SAs as follows:
上記のAPIは、IPSECキーマネージャーの新しいサービスです。特に、IPSECキーマネージャーは、ラッチ間の競合を防ぐ必要があり、次のように、ラッチと既存または提案された子SAS間の対立を防ぐ必要があります。
o Non-listener connection latches MUST NOT be created if there exist conflicting SAs in the SAD at the time the connection latch is requested or would be created (from a listener latch). A child SA conflicts with another, in view of a latch, if and only if: a) its traffic selectors and the conflicting SA's match the given latch's, and b) its peer, type-of-protection, or quality-of-protection parameters differ from the conflicting SA.
o 接続ラッチが要求されるか、（リスナーラッチから）作成された時点で、競合するSASがSASが存在する場合は、登場しない接続ラッチを作成しないでください。子どものSAは、次の場合にのみ、ラッチを考慮して他の人と競合します。a）そのトラフィックセレクターと競合するSAの一致は、与えられたラッチと一致し、b）その仲間、保護の種類、または保護の質パラメーターは競合するSAとは異なります。
o Child SA proposals that would conflict with an extant connection latch and whose traffic selectors can be narrowed to avoid the conflict SHOULD be narrowed (see Section 2.9 of [RFC4306]); otherwise, the latch MUST be transitioned to the BROKEN state.
o 現存する接続ラッチと競合する子SA SAの提案と、紛争を避けるためにトラフィックセレクターを狭めることができるものを狭めることができます（[RFC4306]のセクション2.9を参照）。それ以外の場合、ラッチは壊れた状態に移行する必要があります。
o Where child SA proposals that would conflict with an extant connection latch cannot be narrowed to avoid the conflict, the key manager MUST break the connection latch and inform the holder (i.e., the ULP) prior to accepting the conflicting SAs.
o 現存する接続ラッチと競合する子SAの提案を狭くすることができない場合、競合を回避することはできません。キーマネージャーは、競合するSASを受け入れる前に、接続ラッチを破壊し、所有者（つまりULP）に通知する必要があります。
Finally, the key manager MUST protect latched connections against SPD changes that would change the quality of protection afforded to a latched connection's traffic, or which would bypass it. When such a configuration change takes place, the key manager MUST respond in either of the following ways. The REQUIRED to implement behavior is to transition into the BROKEN state all connection latches that conflict with the given SPD change. An OPTIONAL behavior is to logically update the SPD as if a PROTECT entry had been added at the head of the SPD-S with traffic selectors matching only the latched connection's 5-tuple, and with processing information taken from the connection latch. Such updates of the SPD MUST NOT survive system crashes or reboots.
最後に、キーマネージャーは、Latched Connectionのトラフィックに与えられる保護の質を変える、またはそれをバイパスするSPDの変更から、ラッチング接続を保護する必要があります。このような構成の変更が行われた場合、キーマネージャーは次のいずれかの方法で応答する必要があります。動作を実装するために必要なのは、壊れた状態に移行することです。特定のSPDの変更と矛盾するすべての接続ラッチが壊れます。オプションの動作は、Latched Connectionの5タプルのみを一致させるトラフィックセレクターと、接続ラッチから取得した処理情報を使用して、SPD-Sのヘッドに保護エントリが追加されたかのようにSPDを論理的に更新することです。SPDのこのような更新は、システムのクラッシュや再起動に耐えてはなりません。
ULPs create latched connections by interfacing with IPsec as follows:
ULPSは、次のようにIPSECとインターフェースすることにより、ラッチされた接続を作成します。
o For listening end-points, the ULP will request a connection latch listener object for the ULP listener's 3-tuple. Any latching parameters requested by the application MUST be passed along.
o リスニングエンドポイントの場合、ULPはULPリスナーの3タプルの接続ラッチリスナーオブジェクトを要求します。アプリケーションによって要求されたラッチングパラメーターは、渡す必要があります。
o When the ULP receives a packet initiating a connection for a 5-tuple matching a 3-tuple listener latch, then the ULP will ask the key manager whether a 5-tuple connection latch was created. If not, then the ULP will either reject the new connection or accept it and inform the application that the new connection is not latched.
o ULPが3タプルリスナーラッチに一致する5タプルの接続を開始するパケットを受信すると、ULPはキーマネージャーに5タプル接続ラッチが作成されたかどうかを尋ねます。そうでない場合、ULPは新しい接続を拒否するか、それを受け入れ、新しい接続がラッチされていないことをアプリケーションに通知します。
o When initiating a connection, the ULP will request a connection latch object for the connection's 5-tuple. Any latching parameters requested by the application MUST be passed along. If no latch can be created, then the ULP MUST either return an error to the application or continue with the new connection and inform the application that the new connection is not latched.
o 接続を開始すると、ULPは接続の5タプルの接続ラッチオブジェクトを要求します。アプリケーションによって要求されたラッチングパラメーターは、渡す必要があります。ラッチを作成できない場合、ULPはアプリケーションにエラーを返すか、新しい接続を続行し、新しい接続がラッチされていないことをアプリケーションに通知する必要があります。
o When a connection is torn down and no further packets are expected for it, then the ULP MUST request that the connection latch object be destroyed.
o 接続が取り壊され、それ以上のパケットが予想されない場合、ULPは接続ラッチオブジェクトを破壊するように要求する必要があります。
o When tearing down a listener, the ULP MUST request that the connection latch listener object be destroyed.
o リスナーを解体するとき、ULPは接続ラッチリスナーオブジェクトを破壊するように要求する必要があります。
o When a ULP listener rejects connections, the ULP will request the destruction of any connection latch objects that may have been created as a result of the peer's attempt to open the connection.
o ULPリスナーが接続を拒否すると、ULPは、接続を開こうとするピアの試みの結果として作成された可能性のある接続ラッチオブジェクトの破壊を要求します。
o When the key manager informs a ULP that a connection latch has transitioned to the BROKEN state, then the ULP MUST stop sending packets and MUST drop all subsequent incoming packets for the affected connection until it transitions back to ESTABLISHED. Connection-oriented ULPs SHOULD act as though the connection is experiencing packet loss.
o キーマネージャーがULPに接続ラッチが壊れた状態に移行したことを通知すると、ULPはパケットの送信を停止する必要があり、影響を受ける接続のために後続のすべての着信パケットを確立するまでドロップする必要があります。接続指向のULPは、接続がパケット損失を経験しているかのように機能する必要があります。
o When the key manager informs a ULP that a connection latch has been administratively transitioned to the CLOSED state, then connection-oriented ULPs MUST act as though the connection has been reset by the peer. Implementations of ULPs that are not connection-oriented, and which have no API by which to simulate a reset, MUST drop all inbound packets for that connection and MUST NOT send any further packets -- the application is expected to detect timeouts and act accordingly.
o キーマネージャーがULPに、接続ラッチが管理上閉じた状態に移行されたことを通知する場合、接続指向のULPは、接続がピアによってリセットされているかのように動作する必要があります。接続指向ではなく、リセットをシミュレートするためのAPIがないULPの実装は、その接続のすべてのインバウンドパケットをドロップし、それ以上のパケットを送信する必要はありません - アプリケーションはタイムアウトを検出し、それに応じて行動することが期待されます。
The main benefit of this model of connection latching is that it accommodates IPsec implementations where ESP/AH handling is implemented in hardware (for all or a subset of the host's SAD), even where the hardware does not support tagging inbound packets with the indexes of SAD entries corresponding to the SAs that protected them.
この接続ラッチのモデルの主な利点は、ハードウェアがインデックスのインバウンドパケットのタグ付けをサポートしていない場合でも、ESP/AHハンドリングがハードウェア（ホストのすべてまたはサブセットに対して）に実装されるIPSEC実装に対応することです。それらを保護したSASに対応する悲しいエントリ。
ULPs MUST drop inbound packets and stop sending packets immediately upon receipt of a connection latch break message. Otherwise, the ULP will not be able to distinguish inbound packets that were protected consistently with the connection's latch from inbound packets that were not. This may include dropping inbound packets that were protected by a suitable SA; dropping such packets is no different, from the ULP's point of view, than packet loss elsewhere on the network at the IP layer or below -- harmless, from a security point of view as the connection fails safe, but it can result in retransmits.
ULPSは、インバウンドパケットをドロップし、接続ラッチブレークメッセージを受信するとすぐにパケットの送信を停止する必要があります。それ以外の場合、ULPは、接続のラッチと一貫して保護されていなかったインバウンドパケットと一貫して保護されていないパケットを区別することはできません。これには、適切なSAによって保護されたインバウンドパケットの削除が含まれる場合があります。このようなパケットをドロップすることは、ULPの観点とは、IPレイヤー以下のネットワーク上の他の場所のパケット損失と同じです。接続が安全に失敗するため、セキュリティの観点からは無害ですが、再送信になる可能性があります。
Another race condition is as follows. A PROTECTed TCP SYN packet may be received and decapsulated, but the SA that protected it could have expired before the key manager creates the connection latch that would be created by that packet. In this case, the key manager will have to initiate new child SAs so as to determine what the sender's peer ID is so it can be included in the connection latch. Here, there is no guarantee that the peer ID for the new SAs will be the same as those of the peer that sent the TCP SYN packet. This race condition is harmless: TCP will send a SYN+ACK to the wrong peer, which will then respond with a RST -- the connection latch will reflect the new peer however, so if the new peer is malicious it will not be able to appear to be the old peer. Therefore, this race condition is harmless.
別の人種条件は次のとおりです。保護されたTCP synパケットが受信されて脱カプセル化される場合がありますが、キーマネージャーがそのパケットによって作成される接続ラッチを作成する前に、保護されたSAが有効期限が切れていた可能性があります。この場合、キーマネージャーは、送信者のピアIDが何であるかを判断して、接続ラッチに含めることができるように、新しい子SASを開始する必要があります。ここでは、新しいSASのピアIDがTCP synパケットを送信したピアのピアIDと同じであるという保証はありません。このレースの状態は無害です。TCPは間違ったピアにSyn ACKを送信します。これはRSTで応答します。ただし、接続ラッチは新しいピアを反映します。古い仲間になること。したがって、この人種状態は無害です。
Consider several systems with a very simple PAD containing a single entry like so:
SOのような単一のエントリを含む非常にシンプルなパッドを備えたいくつかのシステムを検討してください。
Child SA
Rule Remote ID IDs allowed SPD Search by
---- --------- ----------- -------------
1 <any valid to trust anchor X> 192.0.2/24 by-IP
Figure 3: Example PAD
図3：パッドの例
And a simple SPD like so:
そして、ような単純なSPD：
Rule Local Remote Next Action
TS TS Proto
---- ----- ------ ----- ----------------
1 192.0.2/24:ANY 192.0.2/24:1-5000 TCP PROTECT(ESP,...)
1 192.0.2/24:1-5000 192.0.2/24:ANY TCP PROTECT(ESP,...)
1 ANY ANY ANY BYPASS
Figure 4: [SG-A] SPD Table
図4：[SG-A] SPDテーブル
Effectively this says: for TCP ports 1-5000 in our network, allow only peers that have credentials issued by CA X and PROTECT that traffic with ESP, otherwise, bypass all other traffic.
事実上、これは次のとおりです。ネットワーク内のTCPポート1-5000の場合、Ca Xによって発行された資格情報を持つピアのみを許可し、そのトラフィックをESPで保護します。
Now let's consider two hosts, A and B, in this network that wish to communicate using port 4000, and a third host, C, that is also in the same network and wishes to attack A and/or B. All three hosts have credentials and certificates issued by CA X. Let's also imagine that A is connected to its network via a wireless link and is dynamically addressed.
次に、ポート4000を使用して通信したいこのネットワークで、同じネットワークに通信したいこのネットワークの2つのホストを考えてみましょう。Ca Xが発行した証明書。また、Aがワイヤレスリンクを介してネットワークに接続され、動的に対処されていると想像してみましょう。
B is listening on port 4000. A initiates a connection from port 32800 to B on port 4000.
Bはポート4000で聴いています。Aは、ポート4000でポート32800からBへの接続を開始します。
We'll assume no IPsec APIs, but that TCP creates latches where possible.
IPSEC APIはありませんが、TCPは可能な限りラッチを作成します。
We'll consider three cases: a) A and B both support connection latching, b) only A does, c) only B does. For the purposes of this example, the SAD is empty on all three hosts when A initiates its TCP connection to B on port 4000.
3つのケースを検討します。A）AとBの両方をサポート接続ラッチング、b）Aのみ、c）Bのみが行います。この例の目的のために、Aがポート4000でBへのTCP接続を開始すると、3つのホストすべてがSADが空になります。
When an application running on A initiates a TCP connection to B on port 4000, A will begin by creating a connection latch. Since the SAD is empty, A will initiate an IKEv2 exchange to create an IKE_SA with B and a pair of child SAs for the 5-tuple {TCP, A, 32800, B, 4000}, then a new latch will be created in ESTABLISHED state. Sometime later, TCP will send a SYN packet protected by the A-to-B child SA, per the SPD.
Aで実行されるアプリケーションがポート4000でBへのTCP接続を開始すると、Aは接続ラッチを作成することから始まります。SADが空いているので、AはIKEV2 Exchangeを開始してBでIKE_SAを作成し、5タプル{TCP、A、32800、B、4000}の子SASのペアを作成します。州。しばらくして、TCPはSPDごとにA-t-B Child SAによって保護されたSynパケットを送信します。
When an application running on B creates a TCP listener "socket" on port 4000, B will create a LISTENER connection latch for the 3-tuple {TCP, B, 4000}. When B receives A's TCP SYN packet, it will then create a connection latch for {TCP, B, 4000, A, 32800}. Since, by this point, child SAs have been created whose traffic selectors encompass this 5-tuple and there are no other conflicting SAs in the SAD, this connection latch will be created in the ESTABLISHED state.
Bで実行されるアプリケーションがポート4000にTCPリスナー「ソケット」を作成すると、Bは3タプル{TCP、B、4000}のリスナー接続ラッチを作成します。BがAのTCP Synパケットを受信すると、{TCP、B、4000、A、32800}の接続ラッチが作成されます。この時点までに、トラフィックセレクターがこの5タプルを包含する子供SASが作成されており、SADには他の矛盾するSAがありません。この接続ラッチは確立された状態で作成されます。
If C attempts to mount a man-in-the-middle attack on A (i.e., pretends to have B's address(es)) any time after A created its connection latch, then C's SAs with A will cause the connection latch to break, and the TCP connection to be reset (since we assume no APIs by which TCP could notify the application of the connection latch break). If C attempts to impersonate A to B, then the same thing will happen on B.
cが接続ラッチを作成した後でも（つまり、Bのアドレスを持っているふりをする）（つまり、Bのアドレスを持っているふりをする）にCが試みた場合、AとAのSASが接続ラッチを破壊します。また、リセットするTCP接続（TCPが接続ラッチブレークの適用を通知できるAPIがないと想定しているため）。Cがaにbになりすまそうとした場合、同じことがBで起こります。
If A does not support connection latching, then C will be able to impersonate B to A at any time. Without having seen the cleartext of traffic between A and B, C will be limited by the TCP sequence numbers to attacks such as RST attacks. Similarly, if B does not support connection latching, then C will be able to impersonate A to B.
Aが接続ラッチングをサポートしていない場合、CはいつでもBになりすまします。AとBの間のトラフィックのクリアテキストを見ることなく、CはTCPシーケンス番号によってRST攻撃などの攻撃に制限されます。同様に、Bが接続ラッチングをサポートしていない場合、CはAからBになりすまします。
In this section, we describe connection latching in terms of interfaces between ULPs and IPsec based on tagging packets as they go up and down the IP stack.
このセクションでは、IPスタックを上下にタグ付けするパケットに基づいて、ULPSとIPSECの間のインターフェイスの観点から接続ラッチングについて説明します。
This section is INFORMATIVE.
このセクションは有益です。
In this model, the ULPs maintain connection latch objects and state, rather than the IPsec key manager, as well as effectively caching a subset of the decorrelated SPD in ULP TCBs. Tagging packets, as they move up and down the stack, with SA identifiers then allows the ULPs to enforce connection latching semantics. These tags, of course, don't appear on the wire.
このモデルでは、ULPSはIPSECキーマネージャーではなく、接続ラッチオブジェクトと状態を維持し、ULP TCBSの脱相関SPDのサブセットを効果的にキャッシュします。タグ付けパケットは、スタックを上下に移動するときに、SA識別子を使用して、ULPSが接続ラッチのセマンティクスを実施できるようにします。もちろん、これらのタグはワイヤーに表示されません。
The interface between the ULPs and IPsec interface is as follows:
ULPSとIPSECインターフェイスの間のインターフェイスは次のとおりです。
o The IPsec layer tags all inbound protected packets addressed to the host with the index of the SAD entry corresponding to the SA that protected the packet.
o IPSECレイヤーは、パケットを保護したSAに対応するSADエントリのインデックスを使用して、ホストにアドレス指定されたすべてのインバウンド保護されたパケットをタグ付けします。
o The IPsec layer understands two types of tags on outbound packets:
o IPSECレイヤーは、アウトバウンドパケットの2種類のタグを理解しています。
* a tag specifying a set of latched parameters (peer ID, quality of protection, etc.) that the IPsec layer will use to find or acquire an appropriate SA for protecting the outbound packet (else IPsec will inform the ULP and drop the packet);
* IPSECレイヤーが使用するラッチングパラメーターのセット（ピアID、保護品質など）を指定するタグは、アウトバウンドパケットを保護するために適切なSAを見つけたり取得したりします（IPSECはULPに通知し、パケットをドロップします）。
* a tag requesting feedback about the SA used to protect the outgoing packet, if any.
* 発信パケットを保護するために使用されるSAに関するフィードバックを要求するタグがある場合。
ULPs create latched connections by interfacing with IPsec as follows:
ULPSは、次のようにIPSECとインターフェースすることにより、ラッチされた接続を作成します。
o When the ULP passes a connection's initiating packet to IP, the ULP requests feedback about the SA used to protect the outgoing packet, if any, and may specify latching parameters requested by the application. If the packet is protected by IPsec, then the ULP records certain parameters of the SA used to protect it in the connection's TCB.
o ULPが接続の開始パケットをIPに渡すと、ULPは発信パケットを保護するために使用されるSAに関するフィードバックを要求し、アプリケーションで要求されたラッチパラメーターを指定する場合があります。パケットがIPSECによって保護されている場合、ULPは接続のTCBで保護するために使用されるSAの特定のパラメーターを記録します。
o When a ULP receives a connection's initiating packet, it processes the IPsec tag of the packet, and it records in the connection's TCB the parameters of the SA that should be latched.
o ULPが接続の開始パケットを受信すると、パケットのIPSECタグを処理し、接続のTCBにラッチする必要があるSAのパラメーターを記録します。
Once SA parameters are recorded in a connection's TCB, the ULP enforces the connection's latch, or binding, to these parameters as follows:
接続のTCBにSAパラメーターが記録されると、ULPは次のようにこれらのパラメーターに接続のラッチまたはバインディングを強制します。
o The ULP processes the IPsec tag of all inbound packets for a given connection and checks that the SAs used to protect input packets match the connection latches recorded in the TCBs. Packets that are not so protected are dropped (this corresponds to transitioning the connection latch to the BROKEN state until the next acceptable packet arrives, but in this model, this transition is imaginary) or cause the ULP to break the connection latch and inform the application.
o ULPは、特定の接続のすべてのインバウンドパケットのIPSECタグを処理し、入力パケットを保護するために使用されたSASがTCBで記録された接続ラッチと一致することをチェックします。それほど保護されていないパケットは削除されます（これは、次の許容可能なパケットが到着するまで壊れた状態に接続ラッチを遷移することに対応しますが、このモデルでは、この遷移は想像上のものです）またはULPに接続ラッチを破壊し、アプリケーションに通知します。
o The ULP always requests that outgoing packets be protected by SAs that match the latched connection by appropriately tagging outbound packets.
o ULPは常に、発信パケットが、適切にタグ付けされたアウトバウンドパケットに一致するSASによって保護されることを要求します。
By effectively caching a subset of the decorrelated SPD in ULP TCBs and through its packet tagging nature, this method of connection latching can also optimize processing of the SPD by obviating the need to search it, both, on input and output, for packets intended for the host or originated by the host. This makes implementation of the OPTIONAL "logical SPD" updates described in Sections 2.3 and 3.1 an incidental side effect of this approach.
ULP TCBSの脱線化されたSPDのサブセットを効果的にキャッシュすることにより、およびそのパケットタグ付けの性質を介して、この接続ラッチの方法は、入力と出力の両方で検索する必要性を削除することにより、SPDの処理を最適化することもできます。ホストまたはホストが生み出した。これにより、セクション2.3および3.1で説明されているオプションの「論理SPD」更新の実装により、このアプローチの偶発的な副作用が可能になります。
This model of connection latching may not be workable with ESP/AH offload hardware that does not support the packet tagging scheme described above.
この接続ラッチのモデルは、上記のパケットタグスキームをサポートしていないESP/AHオフロードハードウェアでは機能しない場合があります。
Note that this model has no explicit BROKEN connection latch state.
このモデルには、明示的な壊れた接続ラッチ状態がないことに注意してください。
Extending the ULP/IPsec packet-tagging interface to the application for use with connection-less datagram transports should enable applications to use such transports and implement connection latching at the application layer.
ULP/IPSECパケットタグのインターフェイスを接続のないデータグラムトランスポートで使用するアプリケーションに拡張すると、アプリケーションがそのようなトランスポートを使用し、アプリケーションレイヤーに接続ラッチを実装できるようになります。
This section is INFORMATIVE.
このセクションは有益です。
Non-native IPsec implementations, primarily BITS and SG, can implement connection latching, too. One major distinction between native IPsec and BITS, bump-in-the-wire (BITW), or SG IPsec is the lack of APIs for applications at the end-points in the case of the latter. As a result, there can be no uses of the latch management interfaces as described in Section 2.3: not at the ULP end-points. Therefore, BITS/BITW/SG implementations must discern ULP connection state from packet inspection (which many firewalls can do) and emulate calls to the key manager accordingly.
主にビットとSGである非ネイティブのIPSEC実装は、接続ラッチを実装することもできます。ネイティブのIPSECとビット、Bump-in-the-Wire（BITW）、またはSG IPSECの1つの大きな区別は、後者の場合のエンドポイントでのアプリケーションのAPIの欠如です。その結果、セクション2.3：ULPエンドポイントではなく、セクション2.3で説明されているように、ラッチ管理インターフェイスの使用はありません。したがって、BITS/BITW/SGの実装は、Packet Inspection（多くのファイアウォールができる）からULP接続状態を識別し、それに応じてキーマネージャーに通話をエミュレートする必要があります。
When a connection latch is broken, a BITS/BITW/SG implementation may have to fake a connection reset by sending appropriate packets (e.g., TCP RST packets), for the affected connections.
接続ラッチが壊れている場合、影響を受ける接続のために、適切なパケット（TCP RSTパケットなど）を送信して、ビット/BITW/SG実装で接続リセットを偽造する必要があります。
As with all stateful middleboxes, this scheme suffers from the inability of the middlebox to interact with the applications. For example, connection death may be difficult to ascertain. Nor can channel binding applications work with channels maintained by proxy without being able to communicate (securely) about it with the middlebox.
すべてのステートフルミドルボックスと同様に、このスキームは、ミドルボックスがアプリケーションと対話できないことに苦しんでいます。たとえば、接続の死を確認するのは難しい場合があります。また、チャネルバインディングアプリケーションは、ミドルボックスで（安全に）通信することなく、プロキシによって維持されるチャネルで動作することもできません。
One of the recommendations for connection latching implementors is to make peer CERT payloads (certificates) available to the applications.
接続ラッチの実装者の推奨事項の1つは、アプリケーションでピア証明書のペイロード（証明書）を利用できるようにすることです。
Additionally, raw public keys are likely to be used in the construction of channel bindings for IPsec channels (see [IPSEC-CB]), and they must be available, in any case, in order to implement leap-of-faith at the application layer (see [RFC5386] and [RFC5387]).
さらに、生のパブリックキーは、IPSECチャネル用のチャネルバインディングの構築に使用される可能性が高く（[IPSEC-CB]を参照）、いずれにしても、アプリケーションに不利な信念を実装するために利用可能でなければなりません。層（[RFC5386]および[RFC5387]を参照）。
Certificates and raw public keys are large bit strings, too large to be reasonably kept in kernel-mode implementations of connection latching (which will likely be the typical case). Such implementations should intern peer IDs in a user-mode database and use small integers to refer to them from the kernel-mode SAD and LD. Corruption of such a database is akin to corruption of the SAD/LD; in the event of corruption, the implementation MUST act as though all ESTABLISHED and BROKEN connection latches are administratively transitioned to the CLOSED state. Implementations without IPsec APIs MAY hash peer IDs and use the hash to refer to them, preferably using a strong hash algorithm.
証明書と生のパブリックキーは大きなビット文字列であり、大きすぎて接続ラッチのカーネルモード実装で合理的に保持するには容易に保持されません（これはおそらく典型的なケースになります）。このような実装は、ユーザーモードデータベースにピアIDをインターンし、小整数を使用してカーネルモードSADおよびLDからそれらを参照する必要があります。そのようなデータベースの破損は、SAD/LDの腐敗に似ています。腐敗が発生した場合、実装は、すべての確立された壊れた接続ラッチが管理上閉じた状態に移行されているかのように動作する必要があります。IPSEC APIのない実装は、ハッシュピアIDを使用し、ハッシュを使用してそれらを参照することができます。できれば強力なハッシュアルゴリズムを使用します。
At its bare minimum, connection latching is a passive layer atop IPsec that warns ULPs of SPD and SAD changes that are incompatible with the SPD/SAD state that was applicable to a connection when it was established.
最小限の場合、接続ラッチはIPSECの上のパッシブ層であり、SPDのULPとSADの変化を警告します。
There are some optional features, such as (abstract) APIs. Some of these features make connection latching a somewhat more active feature. Specifically, the optional logical SPD updates described in Section 2.3 and the optional protection/bypass feature described in the following sub-section.
（要約）APIなどのオプションの機能がいくつかあります。これらの機能のいくつかは、接続ラッチをややアクティブな機能にします。具体的には、セクション2.3で説明されているオプションの論理SPD更新と、次のサブセクションで説明されているオプションの保護/バイパス機能。
Given IPsec APIs, an application could request that a connection's packets be protected where they would otherwise be bypassed; that is, applications could override BYPASS policy. Locally privileged applications could request that their connections' packets be bypassed rather than protected; that is, privileged applications could override PROTECT policy. We call this "optional protection".
IPSEC APIを考慮すると、アプリケーションは、接続のパケットをバイパスされる場所で保護することを要求できます。つまり、アプリケーションはバイパスポリシーをオーバーライドする可能性があります。地元の特権アプリケーションは、接続のパケットを保護するのではなくバイパスすることを要求できます。つまり、特権アプリケーションは保護ポリシーをオーバーライドする可能性があります。これを「オプションの保護」と呼びます。
Both native IPsec models of connection latching can be extended to support optional protection. With the model described in Section 2.4, optional protection comes naturally: the IPsec layer need only check that the protection requested for outbound packets meets or exceeds (as determined by local or system policy) the quality of protection, if any, required by the SPD. In the case of the model described in Section 2.3, enforcement of minimum protection requirements would be done by the IPsec key manager via the connection latch state machine.
接続ラッチングのネイティブIPSECモデルは、オプションの保護をサポートするために拡張できます。セクション2.4で説明されているモデルでは、オプションの保護が自然に行われます。IPSECレイヤーは、アウトバウンドパケットの保護が（ローカルポリシーまたはシステムポリシーによって決定される）を満たしているか、それを超えているかを確認する必要があります。。セクション2.3で説明されているモデルの場合、最小保護要件の施行は、接続ラッチ状態マシンを介してIPSECキーマネージャーによって行われます。
When an application requests, and local policy permits, either additional protection or bypassing protection, then the SPD MUST be logically updated such that there exists a suitable SPD entry protecting or bypassing the exact 5-tuple recorded by the corresponding connection latch. Such logical SPD updates MUST be made at connection latch creation time, and MUST be made atomically (see the note about race conditions in Section 2.3). Such updates of the SPD MUST NOT survive system crashes or reboots.
アプリケーションが要求し、ローカルポリシーが追加の保護またはバイパスを要求する場合、SPDは、対応する接続ラッチによって記録された正確な5タプルを保護またはバイパスする適切なSPDエントリが存在するように論理的に更新する必要があります。このような論理SPD更新は、接続ラッチの作成時間で行う必要があり、原子的に行う必要があります（セクション2.3の人種条件についてのメモを参照）。SPDのこのような更新は、システムのクラッシュや再起動に耐えてはなりません。
Some connection-oriented ULPs, specifically TCP, support simultaneous connections (where two clients connect to each other, using the same 5-tuple, at the same time). Connection latching supports simultaneous latching as well, provided that the key exchange protocol does not make it impossible.
一部の接続指向のULP、特にTCPは、同時接続をサポートします（同じ5タプルを使用して同時に2つのクライアントが互いに接続します）。キーエクスチェンジプロトコルが不可能にならない場合、接続ラッチングも同時にラッチングをサポートします。
Consider two applications doing a simultaneous TCP connect to each other and requesting an IPsec channel. If they request the same connection latching parameters, then the connection and channel should be established as usual. Even if the key exchange protocol in use doesn't support simultaneous IKE_SA and/or child SA establishment, provided one peer's attempt to create the necessary child SAs succeeds, then the other peer should be able to notice the new SAs immediately upon failure of its attempts to create the same.
同時にTCP接続を互いに接続し、IPSECチャネルを要求する2つのアプリケーションを検討してください。同じ接続ラッチパラメーターを要求する場合、接続とチャネルを通常どおり確立する必要があります。使用中のキーエクスチェンジプロトコルが、必要な子SASを作成するための1人のピアの試みを条件に同時にIKE_SAおよび/またはチャイルドSAの設立をサポートしていなくても、他のピアはその失敗の直後に新しいSASにすぐに気付くことができるはずです同じものを作成しようとします。
If, however, the two peer applications were to request different connection latching parameters, then the connection latch must fail on one end or on both ends.
ただし、2つのピアアプリケーションが異なる接続ラッチパラメーターを要求する場合、接続ラッチは一端または両端で故障する必要があります。
The following sub-sections describe connection latching for each of three transport protocols. Note that for TCP and UDP, there is nothing in the following sections that should not already be obvious from the remainder of this document. The section on SCTP, however, specifies details related to SCTP multi-homing, that may not be as obvious.
次のサブセクションでは、3つの輸送プロトコルのそれぞれの接続ラッチングについて説明します。TCPとUDPの場合、次のセクションには、このドキュメントの残りの部分からまだ明らかではないはずではないことに注意してください。ただし、SCTPのセクションでは、SCTPマルチホミングに関連する詳細を指定していますが、それほど明白ではない場合があります。
IPsec connection latch creation/release for TCP [RFC0793] connections is triggered when:
TCP [RFC0793]のIPSEC接続ラッチの作成/リリースは次の場合にトリガーされます。
o a TCP listener end-point is created (e.g., when the BSD Sockets listen() function is called on a socket). This should cause the creation of a LISTENER connection latch.
o TCPリスナーのエンドポイントが作成されます（たとえば、BSD Socketsの聞き取り（）関数がソケットで呼び出されるとき）。これにより、リスナー接続ラッチが作成されます。
o a TCP SYN packet is received on an IP address and port number for which there is a listener. This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o TCP synパケットは、リスナーがいるIPアドレスとポート番号で受信されます。これにより、確立されたまたは壊れた接続ラッチが作成されるはずです。
o a TCP SYN packet is sent (e.g., as the result of a call to the BSD Sockets connect() function). This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o TCP synパケットが送信されます（たとえば、BSD Sockets Connect（）関数への呼び出しの結果として）。これにより、確立されたまたは壊れた接続ラッチが作成されるはずです。
o any state transition of a TCP connection to the CLOSED state will cause a corresponding transition for any associated connection latch to the CLOSED state as well.
o 閉じた状態へのTCP接続の状態移行は、閉じた状態への関連する接続ラッチに対しても対応する遷移を引き起こします。
See Section 5.5 for how to handle latch transitions to the BROKEN state.
壊れた状態へのラッチ遷移を処理する方法については、セクション5.5を参照してください。
UDP [RFC0768] is a connection-less transport protocol. However, some networking APIs (e.g., the BSD Sockets API) allow for emulation of UDP connections. In this case, connection latching can be supported using either model given above. We ignore, in this section, the fact that the connection latching model described in Section 2.4 can support per-datagram latching by extending its packet tagging interfaces to the application.
UDP [RFC0768]は、接続のないトランスポートプロトコルです。ただし、一部のネットワーキングAPI（BSDソケットAPIなど）により、UDP接続のエミュレーションが可能です。この場合、上記のいずれかのモデルを使用して接続ラッチをサポートできます。このセクションでは、セクション2.4で説明されている接続ラッチモデルが、パケットタグ付けインターフェイスをアプリケーションに拡張することにより、ダタグラムごとのラッチをサポートできるという事実を無視します。
IPsec connection latch creation/release for UDP connections is triggered when:
UDP接続のIPSEC接続ラッチの作成/リリースは、次の場合にトリガーされます。
o an application creates a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o アプリケーションは、UDP「接続」を作成します。これにより、確立されたまたは壊れた接続ラッチが作成されるはずです。
o an application destroys a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch.
o アプリケーションは、UDP「接続」を破壊します。これにより、確立されたまたは壊れた接続ラッチが作成されるはずです。
When a connection latch transitions to the BROKEN state and the application requested (or system policy dictates it) that the connection be broken, then UDP should inform the application, if there is a way to do so, or else it should wait, allowing the application-layer keepalive/timeout strategy, if any, to time out the connection.
接続ラッチが壊れた状態に移行し、アプリケーションが接続を壊すことを要求した（またはシステムポリシーがそれを指定する）場合、UDPはアプリケーションに通知する必要があります。アプリケーションレイヤーのKeepalive/Timeout戦略がある場合は、接続をタイムアウトします。
What constitutes an appropriate action in the face of administrative transitions of connection latches to the CLOSED state depends on whether the implementation's "connected" UDP sockets API provides a way for the socket to return an error indicating that it has been closed.
閉じた状態への接続ラッチの管理遷移に直面して適切なアクションを構成するものは、実装の「接続された」UDPソケットAPIが、ソケットが閉じられていることを示すエラーを返す方法を提供するかどうかによって異なります。
Implementations based on either model of connection latching can provide applications with datagram-tagging APIs based on those described in Section 2.4. Implementations UDP with of the normative model of IPsec connection latching have to confirm, on output, that the application provided 5-tuple agrees with the application-provided connection latch; on input, UDP can derive the tag by searching for a connection latch matching incoming datagram's 5-tuple.
接続ラッチングのいずれかのモデルに基づく実装は、セクション2.4で説明されているものに基づいて、データグラムタグのAPIでアプリケーションを提供できます。IPSEC接続ラッチの規範モデルを使用した実装UDPは、出力で5タプルが提供されたアプリケーションが提供する接続ラッチと同意していることを確認する必要があります。入力では、UDPは、着信データグラムの5タプルと一致する接続ラッチを検索することにより、タグを導き出すことができます。
SCTP [RFC4960], a connection-oriented protocol is similar, in some ways, to TCP. The salient difference, with respect to connection latching, between SCTP and TCP is that SCTP allows each end-point to be identified by a set of IP addresses, though, like TCP, each end-point of an SCTP connection (or, rather, SCTP association) can only have one port number.
SCTP [RFC4960]、接続指向のプロトコルは、ある意味でTCPに類似しています。接続ラッチに関する顕著な違いは、SCTPとTCPの間の顕著な違いは、SCTPを使用すると、各エンドポイントを一連のIPアドレスで識別できることですが、TCPのように、SCTP接続の各エンドポイント（またはむしろ、むしろ、SCTP Association）は、1つのポート番号のみを持つことができます。
We can represent the multiplicity of SCTP association end-point addresses as a multiplicity of 5-tuples, each of which with its own connection latch. Alternatively, we can extend the connection latch object to support a multiplicity of addresses for each end-point. The first approach is used throughout this document; therefore, we will assume that representation.
SCTP Associationのエンドポイントアドレスの多様性を5タプルの多様性として表すことができます。または、接続ラッチオブジェクトを拡張して、各エンドポイントの多数のアドレスをサポートすることもできます。最初のアプローチは、このドキュメント全体で使用されます。したがって、その表現を想定します。
Of course, this approach results in N x M connection latches for any SCTP associations (where one end-point has N addresses and the other has M); whereas the alternative requires one connection latch per SCTP association (with N + M addresses). Implementors may choose either approach.
もちろん、このアプローチにより、任意のSCTP関連（1つのエンドポイントにはnアドレスがあり、もう1つにはmがあります）のn x m接続ラッチが得られます。一方、代替案には、SCTPアソシエーションごとに1つの接続ラッチが必要です（N Mアドレスを含む）。実装者はどちらのアプローチを選択できます。
IPsec connection latch creation/release for SCTP connections is triggered when:
sctp接続のIpsec接続ラッチの作成/リリースは、次の場合にトリガーされます。
o an SCTP listener end-point is created (e.g., when the SCTP sockets listen() function is called on a socket). This should cause the creation of a LISTENER connection latch for each address of the listener.
o SCTPリスナーのエンドポイントが作成されます（たとえば、SCTP Socketsの聞き取り（）関数がソケットで呼び出されたとき）。これにより、リスナーの各アドレスに対してリスナー接続ラッチが作成されます。
o an SCTP INIT chunk is received on an IP address and port number for which there is a listener. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches, one for each distinct 5-tuple given the client and server's addresses.
o SCTP initチャンクは、リスナーがいるIPアドレスとポート番号で受信されます。これにより、クライアントとサーバーのアドレスが与えられた5タプルごとに1つ以上の確立または破損した接続ラッチが作成されます。
o an SCTP INIT chunk is sent (e.g., as the result of a call to the SCTP sockets connect() function). This should cause the creation of one or more ESTABLISHED or BROKEN connection latches.
o SCTP initチャンクが送信されます（たとえば、SCTP Sockets Connect（）関数への呼び出しの結果として）。これにより、1つ以上の確立または破損接続ラッチが作成されるはずです。
o an SCTP Address Configuration Change Chunk (ASCONF) [RFC5061] adding an end-point IP address is sent or received. This should cause the creation of one or more ESTABLISHED or BROKEN connection latches.
o SCTPアドレス構成変更チャンク（ASCONF）[RFC5061]エンドポイントIPアドレスの追加が送信または受信されます。これにより、1つ以上の確立または破損接続ラッチが作成されるはずです。
o any state transition of an SCTP association to the CLOSED state will cause a corresponding transition for any associated connection latches to the CLOSED state as well.
o 閉じた状態へのSCTP関連の状態移行は、閉じた状態への関連する接続ラッチの対応する遷移を引き起こします。
o an SCTP ASCONF chunk [RFC5061] deleting an end-point IP address is sent or received. This should cause one or more associated connection latches to be CLOSED.
o 末点IPアドレスを削除するSCTP ASCONFチャンク[RFC5061]が送信または受信されます。これにより、1つ以上の関連する接続ラッチが閉じられます。
See Section 5.5 for how to handle latch transitions to the BROKEN state.
壊れた状態へのラッチ遷移を処理する方法については、セクション5.5を参照してください。
There are several ways to handle connection latch transitions to the BROKEN state in the case of connection-oriented ULPs like TCP or SCTP:
TCPやSCTPなどの接続指向ULPの場合、壊れた状態への接続ラッチ遷移を処理する方法はいくつかあります。
a. Wait for a possible future transition back to the ESTABLISHED state, until which time the ULP will not move data between the two end-points of the connection. ULP and application timeout mechanisms will, of course, be triggered in the event of too lengthy a stay in the BROKEN state. SCTP can detect these timeouts and initiate failover, in the case of multi-homed associations.
a. 確立された状態に戻る可能性のある将来の移行を待ちます。これは、ULPが接続の2つのエンドポイント間でデータを移動しないまでです。もちろん、ULPとアプリケーションのタイムアウトメカニズムは、壊れた状態で長すぎる滞在があった場合にトリガーされます。SCTPは、これらのタイムアウトを検出し、マルチホームの関連付けの場合にフェイルオーバーを開始できます。
b. Act as though the connection has been reset (RST message received, in TCP, or ABORT message received, in SCTP).
b. 接続がリセットされているかのように動作します（TCPで受信したRSTメッセージ、またはSCTPで受信した中止メッセージ）。
c. Act as though an ICMP destination unreachable message had been received (in SCTP such messages can trigger path failover in the case of multi-homed associations).
c. ICMP宛先の到達不可能なメッセージが受信されたかのように動作します（SCTPでは、そのようなメッセージは、マルチホームの関連付けの場合、パスフェールオーバーをトリガーする可能性があります）。
Implementations SHOULD provide APIs that allow applications either 1) to be informed (asynchronously or otherwise) of latch breaks so that they may choose a disposition, and/or 2) to select a specific disposition a priori (before a latch break happens). The options for disposition are wait, close, or proceed with path failover.
実装では、1）ラッチブレークの通知（非同期またはその他の）のいずれかのアプリケーションを可能にするAPIを提供する必要があります。処分のオプションは、待機、閉鎖、またはパスフェールオーバーの進行です。
Implementations MUST provide a default disposition in the event of a connection latch break. Though (a) is clearly the purist default, we RECOMMEND (b) for TCP and SCTP associations where only a single path remains (one 5-tuple), and (c) for multi-homed SCTP associations. The rationale for this recommendation is as follows: a conflicting SA most likely indicates that the original peer is gone and has been replaced by another, and it's not likely that the original peer will return; thus, failing faster seems reasonable.
実装は、接続ラッチブレークが発生した場合にデフォルトの処分を提供する必要があります。（a）は明らかに純粋主義者のデフォルトですが、（b）TCPおよびSCTP関連の場合は（b）単一のパスのみが残っている（1つの5タプル）、（c）マルチホームのSCTP関連付けにはお勧めします。この推奨事項の理論的根拠は次のとおりです。矛盾するSAは、元のピアがなくなって別のピアに置き換えられていることを示しており、元のピアが戻ってくる可能性が高いことを示しています。したがって、より速く失敗すると、合理的に思えます。
Note that our recommended default behavior does not create off-path reset denial-of-service (DoS) attacks. To break a connection latch, an attacker would first have to successfully establish an SA, with one of the connection's end-points, that conflicts with the connection latch and that requires multiple messages to be exchanged between that end-point and the attacker. Unless the attacker's chosen victim end-point allows the attacker to claim IP address ranges for its SAs, then the attacker would have to actually take over the other end-point's addresses, which rules out off-path attacks.
推奨されるデフォルトの動作は、オフパスリセットリセットサービス拒否（DOS）攻撃を作成しないことに注意してください。接続ラッチを破るには、攻撃者が最初に接続のエンドポイントの1つを使用してSAを正常に確立する必要があります。これは、接続ラッチと競合し、そのエンドポイントと攻撃者の間で複数のメッセージを交換する必要があります。攻撃者が選択した被害者のエンドポイントが、攻撃者がSASのIPアドレス範囲を請求することを許可しない限り、攻撃者は実際に他のエンドポイントのアドレスを引き継ぐ必要があります。
Connection latching effectively adds a mechanism for dealing with the existence, in the SAD, of multiple non-equivalent child SAs with overlapping traffic selectors. This mechanism consists of, at minimum, a local notification of transport protocols (and, through them, applications) of the existence of such a conflict that affects a transport layer's connections. Affected transports are also notified when the conflict is cleared. The transports must drop inbound packets, and must not send outbound packets for connections that are affected by a conflict. In this minimal form, connection latching is a passive, local feature layered atop IPsec.
接続ラッチは、重複するトラフィックセレクターを備えた複数の非等価な子供SAの存在に対処するためのメカニズムを効果的に追加します。このメカニズムは、少なくとも、輸送層の接続に影響するそのような競合の存在の輸送プロトコル（およびそれらを通じて）のローカル通知（およびそれらを通じて）で構成されています。紛争が解消されたときに、影響を受ける輸送も通知されます。トランスポートは、インバウンドパケットを落とす必要があり、競合の影響を受ける接続用にアウトバウンドパケットを送信してはなりません。この最小限の形では、接続ラッチングは、IPSECの上に階層化された受動的なローカル機能です。
We achieve this by adding a new type of IPsec database, the Latch Database (LD), containing objects that represent a transport protocol's interest in protecting a given packet flow from such conflicts. The LD is managed in conjunction with updates to the SAD and the SPD, so that updates to either that conflict with established connection latches can be detected. For some IPsec implementations, this may imply significant changes to their internals. However, two different models of connection latching are given, and we hope that most native IPsec implementors will find at least one model to be simple enough to implement in their stack.
これを実現し、新しいタイプのIPSECデータベース、ラッチデータベース（LD）を追加します。これは、そのような競合から特定のパケットフローを保護することにトランスポートプロトコルの関心を表すオブジェクトを含むものです。LDは、SADおよびSPDの更新と組み合わせて管理されているため、確立された接続ラッチとの競合のいずれかの更新を検出できます。一部のIPSEC実装では、これは内部の大幅な変化を意味する場合があります。ただし、接続ラッチの2つの異なるモデルが示されており、ほとんどのネイティブIPSEC実装者が、少なくとも1つのモデルがスタックに実装するのに十分なシンプルであることを願っています。
This notion of conflicting SAs and how to deal with the situation does not modify the basic IPsec architecture -- the feature of IPsec that allows such conflicts to arise remains, and it is up to the transport protocols and applications to select whether and how to respond to them.
矛盾するSASのこの概念と状況に対処する方法は、基本的なIPSECアーキテクチャを変更するものではありません。そのような競合を発生させるIPSECの特徴は残り、輸送プロトコルとアプリケーションが次々と対応するかどうか、どのように応答するかを選択します。彼らへ。
There are, however, interesting corner cases in the normative model of connection latching that implementors must be aware of. The notes in Section 2.3.1 are particularly relevant.
ただし、接続ラッチの規範モデルには、実装者が認識している必要がある興味深いコーナーケースがあります。セクション2.3.1のノートは特に関連しています。
Section 3 describes optional features of connection latching where the key manager takes on a somewhat more active, though still local, role. There are two such features: optional protect/bypass and preservation of "logical" SPD entries to allow latched connections to remain in the ESTABLISHED state in the face of adverse administrative SPD (but not SAD) changes. These two features interact with administrative interfaces to IPsec; administrators must be made aware of these features, and they SHOULD be given a way to break ESTABLISHED connection latches. Also, given recent trends toward centralizing parts of IPsec policy, these two features can be said to have non-local effects where they prevent distributed policy changes from taking effect completely.
セクション3では、キーマネージャーが、まだローカルな役割ではあるが、やや活発な役割を引き受ける接続ラッチのオプションの機能について説明します。このような機能は2つあります。オプションの保護/バイパスと「論理」SPDエントリの保存と、不利な管理SPD（ただし、悲しいことではない）の変更に直面して、定着した状態にラッチされた接続が留まることができます。これらの2つの機能は、管理インターフェイスとIPSECへの相互作用です。管理者はこれらの機能を認識する必要があり、確立された接続ラッチを破る方法を与えられる必要があります。また、IPSECポリシーの一部を集中化するための最近の傾向を考えると、これらの2つの機能は、分散したポリシーの変更が完全に有効になるのを防ぐ非ローカルな効果を持つと言えます。
Connection latching is not negotiated. It is therefore possible for one end of a connection to be using connection latching while the other does not; in which case, it's possible for policy changes local to the non-latched end to cause packets to be sent unprotected. The end doing connection latching will reject unprotected packets, but if they bear sensitive data, then the damage may already be done. Therefore, applications SHOULD check that both ends of a connection are latched (such a check is implicit for applications that use channel binding to IPsec).
接続ラッチは交渉されません。したがって、接続の一方の端が接続ラッチを使用することは可能ですが、もう一方の端はそうではありません。その場合、ポリシーがラッチングされていない端からローカルな変更を変更して、パケットが保護されていないと送信される可能性があります。接続ラッチの終了は、保護されていないパケットを拒否しますが、敏感なデータを持つ場合、損傷はすでに発生する可能性があります。したがって、アプリケーションは、接続の両端がラッチされていることを確認する必要があります（このようなチェックは、IPSECにチャネルバインディングを使用するアプリケーションに暗黙的です）。
Connection latching protects individual connections from weak peer ID<->address binding, IPsec configuration changes, and from configurations that allow multiple peers to assert the same addresses. But connection latching does not ensure that any two connections with the same end-point addresses will have the same latched peer IDs. In other words, applications that use multiple concurrent connections between two given nodes may not be protected any more or less by use of IPsec connection latching than by use of IPsec alone without connection latching. Such multi-connection applications can, however, examine the latched SA parameters of each connection to ensure that all concurrent connections with the same end-point addresses also have the same end-point IPsec IDs.
接続ラッチは、個々の接続を弱いピアID <->アドレスバインディング、IPSEC構成の変更、および複数のピアが同じアドレスを主張できる構成から保護します。ただし、接続ラッチは、同じエンドポイントアドレスを持つ2つの接続が同じラッチのピアIDを持つことを保証しません。言い換えれば、2つの指定されたノード間で複数の同時接続を使用するアプリケーションは、接続ラッチなしでIPSECのみを使用するよりもIPSEC接続ラッチを使用することにより、それ以上保護されない場合があります。ただし、このようなマルチ接続アプリケーションは、各接続のラッチされたSAパラメーターを調べて、同じエンドポイントアドレスとのすべての同時接続が同じエンドポイントIPSEC IDを持つようにすることができます。
Connection latching protects against TCP RST attacks. It does not help, however, if the original peer of a TCP connection is no longer available (e.g., if an attacker has been able to interrupt the network connection between the two peers).
接続ラッチは、TCP RST攻撃から保護されます。ただし、TCP接続の元のピアが使用できなくなった場合（たとえば、攻撃者が2人のピア間のネットワーク接続を中断できた場合）。
IPsec channels are a prerequisite for channel binding [RFC5056] to IPsec. Connection latching provides such channels, but the channel bindings for IPsec channels (latched connections) are not specified herein -- that is a work in progress [IPSEC-CB].
IPSECチャネルは、IPSECに対するチャネル結合[RFC5056]の前提条件です。接続ラッチはそのようなチャネルを提供しますが、IPSECチャネルのチャネルバインディング（ラッチング接続）は本明細書では指定されていません。これは進行中の作業です[IPSEC-CB]。
Without IPsec APIs, connection latching provides marginal security benefits over traditional IPsec. Such APIs are not described herein; see [ABSTRACT-API].
IPSEC APIがなければ、接続ラッチは従来のIPSECよりも限界的なセキュリティ給付を提供します。このようなAPIは本明細書では説明されていません。[要約-API]を参照してください。
Connection latch state transitions to the BROKEN state can be triggered by on-path attackers and any off-path attackers that can attack routers or cause an end-point to accept an ICMP Redirect message. Connection latching protects applications against on- and off-path attackers in general, but not against on-path denial of service specifically.
壊れた状態への接続ラッチ状態の遷移は、パスオンパス攻撃者と、ルーターを攻撃したり、エンドポイントにICMPリダイレクトメッセージを受け入れることができるパス外の攻撃者によって引き起こされます。接続ラッチは、一般的にはオンパスおよびオフパスの攻撃者に対してアプリケーションを保護しますが、具体的にはパスの拒否に対してではありません。
Attackers can break latches if they can trigger DPD on one or both end-points and if they cause packets to not move between two end-points. Such attacks generally require that the attacker be on-path; therefore, we consider it acceptable to break latches when DPD concludes that a peer is dead or rebooted.
攻撃者は、一方または両方のエンドポイントでDPDをトリガーでき、パケットが2つのエンドポイント間で移動しない場合、ラッチを破ることができます。そのような攻撃では、一般に、攻撃者がパスであることが必要です。したがって、DPDがピアが死んでいるか再起動していると結論付けた場合、ラッチを破ることは許容できると考えます。
Attackers can also break latches if IPsec policy on a node allows the attacker to use the IP address of a peer of that node. Such configurations are expected to be used in conjunction with BTNS in general. Such attacks generally require that the attacker be on-path.
攻撃者は、ノードのIPSECポリシーにより、攻撃者がそのノードのピアのIPアドレスを使用できる場合、ラッチを破ることもできます。このような構成は、一般にBTNと組み合わせて使用されることが期待されています。そのような攻撃では、一般に、攻撃者がパスであることが必要です。
The author thanks Michael Richardson for all his help, as well as Stephen Kent, Sam Hartman, Bill Sommerfeld, Dan McDonald, Daniel Migault, and many others who've participated in the BTNS WG or who've answered questions about IPsec, connection latching implementations, etc.
著者は、マイケル・リチャードソンのすべての助けに感謝し、スティーブン・ケント、サム・ハートマン、ビル・ゾンマーフェルド、ダン・マクドナルド、ダニエル・ミゴール、その他BTNS WGに参加した、またはIPSECについての質問に答えた他の多くの人々、接続ラッチング実装など
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）動的アドレス再構成」、RFC 5061、2007年9月。
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[RFC5386]ウィリアムズ、N。およびM.リチャードソン、「より良いセキュリティ：IPSECの無認定モード」、RFC 5386、2008年11月。
[ABSTRACT-API] Richardson, M., "An abstract interface between applications and IPsec", Work in Progress, November 2008.
[要約-API]リチャードソン、M。、「アプリケーションとIPSECの間の抽象インターフェース」、2008年11月、Work in Progress。
[IPSEC-CB] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys", Work in Progress, April 2008.
[IPSEC-CB]ウィリアムズ、N。、「IKEV2およびパブリックキーを使用したIPSEC用のエンドポイントチャネルバインディング」、2008年4月、進行中の作業。
[IP_SEC_OPT.man] Sun Microsystems, Inc., "ipsec(7P) man page, Solaris 10 Reference Manual Collection".
[IP_SEC_OPT.MAN] SUN Microsystems、Inc。、「IPSEC（7P）Man Page、Solaris 10リファレンスマニュアルコレクション」。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズ、N。、「チャンネルを保護するためのチャネルバインディングの使用について」、RFC 5056、2007年11月。
[RFC5387] Touch, J., Black, D., and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008.
[RFC5387] Touch、J.、Black、D。、およびY. Wang、「より良いセキュリティ（BTNS）の問題と適用声明」、RFC 5387、2008年11月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406] Bellovin、S。、「IPSECバージョン2の使用を指定するためのガイドライン」、BCP 146、RFC 5406、2009年2月。
[USING-IPSEC] Dondeti, L. and V. Narayanan, "Guidelines for using IPsec and IKEv2", Work in Progress, October 2006.
[IPSECを使用] Dondeti、L。およびV. Narayanan、「IPSECおよびIKEV2を使用するためのガイドライン」は、2006年10月に進行中です。
Author's Address
著者の連絡先
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラス・ウィリアムズ・サンマイクロシステムズ5300リアタトレースCTオースティン、テキサス78727 US
EMail: Nicolas.Williams@sun.com