Network Working Group J. Touch
Request for Comments: 5387 USC/ISI
Category: Informational D. Black
EMC
Y. Wang
Microsoft
November 2008
Problem and Applicability Statement
for Better-Than-Nothing Security (BTNS)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 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.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
インターネットのネットワークセキュリティプロトコル・スイート、IPsecは、アクセス制御を可能にし、セキュリティサービスを提供するために、通常はネットワーク層のエンティティの、認証が必要です。この認証は、事前共有対称鍵、関連する非対称鍵と証明書、又は（キーのケルベロスインターネットネゴシエーション（KINK）を介して）ケルベロスの使用などのメカニズムに基づくことができます。認証情報とそれに関連するアイデンティティを展開する必要性は、IPsecの使用に重大な障害となり得ます。
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable.
この文書では、認証なしでIPsecセキュリティサービスの利用を可能にするために、インターネットのネットワークセキュリティプロトコルスイートを拡張するための理論的根拠を説明しています。これらの拡張機能は、「より良いよりも、何もセキュリティ」（BTNS）を提供し、通信を保護することを意図しています。拡張子は、自分で使用することができる（この使用は、スタンドアロンBTNS、またはSABと呼ばれている）、またはプロトコルスタック（この使用は、チャネルの結合と呼ばれている中で、より高い層で認証することができ、ネットワーク層のセキュリティを提供するために使用することができますBTNS、またはCBB）。文書はまた、拡張子が適用されSABおよび/またはCBBのどちらを使用するために状況を説明します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Authentication .............................................3
1.2. IPsec Channels and Channel Binding .........................4
1.3. BTNS Methods ...............................................6
1.4. BTNS Scope .................................................6
1.5. Structure of This Document .................................7
2. Problem Statement ...............................................7
2.1. Network Layer ..............................................8
2.1.1. Authentication Identities ...........................8
2.1.2. Authentication Methods ..............................8
2.1.3. Current IPsec Limits on Unauthenticated Peers .......9
2.2. Higher Layer Issues ........................................9
2.2.1. Transport Protection from Packet Spoofing ...........9
2.2.2. Authentication at Multiple Layers ..................10
3. BTNS Overview and Threat Models ................................12
3.1. BTNS Overview .............................................12
3.2. BTNS and IPsec Security Services ..........................13
3.3. BTNS and IPsec Modes ......................................14
4. Applicability Statement ........................................15
4.1. Benefits ..................................................16
4.2. Vulnerabilities ...........................................16
4.3. Stand-Alone BTNS (SAB) ....................................17
4.3.1. Symmetric SAB ......................................17
4.3.2. Asymmetric SAB .....................................18
4.4. Channel-Bound BTNS (CBB) ..................................18
4.5. Summary of Uses, Vulnerabilities, and Benefits ............19
5. Security Considerations ........................................20
5.1. Threat Models and Evaluation ..............................20
5.2. Interaction with Other Security Services ..................20
5.3. MITM and Masquerader Attacks ..............................21
5.4. Denial of Service (DoS) Attacks and Resource
Consumptions ..............................................22
5.5. Exposure to Anonymous Access ..............................22
5.6. ICMP Attacks ..............................................22
5.7. Leap of Faith .............................................22
5.8. Connection Hijacking through Rekeying .....................24
5.9. Configuration Errors ......................................25
6. Related Efforts ................................................25
7. Acknowledgments ................................................25
8. Informative References .........................................26
Network security is provided by a variety of protocols at different layers in the stack. At the network layer, the IPsec protocol suite (consisting of IKE (Internet Key Exchange protocol), ESP (Encapsulating Security Payload), and AH (Authentication Header)) is used to secure IP traffic. IPsec, including IKE, offers high levels of security that provide protection from a wide array of possible threats, but authentication is required [5][7][8]. In turn, authentication requires deployment of authentication identities and credentials, which can be an obstacle to IPsec usage. This document discusses this dependency and introduces "Better-Than-Nothing Security" (BTNS) as one solution, whose goal is to provide a generally useful means of applying IPsec security services without requiring network-layer authentication.
ネットワークセキュリティは、スタック内の異なる層でのさまざまなプロトコルによって提供されます。ネットワーク層では、（IKE（インターネット鍵交換プロトコル）、ESP（カプセル化セキュリティペイロード）、およびAH（認証ヘッダー）からなる）のIPsecプロトコルスイートは、IPトラフィックを保護するために使用されます。 IKEを含むIPsecは、[8] [7] [5]脅威の可能性の広い配列からの保護を提供する高レベルのセキュリティを提供していますが、認証が必要です。ターンでは、認証は、IPsecの使用に障害となり得る認証アイデンティティと資格情報の展開が必要です。この文書では、この依存関係を説明し、その目標は、ネットワーク層認証を必要とせずにIPsecセキュリティサービスを適用する一般的に有用な手段を提供することである一つの解決策として、「ベター・ザン・ナッシングセキュリティ」（BTNS）を紹介します。
There are two primary architectural approaches to authentication: employing out-of-band communications and using pre-deployed information. Out-of-band authentication can be done via a trusted third party, via a separate communication channel to the peer, or via the same channel as the communications to be secured but at a higher layer. Out-of-band authentication requires mechanisms and interfaces to bind the authenticated identities to the secure communication channels, and is out of scope for this document (although it may be possible to extend the channel binding mode of BTNS to work with such mechanisms). Pre-deployed information includes identities, pre-shared secrets, and credentials that have been authenticated by trusted authorities (e.g., a certificate and its corresponding private key).
アウト・オブ・バンド通信を使用し、事前配備情報を使用して：認証には2つの主要アーキテクチャアプローチがあります。アウトオブバンド認証を信頼できる第三者機関を介して、ピアに別個の通信チャネルを介して、または通信が確保されるように同じチャネルを介して、より高い層で行うことができます。アウトオブバンド認証は安全な通信チャネルに認証IDをバインドするメカニズムとインターフェースを必要とし、（そのようなメカニズムで動作するようにBTNSのチャネル結合モードを拡張することが可能かもしれないが）、この文書の範囲外です。事前に配備情報は、信頼できる当局（例えば、証明書とそれに対応する秘密鍵）によって認証されたアイデンティティ、事前共有秘密、および認証情報を含んでいます。
This form of authentication often requires manual deployment and coordination among communicating peers. Furthermore, obtaining and deploying credentials such as certificates signed by certification authorities (CA) involves additional protocol and administrative actions that may incur significant time and effort to perform.
認証のこの形式は、多くの場合、通信ピア間の手動展開と調整を必要とします。また、このような証明機関によって署名された証明書（CA）としての資格情報を取得して展開すると、追加のプロトコルおよび実行するために多大な時間と労力を被る可能性が管理アクションを必要とします。
These factors increase the work required to use IKE with IPsec for peer authentication. Consequently, some users and applications do not use IPsec to protect traffic at the network layer, but rely instead on higher-layer security protocols (e.g., TLS [4]) or operate without any security. As Section 2.2.1 describes, higher-layer security protocols may not be enough to protect against some network-layer attacks.
これらの要因は、ピア認証用のIPsecとIKEを使用するために必要な作業を増やします。その結果、一部のユーザーおよびアプリケーションはネットワーク層でトラフィックを保護するためにIPsecを使用していないが、上位層セキュリティプロトコルに頼る代わりに、（例えば、TLS [4]）または任意のセキュリティなしで動作します。 2.2.1項で説明したように、より高い層のセキュリティプロトコルは、いくつかのネットワーク層の攻撃から保護するのに十分ではないかもしれません。
To improve the situation, one could either reduce the hurdles to obtain and configure authentication information or remove the requirement for authentication in IPsec. The latter approach is the core idea of BTNS, which provides anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers that do not possess requisite authentication credentials. This requires extensions to the IPsec architecture. As the new BTNS modes for IPsec relax the authentication requirement, the impacts, tradeoffs, and risks must be thoroughly understood before applying BTNS to any communications. More specifically, this document addresses the issues of whether and when network-layer authentication can be omitted, the risks of using BTNS, and finally, the impacts to the existing IPsec architecture.
状況を改善するためには、取得した認証情報を設定やIPsecでの認証のための要件を削除するためにハードルを減らすことができるのいずれか。後者のアプローチは、IPsecが必要な認証資格を持たないピアとセキュリティアソシエーション（SA）を作成するためにキーイング匿名（認証されていない）を提供BTNSのコアアイデアです。これは、IPsecアーキテクチャへの拡張を必要とします。 IPsecのための新たなBTNSモードが認証要件を緩和したよう、影響、トレードオフ、およびリスクは徹底的に任意の通信にBTNSを適用する前に理解しておく必要があります。具体的には、この文書は、ネットワーク層認証を省略することができたときかどうかとの問題に対処し、最終的にはBTNSを使用して、とのリスク、既存のIPsecアーキテクチャへの影響。
BTNS employs a weaker notion of authenticated identity by comparison to most authentication protocols; this weaker notion is bootstrapped from the security association itself. This notion, called "continuity of association", doesn't mean "Bill Smith" or "owner of shared secret X2YQ", but means "the entity with which I have been communicating on connection #23". Continuity of association is only invariant within a single SA; it is not invariant across SAs, and hence can only be used to provide protection during the lifetime of an SA. This is a core notion used by BTNS, particularly in the absence of higher-layer authentication. Continuity of association can be viewed as a form of authentication in which an identity is not authenticated across separate associations or out-of-band, but does not change during the lifetime of the SA.
BTNSは、ほとんどの認証プロトコルと比較することによって認証されたアイデンティティの弱い概念を採用します。この弱い概念はセキュリティ協会自体からブートストラップされます。 「協会の継続性」と呼ばれるこの概念は、「ビル・スミス」または「共有秘密X2YQの所有者を」、という意味ではありませんが、「実体がどのと私は、接続＃23上で通信されている」という意味します。関連の連続性は、単一のSA内でのみ不変です。それはSAの間で不変ではない、したがって、SAの存続期間中に保護を提供するためにのみ使用することができます。これは、特に上位層認証の不在下で、BTNSによって使用される中核概念です。関連の連続性がアイデンティティが別の関連を横切ってまたは帯域外認証されていない認証の形態とみなすことができるが、SAの存続期間中に変化しません。
When IPsec security services are used by higher-layer protocols, it is important to bind those services to higher-layer protocol sessions in order to ensure that the security services are consistently applied to the higher-layer traffic involved. The result of this binding is an "IPsec channel", and the act of creating an IPsec channel is an instance of channel binding. Channel binding is discussed in RFC 5056 [27] and in an associated connection latching document [26]. This subsection summarizes the portions of these documents that are essential to understanding certain aspects of BTNS.
IPsecセキュリティサービスは、上位層プロトコルで使用されている場合は、セキュリティ・サービスを一貫して関与上位層のトラフィックに適用されることを保証するために、上位層プロトコルセッションにそれらのサービスをバインドすることが重要です。この結合の結果は、「IPsecのチャンネル」であり、IPsecのチャンネルを作成する行為は、結合チャネルのインスタンスです。結合チャネルは、RFC 5056 [27]において、文書[26]をラッチ関連関連して説明されています。ここでは、BTNSの特定の側面を理解するために不可欠なこれらの文書の一部をまとめたもの。
A secure channel is a packet, datagram, octet stream connection, or sequence of connections between two endpoints that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it [27]. Applying this concept to IPsec, an "IPsec channel" is a packet flow associated with a higher-layer protocol session, 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, and
セキュアチャネルは、[27]パケット、データグラム、オクテットストリームの接続、または必要に応じて、暗号化完全性を提供し、2つのエンドポイント、その上で交換されるデータの機密性との間の接続のシーケンスです。ピアのアイデンティティOに同じである：IPsecの、「IPsecのチャンネル」にこの概念を適用することは、すべてのパケットがそのようなことのIPsec SAのによって保護されているTCP接続などの上位層プロトコルセッションに関連付けられたパケットフローでありますパケットフローの存続期間、および
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 [26].
oをパケットフローの個々のパケットに使用するIPsec保護の品質は、パケットフローの寿命のためにそれらのすべてのために[26]と同じです。
The endpoints of an IPsec channel are the higher-layer protocol endpoints, which are beyond the endpoints of the IPsec SAs involved. This creates a need to bind each IPsec SA to the higher-layer protocol session and its endpoints. Failure to do this binding creates vulnerabilities to man-in-the-middle (MITM) attacks, where what appears to be a single IPsec SA for the higher-layer protocol traffic is actually two separate SAs concatenated by the attacker acting as a traffic-forwarding proxy.
IPsecチャネルのエンドポイントは、関連のIPsec SAのエンドポイントを超えて上位層プロトコルのエンドポイントです。これは、上位層プロトコルのセッションとそのエンドポイントにそれぞれのIPsec SAをバインドする必要が作成されます。この結合を行うに失敗すると、どのような上位層プロトコルのトラフィックのための単一のIPsec SAのように見えるが実際traffic-として動作する攻撃者により連結二つの別々のSAでのman-in-the-middleへの脆弱性（MITM）攻撃を作成しますプロキシを転送します。
The combination of connection latching [26] with channel binding [27] creates IPsec channels and binds IPsec SAs to higher-layer protocols. Connection latching creates an IPsec channel by associating IPsec SAs to higher-layer protocol sessions, and channel binding enables a higher-layer protocol to bind its authentication to the IPsec SAs. Caching of this "latch" across higher-layer protocol sessions is necessary to counter inter-session spoofing attacks, and the channel binding authentication should be performed on each higher-layer protocol session. Connection latching and channel binding are useful not only for BTNS but also for IPsec SAs whose peers are fully authenticated by IKE during creation of the SA.
結合チャネル[27]とのラッチ接続[26]の組合せは、IPsecチャネルを作成し、上位層プロトコルへのIPsec SAを結合します。接続ラッチは、上位層プロトコルのセッションへのIPsec SAを関連付けることによって、IPsecのチャネルを作成し、チャネル結合は、IPsecのSAへの認証を結合する上位層プロトコルを可能にします。上位層プロトコルセッションにわたってこの「ラッチ」のキャッシングは、インターセッションスプーフィング攻撃に対抗する必要があり、認証を結合チャネルは、各上位層プロトコルセッション上で実行されるべきです。接続ラッチおよびチャネル結合はBTNSのためだけでなく、そのピア完全にSAの作成中にIKEによって認証されたIPsec SAのではないだけに有用です。
Channel binding for IPsec is based on information obtained from the SA creation process that uniquely identifies an SA pair. Channel binding can be accomplished by adding this identifying information to higher-layer authentication mechanisms based on one-way hashes, key exchanges, or (public key) cryptographic signatures; in all three cases, the resulting higher-layer authentication resists man-in-the-middle attacks on SA creation. When each IKE peer uses a public-private key pair for IKE authentication to create an SA pair, the pair of public keys used (one for each peer) suffices for channel binding; strong incorporation of this information into higher-layer authentication causes that higher-layer authentication to fail when an MITM attacker has concatenated separate SAs by acting as a traffic-forwarding proxy.
IPsecのための結合チャネルを一意SAペアを識別するSA作成プロセスから得られた情報に基づくものです。結合チャネルは、一方向ハッシュ、鍵交換、または（公開鍵）暗号署名に基づいて、上位層認証メカニズムには、この識別情報を付加することによって達成することができます。すべての3つのケースでは、結果として上位層認証は、SAの作成上のman-in-the-middle攻撃に抵抗します。各IKEピアがSAのペアを作成するためにIKE認証用公開鍵と秘密鍵のペアを使用する場合、使用される公開鍵の対（各ピアに対して1つ）は、結合チャネルのために十分です。上位層認証にこの情報の強い取り込みはMITM攻撃者がトラフィック転送プロキシとして作用することにより、別のSAを連結したときに上位層認証が失敗することを引き起こします。
There are two classes of scenarios in which BTNS may be used to apply IPsec services without network-layer authentication:
BTNSは、ネットワーク層認証なしのIPsecサービスを適用するために使用することが可能なシナリオの2つのクラスがあります。
1. Protection of traffic for a higher-layer protocol that does not use authentication. The resulting protection is "better than nothing" because once an unauthenticated SA is successfully created without an MITM, that SA's IPsec security services resist subsequent MITM attacks even though the absence of authentication allows the initial creation of the BTNS-based security association (SA) to be subverted by an MITM. This method of using BTNS is called Stand-Alone BTNS (SAB) because it does not rely on any security services outside of IPsec.
認証を使用しない上位層プロトコルのトラフィックの1.保護。一度認証されていないSAが正常にMITMなしで作成されるため、結果として保護がSAのIPsecセキュリティサービスは、認証の有無がBTNSベースのセキュリティアソシエーション（SA）の初期作成を可能にするにもかかわらず、その後のMITM攻撃に抵抗することを、「何もないよりはまし」でありますMITMによって堕落します。それはIPsecの外の任意のセキュリティ・サービスに依存しないため、BTNSを使用するこの方法は、スタンドアロンBTNS（SAB）と呼ばれています。
2. Protection of traffic generated by a higher-layer protocol that uses authentication. The "better-than-nothing" protection in this case relies on the strength of the higher-layer protocol's authentication and the channel binding of that authentication with the BTNS-based SAs. The level of protection may be comparable to the level afforded by the use of network-layer IKE authentication when the higher-layer protocol uses strong authentication and strong channel binding is employed to associate the BTNS-based SA with that higher-layer authentication. This method of using BTNS is called Channel-Bound BTNS (CBB) when the combination of the higher-layer authentication and channel binding is sufficient to detect an MITM attack on creation of a BTNS-based SA.
認証を使用する上位層プロトコルによって生成されるトラフィックの2.保護。この場合の「よりも良い無か」の保護は、上位層プロトコルの認証の強度とBTNSベースのSAとその認証の結合チャネルに依存しています。保護のレベルは、上位層プロトコルは、強力な認証および強いチャネル結合を使用するネットワーク層IKE認証の使用によって得られるレベルに匹敵することができることを上位層認証とBTNSベースのSAを関連付けるために使用されます。 BTNSを使用するこのメソッドが呼び出されるチャネル結合型BTNS（CBB）上位層認証及び結合チャネルの組み合わせがBTNSベースSAの作成にMITM攻撃を検出するのに十分です。
It is possible to combine IKE authentication for one end of an SA pair with BTNS's absence of network-layer authentication for the other end. The resulting asymmetric authentication creates asymmetric modes of BTNS that are discussed further in Section 3.2 below.
もう一方の端のためのネットワーク層認証のBTNSの不在でSAペアの一方の端のためのIKE認証を組み合わせることが可能です。得られた非対称認証は、以下のセクション3.2でさらに議論されるBTNSの非対称モードを生成します。
The scope of BTNS is to provide a generally useful means of applying IPsec security services that does not require network-level authentication credentials. The following areas are outside this scope of BTNS and hence are not discussed further in this document:
BTNSの範囲は、ネットワークレベル認証の資格情報を必要としないIPsecセキュリティサービスを適用する一般的に有用な手段を提供することです。次の領域はBTNSのこの範囲外にあり、従って、本書で詳しく説明されていません。
1. Use of security frameworks other than IPsec to provide security services for higher-layer protocols. There are a variety of security service frameworks other than IPsec, such as TLS [4], Simple Authentication and Security Layer (SASL) [11], and Generic Security Service Application Program Interface (GSS-API) [10], as well as a variety of non-IPsec security mechanisms, such as TCP
上位層プロトコルのためのセキュリティサービスを提供するためにIPsec以外のセキュリティフレームワークの使用。そこにIPsec以外のセキュリティサービスフレームワークの様々な[10]は、このようなTLS [4]、簡易認証セキュリティー層（SASL）[11]、および一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）として、あるだけでなく、 TCPのような非IPsecセキュリティメカニズム、多様な
MD5 [6], that are described in other documents. BTNS is based on IPsec by design; it will not always be the most appropriate solution.
他の文書に記載されているMD5 [6]。 BTNSは設計のIPsecに基づいています。それは常に最も適切な解決策ではありません。
2. Use of the Extensible Authentication Protocol (EAP) for IKE authentication. Section 1.3 of RFC 3748 clearly restricts EAP's applicability to network access protocols [1]:
IKE認証のための拡張認証プロトコル（EAP）の使用。 RFC 3748のセクション1.3は明らかにネットワークアクセスプロトコルにEAPの適用可能性を制限し、[1]：
"EAP was designed for use in network access authentication,
where IP layer connectivity may not be available. Use of EAP
for other purposes, such as bulk data transport, is NOT
RECOMMENDED."
Hence, EAP authentication for IKE is only applicable to situations where IKE is being used to establish network access (e.g., create a Virtual Private Network (VPN) connection). In contrast, the BTNS goal of general applicability encompasses many areas other than network access and specifically includes protocols that transfer large amounts of data, such as iSCSI [19] and NFSv4 [21].
したがって、IKEのためのEAP認証が（例えば、仮想プライベートネットワーク（VPN）接続を作成する）IKEは、ネットワークアクセスを確立するために使用されている状況にのみ適用可能です。対照的に、一般的な適用のBTNS目標は、ネットワーク・アクセス以外の多くの領域を包含し、具体的には、iSCSIの[19]とのNFSv4 [21]のように大量のデータを転送するプロトコルを含みます。
3. Manual keying is not considered for BTNS because manual keying is unsafe for protocols that transfer large amounts of data (e.g., RFC 3723 forbids use of manual keying with the IP Storage protocols, including iSCSI, for this reason [2]).
3.手動キー手動キーが大量のデータを転送するプロトコルのため危険であるため、BTNSのために考慮されていない（例えば、RFC 3723は、この理由のためのiSCSIなどのIPストレージプロトコルと手動キーの使用を禁止する[2]）。
The next section discusses the motivations for BTNS, primarily based on the implications of IKE's requirements for network-layer authentication. Section 3 provides a high level overview of BTNS, both SAB and CBB. Section 3 also includes descriptions of the security services offered and the BTNS modes of operation (based on combinations of SAB, CBB, and/or IKE authentication). Section 4 explores the applicability of all of the modes of BTNS. This is followed by a discussion of the risks and other security considerations in Section 5. Section 6 briefly describes other related efforts.
次のセクションでは、主にネットワーク層認証のためのIKEの要件の意味に基づいて、BTNSのための動機を説明します。セクション3はBTNS、SABとCBBの両方の高レベルの概要を提供します。セクション3は、また、提供されるセキュリティサービスと（SAB、CBBの組み合わせに基づいて、及び/又はIKE認証）操作のBTNSモードの記述を含みます。第4節では、BTNSのモードのすべての適用可能性を探ります。これは、6簡単には他の関連する取り組みを説明し、セクション5節でのリスクやその他のセキュリティの考慮事項についての議論が続いています。
This section describes the problems that motivated the development of BTNS. The primary concern is that IPsec is not widely utilized despite rigorous development effort and emphasis on network security by users and organizations. There are also differing viewpoints on which layer is best for securing network communications and how security protocols at different layers should interact. The following discussion roughly categorizes these issues by layers: network layer and higher layers.
このセクションでは、BTNSの開発を動機問題について説明します。主な関心事は、IPsecが広くユーザーや組織によるネットワークセキュリティ上の厳格な開発努力と強調にもかかわらず、利用されないということです。層は、ネットワーク通信を確保し、どのように異なる層でのセキュリティプロトコルが相互作用すべきであるために最善であるに異なる視点もあります。ネットワーク層と上位層：以下の議論では、おおよその層によって、これらの問題を分類しています。
At the network layer, one of the hurdles is to satisfy the authentication requirements of IPsec and IKE. This section discusses some drawbacks of network-layer authentication and the results of these requirements.
ネットワーク層では、ハードルの一つは、IPsecとIKEの認証要件を満たすことです。このセクションでは、ネットワーク層認証のいくつかの欠点と、これらの要件の結果について説明します。
Current IPsec authentication supports several types of identities in the Peer Authorization Database (PAD): IPv4 addresses, IPv6 addresses, DNS names, Distinguished Names, RFC 822 email addresses, and Key IDs [8]. All require either certificates or pre-shared secrets to authenticate. The identities supported by the PAD can be roughly categorized as network-layer identifiers or other identifiers.
現在のIPsec認証は、ピア認証データベース（PAD）でアイデンティティのいくつかのタイプをサポートしています。IPv4のアドレス、IPv6アドレス、DNS名、識別名、RFC 822電子メールアドレス、およびキーIDは、[8]。すべては、認証に証明書または事前共有秘密のいずれかが必要です。 PADによってサポートされるアイデンティティは、大別ネットワーク層識別子または他の識別子として分類することができます。
The first three types of identifiers -- IPv4 addresses, IPv6 addresses and DNS names -- are network-layer identifiers. The main deficiency of IP addresses as identifiers is that they often do not consistently represent the same physical systems due to the increasing use of dynamic address assignments (DHCP) and system mobility. The use of DNS names is also affected because the name to address mapping is not always up to date as a result. Stale mapping information can cause inconsistencies between the IP address recorded in the DNS for a named system and the actual IP address of that system, leading to problems if the DNS is used to cross-check the IP address from which a DNS name was presented as an identifier. DNS names are also not always under the control of the endpoint owner.
IPv4アドレス、IPv6アドレスとDNS名 - - 識別子の最初の3つのタイプがネットワーク層識別子です。識別子としてIPアドレスの主な欠点は、彼らはしばしば一貫による動的アドレス割り当て（DHCP）、およびシステムのモビリティの使用の増加に同一の物理システムを表すものではないということです。アドレスマッピングに名前が結果として常に最新ではないので、DNS名の使用にも影響されます。古いマッピング情報はDNSがDNS名は次のように提示されたクロスチェックIPアドレスに使用されている場合は問題につながる、というシステムのためのDNSとそのシステムの実際のIPアドレスに記録されているIPアドレス間の不整合を引き起こす可能性があります識別子。 DNS名は、エンドポイントの所有者の制御下でも常にではありません。
There are two main drawbacks with the other, non-network-layer identifiers defined for the PAD. The PAD functionality can be overly restrictive because there are other forms of identifiers not covered by the PAD specification (EAP does not loosen these restrictions in general; see Section 1.4). Use of any non-network-layer identifiers for IPsec authentication may result in multiple authentications for the same or different identifiers at different layers, creating a need to associate authentications and new error cases (e.g., one of two authentications for the same identifier fails). These issues are also related to channel binding and are further discussed later in this document.
PADのために定義された他、非ネットワーク層識別子を持つ2つの主要な欠点があります。 PADの仕様でカバーされていない識別子の他の形態は、（;セクション1.4を参照してくださいEAPは、一般的にはこれらの制限を緩めていない）があるので、パッドの機能が過度に制限することができます。 IPsec認証のための任意の非ネットワーク層識別子の使用を認証し、新しいエラーケースを関連付ける必要性を作成、異なる層で同じ又は異なる識別子の複数の認証をもたらすことができる（例えば、同じ識別子のための2つの認証のいずれかが失敗します） 。これらの問題はまた、結合チャンネルに関連しており、さらに、このドキュメントで後述します。
As described earlier, certificates and pre-shared secrets are the only methods of authentication accepted by current IPsec and IKE specifications. Pre-shared secrets require manual configuration and out-of-band communications. The verification process for certificates is cumbersome, plus there are administrative and potential monetary costs in obtaining certificates. These factors are among the possible reasons why IPsec is not widely used outside of environments with the highest security requirements.
前述したように、証明書と事前共有秘密は、現在のIPsecとIKE仕様によって受け入れられた認証の唯一の方法です。事前共有秘密は、手動設定とアウトオブバンド通信を必要とします。証明書の検証プロセスが煩雑であり、プラスの証明書を得る上で管理し、潜在的な金銭的コストがあります。これらの要因は、IPsecが広く、最高のセキュリティ要件を持つ環境の外で使用されていない理由を考えられる理由の一つです。
Pre-configuration of Security Policy Database (SPD) "bypass" entries to enable communication with unauthenticated peers only works if the peer IP addresses are known in advance. The lack of unauthenticated IPsec modes often prevents secure communications at the network layer with unauthenticated or unknown peers, even when they are subsequently authenticated in a higher-layer protocol or application. The lack of a channel binding API between IPsec and higher-layer protocols may further force such communications to completely bypass IPsec, leaving the network layer of such communications unprotected.
ピアIPアドレスが事前に分かっている場合、認証されていないピアとの通信を可能にするセキュリティポリシーデータベース（SPD）「バイパス」のエントリの事前設定にのみ機能します。認証されていないのIPsecモードの欠如は、多くの場合、彼らはその後、上位層のプロトコルやアプリケーションに認証された場合でも、認証されていないか、未知のピアとのネットワーク層での安全な通信を防ぐことができます。 IPsecと上位層プロトコルとの間のチャネル結合APIの欠如はさらに、保護されていないような通信のネットワーク層を残し、完全にバイパスIPsecのこのような通信を強制することができます。
For higher layers, the next subsection focuses on whether IPsec is necessary if transport layer security is already in use. The use of IPsec in the presence of transport security provides further motivation for reducing the administrative burdens of using IPsec. This is followed by a discussion of the implications of using authentication at both the network layer and a higher layer for the same connection.
上位層については、次のサブセクションはトランスポート層セキュリティが既に使用されている場合、IPsecが必要であるかどうかに焦点を当てています。トランスポート・セキュリティの存在下でのIPsecの使用は、IPsecを使用しての管理負担を軽減するための更なるモチベーションを提供します。これは、ネットワーク層と同じ接続のための上位層の両方で認証を使用する場合の影響についての議論が続いています。
Consider the case of transport protocols. Increases in network performance and the use of long-lived connections have resulted in increased vulnerability of connection-oriented transport protocols to certain forms of attacks. TCP, like many other protocols, is susceptible to off-path third-party attacks, such as injection of a TCP RST [24]. The Internet lacks comprehensive ingress filtering to discard such spoofed traffic before it can cause damage. These attacks can affect BGP sessions between core Internet routers, and are thus of significant concern [3][12]. As a result, a number of proposed solutions have been developed, most of which are at the transport layer.
トランスポートプロトコルの場合を考えてみましょう。ネットワークのパフォーマンスと長命の接続の使用の増加は、攻撃の特定の形態への接続指向のトランスポートプロトコルの脆弱性の増加をもたらしました。 TCPは、多くの他のプロトコルと同様に、そのようなTCP RST [24]の注入をオフパスサードパーティの攻撃を受けやすいです。それが損傷を引き起こす可能性があります前に、インターネットは、このような偽装されたトラフィックを破棄する包括的なイングレスフィルタリングを欠いています。これらの攻撃は、コアインターネットルータ間のBGPセッションに影響を与えるため、重要な問題のあることができます[3] [12]。結果として、提案された解決策の数は、そのほとんどはトランスポート層であり、開発されてきました。
Some of these solutions augment the transport protocol by improving its own security, e.g., TCP MD5 [6]. Others modify the core TCP processing rules to make it harder for off-path attackers to inject meaningful packets either during the initial handshake (e.g., SYN cookies) or after a connection is established (e.g., TCPsecure) [15][23]. Some of these approaches are new to TCP, but have already
これらの解決策のいくつかは、例えば、独自のセキュリティを改善することにより、TCP MD5をトランスポートプロトコルを増強する[6]。他のものは、[15] [23]最初のハンドシェイク（例えば、SYNクッキー）の間、または接続が確立された後のいずれかに意味のあるパケットを注入するオフパス攻撃者（例えば、TCPsecure）ことが難しく、コアTCP処理ルールを修正します。これらのアプローチのいくつかは、TCPに新しいですが、すでに持っています
been incorporated into other transport protocols (e.g., Stream Control Transmission Protocol (SCTP) [22]) or intermediate (so-called layer 3.5) protocols (e.g., Host Identity Protocol (HIP) [14]).
他のトランスポートプロトコルに組み込まれて（例えば、ストリーム制御伝送プロトコル（SCTP）[22]）または中間体（いわゆる層3.5）プロトコル（例えば、ホストアイデンティティプロトコル（HIP）[14]）。
TCP MD5 and its potential successor, TCP Auth [25], are based on authentication; TCP-specific modifications that lack authentication are, at best, temporary patches to the ubiquitous vulnerability to spoofing attacks. The obvious solution to spoofing is end-to-end validation of the traffic, either at the transport layer or the network layer. The IPsec suite already provides authentication of a network-layer packet and its contents, but the costs of an authentication infrastructure required for the use of IPsec can be prohibitive. Similarly, TCP MD5 requires pre-shared keys, which can likewise be prohibitive. TCP Auth is currently under development, and may include a BTNS-like mode.
TCP MD5およびその潜在的な後継者、TCP認証[25]、認証に基づいています。認証が不足しているTCP固有の変更は、せいぜい、スプーフィング攻撃へのユビキタスな脆弱性への一時的なパッチです。なりすましに対する明白な解決策は、トランスポート層、ネットワーク層のいずれかで、トラフィックのエンドツーエンドの検証です。 IPsecのスイートには、すでにネットワーク層パケットとその内容の認証を提供しますが、IPsecの使用に必要な認証インフラストラクチャのコストは法外することができます。同様に、TCP MD5も同様に法外することができ、事前共有キーが必要です。 TCP認証は、現在開発中であり、BTNSのようなモードを備えていてもよいです。
Protecting systems from spoofed packets is ultimately an issue of authentication, ensuring that a receiver's interpretation of the source of a packet is accurate. Authentication validates the identity of the source of the packet. The current IPsec suite assumes that identity is validated either by a trusted third party -- e.g., a certification authority -- or by a pre-deployed shared secret. Such an identity is unique and invariant across associations (pair-wise security configuration), and can be used to reject packets that are not authentic.
偽装されたパケットからシステムを保護することは、パケットの送信元の受信者の解釈が正確であることを確認して、最終的に認証の問題です。認証は、パケットの送信元の身元を検証します。例えば、認証局 - - または事前共有秘密展開により、現在のIPsecスイートは、アイデンティティが信頼できる第三者のいずれかによって検証されることを前提としています。このようなアイデンティティは、団体（ペアワイズセキュリティ設定）全体でユニークで不変であり、本物ではないパケットを拒否するために使用することができます。
With regard to BGP in particular, it has been understood that the use of appropriate network- or transport-layer authentication is the preferred protection from TCP spoofing attacks [3]. Authentication at one router by itself does not provide overall BGP security because that router remains at the mercy of all routers it peers with, since it depends on them to also support authentication [25]. The reality is that few Internet routers are configured to support authentication at all, and the result is the use of unsecured TCP for sending BGP packets. BTNS allows an individual router to relax the need for authentication in order to enable the use of protected sessions that are not authenticated. The latter is "better than nothing" in cases where "nothing" is the alternative. Although the routing community has chosen solutions other than BTNS for protection of BGP's TCP connections (e.g., TCP MD5), the discussion of BGP remains in this document because it was a motivation for the development of BTNS.
特にBGPに関しては、適切なネットワーク - またはトランスポート層認証の使用は、TCPスプーフィング攻撃から好ましい保護があることが理解されている[3]。それはまた、認証[25]をサポートするためにそれらに依存するので、そのルータは、それが持つピアすべてのルータのなすがままに残っているので、それ自体で1台のルータでの認証は、全体的なBGPのセキュリティを提供しません。現実には、いくつかのインターネットルータが全く認証をサポートするように設定されていることである、との結果がBGPパケットを送信するための無担保TCPを使用することです。 BTNSが認証されていない保護されたセッションの使用を可能にするために、認証の必要性を緩和するために、個々のルータを可能にします。後者は「何も」の代替ではない場合には「何もないよりはまし」です。ルーティングコミュニティはBGPのTCP接続（例えば、TCP MD5）の保護のためにBTNS以外のソリューションを選択したが、それはBTNSの開発のための動機だったので、BGPの議論は、この文書に残ります。
Some existing protocols used on the Internet provide authentication above the network and transport layers but rely on the IPsec suite for packet-by-packet cryptographic integrity and confidentiality services. Examples of such protocols include iSCSI [19] and the
インターネット上で使用されるいくつかの既存のプロトコルは、ネットワーク層とトランスポート層以上の認証を提供するが、パケットごとの暗号完全性と機密性サービスのためのIPsecスイートに依存しています。そのようなプロトコルの例は、iSCSI [19]と含みます
remote direct data placement (RDDP) protocols [16][20]. With the current IPsec suite, the result is two authentication operations: one at the IPsec layer using an identity for IKE and an associated secret or key, and another by the higher-layer protocol using a higher-layer identity and secret or key. With the current IPsec specifications, this redundant authentication is necessary because the identity and key formats differ between IPsec and the higher-layer protocol and/or because there is no standard interface to pass authentication results from IPsec up to the higher layer. End-node software is then responsible for ensuring that the identities used for these two authentication operations are consistent in some fashion; determining whether these identities are consistent is an authorization policy decision.
遠隔直接データ配置（RDDP）プロトコル[16] [20]。 IKEのIDと関連付けられた秘密キーまたはキーを使用して、IPSecレイヤに1つ、および上位層アイデンティティと秘密または鍵を使用して、上位層プロトコルによって別の現在のIPsecスイートで、結果は、2回の認証操作です。アイデンティティ及びキーフォーマットがIPsecと上位層プロトコルとの間で異なるため、現在のIPsec仕様で、この冗長な認証が必要である/又は上位層までのIPsecから認証結果を渡すための標準的なインターフェースが存在しないからです。エンドノードソフトウェアは、これらの2つの認証操作に使用されるアイデンティティは何らかの方法で一貫していることを確実にする責任があります。これらのIDが一致しているかどうかを決定することは許可ポリシーの決定です。
Failure of the end-node software to enforce appropriate consistency across authentication operations at different layers creates man-in-the-middle attack opportunities at the network layer. An attacker may exploit this omission by interposing as a proxy; rather than impersonate the attacked endpoints, the attacker need only authenticate with identities that are acceptable to the attacked endpoints. The resulting success enables the attacker to obtain full access to the higher-layer traffic by passing the higher-layer authentication operation through without modification. In the complete absence of consistency checks on the identities used at different layers, higher-layer traffic may be accessible to any entity that can successfully authenticate at the network layer.
異なる層で認証操作を横切って適切な整合性を強制するエンドノードソフトウェアの故障は、ネットワーク層でman-in-the-middle攻撃の機会を作成します。攻撃者はプロキシとして介在させることにより、この省略を利用することができます。攻撃のエンドポイントを偽装するのではなく、攻撃者は攻撃のエンドポイントに受け入れられるアイデンティティを使用して認証する必要が。結果として成功するには、修正なしを通じて上位層の認証操作を渡すことによって、上位層のトラフィックへの完全なアクセスを得ることが攻撃者を可能にします。異なる層で使用されるアイデンティティに整合性チェックの完全な非存在下では、上位層のトラフィックが正常にネットワーク層で認証できる任意のエンティティにアクセス可能であってもよいです。
In principle, a single authentication operation should suffice to protect the higher-layer traffic, removing the need for:
原則として、単一の認証操作が必要性を取り除く、上位層のトラフィックを保護するために十分です。
o the second authentication operation,
第二の認証動作O、
o configuration and management of the identities and secrets or keys for the second authentication (even if the identities and secrets or keys are the same, the two authentication operations may employ different repositories for identities, secrets, and keys), and
O構成と第二の認証（IDと秘密またはキーが同じであっても、2つの認証操作がアイデンティティ、秘密、およびキーの異なるリポジトリを使用することができる）のためのIDと秘密または鍵の管理、および
o determining in some fashion that the two authenticated identities are consistent. As noted above, there are significant potential MITM vulnerabilities if this is not done.
2人の認証されたアイデンティティが一致しているいくつかの方法で決定し、O。上述したように、これは行われていない場合、重大な潜在的なMITMの脆弱性があります。
IPsec may not always be present for these higher-layer protocols, and even when present, may not always be used. Hence, if there is a choice, the higher-layer protocol authentication is preferable as it will always be available for use, independent of IPsec.
IPsecは常に、これらの上位層プロトコルのために存在しなくてもよく、さらに存在する場合、必ずしも使用しなくてもよいです。選択がある場合、それは常にのIPsecとは無関係に、使用のために利用可能になるようしたがって、上位層プロトコルの認証が好ましいです。
A "better-than-nothing" security approach to IPsec can address this problem by setting up an IPsec security association without an authentication, and then using an extended form of the higher-layer authentication to establish that the higher-layer protocol session is protected by a single IPsec SA. This counters man-in-the-middle (MITM) attacks on BTNS IPsec session establishment by terminating the higher-layer session via an authentication failure when such an attack occurs. The result is that a single authentication operation validates not only the higher-layer peer's identity but also continuity of the security association to that peer. This higher-layer check for a single IPsec SA is referred in this document as "channel binding", thus the name Channel-Bound BTNS (CBB) [27].
IPsecのが「よりも良い無か」のセキュリティアプローチは、認証なしのIPsecセキュリティアソシエーションを設定することでこの問題に対処した後、上位層プロトコルセッションが保護されていることを確立するために、上位層認証の拡張形式を使用することができます単一のIPsec SAによります。これは、このような攻撃が発生した場合に認証失敗を介して上位層セッションを終了するBTNSのIPsecセッションの確立でのman-in-the-middle（MITM）攻撃に対抗します。結果は、単一の認証操作は、上位層のピアのアイデンティティだけでなく、そのピアへのセキュリティアソシエーションの継続だけでなく、検証ということです。単一のIPsec SAのために、この上位層のチェックは、「チャネル結合」として本書で参照され、したがって名チャネル・バウンドBTNS（CBB）[27]。
This section provides an overview of BTNS and the IPsec security services that are offered when BTNS is used. It also describes the multiple operating modes of BTNS.
このセクションでは、BTNSとBTNSを使用する場合に提供されているIPsecセキュリティサービスの概要を説明します。また、BTNSの複数の動作モードを示します。
This is an overview of what is needed in IPsec to enable BTNS. The detailed specifications of the extensions are addressed by the relevant protocol specifications.
これはBTNSを有効にするためにIPsecに必要なものの概要です。拡張子の詳細な仕様は、関連するプロトコル仕様によって対処されています。
The main update to IPsec is adding extensions to security policy that permit secure communications with unauthenticated peers. These extensions are necessary for both IPsec and IKE. For IPsec, the first extension applies to the PAD, which specifies the forms of authentication allowed for each IKE peer. In addition to existing forms of authentication, such as X.509 certificates and pre-shared secrets, the extension adds an unauthenticated category in which the public key presented by the peer serves as its identity (and is authenticated by the peer demonstrating knowledge of the corresponding private key) [28]. The second extension is that a flag is added to each SPD entry to indicate whether BTNS lack of authentication is acceptable for that SPD entry.
IPsecのメインの更新は、認証されていないピアとのセキュアな通信を許可するセキュリティポリシーへの拡張を追加しています。これらの拡張機能は、IPsecとIKEの両方のために必要です。 IPsecのために、最初の拡張は、各IKEピアに許可認証の形式を指定するパッドに適用されます。そのようなX.509証明書と事前共有秘密として認証の既存の形態に加えて、エクステンションは、ピアによって提示された公開鍵は、その識別としての役割を果たす（との知見を実証するピアによって認証された認証されていないカテゴリを追加します対応する秘密鍵）[28]。第二の拡張フラグが認証のBTNSの欠如は、そのSPDエントリのために許容可能であるかどうかを示すために各SPDエントリに追加されることです。
The changes to enable channel binding between IPsec and higher-layer protocols or applications are more complex than the policy extensions above. They require specifying APIs and interactions between IPsec and higher-layer protocols. This document assumes such provisions will be developed, but does not address their details.
IPsecと上位層プロトコルまたはアプリケーションとの間の結合チャネルを有効にする変更は、上記のポリシー拡張子よりも複雑です。彼らは、IPsecと上位層プロトコル間のAPIとの相互作用を指定する必要があります。この文書では、そのような規定が開発されると仮定しますが、その詳細には対応していません。
The changes and extensions of BTNS primarily affect IPsec policy as described above. Other parts of IPsec and IKE specifications are unchanged. BTNS does not require a separate IPsec implementation, as BTNS can be integrated with any IPsec implementation in a system. The scope of BTNS functionality applies only to the SAs matching the policies that explicitly specify or enable BTNS modes in the PAD and for which the corresponding SPD entries allow BTNS. All other non-BTNS policy entries, including entries in the SPD and the PAD, and non-BTNS SAs are not affected by BTNS.
上記のようにBTNSの変更や拡張は、主にIPsecポリシーに影響を与えます。 IPsecとIKE仕様の他の部分は変更されません。 BTNSは、システム内の任意のIPsec実装と統合することができるようにBTNSは、別個のIPsec実装を必要としません。 BTNSの機能の範囲を明示的に指定するか、またはパッド内に、対応するSPDエントリはBTNSを可能にするためのBTNSモードを有効にするポリシーをマッチングのみのSAに適用されます。 SPDとパッド、および非BTNSのSA内のエントリを含むすべての他の非BTNSポリシーエントリは、BTNSの影響を受けません。
In principle, the result of removing the requirement that all SAs be authenticated is that BTNS can establish secure IPsec connections in a fashion similar to fully authenticated IKE, but BTNS cannot verify or authenticate the peer identities of these SAs. The following is a list of security services offered by the IPsec protocol suite with notes that address the differences created by the addition of BTNS.
原則として、すべてのSAが認証される必要性を除去した結果は、BTNSが完全にIKEを認証されたと同様に安全なIPsec接続を確立することができますが、BTNSが確認またはこれらのSAのピアIDを認証できないということです。次はBTNSの添加によって作成さの違いに対処ノートとのIPsecプロトコルスイートが提供するセキュリティサービスのリストです。
BTNS extends IPsec's access control services to allow unauthenticated connections. These extensions are integrated with the IPsec PAD and SPD in a fashion that does not affect the access controls associated with entries that do not use the BTNS extensions. For Channel-Bound BTNS, the authentication that applies to the SA is performed at a higher layer in a fashion that links higher-layer access control policy to IPsec's network-layer access control mechanisms.
BTNSは、認証されていない接続を許可するようにIPsecのアクセス制御サービスを拡張します。これらの拡張機能は、BTNSの拡張機能を使用しないエントリに関連付けられたアクセス制御には影響を与えない形でのIPsecパッドとSPDと統合されています。チャンネル・バウンドBTNSのために、SAに適用される認証は、IPsecのネットワーク層のアクセス制御メカニズムに上位層のアクセス制御ポリシーを結ぶ形で上位層で実行されます。
Stand-Alone BTNS weakens data origin authentication to continuity of association, namely the assurance that traffic on an SA continues to originate from the same unauthenticated source.
スタンドアロンBTNSは、協会、SA上のトラフィックが同じ認証されていないソースから発信し続けていること、すなわち保証の継続にデータ発信元認証を弱めます。
Channel-Bound BTNS relies on higher-layer authentication to provide data origin authentication of protected network traffic.
チャネル結合型BTNSは、保護されたネットワークトラフィックのデータ発信元認証を提供するために、上位層の認証に依存しています。
For the security services offered by IPsec that are listed in items 3 through 6, it is possible to establish secure IPsec connections with rogue peers via BTNS because authentication is not required. On the other hand, once a secure connection is established, the communication is protected by these security services in the same fashion as a connection established by conventional IPsec means.
3〜6の項目に記載されていたIPsecによって提供されるセキュリティサービスの場合は、認証が必要とされていないため、BTNSを経由して不正なピアとのセキュアなIPsec接続を確立することが可能です。安全な接続が確立される一方、通信は、従来のIPsecによって確立された接続と同じように、これらのセキュリティサービスによって保護されています。
The previous sections have described two ways of using BTNS: Stand-Alone (SAB) and Channel-Bound (CBB). Both of these can also be used either symmetrically, where neither party authenticates at the network layer, or asymmetrically, where only one party does not authenticate at the network layer. There are a number of cases to consider, based on combinations of the endpoint security capabilities of SAB, CBB, and conventional IKE authentication of an identity (denoted as AUTH below). The following tables show all of the combinations based on the capabilities of the two security endpoints:
前のセクションはBTNSを使用しての二つの方法を記載している：（SAB）スタンドアロンおよびチャネル結合（CBB）。これらのどちらもどちらか対称的に、いずれの当事者が一方の当事者だけがネットワーク層で認証されない非対称ネットワーク層、または、で認証する場合に使用することができます。 SAB、CBB、および（以下AUTHと表記）アイデンティティの従来のIKE認証のエンドポイントセキュリティ機能の組み合わせに基づいて、考慮すべき例がいくつかあります。以下の表は、2つのセキュリティエンドポイントの機能に基づいて、組み合わせの全てを示しています。
| AUTH | SAB | | CB-AUTH | CBB |
-----+-------+-------+ -------+---------+---------+
| | | | | |
AUTH | AUTH | A-SAB | CB-AUTH| CB-AUTH | A-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
| | | | | |
SAB | A-SAB | S-SAB | CBB | A-CBB | S-CBB |
| | | | | |
-----+-------+-------+ -------+---------+---------+
No Channel Binding With Channel Binding
何チャンネルは、チャネルバインディングと結合しません
There are six operating modes that result from the combinations. The first three modes consist of network-layer authentication schemes used without channel binding to higher-layer authentication:
それらの組み合わせからなる6つの動作モードがあります。最初の3つのモードは上位層認証に結合チャネルなしで使用ネットワーク層認証方式で構成されます。
1. AUTH: both parties provide and authenticate conventional, IKE-supported identities.
1. AUTH：両当事者が提供し、従来、IKE-サポートアイデンティティを認証します。
2. Symmetric SAB (S-SAB): neither party authenticates with a conventional, IKE-supported identity.
2.対称SAB（S-SAB）：いずれの当事者は、従来、IKE-サポートIDで認証されます。
3. Asymmetric SAB (A-SAB): one party does not authenticate with a conventional, IKE-supported identity, but the other side does authenticate with such an identity.
3.非対称SAB（-SAB）：一方の当事者は、従来、IKE-サポートIDで認証しないが、他の側は、同一で認証ありません。
The following three modes combine the network-layer behaviors with channel binding to higher-layer authentication credentials:
以下の3つのモードは上位層の認証証明書への結合チャネルとネットワーク層の動作を組み合わせました：
4. CB-AUTH: channel binding is used and both parties authenticate with conventional, IKE-supported identities.
4. CB-AUTH：チャネル結合が使用され、両当事者は、従来、IKE-サポートアイデンティティで認証されています。
5. Symmetric CBB (S-CBB): neither party authenticates with a conventional, IKE-supported identity, but channel binding is used to bind the SAs to higher-layer authentication operations.
5.対称CBB（S-CBB）は：当事者は、従来、IKE-サポートアイデンティティを認証するが、チャネル結合は、上位層認証操作にSAを結合するために使用されます。
6. Asymmetric CBB (A-CBB): asymmetric SAB (A-SAB) used with channel binding; at the network layer, one party does not authenticate with a conventional, IKE-supported identity, but the other party does authenticate with such an identity. Channel binding is used to bind the SA to higher-layer authentication operations.
前記非対称CBB（-CBB）：チャネル結合を使用する不斉SAB（-SAB）。ネットワーク層で、一方の当事者は、従来、IKE-サポートIDで認証しませんが、他の当事者は、そのようなアイデンティティで認証ありません。結合チャネルは、上位層の認証操作にSAを結合するために使用されます。
There are three security mechanisms involved in BTNS with channel binding:
チャネル結合とBTNSに関わる3つのセキュリティ・メカニズムがあります。
3. the connection latching plus channel binding mechanisms that bind the higher-layer authentication credentials with the secure IPsec channel.
3.接続は、ラッチプラスチャネルは、安全なIPsecのチャネルと上位層認証クレデンシャルを結合機構に結合します。
Authentication at both the network and higher layers can be either bidirectional (both peers are authenticated) or unidirectional (one of the two peers does not authenticate). In contrast, when channel binding is used, it must be applied at both ends of the communication to prevent MITM attacks. Existing channel binding mechanisms and APIs for this purpose (e.g., as defined in GSS-API [10]) mandate the exchange and verification of the channel binding values at both ends to ensure that correct, non-spoofed channel characteristics are bound to the higher-layer authentication.
ネットワークと上位層の両方で認証が（二ピアの1つが認証しない）、双方向（両方のピアが認証されている）、または単方向のどちらかであることができます。チャネル結合が使用される場合は対照的に、MITM攻撃を防止するために、通信の両端に印加されなければなりません。既存のチャネルバインディングこの目的のためのメカニズムとAPI（例えば、GSS-APIで定義されるように[10]）委任チャンネルの交換及び検証が正しい、非スプーフィングチャネル特性が高いに結合されることを確実にするために両端の値を結合-layer認証。
Note: When any Stand-Alone BTNS (SAB) or Channel-Bound BTNS (CBB) is used without being qualified as symmetric or asymmetric, the symmetric mode is the intended default meaning.
注意：任意のスタンドアロンBTNS（SAB）またはチャンネル・バウンドBTNS（CBB）は、対称または非対称の資格せずに使用すると、対称モードは、意図したデフォルトの意味があります。
BTNS is intended for services open to the public but for which protected associations are desired, and for services that can be authenticated at higher layers in the protocol stack. BTNS can also provide some level of protection for private services when the alternative BTNS is no protection at all.
BTNSは、一般に公開サービスのためのものではなく、対象の関連付けは、所望の、およびプロトコルスタックの上位層で認証することができるサービスのためされている保護されています。代替BTNSはまったく保護されていないときBTNSは、プライベートなサービスのためにあるレベルの保護を提供することができます。
BTNS uses the IPsec protocol suite, and therefore should not be used in situations where IPsec and specifically IKE are unsuitable. IPsec and IKE incur additional computation overhead, and IKE further requires message exchanges that incur round-trip latency to setup security associations. These may be undesirable in environments with limited computational resources and/or high communication latencies.
BTNSは、IPsecプロトコルスイートを使用し、したがって、IPsecと特異的にIKEが不適切である状況で使用すべきではありません。 IPsecとIKEは、追加の計算のオーバーヘッドが発生し、IKEはさらに、セットアップのセキュリティアソシエーションにラウンドトリップ遅延を招くメッセージ交換が必要です。これらは、限られた計算資源及び/又は高い通信待ち時間を有する環境において望ましくない場合があります。
This section provides an overview of the types of applications suitable for various modes of BTNS. The next two sections describe the overall benefits and vulnerabilities, followed by the applicability analysis for each BTNS mode. The applicability statement covers only the four BTNS-specific modes; the AUTH and CB-AUTH modes are out of scope for this discussion.
このセクションでは、BTNSの様々なモードに適したアプリケーションの種類の概要を提供します。次の2つのセクションでは、各BTNSモードの適用可能性の分析に続いて、全体的な利益や脆弱性について説明します。適用文は、わずか4 BTNS固有モードをカバー。 AUTHとCB-AUTHモードは、この議論の範囲外です。
BTNS protects security associations after they are established by reducing vulnerability to attacks from parties that are not participants in the association. BTNS-based SAs protect network and transport layers without requiring network-layer authentication. BTNS can be deployed without pre-deployment of authentication material for IPsec or pre-shared information and can protect all transport layer protocols using a common mechanism.
それらが関連して、参加者でない関係者からの攻撃に対する脆弱性を減らすことによって確立された後BTNSは、セキュリティアソシエーションを保護します。 BTNSベースのSAは、ネットワーク層認証を必要とせずにネットワークおよびトランスポート層を保護します。 BTNSは、IPsecまたは事前共有情報の認証材の展開前なしで展開することができ、共通のメカニズムを使用して、すべてのトランスポート層プロトコルを保護することができます。
BTNS also helps protect systems from low-effort attacks on higher-layer sessions or connections that disrupt valuable services or resources. BTNS raises the level of effort for many types of network- and transport-layer attacks. Simple transport layer packet attacks are rejected because the malicious packet or packets are not part of an IPsec SA. The attacker is instead forced to establish an unauthenticated IPsec SA and a transport connection for SAB, requiring the attacker to perform as much work as a host engaging in the higher-layer communication. SAB thus raises the effort for a DDoS (Distributed Denial of Service) attack to that of emulating a flash crowd. For open services, there may be no way to distinguish such a DDoS attack from an actual flash crowd.
BTNSはまた、価値あるサービスやリソースを混乱させる上位層セッションまたは接続の低努力の攻撃からシステムを保護します。 BTNSはネットワーク - およびトランスポート層の攻撃の多くの種類のための努力のレベルを上げます。悪意のあるパケットまたはパケットは、IPsecのSAの一部ではないので、単純なトランスポート層パケット攻撃は拒否されます。攻撃者は、代わりに、非認証のIPsec SAと上位層の通信に従事ホスト限り多くの作業を実行するために、攻撃者を必要とSABのためのトランスポート接続を確立するように強制されます。 SABは、このようにフラッシュ・クラウドをエミュレートすると（サービス拒否の分散）のDDoS攻撃のための努力を発生させます。オープンサービスについては、実際のフラッシュ群衆から、このようなDDoS攻撃を区別する方法はありません。
BTNS also allows individual security associations to be established for protection of higher-layer traffic without requiring pre-deployed authentication credentials.
BTNSは、個々のセキュリティアソシエーションが事前に配備認証証明書を必要とせずに、上位層のトラフィックの保護のために確立することができます。
BTNS removes the requirement that every IPsec SA be authenticated. Hosts connecting to BTNS hosts are vulnerable to communicating with a masquerader throughout the association for SAB, or until higher layers provide additional authentication for CBB. As a result, authentication data (e.g., passwords) sent to a masquerading peer could be disclosed to an attacker. This is a deliberate design tradeoff; in BTNS, network- and transport-layer access is no longer controlled by the identity presented by the other host, opening hosts to potential masquerading and flash crowd attacks. Conversely, BTNS can secure connections to hosts that are unable to authenticate at the network layer, so the network and transport layers are more protected than can be achieved via higher-layer authentication alone.
BTNSは、すべてのIPsec SAが認証される必要がなくなります。 SAB協会を通して成り済ましと通信に対して脆弱であるか、またはより高い層までBTNSホストに接続するホストは、CBBのために追加の認証を提供します。結果として、マスカレードピアに送信される認証データ（例えば、パスワード）を攻撃者に公開することができます。これは意図的な設計上のトレードオフです。 BTNSで、ネットワーク - およびトランスポート層のアクセスは、もはや潜在的なマスカレードとフラッシュ群衆攻撃にホストを開いて、他のホストが提示する身元によって制御されていません。逆に、BTNSは、ネットワーク層で認証できないホストへの接続を確保することができるので、ネットワーク層とトランスポート層は、単独で、上位層認証を介して達成することができるよりも保護されています。
Lacking network-layer authentication information, other means must be used to provide access control for local resources. Traffic selectors for the BTNS SPD entries can be used to limit which interfaces, address ranges, and port ranges can access BTNS-enabled services. Rate limiting can further restrict resource usage. For SAB, these protections need to be considered throughout associations, whereas for CBB they need be present only until higher-layer protocols provide the missing authentication. CBB also relies on the effectiveness of the binding of higher-layer authentication to the BTNS network association.
ネットワーク層の認証情報を欠いている、他の手段は、ローカルリソースに対するアクセス制御を提供するために使用する必要があります。 BTNS SPDエントリのトラフィックセレクタはBTNS対応サービスにアクセスできるインターフェース、アドレス範囲、およびポート範囲を制限するために使用することができます。レート制限は、さらにリソース使用量を制限することができます。 CBBのために、彼らは上位層プロトコルが存在しない認証を提供するまでの間だけ存在する必要があるのに対し、SABのために、これらの保護は、協会全体で検討する必要があります。 CBBもBTNSネットワークアソシエーションの上位層認証の結合の有効性に依存しています。
SAB is intended for applications that are unable to use IKE-compatible authentication credentials and do not employ higher-layer authentication or other security protection. SAB is also suitable when the identities of either party are not important or are deliberately omitted, but IPsec security services are desired (see Section 3.2). SAB is particularly applicable to long-lived connections or sessions for which assurance that the entity at the other end of the connection has not changed may be a good enough substitute for the lack of authentication. This section discusses symmetric and asymmetric SAB.
SABは、IKE互換の認証資格情報を使用することができず、上位層認証または他のセキュリティ保護を使用しないアプリケーションを対象としています。 SABは、いずれかの当事者のアイデンティティが重要ではないか、故意に省略されている場合にも適しているが、IPsecセキュリティサービスは、（3.2節を参照）が望まれています。 SABは、接続のもう一方の端のエンティティが変更されていないという保証は、認証の欠如のために十分良い代替とすることができるため長寿命の接続またはセッションに適用可能です。このセクションでは、対称および非対称のSABについて説明します。
Symmetric SAB (S-SAB) is applicable when both parties lack network-layer authentication information and that authentication is not available from higher-layer protocols. S-SAB can still provide some forms of protection for network and transport protocols, but does not provide authentication beyond continuity of association. S-SAB is useful in situations where transfer of large files or use of other long-lived connections would benefit from not being interrupted by attacks on the transport connection (e.g., via a false TCP RST), but the particular endpoint identities are not important.
両当事者は、ネットワーク層の認証情報が不足していると、認証が上位層プロトコルから利用できない場合に対称SAB（S-SAB）が適用されます。 S-SABは、まだネットワークおよびトランスポートプロトコルの保護のいくつかの形態を提供することができますが、協会の継続を超えて認証を提供していません。 S-SABは、他の長命の接続の大きなファイルの転送や使用は（偽のTCP RSTを経由して、例えば）トランスポート接続への攻撃によって中断されていないから利益を得るであろう状況で有用であるが、特定のエンドポイントのアイデンティティは重要ではありません。
Open services, such as web servers, and peer-to-peer networks could utilize S-SAB when their identities need not be authenticated but their communication would benefit from protection. Such services might provide files that are either not validated or validated by other means (e.g., published hashes). These transmissions present a target for off-path attacks that could be mitigated by S-SAB. S-SAB may also be useful for protecting voice-over-IP (VoIP) traffic between peers, such as direct calls between VoIP clients.
自分の身元を認証する必要がないとき、このようなWebサーバ、およびピア・ツー・ピア・ネットワークなどのオープンサービスは、S-SABを利用することができるが、その通信が保護の恩恵を受けるだろう。このようなサービスはいずれかの検証または他の手段（例えば、ハッシュ公開）によって検証されていないファイルを提供するかもしれません。これらの送信はS-SABによって軽減することができ、オフパス攻撃のターゲットを提示します。 S-SABはまた、VoIPクライアント間の直接の呼び出しなどのピアとの間のボイスオーバーIP（VoIP）トラフィックを保護するために有用である可能性があります。
S-SAB is also useful in protecting any transport protocol when the endpoints do not deploy authentication, for whatever reason. This is the case for BGP TCP connections between core routers, where the protection afforded by S-SAB is better than no protection at all, even though BGP is not intended as an open service.
S-SABは、エンドポイントが何らかの理由で、認証を導入していない時に任意のトランスポートプロトコルを保護するのにも便利です。これは、S-SABによる保護は、BGPはオープンサービスとして意図されていなくても、まったく保護よりも優れているコアルータ間のBGP TCP接続のためのケースです。
S-SAB can also serve as an intermediate step towards S-CBB. S-SAB is the effective result when an IPsec channel is used (via connection latching), but the higher-layer authentication is not bound to the IPsec SAs within the channel.
S-SABはまた、S-CBBに向かって中間ステップとして役立つことができます。 S-SABは、IPsecチャネルを使用した場合（ラッチ接続を介して）効果的な結果であるが、上位層認証は、チャネル内のIPsec SAのにバインドされていません。
Asymmetric SAB (A-SAB) allows one party lacking network-layer authentication information to establish associations with another party that possesses authentication credentials for any applicable IKE authentication mechanism.
非対称SAB（A-SAB）は一方の当事者は、いつでも、適用IKE認証メカニズムのための認証資格情報を所有している別の相手とのアソシエーションを確立するために、ネットワーク層の認証情報を欠くことができます。
Asymmetric SAB is useful for protecting transport connections for open services on the Internet, e.g., commercial web servers, etc. In these cases, the server is typically authenticated by a widely known CA, as is done with TLS at the application layer, but the clients need not be authenticated [4]. Although this may result in IPsec and TLS being used on the same connection, this duplication of security services at different layers is necessary when protection is required from the sorts of spoofing attacks described in Section 2 (e.g., TLS cannot prevent a spoofed TCP RST, as the RST is processed by TCP rather than being passed to TLS).
非対称SABは、アプリケーション層でTLSで行われるようにこれらの例では、サーバは一般的に、広く知られているCAによって認証されるなど、商用Webサーバなど、インターネット上のオープンサービスのための交通機関の接続を保護するのに有用であるが、クライアントが認証される必要がない[4]。これは、IPsecとTLSは同じ接続で使用される可能性がありますが保護が第2節で説明したスプーフィング攻撃の種類から必要とされている場合、異なる層でのセキュリティサービスのこの重複は必要である（例えば、TLSは、偽装されたTCP RSTを防ぐことができません、 RSTは、TCPによって処理されるのではなくTLSに渡されるものとして）。
A-SAB can also secure transport for streaming media such as would be used by webcasts for remote education and entertainment.
-SABはまた、このようなメディアをストリーミングするための安全な輸送は、遠隔教育や娯楽のためのWebキャストで使用されることができます。
CBB allows hosts without network-layer authentication information to cryptographically bind BTNS-based IPsec SAs to authentication at higher layers. CBB is intended for applications that employ higher-layer authentication but that also benefit from additional network-layer security. CBB provides network-layer security services without requiring authentication at the network layer. This enables IPsec security services for applications that have IKE-incompatible authentication credentials. CBB allows IPsec to be used with authentication mechanisms not supported by IKE and frees higher-layer applications and protocols from duplicating security services already available in IPsec.
CBBは、ネットワーク層認証情報なしでホストが上位層で認証にバインドBTNSベースのIPsec SAを暗号ことを可能にします。 CBBは、上位層の認証を採用するが、それはまた、追加のネットワーク層セキュリティの恩恵を受けるアプリケーションを対象としています。 CBBは、ネットワーク層で認証を必要とせずにネットワーク層のセキュリティサービスを提供します。これは、IKE-互換性のない認証資格情報を持っているアプリケーションのためのIPsecセキュリティサービスを可能にします。 CBBは、IPsecがIKEによってサポートされていない認証メカニズムで使用することを可能にするとIPsecですでに利用可能なセキュリティ・サービスを複製するから、上位層のアプリケーションとプロトコルを解放します。
Symmetric CBB integrates channel binding with S-SAB, as does asymmetric CBB with A-SAB. In both cases, the target applications have similar characteristics at the network layer to their non-channel-binding counterparts. The only significant difference is the binding of authentication credentials at a higher layer to the resulting IPsec channels.
-SAB非対称CBBと同様に対称CBBは、S-SABとの結合チャネルを統合します。両方の場合において、ターゲット・アプリケーションは、それらの非チャネル結合相手へのネットワーク層に類似した特性を有しています。唯一の有意差は得られたIPsecチャネルに、より高い層で認証資格証明の結合です。
Although the modes of CBB refer to the authentication at the network layer, higher-layer authentication can also be either asymmetric (one-way) or symmetric (two-way). Asymmetric CBB can be used to complement one-way authentication at a higher layer by providing one-way authentication of the opposite direction at the network layer. Consider an application with one-way, client-only authentication. The client can utilize A-CBB where the server must present IKE-authenticated credentials at the network layer. This form of A-CBB achieves mutual authentication, albeit at separate layers. Many remote file system protocols, such as iSCSI and NFS, fit into this category and can benefit from channel binding with IPsec for better network-layer protection, including prevention of MITM attacks.
CBBのモードはネットワーク層で認証を指すが、より高い層の認証も非対称（片道）または対称（双方向）のいずれかであり得ます。非対称CBBは、ネットワーク層での逆方向の一方向認証を提供することによって、より高い層で一方向認証を補完するために使用することができます。一方向、クライアントのみの認証を使用してアプリケーションを考えてみましょう。クライアントは、サーバがネットワーク層でIKE認証資格情報を提示する必要があり、CBBを利用することができます。 A-CBBのこの形態は、別々の層であるが、相互認証を達成します。このようiSCSIとNFSのような多くのリモートファイルシステムプロトコルは、この範疇に収まるとMITM攻撃の防止を含む、より良いネットワーク層の保護のためにIPsecとの結合チャネルの恩恵を受けることができます。
Mechanisms and interfaces for BTNS channel binding with IPsec are discussed in further detail in [26].
IPSecを結合BTNSチャネルのためのメカニズムとのインタフェースは、[26]においてさらに詳細に議論されます。
The following is a summary of the properties of each type of BTNS, based on the previous subsections:
以下は、前のサブセクションに基づいBTNSの各タイプの特性の要約です。
SAB CBB
--------------------------------------------------------------
Uses Open services Same as SAB but with
Peer-to-peer higher-layer auth.,
Zero-config Infrastructure e.g., iSCSI [19], NFSv4 [21]
Vuln. Masqueraders Masqueraders until bound Needs data rate limit Needs data rate limit Load on IPsec Load on IPsec Exposure to open access
Vuln。 Masqueraders Masqueradersバウンドニーズのデータレート制限は、アクセスを開くためのIPsec暴露でのIPsec負荷のデータレート制限荷重が必要になるまで
Benefit Protects L3 & L4 Protects L3 & L4 Avoids all auth. keys Avoids L3 auth. keys Full auth. once bound
利点は、L3＆L4はL3＆L4は、すべての認証を回避保護保護します。キーは、L3の認証を回避します。キーのフルAUTH。一度バウンド
Most of the potential vulnerabilities in the above table have been discussed in previous sections of this document; some of the more general issues, such as the increased load on IPsec processing, are addressed in the Security Considerations section of this document.
上記表中の潜在的な脆弱性のほとんどは、この文書の前のセクションで説明されています。このようIPsec処理の負荷増大など、より一般的な問題のいくつかは、このドキュメントのSecurity Considerations部で対処されています。
This section describes the threat models for BTNS and discusses other security issues based on the threat models for different modes of BTNS. Some of the issues were mentioned previously in the document but are listed again for completeness.
このセクションでは、BTNSのための脅威モデルを説明し、BTNSの異なるモードのための脅威モデルに基づいて、他のセキュリティ問題について説明します。問題の一部は、文書で前述されたが、完全を期すために再び記載されています。
BTNS is intended to protect sessions from a variety of threats, including on-path, man-in-the-middle attacks after key exchange, and off-path attacks. It is intended to protect the contents of a session once established, but does not protect session establishment itself. This protection has value because it forces the attacker to target connection establishment as opposed to waiting for a more convenient time; this is of particular value for long-lived sessions.
BTNSは、man-in-the-middle攻撃は、鍵交換、およびオフ・パス攻撃した後、上のパスを含む、さまざまな脅威からセッションを保護することを意図しています。一度確立されたセッションの内容を保護することを意図されていますが、セッション確立自体を保護することはできません。それがより便利に時間を待っているとは対照的に、接続確立をターゲットとする攻撃者が強制的にので、この保護は、値を持っています。これは、長寿命のセッションのために特に価値があります。
BTNS is not intended to protect the key exchange itself, so this presents an opportunity for a man-in-the-middle attack or a well-timed attack from other sources. Furthermore, Stand-Alone BTNS is not intended to protect the endpoint from nodes masquerading as legitimate clients of a higher-layer protocol or service. Channel-Bound BTNS can protect from such masquerading, though at a later point after the security association is established, as a masquerade attack causes a client authentication failure at a higher layer.
BTNSは、鍵交換自体を保護することを意図していないので、これはman-in-the-middle攻撃や他のソースからの時宜を得た攻撃の機会を提供します。また、スタンドアロンBTNSは、上位層プロトコルまたはサービスの正当なクライアントとしてなりすましノードからエンドポイントを保護することを意図していません。チャネル結合型BTNSはマスカレード攻撃は、上位層でのクライアント認証の失敗の原因として、セキュリティアソシエーションが確立された後に、後の時点で、しかし、マスカレードなどから保護することができます。
BTNS is also not intended to protect from DoS (Denial of Service) attacks that seek to overload a CPU performing authentication or other security computations, nor is BTNS intended to provide protection from configuration mistakes. These latter two threat assumptions are also the case for IPsec.
BTNSは、認証やその他のセキュリティの計算を実行するCPUが過負荷にしようとのDoS（サービス拒否）攻撃から保護することを意図していない、またBTNSは、設定ミスからの保護を提供することを意図しています。これらの後者の2つの脅威の仮定はまた、IPsecのケースです。
The following sections discuss the implications of the threat models in more details.
次のセクションでは、より詳細に脅威モデルの含意を議論します。
As with any aspect of network security, the use of BTNS must not interfere with other security services. Within IPsec, the scope of BTNS is limited to the SPD and PAD entries that explicitly specify BTNS and to the resulting SAD entries. It is incumbent on system administrators to deploy BTNS only where safe, preferably as an alternative to the use of "bypass" SPD entries that exempt specified traffic from IPsec cryptographic protection. In other words, BTNS should be used only as a substitute for no security, rather than as a substitute for stronger security. When the higher-layer authentication required for CBB is not available, other methods, such as IP address filtering, can help reduce the vulnerability of SAB to exposure to anonymous access.
ネットワークセキュリティのあらゆる側面と同様に、BTNSの使用は、他のセキュリティ・サービスを妨害してはなりません。 IPsecの内、BTNSの範囲は、明示的BTNSを指定SPDとPADのエントリに、得られたSADエントリに制限されています。好ましくは、IPsecの暗号保護から指定されたトラフィックを免除「バイパス」SPDエントリを使用する代わりとして、場合にのみ安全なBTNSを展開するために、システム管理者の義務です。言い換えれば、BTNSはセキュリティなしの代用としてではなく、強固なセキュリティの代用として使用する必要があります。 CBBに必要な上位層認証が利用できない場合には、そのようなIPアドレスフィルタリングなどの他の方法は、匿名アクセスへの暴露にSABの脆弱性を減らすことができます。
Previous sections have described how CBB can counter MITM and masquerader attacks, even though BTNS does not protect key exchange and does not authenticate peer identities at the network layer. Nonetheless, there are some security issues regarding CBB that must be carefully evaluated before deploying BTNS.
前のセクションでは、CBBはBTNSが鍵交換を保護しないと、ネットワーク層でピアのアイデンティティを認証していないにもかかわらず、MITMや成り済まし攻撃に対抗する方法を説明してきました。それにもかかわらず、慎重にBTNSを展開する前に評価されなければならないCBBに関するいくつかのセキュリティ問題があります。
For regular IPsec/IKE, a man in the middle cannot subvert IKE authentication, and hence an attempt to attack an IPsec SA via use of two SAs concatenated by the attacker acting as a traffic-forwarding proxy will cause an IKE authentication failure. On the other hand, a man-in-the-middle attack on IPsec with CBB is discovered later. With CBB, the IKE protocol will succeed because it is unauthenticated, and the security associations will be set up. The man in the middle will not be discovered until the higher-layer authentication fails. There are two security concerns with this approach: possible exposure of sensitive authentication information to the attackers, and resource consumption before attacks are detected.
通常のIPsecの/ IKEの場合は、真ん中の男がIKE認証を覆すことができない、したがって、トラフィック転送プロキシとして動作し、攻撃者により連結2つのSAを使用することによってIPsecのSAを攻撃しようとすると、IKE認証の失敗の原因となります。一方、CBBとのIPsecでman-in-the-middle攻撃が後に発見されます。それが認証されていないで、セキュリティアソシエーションが設定されますので、CBBでは、IKEプロトコルが成功します。上位層の認証が失敗するまで、真ん中の男性が発見されることはありません。攻撃が検出される前に敏感な攻撃者に認証情報、およびリソース消費の曝露の可能性：このアプローチには2つのセキュリティ上の懸念があります。
The exposure of information depends on the higher-layer authentication protocols used in applications. If the higher-layer authentication requires exchange of sensitive information (e.g., passwords or password-derived materials) that are directly useful or can be attacked offline, an attacker can gain such information even though the attack can be detected. Therefore, CBB must not be used with higher-layer protocols that may expose sensitive information during authentication exchange. For example, Kerberos V AP exchanges would leak little other than the target's krb5 principal name, while Kerberos V AS exchanges using PA-ENC-TIMESTAMP pre-authentication would leak material that can then be attacked offline. The latter should not be used with BTNS, even with Channel Binding. Further, the ways in which BTNS is integrated with the higher-layer protocol must take into consideration vulnerabilities that could be introduced in the APIs between these two systems or in the information that they share.
情報の暴露は、アプリケーションで使用される上位層の認証プロトコルに依存します。上位層認証は、機密情報の交換を必要とする場合（例えば、パスワードまたはパスワード由来の材料）を直接有用であるか、またはオフラインで攻撃することができ、攻撃者は、攻撃を検出することができるにもかかわらず、そのような情報を得ることができます。したがって、CBBは、認証交換中に機密情報を公開することができる上位層プロトコルと一緒に使用してはなりません。例えば、ケルベロスV AP交換はケルベロスVながらオフラインで攻撃することができる材料を漏らすことになるPA-ENC-TIMESTAMP事前認証を使用して交換として、ターゲットのkrb5のプリンシパル名より少ない他のリークになります。後者はさらにチャンネルバインディングで、BTNSを使用するべきではありません。さらに、BTNSは、上位層プロトコルと統合された方法は、これら2つのシステム間のAPI、またはそれらが共有する情報で導入することができる検討の脆弱性に入れなければなりません。
The resource consumption issue is addressed in the next section on DoS attacks.
リソース消費の問題は、DoS攻撃の次のセクションで扱われています。
A consequence of BTNS deployment is that more traffic requires cryptographic operations; these operations increase the computation required in IPsec implementations that receive protected traffic and/or verify incoming traffic. That additional computation raises vulnerability to overloading, which may be the result of legitimate flash crowds or a DoS or DDoS attack. Although this may itself present a substantial impediment to deployment, it is an issue for all cryptographically protected communication systems. This document does not address the impact BTNS has on such increases in required computation.
BTNSの展開の結果は、より多くのトラフィックが暗号化操作を必要とすることです。これらの操作は、トラフィックを保護および/または着信トラフィックを確認する受信IPsec実装に必要な計算を高めます。その追加の計算は、正当なフラッシュ群衆やDoSまたはDDoS攻撃攻撃の結果である可能性がある、過負荷状態にする脆弱性を提起します。これは展開にかなりの障害を自分自身を提示してもよいが、それはすべて暗号で保護された通信システムのための問題です。この文書は、BTNSは、必要な計算におけるこのような増加に対して有する影響に対処していません。
The effects of the increased resource consumption are twofold. The consumption raises the level of effort for attacks such as MITM, but also consumes more resources to detect such attacks and to reject spoofed traffic. At the network layer, proper limits and access controls for resources should be set up for all BTNS SAs. CBB SAs may be granted increased resource access after the higher-layer authentications succeed. The same principles apply to the higher-layer protocols that use CBB SAs. Special care must be taken to avoid excessive resource usage before authentication is established in these applications.
増加したリソース消費の影響は2つあります。消費量は、そのようなMITMなどの攻撃のための努力のレベルを上げ、また、そのような攻撃を検出すると、偽装されたトラフィックを拒否するために、より多くのリソースを消費します。ネットワーク層では、資源のための適切な制限やアクセス制御は、すべてのBTNSのSA用に設定する必要があります。上位層の認証が成功した後、CBB SAが増加し、リソースへのアクセスを許可することができます。同じ原理がCBBのSAを使用する上位層プロトコルに適用されます。特別なケアは、認証がこれらのアプリケーションに確立される前に、過剰なリソース使用量を避けるようにしなければなりません。
The use of SAB by a service implies that the service is being offered for open access, since network-layer authentication is not performed. SAB should not be used with services that are not intended to be openly available.
サービスによってSABの使用は、ネットワーク層認証が行われないため、サービスは、オープンアクセスのために提供されていることを意味します。 SABは公然と利用できるように意図されていないサービスを使用するべきではありません。
This document does not consider ICMP attacks because the use of BTNS does not change the existing IPsec guidelines on ICMP traffic handling [8]. BTNS focuses on the authentication part of establishing security associations. BTNS does not alter the IPsec traffic processing model and protection boundary. As a result, the entire IPsec packet processing guidelines, including ICMP processing, remain applicable when BTNS is added to IPsec.
BTNSの使用は取り扱いICMPトラフィック上の既存のIPsecガイドラインを変更しないので、この文書では、ICMP攻撃を考慮していない[8]。 BTNSは、セキュリティアソシエーションを確立するための認証部分に焦点を当てています。 BTNSは、IPsecトラフィック処理モデルと保護境界を変更しません。 BTNSは、IPsecのに追加されたときに結果として、ICMP処理を含む全体のIPsecパケット処理ガイドラインは、適用可能なままです。
BTNS allows systems to accept and establish security associations with peers without authenticating their identities. This can enable functionality similar to "Leap of Faith" authentication utilized in other security protocols and applications such as the Secure Shell Protocol (SSH) [29].
BTNSはシステムが受け入れ、自分のアイデンティティを認証することなく、ピアとセキュリティアソシエーションを確立することができます。これは、セキュアシェルプロトコル（SSH）などの他のセキュリティプロトコルとアプリケーションで利用「リープ信仰の」認証[29]と同様の機能を有効にすることができます。
SSH implementations are allowed to accept unknown peer credentials (host public keys) without authentication, and these unauthenticated credentials may be cached in local databases for future authentication of the same peers. Similar to BTNS, such measures are allowed due to the lack of "widely deployed key infrastructure" [29] and to improve ease of use and end-user acceptance.
SSHの実装は認証なし（公開鍵をホスト）、未知のピア資格情報を受け入れることを許可されており、これらの非認証の資格情報が同じピアの将来の認証にローカルデータベースにキャッシュすることができます。 BTNSと同様、このような対策は、[29]により、「広く展開されている鍵インフラストラクチャ」の欠如のために許可されていると使いやすさとエンドユーザーの受け入れを向上させます。
There are subtle differences between SSH and BTNS regarding Leap of Faith, as shown in the following table:
次の表に示すように、信仰のリープに関するSSHとBTNSの間に微妙な違いがあります：
| SSH | BTNS |
-------------------------------+---------+---------+
Accept unauthenticated | Allowed | Allowed |
credentials | | |
-------------------------------+---------+---------+
Options/Warnings to reject | Yes | No |
unauthenticated credentials | | |
-------------------------------+---------+---------+
Cache unauthenticated |Required | Allowed |
credential for future refs | | |
-------------------------------+---------+---------+
SSH requires proper warnings and options in applications to reject unauthenticated credentials, while BTNS accepts such credentials automatically when they match the corresponding policy entries. Once SSH accepts a credential for the first time, that credential should be cached and can be reused automatically without further warnings. BTNS credentials can be cached for future use, but there is no security advantage to doing so, as a new unauthenticated credential that is allowed by the policy entries will be automatically accepted.
彼らは、対応するポリシーエントリと一致したときにBTNSは自動的に、このような資格情報を受け入れながら、SSHは、認証されていない資格情報を拒否するアプリケーションで適切な警告とオプションが必要です。 SSHは、初めて資格を受け入れたら、その資格をキャッシュすると、さらに警告なしに自動的に再利用することができます。 BTNS資格は、将来の使用のためにキャッシュすることができますが、ポリシーエントリで許可され、新しい未認証の資格情報が自動的に受け入れられるようにはセキュリティ上の利点は、そうすることにはありません。
In addition, BTNS does not require IPsec to reuse credentials in a manner similar to SSH. When IPsec does reuse unauthenticated credentials, there may be implementation advantages to caching them.
また、BTNSはSSHと同様の方法で資格情報を再利用するためにIPsecを必要としません。 IPsecは認証されていない資格情報を再利用しない場合は、それらをキャッシュするために、実装上の利点があるかもしれません。
SSH-style credential caching for reuse with SAB could be addressed by future extension(s) to BTNS; such extension(s) would need to provide warnings about unauthenticated credentials and a mechanism for user acceptance or rejection of them in order to establish a level of authentication assurance comparable to SSH's "Leap of Faith". Such extension(s) would also need to deal with issues caused by the absence of identities in BTNS. At best, a cached BTNS credential reauthenticates the network-layer source of traffic when the credential is reused -- in contrast, SSH credential reuse reauthenticates an identity.
SABと再利用のためのSSHスタイルの資格情報のキャッシュはBTNSへの将来の拡張（S）によって対処することができ、そのような拡張（複数可）認証されていない証明書とSSHの「信仰の飛躍」に匹敵する認証保証レベルを確立するために、ユーザーの受け入れやそれらの拒絶のためのメカニズムについての警告を提供する必要があります。このような拡張機能（複数可）もBTNSにおけるアイデンティティの欠如によって引き起こされる問題に対処する必要があります。対照的に、SSH資格の再利用は、アイデンティティを再認証 - 最高の状態で、キャッシュされたBTNS資格は、資格情報が再利用されるトラフィックのネットワーク層ソースを再認証します。
Network-layer reauthentication for SAB is further complicated by:
SABのためのネットワーク層の再認証はさらに複雑です。
o the ability of NATs to cause multiple independent network-layer sources of traffic to appear to be one source (potentially requiring acceptance and caching of multiple BTNS credentials),
Oトラフィックの複数の独立したネットワーク層のソースを引き起こすのNATの機能が一つのソースであると思われる（潜在的に複数のBTNS資格情報の受け入れ及びキャッシングを必要とします）、
o the ability of multihoming to cause one network-layer source of traffic to appear to be multiple sources (potentially triggering unexpected warnings and requiring re-acceptance of the same BTNS credential), and
複数のソース（潜在的に、予期しない警告をトリガと同じBTNS資格の再受諾を必要とする）であることが表示されるトラフィックのネットワーク層のソースを引き起こすマルチホーミングの能力O、及び
o interactions with both mobility and address ownership changes (potentially requiring controlled BTNS credential reassignment and/or invalidation).
Oモビリティおよびアドレスの両方所有権の変更との相互作用は、（潜在的に制御されたBTNS資格再割当ておよび/または無効化を必要とします）。
These issues are left to be addressed by possible future work on the addition of "Leap of Faith" functionality to BTNS.
これらの問題はBTNSの「リープ信仰の」機能の追加の可能性今後の作業によって対処することが残されています。
In contrast, for CBB, credential caching and verification are usually done at the higher-layer protocols or applications. Caching credentials for CBB at the BTNS level is not as important because the channel binding will bind whatever credentials are presented (new or cached) to the higher-layer protocol identity.
対照的に、CBBため、資格キャッシュおよび検証は、通常、上位層プロトコルまたはアプリケーションで行われます。チャネルは、上位層プロトコルアイデンティティに（新規またはキャッシュされた）を提示しているものは何でも資格情報結合する結合のでBTNSレベルでのCBBの資格情報をキャッシュするように重要ではありません。
Each IPsec SA has a limited lifetime (defined as a time and/or byte count) and must be rekeyed or terminated when the lifetime expires. Rekeying an SA provides a small window of opportunity where an on-path attacker can step in and hijack the new SA created by rekeying by spoofing the victim during rekeying. BTNS, and particularly SAB, simplify this attack by removing the need for the attacker to authenticate as the victim or via the same non-BTNS PAD entry that was used by the victim for the original SA. CBB, on the other hand, can detect such attacks by detecting the changes in the secure channel properties.
各IPsecのSAは、（時間および/またはバイト数として定義される）限られた寿命を持っており、寿命が満了したときにリキーまたは終了する必要があります。 SAを再入力することで、パス攻撃者がでステップや再入力の際に被害者を偽装することによって再キーイングによって作成された新しいSAをハイジャックすることができます機会の小さなウィンドウを提供します。 BTNS、特にSAB、攻撃者は被害者として、元SAのために被害者が使用したのと同じ非BTNS PADのエントリを経由して認証するための必要性を除去することによって、この攻撃を簡素化します。 CBBは、一方で、安全なチャネル特性の変化を検出することによって、そのような攻撃を検出することができます。
This vulnerability is caused by the lack of inter-session binding or latching of IKE SAs with the corresponding credentials of the two peers. Connection latching, together with channel binding, enables such binding but requires higher-layer protocols or applications to verify consistency of identities and authentication across the two SAs.
この脆弱性は間のセッションが結合または2つのピアの対応する資格情報を使用してIKE SAのラッチの欠如によって引き起こされます。一緒に結合チャネルと、ラッチ接続は、そのような結合を可能にするが、2つのSAを横切って識別と認証の整合性を検証するために上位層プロトコルまたはアプリケーションを必要とします。
BTNS does not address errors of configuration that could result in increased vulnerability; such vulnerability is already possible using "bypass" SPD entries. SPD entries that allow BTNS must be explicitly flagged, and hence can be kept separate from SPD entries that do not allow BTNS, just as "bypass" SPD entries are separate from entries that create SAs with more conventional, stronger security.
BTNSは増加した脆弱性につながる可能性コンフィギュレーションのエラーに対処していません。こうした脆弱性は「バイパス」SPDエントリを使用して既に可能です。 BTNSが明示的にフラグを設定する必要があり、それゆえBTNSことはできませんSPDエントリから分離して保持することができます許可SPDエントリ、「バイパス」SPDエントリは、より従来の、強力なセキュリティとSAを作成するエントリから独立しているだけのよう。
There have been a number of related efforts in the IETF and elsewhere to reduce the configuration effort of deploying the Internet security suite.
インターネットセキュリティスイートを展開する設定の手間を軽減するために他の場所に関連するIETFでの努力と多くのがありました。
The IETF PKI4IPsec effort focused on providing an automatic infrastructure for the configuration of Internet security services, e.g., to assist in deploying signed certificates and CA information [9]. The IETF KINK effort focused on adapting Kerberos [13] for IKE, enabling IKE to utilize the Kerberos key distribution infrastructure rather than requiring certificates or shared private keys [18]. KINK takes advantage of an existing architecture for automatic key management in Kerberos. Opportunistic Encryption (OE) is a system for automatic discovery of hosts willing to do a BTNS-like encryption, with authentication being exchanged by leveraging existing use of the DNS [17]. BTNS differs from all three in that BTNS is intended to avoid the need for such infrastructure altogether, rather than to automate it.
IETF PKI4IPsec努力[9]署名された証明書およびCA情報を配置するのを助けるために、例えば、インターネットセキュリティサービスの構成の自動インフラストラクチャを提供することに焦点を当てました。 IETF KINK努力が必要証明書または共有秘密鍵[18]ではなく、ケルベロス鍵配布インフラストラクチャを利用するためにIKEを可能にする、IKEのKerberos [13]適応に焦点を当てました。 KINKは、Kerberosでの自動鍵管理のための既存のアーキテクチャを利用しています。日和見暗号化（OE）がDNS [17]の既存の使用を活用することによって交換される認証でBTNSのような暗号化をしても構わないと思っホストの自動検出のためのシステムです。 BTNSは完全なインフラの必要性を回避するためではなく、それを自動化するために意図されていることBTNSにすべての3つとは異なります。
This document was inspired by discussions on the IETF TCPM WG about the spoofed RST attacks on BGP routers and various solutions, as well as discussions in the NFSv4 and IPS WGs about how to better integrate with IPsec. The concept of BTNS was the result of these discussions as well as discussions with USC/ISI's T. Faber, A. Falk, and B. Tung, and discussions on the IETF SAAG (Security Area open meeting) mailing list and IPsec mailing list. The authors would like to thank the members of those WGs and lists, as well as the IETF BTNS BOFs and WG and its associated ANONsec mailing list (http://www.postel.org/anonsec) for their feedback -- in particular, Steve Kent, Sam Hartman, Nicolas Williams, and Pekka Savola.
この文書は、BGPルータおよび様々なソリューションの偽装されたRST攻撃に関するIETF TCPM WGの議論だけでなく、より良いのIPsecと統合する方法についてはNFSv4とIPSのWGでの議論に触発されました。 BTNSの概念は、これらの議論だけでなく、USC / ISIのT.フェーバー、A.フォーク、およびB.桐との議論、およびIETF SAAG（警備区域オープンミーティング）メーリングリストおよびIPsecメーリングリストでの議論の結果でした。特に - 著者は、これらのWGとリストのメンバーだけでなく、彼らのフィードバックのためのIETF BTNS BOFsとWG及びその関連ANONsecメーリングリスト（http://www.postel.org/anonsec）を感謝したいと思いますスティーブ・ケント、サム・ハートマン、ニコラス・ウィリアムズ、およびペッカSavola。
This document was prepared using 2-Word-v2.0.template.dot.
この文書は2-Word-v2.0.template.dotを用いて調製しました。
[1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[1] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[2] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[2] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[3] CERT Vulnerability Note VU#415294, "The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements", 4/20/2004.
[3] CERTの脆弱性ノートVU＃415294、2004年4月20日、「ボーダーゲートウェイプロトコルは、認証要件を指定せずに永続的なTCPセッションに依存しています」。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[4]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[5]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[6] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[7] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[7]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[8]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[9] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[9]コーバー、B.、RFC 4945、2007年8月 "のIKEv1 / ISAKMP、IKEv2の、およびPKIXのインターネットIPセキュリティPKIプロファイル"。
[10] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[10]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[11] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[11]メルニコフ、A.編、およびK. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[12] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[12]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、RFC 4272、2006年1月。
[13] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[13]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 4120、2005年7月。
[14] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[14]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[15] Ramaiah, A., R Stewart, M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", Work in Progress, January 2008.
[15] Ramaiah、A.、 "ブラインドインウィンドウ攻撃へのTCPの頑健性を向上させる" R・スチュワート、M. Dalal、進歩、2008年1月での作業。
[16] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[16] Recio、R.、メッツラー、B.、Culley、P.、Hilland、J.、およびD.ガルシア、 "リモートダイレクトメモリアクセスプロトコル仕様"、RFC 5040、2007年10月。
[17] Richardson, M. and D. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005.
[17]リチャードソン、M.とD. Redelmeier、 "IKE（Internet Key Exchange）を使用して日和見暗号化"、RFC 4322、2005年12月。
[18] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[18]坂根、S.、鎌田、K.、トーマス、M.、およびJ. Vilhuber、 "キーのケルベロスインターネットネゴシエーション（KINK）"、RFC 4430、2006年3月。
[19] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[19] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[20] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[20]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[21] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[21] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[22] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[22]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[23] TCP SYN-cookies, http://cr.yp.to/syncookies.html
[23] TCP SYN-クッキー、http://cr.yp.to/syncookies.html
[24] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPディフェンディング" [24]タッチ、J.、。
[25] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option", Work in Progress, November 2007.
[25]タッチ、J.、A.マンキン、R. Bonica、 "TCP認証オプション"、進歩、2007年11月に作業。
[26] Williams, N., "IPsec Channels: Connection Latching", Work in Progress, April 2008.
[26]ウィリアムズ、N.、 "IPsecのチャンネル：接続ラッチング" 進行中、仕事、2008年4月。
[27] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
"チャネルを確保するチャネルバインディングの使用について" [27]ウィリアムズ、N.、RFC 5056、2007年11月。
[28] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[28]ウィリアムズ、N.およびM.リチャードソン、 "ベター・ザン・ナッシングセキュリティ：IPsecのの非認証モード"、RFC 5386、2008年11月。
[29] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[29] Ylonenと、T.とC. Lonvick、エド。、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
Authors' Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
ジョー・タッチUSC / ISI 4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695 U.S.A.
Phone: +1 (310) 448-9151 EMail: touch@isi.edu
電話：+1（310）448-9151 Eメール：touch@isi.edu
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748 USA
デビッドL.ブラックEMCコーポレーション176サウスストリートホプキントン、MA 01748 USA
Phone: +1 (508) 293-7953 EMail: black_david@emc.com
電話：+1（508）293-7953 Eメール：black_david@emc.com
Yu-Shun Wang Microsoft One Microsoft Way Redmond, WA 98052 U.S.A.
ゆーしゅん わんｇ みｃろそｆｔ おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ う。Ｓ。あ。
Phone: +1 (425) 722-6980 EMail: yu-shun.wang@microsoft.com
電話：+1（425）722-6980 Eメール：yu-shun.wang@microsoft.com