Network Working Group N. Williams
Request for Comments: 5660 Sun
Category: Standards Track October 2009
IPsec Channels: Connection Latching
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セキュリティアソシエーション（SA）のパラメータに（パケットフロー）「接続」をラッチすることにより、「チャンネル」を作成するようにIPsecを使用したアプリケーションおよびトランスポートプロトコルをインタフェースする方法を、抽象的に、指定します。接続のラッチは、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を使用した結果として、意図しないピアに流れます。ピア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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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は、上位層プロトコル（のULP）に関連付けられたステートフルパケットフローに対してほとんど又は全くに関してパケットを保護します。これは、セッションのIPsec構成で、複数のピアが同じアドレスにアクセスできるように設定を変更することに伴うリスクへの保護、および/またはピアのIDとそのアドレスの弱い会合のためにIPsecに依存するアプリケーションを公開します。後者は何もセキュリティ（BTNS）[RFC5387]よりも優れが使用される特にIPsecのピア認証データベース（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を使用するアプリケーションは、[-IPSecを使用して様々なエンドポイントのローカルポリシーが適切に[RFC5406]を設定されていることを確認する必要があります。主要な結果は、例えば、アプリケーションがまだホスト名を使用しなければならないということです（と - そこにこれを行うには、標準のアプリケーション・プログラミング・インターフェース（API）は、（例えば[IP_SEC_OPT.man]などの非標準のAPIは、ありますが）ありません例えば、ドメインネームシステム[RFC1034]）と既存のAPIでのIPアドレスと、彼らが検証することができないかもしれないIPsec構成に依存しなければなりません。必要なセキュリティポリシーデータベースの側面（SPD）の設定を指定することに加えて、アプリケーションの仕様にも強く、個々のIPsecアイデンティティと資格情報（証明書、公開鍵、など）に個々のアドレスをバインドするため、PAD / SPDの構成に対処しなければなりません。
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に似ているのAPI（例えば、「BSDソケット」）、そのため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のチャンネル」、いくつかの文脈では、と）これらの「接続ラッチ」と呼びます。以下に説明する方法は、IPsecにのULPとアプリケーションをインタフェースすることによって、これを達成します。
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.
ラッチ接続は、本明細書中で指定されているように、任意のパケットフローのためのアプリケーションの要件に悪影響している変化を検出すると、（そのような同期ULPを警告することなどによって応じて反応する（SAD）SPDとセキュリティアソシエーションデータベースへの更新を見ることについて、主ですパケットの前にアプリケーションが）新しいポリシーの下で送信または受信することができます。いかなる状況下では、関連するパケットフロー、また、再起動の存続期間を超えて存続することができますどのような方法でラッチ接続によって変更されるIPsecポリシーのデータベースがあります。いかなる状況下ではPADはラッチ接続によって全く変更されます。接続ラッチのすべてのオプション機能が除外されている場合は、ラッチ接続は、彼らの働きでのULPとアプリケーションへの同期の警告を提供するために必要とされるよりも、これ以上侵入しない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ピア「ID」それは、インターネットキー交換（IKE）ピアID（例えば、ピアの証明書から派生IDだけでなく、証明書）ではなく、ピアのIPアドレスを参照して言及しています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
抽象関数名はすべて大文字で、括弧のペアで示されています。その説明では、引数は、角括弧で囲まれたオプションの引数で、括弧内に表示されます。 「 - >」と戻り値の説明があれば、値を返す、と関数の引数リストを以下で示されています。例えば、「FOO（3タプル、[メッセージ]）」に対し、二つの引数、それらの任意の一、何も返さないと「FOO」という名前の関数であろう「FOOBAR（ハンドル） - >状態は」関数であろう値を返す単一、必須の引数を持ちます。値タイプは、周囲のテキストで説明されています。
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のチャンネル」は、すべてのパケットがIPSecのSAによって保護されているTCP接続などのULP制御ブロックに関連付けられたパケットフローとなるようにピアのアイデンティティは、パケットフローの存続期間についても同様であるOであり;
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のチャンネルが作成されます。これは、ローカル操作の結果であり得る（例えば、CONNECT（））すなわち、送信するそのフローの初期発信パケットを引き起こす、またはそれがその流れのための第1 /開始パケットを受信した結果であり得る（例えば、 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チャネルが破壊されます。接続ラッチがULP、アプリケーションが通知された場合に、何らかの理由（下記参照）、維持することができない場合のIPsecチャネルは、「壊れた」とすることができます。
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;
トンネルモードVS Oトランスポートモード、
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];
ローカルID（O）ローカルIDは、IPsec処理モデル[RFC4301]とBTNS [RFC5386]に従って、ピアにアサート。
o Peer identity: the peer's asserted and authorized IDs, as per the IPsec processing model [RFC4301] and BTNS [RFC5386].
Oピア・アイデンティティ：ピアのアサートされ、許可IDは、IPsec処理モデルごととして、[RFC4301]とBTNS [RFC5386]。
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のチャンネルのパケットを保護SAは、期限が切れることと同等のSAで交換することで時間の経過とともに変化することがあり、またはそれらを再キーイングすることができます。 IPsecのチャンネルのパケットを保護するSAのセットは、それらが、チャネル（すなわち、SASのパラメータはチャネルにラッチされているものと一致しなければなりません）と合同でなければならないという事実以外のものによって関連する必要はありません。特に、様々な鍵交換プロトコルの動作の考察は、その後の設計とラッチ接続の機能に影響を与えることができないため、IPsecのチャンネルがのIKE_SAsと子SAの満了後も存続することが望ましいです。
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.
IPsecのチャンネルが望まれる場合、チャネルが確立されるまで、O、次いで、所与の接続のためのパケットを送ってはいけません。
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.
IPsecのチャンネルが望まれる場合、チャネルが確立されるまで、O、次いで、所与の接続のためのインバウンドパケットを受け入れてはいけません。すなわち、従来の対応の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.
IPsecのチャネルが確立されると、O、ラッチ接続のためのパケットは、保護されていない送信されず、ラッチのパラメータと一致していない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.
IPsecのチャネルが確立されると、O、ラッチ接続のためのパケットは、保護されていない受け入れられず、ラッチのパラメータと一致していない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に関するすべての関連および利用可能な情報を利用できるようにしなければなりません。これは、1つが使用されるピア証明書、およびそれを検証したトラストアンカー（必ずしも必要ではないが、全体の証明書検証鎖）を含みます。
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.
ラッチ接続は、トンネルモードSAを使用するたびにOようなプログラミング・インターフェースを提供する実装は、アプリケーションの内側及び外側ローカルおよびピアアドレスに利用できるようにすべきです。
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.
アプリケーションが明示的にIPsecチャネルを要求していないときOの実装は、デフォルトで自動的に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チャネルにラッチされたものと一致パラメータで子SAを確立中（起こるように、例えば、ネットワーク・パーティション）。通常の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として大きな表現を有する値）再始動、鍵管理プロセスに接続ラッチ状態のいくつかの側面を維持するに依存している場合、次いでこのような状態は、このようなプロセスの再起動時に復元されなければならない、または未処理の接続ラッチはCLOSED状態に移行する必要があります。
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.
IKEデッド・ピア検出（DPD）は、リモートピアが死んでいるか、再起動したと判断すれば、O、システムはそのピアとのすべての接続ラッチがirremediably壊れて検討すべきです。
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.
我々は2つのモデル、ネイティブのIPsec実装のためのIPsecチャンネルの規範的にそれらのいずれかを、説明します。規範モデルは、関数の形で抽象プログラミングインターフェイスに基づいているのULPと（基本的に、SADは、ラッチデータベース（LD）で増強）のIPsecの鍵管理コンポーネント間のコール。第2のモデルは、のULPおよび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をオフロードが、それがSA情報をホスト・プロセッサに渡された着信パケットにタグを付け、また、ホスト・プロセッサはとても発信パケットにタグを付けることはできませんネットワークインターフェイスカード（NIC）を用いて実装することができません。他のモデルは堅固「接続」の概念に関連付けられているので、拡張することができないが、同じモデルを容易に、接続されていないデータグラム「ソケット」とラッチ接続をサポートするように拡張することができます。二つのモデル間の他のわずかな違いがあるかもしれません。セキュリティ保証のいくつかのセットのための同等を確立しようとするのではなく、我々は代わりに規範的な一つであることが一つのモデルを選択してください。
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].
我々はまた、非ネイティブなバンプ・イン・スタック（BITS）として実装し、セキュリティゲートウェイ（SG）の実装のためのモデルを提供します。それは常に可能ではないかもしれないパケットフローの状態を、推定に依存する非ネイティブの実装のためのモデルをラッチ接続は、フル機能ではありません。 NOR非ネイティブの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と子SAは、「クライアント」（例えば、CONNECT（）BSDソケット関数の呼び出し元）によって開始され、時には「サーバ」（例えば、受け入れる（）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.
接続ラッチの5タプルに一致するトラフィックセレクタと狭い子SAを作成する場合、単一の暗号スイートにIKE保護品質交渉を制約することが可能です。そのため、実装は、そのような子SAの使用を要求するためのAPIを提供する必要があります。実装者は、狭い子SAの要求を意味するように、特定のQoPのためのアプリケーション要求を考慮すべきです。
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.
1つだけの流れ以上を包含するトラフィックセレクタとSAを使用する場合、システムは、暗号スイートのセットではなく、単一の暗号スイートをラッチすることができるかもしれません。このような場合には、実装は不確定として使用されたQoPを報告しなければなりません。
Connection latches can exist in any of the following five states:
接続ラッチは、次の5つのいずれかの状態で存在することができます。
o LISTENER
LISTENER O
o ESTABLISHED
O ESTABLISHED
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 BROKEN（SAが所定の接続ラッチとの競合、矛盾SPDの変更がなされてきた、またはDPDがトリガされ、ピアが死んだとみなさまたは再起動することが存在します）
o CLOSED (by the ULP, the application or administratively)
O CLOSED（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.
接続ラッチは、閉状態に移行することができるLISTENER状態で生まれすることができます。 LISTENER状態はTCP（および他のULP）の状態をLISTENに対応し、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.
接続ラッチも設立され、BROKEN状態で生まれ、いずれかの直接ULPのイニシアチブとき、またはを通じてイベントリスナーが（ESTABLISHEDまたはBROKENのいずれかの状態で）新しいラッチを作成するために、ラッチ原因となることが発生することができます。これらの状態はトラフィックフローの5タプルのためのアクティブな接続のラッチを表します。これら二つの状態の接続ラッチは、2つの状態の他に、ならびにCLOSED状態に遷移することができます。
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.
その所有者は、所有者が、この状態はつかの間であり、その場合には、遷移を引き起こした場合を除いて通知されるまで接続ラッチはCLOSED状態のまま。 CLOSED状態にESTABLISHEDや破損状態からの遷移は、典型的には、ラッチの所有者によって開始されるべきであるが、実装は、アクティブラッチを閉じる介して管理インターフェイスを提供すべきです。
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
そのトラフィックセレクタピアおよび/またはパラメータの競合ラッチによって結合されたものとラッチによって結合5タプルとを包含するSAD内のSAが存在する場合に、接続が切断状態への遷移をラッチします。 BROKEN状態への遷移はまた、ときに行わ
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.
SPDの変更は、それがラッチされ、接続のパケットがラッチされたものとは異なる保護パラメータを送信または受信することが原因となり発生します。 IKEv2のDPDは、リモートピアが死んでいるか、再起動したと判断する場合BROKEN状態に遷移も許可されています。 BROKEN状態への遷移は、常に関連する所有者に通知することになり。すべてのSAおよび/またはSPD競合がクリアされたときに接続が戻っESTABLISHEDにBROKEN状態遷移でラッチします。
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.)
ほとんどの状態遷移は、ラッチ所有者（のULP）の局所的な行動の結果です。唯一の例外は、次のとおりです。CLOSED状態にリスナーの状態でラッチからESTABLISHED状態に誕生、BROKEN状態に遷移し、BROKEN状態からESTABLISHEDに遷移し、行政の遷移。 （また、第2節では、再開の鍵管理プロセスに関する実装の注を参照）
The state diagram below makes use of conventions described in Section 1.1 and state transition events described in Section 2.3.
以下の状態図は、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.
このセクションでは、我々は、のULPとネイティブ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処理モデルは、異なるピアが、重複トラフィックセレクタとSAの同時存在を可能にします。このような挙動は、このモデルでは、直接ラッチ接続（セクション2を参照）の要件に違反します。私たちは、このような競合が発生したときに、接続ラッチが壊れて（と所有者が通知）を要求することによって、この問題に対処します。
The following INFORMATIVE figure illustrates this model and API in terms that are familiar to many implementors, though not applicable to all:
すべてに適用されていないが、次のINFORMATIVEの図は、多くの実装に精通しているという点で、このモデルと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タプル、[タイプと品質の保護パラメータ]） - >ラッチハンドル|エラー
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.
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つのタプルと一致するSAが作成された子ではなく、任意の確立された接続用ラッチの5タプル（ローカルアドレス、リモートアドレス、プロトコル、ローカルポート番号、およびリモートポート番号）は、その後、鍵マネージャは、新たに作成する場合ESTABLISHED状態の接続ラッチのオブジェクト。キーマネージャは、リスナーラッチの結果として作成された接続ラッチのリスナー・ラッチのホルダーを通知しなければなりません。以下の「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タプル、[タイプと品質の保護パラメータ]、[ピアID]、[ローカルID]） - >ラッチハンドル|エラー
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.
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の確立をトリガする、その後、出力パケットことを知ってもよい（MAY）。そのような実装は、本明細書に記載されていない、いわば、接続ラッチ状態マシン、「幼生」状態で追加、つかの間の状態を必要とし得ます。
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.)
最終的に接続ラッチは、いずれかの競合のために確立することができない、または全くSAが宛先アドレスのピアと確立することができないので、エラーがULPに戻された場合。 （キーマネージャはSAの確立を遅らせ、およびSAの確立が最終的に失敗した場合、キー管理者は、おそらく非同期に。これは、幼生の状態を使用して実装者がの世話をしなければならないことをいくつかの詳細の一つであるULPに通知する必要があります。）
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]).
キーマネージャは、それがESTABLISHED状態にあった場合には与えられたラッチと一致するすべての既存の子のSAを削除することができます。キーマネージャは、このようなSAを削除しない場合、それは情報の削除ペイロードを持つピアに知らせるべきである（IKEv2の[RFC4306]を参照）。
o FIND_LATCH(5-tuple) -> latch handle | error
O FIND_LATCH（5タプル） - >ラッチハンドル|エラー
Given a 5-tuple returns a latch handle (or an error).
与えられた5タプルは、ラッチハンドル（又はエラー）を返します。
o INQUIRE_LATCH(latch object handle) -> {latch state, latched parameters} | error
INQUIRE_LATCH（ラッチオブジェクトハンドル）O - > {ラッチ状態、ラッチされたパラメータ} |エラー
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 ALERT（ラッチオブジェクトハンドル、5タプル、新しい状態、[理由]）
Alerts a ULP as to an asynchronous state change for the given
connection latch and, optionally, provides a reason for the
change.
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の鍵マネージャは、ラッチ間の衝突を防止しなければならない、と次のように任意のラッチと、既存または提案子SAの間の競合を防止しなければなりません：
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.
そこに接続ラッチが要求された時点でSADに競合のSAが存在するか（リスナーラッチから）作成される場合は、O以外のリスナーの接続ラッチが作成されてはなりません。子ラッチの観点から相互に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提案（[RFC4306]のセクション2.9を参照）。それ以外の場合は、ラッチはBROKEN状態に移行しなければなりません。
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.
現存の接続ラッチと競合する子SAの提案は、競合を避けるために狭くすることができない場合は、O、キーマネージャは、接続ラッチを解除しホルダーに通知しなければならない（すなわち、ULP）矛盾のSAを受け入れる前に。
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.
最後に、キーマネージャは、ラッチされた接続のトラフィックに与えられる保護の品質を変更するだろうか、それを迂回思われるSPD変化に対してラッチ接続を保護しなければなりません。このような構成の変更が起こるとき、キー管理者は、次のいずれかの方法で応答しなければなりません。動作を実装するために必要なすべての接続が、所与のSPD変化と競合をラッチBROKEN状態に遷移することです。オプションの動作は、PROTECTエントリは、接続ラッチから採取した情報を処理にのみラッチ接続の5タプルと一致するトラフィックセレクタとSPD-Sの先頭に追加されたかのように論理的にSPDを更新することです。 SPDのような更新は、システムがクラッシュしたり、再起動後も存続してはなりません。
ULPs create latched connections by interfacing with IPsec as follows:
ULPは、次のように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.
ULPは3タプルリスナーラッチと一致5タプルの接続を開始するパケットを受信すると、Oは、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.
ULPリスナーは接続を拒否すると、O、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は、パケットの送信を停止しなければならなくて、それがバックESTABLISHEDに遷移するまで、影響を受ける接続のために、後続のすべての着信パケットをドロップしなければなりません。接続はパケットロスが発生しているかのように接続指向の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.
キーマネージャは、接続ラッチが管理CLOSED状態に遷移されたULPに通知する場合、O、次いで接続指向のULPは、接続がピアによってリセットされたかのように行動しなければなりません。コネクション型ではない、とのULPの実装は、その接続のために、すべての着信パケットを削除する必要があり、リセットをシミュレートすることによって、何のAPIを持っていないし、それ以上のパケットを送ってはいけません - アプリケーションがタイムアウトを検出し、それに応じて行動することが期待されます。
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.
接続ラッチのこのモデルの主な利点は、ハードウェアがのインデックスとインバウンドパケットのタグ付けをサポートしていません場合でも、（全部またはホストのSADのサブセットのために）ESP / AH処理をハードウェアで実装されたIPsec実装を収容していることですそれらを保護のSAに対応するSADエントリ。
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.
ULPは、着信パケットをドロップし、接続ラッチブレーク・メッセージの受信時に、すぐにパケットの送信を停止しなければなりません。そうしないと、ULPはなかった着信パケットからの接続のラッチで一貫保護された着信パケットを区別することができません。これは、適切なSAで保護された着信パケットをドロップ挙げられます。接続が安全で失敗したとして、セキュリティの観点から、無害、それは再送につながることができます - このようなパケットをドロップすると、IPレイヤで以下に他の場所で、ネットワーク上のパケット損失よりも、ビューのULPの観点から、違いはありません。
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が何であるかを決定するために、新しい子SAを開始する必要があります。ここでは、新しいSAのピアIDは、TCP SYNパケットを送信したピアのものと同じである保証はありません。 TCPは、その後、RSTで応答します間違った相手にSYN + ACKを送信します - 接続のラッチがしかし、新しいピアが反映されますので、新しいピアが悪意のあるであれば、それはすることができません：この競合状態は無害です古いピアのように見えます。したがって、この競合状態は無害です。
Consider several systems with a very simple PAD containing a single entry like 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.
今度は、二つのホストを考える、AとBは、ポート4000、および第3のホストを使用して通信したい、このネットワークでは、C、それが同じネットワーク内にもあるし、Aおよび/またはBを攻撃することを希望するすべての3つのホストは、資格情報を持っていますそして、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上のBにポート32800からの接続を開始するには聞いています。
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.
b）にのみAはC）のみBがない、ない、a）のAとBの両方のサポート接続ラッチ：私たちは3例を考えてみましょう。 Aは、ポート4000上のBへのTCP接続を開始すると、この例の目的のために、SADは、3つのすべてのホスト上に空です。
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がBと5タプル{TCP、A、32800、B、4000}の子SAの一対のIKE_SAを作成するためのIKEv2交換を開始し、その後、新たなラッチが確立さに作成されます状態。いつか後に、TCPはSPDごとに、A・ツー・B子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}ためのラッチを作成します。この時点で、子供のSAは、そのトラフィックセレクタこの5タプルを網羅し、他の競合SAはSADではありません作成されている、ので、この接続ラッチはESTABLISHED状態で作成されます。
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はA（すなわち、Bのアドレスを持っているふりをする）のman-in-the-middle攻撃をマウントするために、任意の時間をしようとすると、Aはその接続ラッチを作成した後、その後、AとCのSAは、接続が中断するラッチが発生します（私たちはTCPのコネクションラッチブレークのアプリケーションに通知することができたことで何のAPIを負いませんので）とTCP接続がリセットされます。 Cが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は、任意の時点でAにBを偽装することができるようになります。 AとBの間のトラフィックの平文を見なくても、Cは、RST攻撃などの攻撃にTCPシーケンス番号によって制限されます。 Bは、ラッチ接続をサポートしていない場合も同様に、その後、Cは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スタックの下に行くようにパケットをタグ付けに基づいてのULPと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.
このモデルでは、のULPは、接続ラッチオブジェクトおよび状態はなく、IPsecの鍵管理、ならびに有効ULPのTCB中の非相関SPDのサブセットをキャッシュを維持します。彼らは上に移動し、SAの識別子を持つスタック、ダウン、その後のULPが接続ラッチセマンティクスを施行することを可能にするよう、パケットにタグを付けます。これらのタグは、当然のことながら、ワイヤ上では表示されません。
The interface between the ULPs and IPsec interface is as follows:
以下の通りのULPと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.
IPsecの層タグoをすべてのインバウンド保護されたパケットは、パケットを保護された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レイヤが検索またはアウトバウンドパケット保護するための適切なSAを取得（ULPに通知する他のIPsecを、パケットをドロップ）するために使用するラッチパラメータ（ピアID、保護の質、等）のセットを指定するタグ;
* 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:
ULPは、次のように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.
ULPは、IPへの接続の開始パケットを通過すると、O、ULPは、SAについてのフィードバックがあれば、発信パケットを保護するために使用され、アプリケーションによって要求されたパラメータをラッチ指定することも要求します。パケットがIPSecで保護されている場合は、ULPは、SAの特定のパラメータは、接続のTCBでそれを保護するために使用され記録されます。
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.
ULPは、接続の開始パケットを受信すると、O、それはパケットの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:
SAパラメータは、接続のTCBに記録されると、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のタグを処理し、SAが入力されたパケットがの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は常に発信パケットが適切にアウトバウンドパケットにタグを付けることにより、ラッチ接続を一致させるのSAによって保護されることが要求されます。
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のTCBで、そのパケットタギング性質を通じて非相関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.
このモデルは、明示的なBROKEN接続ラッチ状態を持っていないことに注意してください。
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.
非ネイティブのIPsec実装、主にBITSとSGは、あまりにも、ラッチ接続を実装することができます。ネイティブのIPsecとビット間の一つの主な違いは、バンプ・イン・ワイヤ（BITW）、又はSG IPsecは、後者の場合には、エンドポイントでアプリケーションのためのAPIの欠如です。ないULPエンドポイントで：2.3節で説明したようにその結果、ラッチ管理インターフェイスのない用途が存在しないことができます。したがって、BITS / BITW / SGの実装は、パケット検査から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.
接続ラッチが壊れている場合、BITS / BITW / SGの実装では、影響を受けた接続のために、適切なパケット（例えば、TCP RSTパケット）を送信することによって、偽の接続リセットを有していてもよいです。
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.
すべてのステートフルミドルボックスと同じように、この方式は、アプリケーションと対話するためのミドルのできないことに苦しんでいます。例えば、接続死亡は確認することが困難な場合があります。 NOR結合アプリケーションがミドルボックスとそれについて（確実に）通信することができることなく、プロキシによって維持チャネルで動作するチャンネルができます。
One of the recommendations for connection latching implementors is to make peer CERT payloads (certificates) available to the applications.
接続ラッチ実装するための推奨事項の一つは、アプリケーションへのピアCERTペイロード（証明書）が利用できるようにすることです。
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-CB]を参照）のIPsecチャネルのチャネルバインディングの構築に使用される可能性があり、それらはアプリケーションにLEAP-の-信仰を実現するために、いずれの場合にも、利用可能でなければなりません層（[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の破損に似ています。すべて確立し、BROKEN接続ラッチが管理CLOSED状態に移行しているかのように破損した場合には、実装が行動しなければなりません。 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.
その最低限で、接続ラッチは、SPDののULP、それが確立された接続に適用可能であったSPD / SAD状態と互換性のないSAD変更を警告のIPsecの上に不動態層です。
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を考えると、アプリケーションは、彼らがそうでない場合はバイパスされるだろうどこの接続のパケットを保護することを要求することができます。つまり、アプリケーションは、BYPASSポリシーをオーバーライドすることができます。ローカルの特権のアプリケーションは、その接続パケットがバイパスではなく、保護されることを要求することができます。つまり、特権のアプリケーションがPROTECTポリシーをオーバーライドすることができます。私たちは、この「オプションの保護」と呼びます。
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節で説明したモデルでは、オプションの保護が自然に来る：SPDによって要求される、任意の場合の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、（2つのクライアントが同時に、同じ5-タプルを使用して、お互いに接続）の同時接続をサポートします。接続のラッチは、鍵交換プロトコルが、それは不可能にしないことを提供するだけでなくラッチ同時サポートしています。
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チャネルを要求する二つのアプリケーションを考えてみましょう。彼らはパラメータをラッチ同じ接続を要求する場合、接続とチャンネルがいつものように確立されるべきです。使用中の鍵交換プロトコルが同時IKE_SAおよび/または子SAの確立をサポートしていない場合であっても、SAが成功し、必要な子を作成するために、1つのピアの試みを提供し、他のピアが失敗するとすぐに新しいSAに気づくことができる必要があり、その同じ作成しようとします。
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ソケットをリスンするとき（）関数は、ソケットで呼び出されます）。これは、リスナー接続ラッチの作成を起こす必要があります。
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アドレスとポート番号で受信されます。これは、ESTABLISHEDまたはBROKEN接続ラッチの作成を起こす必要があります。
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.
TCP SYNパケットO（例えば、BSDソケット接続（）関数の呼び出しの結果として）送られます。これは、ESTABLISHEDまたはBROKEN接続ラッチの作成を起こす必要があります。
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 CLOSED状態へのTCP接続のいずれの状態遷移は、関連する接続のための対応する遷移が、同様に閉状態にラッチさせます。
See Section 5.5 for how to handle latch transitions to the BROKEN state.
BROKEN状態にラッチ遷移を処理する方法については、セクション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、「接続」を作成します。これは、ESTABLISHEDまたはBROKEN接続ラッチの作成を起こす必要があります。
o an application destroys a UDP "connection". This should cause the creation of an ESTABLISHED or BROKEN connection latch.
Oアプリケーションは、UDP、「接続」を破壊します。これは、ESTABLISHEDまたはBROKEN接続ラッチの作成を起こす必要があります。
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.
BROKEN状態への接続、ラッチ遷移し、アプリケーションが要求された（またはシステムポリシーがそれを指示）接続が切断されることをすると、その後、許可、そうする方法があるかどうUDPは、アプリケーションに通知しなければならない、またはそうでなければ待つべきアプリケーション層のキープアライブ/タイムアウト戦略があれば、接続をタイムアウトします。
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.
どのような接続の管理の移行に直面して適切な行動を構成する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を使用したアプリケーションを提供することができます。実装アプリケーションは、5タプルは、アプリケーションが提供する接続のラッチと一致られて、出力に、確認する必要がラッチIPsec接続の規範モデルとUDP。入力に、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アソシエーション）が唯一のポート番号を持つことができます。
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.
我々は、5タプル、独自の接続ラッチとその各々の多数としてSCTPアソシエーションエンドポイントアドレスの多重度を表すことができます。代替的に、我々は、各エンドポイントのためのアドレスの多様性をサポートするために、接続ラッチオブジェクトを拡張することができます。第一のアプローチは、この文書全体を通して使用されます。そのため、私たちはその表現を仮定します。
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.
もちろん、このアプローチの結果Nのx Mの接続は、任意のSCTPアソシエーション（一方のエンドポイントがN個のアドレスを有し、他方はMを有する場合）のためのラッチ。代替的には、（N + M個のアドレスを持つ）SCTPアソシエーションごとに1つの接続ラッチを必要とするのに対し。実装者は、いずれかのアプローチを選択することもできます。
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ソケットを聞く場合（）関数は、ソケットで呼び出されます）。これは、リスナーの各アドレスのリスナーの接続ラッチの作成を起こす必要があります。
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アドレス及びポート番号で受信されます。これは、1つのまたは複数のESTABLISHEDまたはBROKEN接続ラッチ、クライアントとサーバのアドレスが与えられ、それぞれに異なる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（）関数の呼び出しの結果として、例えば、）送信されます。これは、1つまたは複数の確立またはBROKEN接続ラッチの作成を起こす必要があります。
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.
エンドポイントのIPアドレスが送信または受信される追加SCTPアドレス構成変更チャンク（ASCONF）[RFC5061]は、O。これは、1つまたは複数の確立またはBROKEN接続ラッチの作成を起こす必要があります。
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.
BROKEN状態にラッチ遷移を処理する方法については、セクション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の場合はBROKEN状態に接続ラッチの移行を処理するためのいくつかの方法があります。
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つのエンドポイント間でデータを移動しないであろう、その時点まで戻ってESTABLISHED状態への可能な将来の遷移を待ちます。 ULPとアプリケーションのタイムアウトメカニズムは、当然のことながら、BROKEN状態では、あまりにも長い滞在の場合にトリガされます。 SCTPは、これらのタイムアウトを検出し、マルチホーム団体の場合には、フェイルオーバーを開始することができます。
b. Act as though the connection has been reset (RST message received, in TCP, or ABORT message received, in SCTP).
B。接続がリセットされたかのように作用（RSTメッセージがTCPで、受信した、またはメッセージを中止は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.
彼らは処分を選択することができ、および/または2）先験的特定の配置を選択するように、ラッチブレークが発生する前に、実装は）（ラッチ休憩のアプリケーションは、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）は明らかに純粋主義者のデフォルトですが、我々はTCPとSCTPのみ単一のパスが残っている団体（1 5タプル）、およびマルチホームSCTPアソシエーションの（C）は（B）をお勧めします。次のようにこの勧告の根拠は以下のとおりです。矛盾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）攻撃をリセットしないことに注意してください。接続ラッチを解除するには、攻撃者は、最初の接続との競合をラッチすることを、成功した接続のエンドポイントの一つで、SAを確立しなければならない、それはそのエンドポイントと攻撃者の間で交換される複数のメッセージを必要とします。攻撃者の選択した被害者のエンドポイントは、攻撃者がそのSAの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の、SADに、存在に対処するためのメカニズムが追加されます。この機構は、最低限のトランスポート層の接続に影響を与えるような競合の存在のトランスポートプロトコル（及び、それらを介して、アプリケーション）のローカル通知からなります。競合がクリアされたときに影響を受けるトランスポートにも通知されます。トランスポートは着信パケットをドロップしなければならない、と紛争の影響を受けている接続のためのアウトバウンドパケットを送信してはなりません。この最小限の形態では、接続用ラッチは、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の実装者がそのスタックで実装するのに十分なシンプルに少なくとも一つのモデルを見つけることを願っています。
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.
このような競合が残って発生することを可能にするのIPsecの機能を、それがいるかどうか、どのように対応するために選択するために、トランスポートプロトコルとアプリケーション次第です - SAを矛盾するとどのような状況に対処するための基本的な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節では、キーマネージャは、まだ地元、役割けれども、もう少し積極的に取る場所ラッチ接続のオプション機能について説明します。オプションのプロテクト/バイパスとラッチ接続は不利な行政SPD（しかし、SADではない）の変更の顔に設立された状態のままにできるようにする「論理」SPDエントリの保存：2つのなどの機能があります。これら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を持っていることを保証しません。換言すれば、二つの与えられたノードの間の複数の同時接続を使用するアプリケーションは、接続ラッチせずに単独でのIPsecを使用するよりもラッチIPsec接続を使用することにより、任意の多かれ少なかれ保護されなくてもよいです。このようなマルチ接続アプリケーションは、しかし、同一のエンドポイントアドレスを持つすべての同時接続も同じエンドポイントのIPsec IDを持つことを保証するために、各接続のラッチSAパラメータを調べることができます。
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は、本明細書に記載されていません。 [ABSTRACT-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.
BROKEN状態に接続ラッチ状態遷移は、オンパス攻撃およびルータを攻撃するか、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アドレスを使用することができた場合、攻撃者はまた、ラッチを破ることができます。このような構成は、一般にBTNSと組み合わせて使用することが期待されます。このような攻撃は、一般的に、攻撃者が上のパスであることが必要です。
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.
すべての彼の助けのための著者のおかげでマイケル・リチャードソンと同様に、スティーブン・ケント、サム・ハートマン、ビルゾンマーフェルト、ダン・マクドナルド、ダニエルMigault、およびBTNS WGに参加してきたかのIPsecについての質問に答えてきた多くの人々の他、接続ラッチング実装など
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、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]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル（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.
[ABSTRACT-API]リチャードソン、M.、 "アプリケーションとIPsecとの間に抽象インタフェース"、進歩、2008年11月の作業。
[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]サン・マイクロシステムズ社、 "IPSecの（7P）のマニュアルページ、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]マクドナルド、D.、メッツ、C.、およびB. Phanさん、 "PF_KEY鍵管理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]タッチ、J.、ブラック、D.、およびY.王、RFC 5387、2008年11月 "ベター・ザン・ナッシングセキュリティ（BTNS）のための問題と適用に関する声明"。
[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.ナラヤナン、 "IPsecとのIKEv2を使用するためのガイドライン"、進歩、2006年10月に作業。
Author's Address
著者のアドレス
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラス・ウィリアムズSun Microsystemsの5300 RiataトレースのCtオースティン、TX 78727米国
EMail: Nicolas.Williams@sun.com
メールアドレス：Nicolas.Williams@sun.com