Network Working Group                                   M. Stillman, Ed.
Request for Comments: 5355                                         Nokia
Category: Informational                                         R. Gopal
                                                  Nokia Siemens Networks
                                                              E. Guttman
                                                        Sun Microsystems
                                                             S. Sengodan
                                                  Nokia Siemens Networks
                                                             M. Holdrege
                                                          September 2008
        
       Threats Introduced by Reliable Server Pooling (RSerPool)
          and Requirements for Security in Response to Threats
        

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Abstract

抽象

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats.

信頼性の高いサーバーのプーリング(RSerPool)は、アーキテクチャと信頼性の高いアプリケーションをサポートするサーバー・プールへの管理とアクセスのためのプロトコルで、サーバー・プールへのクライアントアクセスメカニズムに設定されています。この文書はRSerPoolアーキテクチャにセキュリティ上の脅威について説明し、これらの脅威を阻止するために、セキュリティの要件を提示します。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Definitions ................................................3
      1.2. Conventions ................................................4
   2. Threats .........................................................4
      2.1. PE Registration/De-Registration Flooding --
           Non-Existent PE ............................................4
      2.2. PE Registration/De-Registration Flooding --
           Unauthorized PE ............................................5
      2.3. PE Registration/De-Registration Spoofing ...................6
      2.4. PE Registration/De-Registration Unauthorized ...............6
      2.5. Malicious ENRP Server Joins the Group of Legitimate
           ENRP Servers ...............................................7
      2.6. Registration/De-Registration with Malicious ENRP Server ....7
      2.7. Malicious ENRP Handlespace Resolution ......................8
      2.8. Malicious Node Performs a Replay Attack ....................9
      2.9. Re-Establishing PU-PE Security during Failover .............9
      2.10. Integrity ................................................10
      2.11. Data Confidentiality .....................................10
      2.12. ENRP Server Discovery ....................................11
      2.13. Flood of Endpoint-Unreachable Messages from the
            PU to the ENRP Server ....................................12
      2.14. Flood of Endpoint Keep-Alive Messages from the
            ENRP Server to a PE ......................................12
      2.15. Security of the ENRP Database ............................13
      2.16. Cookie Mechanism Security ................................13
      2.17. Potential Insider Attacks from Legitimate ENRP Servers ...14
   3. Security Considerations ........................................15
   4. Normative References ...........................................17
        
1. Introduction
1. はじめに

The RSerPool architecture [RFC5351] supports high-availability and load balancing by enabling a pool user to identify the most appropriate server from the server pool at a given time. The architecture is defined to support a set of basic goals. These include application-independent protocol mechanisms, separation of server naming from IP addressing, the use of the end-to-end principle to avoid dependencies on intermediate equipment, separation of session availability/failover functionality from the application itself, the ability to facilitate different server selection policies, the ability to facilitate a set of application-independent failover capabilities, and a peer-to-peer structure.

RSerPoolアーキテクチャ[RFC5351]は所定の時間に、サーバープールから最も適切なサーバを識別するために、プールユーザを可能にすることによって、高可用性およびロード・バランシングをサポートします。アーキテクチャは、基本的な目標のセットをサポートするために定義されています。これらは、アプリケーションに依存しないプロトコルメカニズム、IPアドレス指定のネーミングサーバの分離、中間装置への依存を回避するために、エンドツーエンドの原理を用い、アプリケーション自体からのセッション可用性/フェイルオーバー機能の分離、異なる促進する能力を含みますサーバー選択ポリシー、アプリケーションに依存しないフェイルオーバー機能のセットを容易にする能力、およびピア・ツー・ピア構造。

RSerPool provides a session layer for robustness. The session layer function may redirect communication transparently to upper layers. This alters the direct one-to-one association between communicating endpoints that typically exists between clients and servers. In particular, secure operation of protocols often relies on assumptions at different layers regarding the identity of the communicating party and the continuity of the communication between endpoints. Further, the operation of RSerPool itself has security implications and risks. The session layer operates dynamically, which imposes additional concerns for the overall security of the end-to-end application.

RSerPoolは、堅牢性のためのセッション層を提供します。セッションレイヤ機能は、上位レイヤにトランスペアレントに通信をリダイレクトすることができます。これは通常、クライアントとサーバの間に存在する通信エンドポイント間の直接一対一の会合を変化させます。具体的には、プロトコルの安全な操作は、多くの場合、通信相手の身元とエンドポイント間の通信の継続性に関する異なる層での仮定に依存しています。さらに、RSerPool自体の動作は、セキュリティへの影響とリスクを持っています。セッション層は、エンドツーエンドのアプリケーションの全体的なセキュリティのための追加の懸念を課している、動的に動作します。

This document explores the security implications of RSerPool, both due to its own functions and due to its being interposed between applications and transport interfaces.

この文書は、その独自の機能および、そのアプリケーションやトランスポート・インタフェースとの間に介在さの両方、RSerPoolのセキュリティへの影響を探ります。

This document is related to the RSerPool Aggregate Server Access Protocol (ASAP) [RFC5352] and Endpoint Name Resolution Protocol (ENRP) [RFC5353] documents, which describe, in their Security Consideration sections, the mechanisms for meeting the security requirements in this document. TLS [RFC5246] is the security mechanism for RSerPool that was selected to meet all the requirements described in this document. The Security Considerations sections of ASAP and ENRP describe how TLS is actually used to provide the security that is discussed in this document.

このドキュメントはRSerPool集計サーバアクセスプロトコル(至急)[RFC5352]およびエンドポイント名解決プロトコル(ENRP)彼らのセキュリティの考慮事項のセクションでは、記述[RFC5353]の文書、この文書のセキュリティ要件を満たすためのメカニズムに関連しています。 TLS [RFC5246]は、この文書に記載されているすべての要件を満たすように選択されたRSerPoolのためのセキュリティ機構です。できるだけ早くとENRPのセキュリティの考慮事項のセクションでは、TLSは、実際にこのドキュメントで説明されたセキュリティを提供するために使用される方法を説明します。

1.1. Definitions
1.1. 定義

This document uses the following terms:

このドキュメントでは、次の用語を使用しています:

Endpoint Name Resolution Protocol (ENRP): Within the operational scope of RSerPool, ENRP[RFC5353] defines the procedures and message formats of a distributed fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.

エンドポイントの名前解決プロトコル(ENRP)は:RSerPoolの動作範囲内で、ENRP [RFC5353]は、簿記を格納、取得、およびプール操作と会員情報を配信するための分散型フォールトトレラントレジストリサービスの手順及びメッセージフォーマットを定義します。

Aggregate Server Access Protocol (ASAP): ASAP [RFC5352] is a session layer protocol that uses ENRP to provide a high-availability handlespace. ASAP is responsible for the abstraction of the underlying transport technologies, load distribution management, fault management, as well as the presentation to the upper layer (i.e., the ASAP User) of a unified primitive interface.

集計サーバアクセスプロトコル(できるだけ早く):ASAPの[RFC5352]は高可用性handlespaceを提供するENRPを使用して、セッション層プロトコルです。 ASAPは、基礎となるトランスポート技術の抽象化、負荷分散管理、障害管理、ならびに統一プリミティブ界面の上部層(すなわち、ASAPのユーザ)に提示する責任があります。

Operational scope: The part of the network visible to pool users by a specific instance of the Reliable Server Pooling protocols.

動作範囲:信頼できるサーバプーリングプロトコルの特定のインスタンスによってプールユーザーに表示ネットワークの一部。

Pool (or server pool): A collection of servers providing the same application functionality.

プール(またはサーバプール):同じアプリケーション機能を提供するサーバの集合。

Pool handle: A logical pointer to a pool. Each server pool will be identifiable in the operational scope of the system by a unique pool handle.

プールハンドル:プールへの論理ポインタ。各サーバー・プールには、独自のプール・ハンドルによってシステムの動作範囲内に識別されます。

ENRP handlespace (or handlespace): A cohesive structure of pool names and relations that may be queried by a client. A client in this context is an application that accesses another remote application running on a server using a network.

ENRPのhandlespace(またはhandlespace):クライアントによって照会することができるプール名と関係の凝集構造。この文脈でのクライアントは、ネットワークを使用して、サーバー上で実行されている別のリモートアプリケーションにアクセスするアプリケーションです。

Pool element (PE): A server entity having registered to a pool.

プール要素(PE):プールに登録されたサーバエンティティ。

Pool user (PU): A server pool user.

プールのユーザー(PU):サーバー・プールのユーザー。

1.2. Conventions
1.2. 表記

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]に記載されているように解釈されます。

2. Threats
2.脅威
2.1. PE Registration/De-Registration Flooding -- Non-Existent PE
2.1. PEの登録/登録解除フラッディング - 非存在
2.1.1. Threat
2.1.1. 脅威

A malicious node could send a stream of false registrations/de-registrations on behalf of non-existent PEs to ENRP servers at a very rapid rate and thereby create unnecessary state in an ENRP server.

悪意のあるノードは、非常に急速にサーバをENRPし、それによってENRPサーバに不要な状態を作成するために存在しないPEの代わりに、偽の登録/デ・登録の流れを送信することができます。

2.1.2. Effect
2.1.2. 効果

The malicious node will corrupt the pool registrar database and/or disable the RSerPool discovery and database function. This represents a denial-of-service attack, as the PU would potentially get an IP address of a non-existent PE in response to an ENRP query.

悪意のあるノードが壊れプールレジストラデータベースおよび/またはRSerPool発見とデータベース機能が無効になります。 PUは、潜在的にENRP照会に応答して、存在しないPEのIPアドレスになるだろう、これは、サービス拒否攻撃を表します。

2.1.3. Requirement
2.1.3. 要求

An ENRP server that receives a registration/de-registration MUST NOT create or update state information until it has authenticated the PE. TLS with a pre-shared-key (PSK) is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. The justification for PSK is that we assume that one administrative domain will control and manage the server pool. This allows for PSK to be implemented and managed by a central security administrator.

それはPEを認証するまで登録/登録解除を受けるENRPサーバは、状態情報を作成または更新してはいけません。事前共有鍵とTLS(PSK)の認証機構として実装することが必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。 PSKのための正当化は、我々は1つの管理ドメインは、サーバー・プールを制御し、管理することを前提としていることです。 PSKが実装され、中央のセキュリティ管理者によって管理されるためこれができます。

2.2. PE Registration/De-Registration Flooding -- Unauthorized PE
2.2. PEの登録/登録解除フラッディング - 無許可
2.2.1. Threat
2.2.1. 脅威

A malicious node or PE could send a stream of registrations/de-registrations that are unauthorized to register/de-register to ENRP servers at a very rapid rate and thereby create unnecessary state in an ENRP server.

悪意のあるノードまたはPEは、非常に速い速度でサーバーをENRP、それによってENRPサーバに不要な状態を作成するために、デ登録/登録することが許可されていない登録/デ登録のストリームを送信することができます。

2.2.2. Effect
2.2.2. 効果

This attack will corrupt the pool registrar database and/or disable the RSerPool discovery and database function. There is the potential for two types of attacks: denial of service and data interception. In the denial-of-service attack, the PU gets an IP address of a rogue PE in response to an ENRP query, which might not provide the actual service. In addition, a flood of message could prevent legitimate PEs from registering. In the data interception attack, the rogue PE does provide the service as a man in the middle (MITM), which allows the attacker to collect data.

この攻撃は、破損しているプールレジストラデータベースおよび/またはRSerPool発見とデータベース機能が無効になります。サービスとデータ傍受の拒否:攻撃の2種類の可能性があります。 DoS攻撃では、PUは、実際のサービスを提供しない場合がありますENRPクエリに応答して、不正なPEのIPアドレスを取得します。また、メッセージの洪水が登録から合法的なのPEを防ぐことができます。データ傍受攻撃では、不正なPEは、攻撃者がデータを収集することを可能にする中間者(MITM)としてサービスを提供します。

2.2.3. Requirement
2.2.3. 要求

An ENRP server that receives a registration/de-registration MUST NOT create or update state information until the authentication information of the registering/de-registering entity is verified.

登録/登録解除エンティティの認証情報が確認されるまでは、登録/登録解除を受けるENRPサーバは、状態情報を作成または更新してはなりません。

TLS is used as the authentication mechanism between the ENRP server and PE. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool.

TLSはENRPサーバとPE間の認証メカニズムとして使用されます。 PSKとTLSは、認証機構として実装するために必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。

2.3. PE Registration/De-Registration Spoofing
2.3. PEの登録/登録解除スプーフィング
2.3.1. Threat
2.3.1. 脅威

A malicious node could send false registrations/de-registrations to ENRP servers concerning a legitimate PE, thereby creating false state information in the ENRP servers.

悪意のあるノードは、それによってENRPサーバに偽の状態情報を作成、正当PEに関するサーバをENRPする偽登録/デ登録を送ることができます。

2.3.2. Effect
2.3.2. 効果

This would generate misinformation in the ENRP server concerning a PE and would be propagated to other ENRP servers, thereby corrupting the ENRP database. Distributed Denial of Service (DDoS) could result: if a PE that is a target for a DDoS attack for some popular high-volume service, then the attacker can register a PE to which a lot of PUs will try to connect. This allows man-in-the-middle or masquerade attacks on the service provided by the legitimate PEs. If an attacker registers its server address as a PE and handles the requests, he can eavesdrop on service data.

これは、PEについてENRPサーバに誤った情報を生成し、それによってENRPデータベースの破損、他のENRPサーバに伝播されることになります。分散型サービス拒否(DDoS攻撃)が生じる可能性:いくつかの人気の高ボリューム・サービスのためのDDoS攻撃の対象となるPEた場合、攻撃者は各PUの多くは、接続しようとする先のPEを登録することができます。これは、マン・中間または正当なのPEが提供するサービスへの攻撃を装うことができます。攻撃者はPEとしてそのサーバのアドレスを登録し、要求を処理した場合、彼はサービスデータを盗聴することができます。

2.3.3. Requirement
2.3.3. 要求

An ENRP server that receives a registration/de-registration MUST NOT create or update state information until it has authenticated the PE. TLS is used as the authentication mechanism between the ENRP server and the PE. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. A PE can register only for itself and cannot register on behalf of other PEs.

それはPEを認証するまで登録/登録解除を受けるENRPサーバは、状態情報を作成または更新してはいけません。 TLSはENRPサーバとPE間の認証メカニズムとして使用されます。 PSKとTLSは、認証機構として実装するために必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。 PEは、それ自体のためにのみ登録することができ、他のPEに代わって登録することができません。

2.4. PE Registration/De-Registration Unauthorized
2.4. PEの登録/登録解除の不正
2.4.1. Threat
2.4.1. 脅威

A PE that is not authorized to join a pool could send registrations/ de-registrations to ENRP servers, thereby creating false state information in the ENRP servers.

プールへの参加を許可されていないPEは、それによってENRPサーバに偽の状態情報を作成し、サーバをENRPする登録/デ登録を送信することができます。

2.4.2. Effect
2.4.2. 効果

This attack would generate misinformation in the ENRP server concerning a PE and would be propagated to other ENRP servers thereby corrupting the ENRP database. This allows man-in-the-middle or masquerade attacks on the service provided by the legitimate PEs. If an attacker registers its server address as a PE and handles the requests, he can eavesdrop on service data.

この攻撃は、PEに関するENRPサーバに誤った情報を生成し、それによってENRPデータベースの破損他のENRPサーバに伝播されます。これは、マン・中間または正当なのPEが提供するサービスへの攻撃を装うことができます。攻撃者はPEとしてそのサーバのアドレスを登録し、要求を処理した場合、彼はサービスデータを盗聴することができます。

2.4.3. Requirement
2.4.3. 要求

An ENRP server that receives a registration/de-registration MUST NOT create or update state information until it has authorized the requesting entity. TLS is used as the authentication mechanism. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool.

それは要求エンティティを承認するまで登録/登録解除を受けるENRPサーバは、状態情報を作成または更新してはなりません。 TLSは、認証メカニズムとして使用されています。 PSKとTLSは、認証機構として実装するために必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。

2.5. Malicious ENRP Server Joins the Group of Legitimate ENRP Servers
2.5. 悪質なENRPサーバは、正当なENRPサーバのグループに参加します
2.5.1. Threat
2.5.1. 脅威

A malicious ENRP server joins the group of legitimate ENRP servers with the intent of propagating inaccurate updates to corrupt the ENRP database. The attacker sets up an ENRP server and attempts to communicate with other ENRP servers.

悪質なENRPサーバが壊れENRPデータベースに不正確な更新を伝播させる目的で、正当なENRPサーバのグループに参加します。攻撃者はENRPサーバを設定し、他のENRPサーバと通信しようとします。

2.5.2. Effect
2.5.2. 効果

The result would be Inconsistent ENRP database state.

結果は、一貫性のないENRPデータベースの状態になります。

2.5.3. Requirement
2.5.3. 要求

ENRP servers MUST perform mutual authentication. This would prevent the attacker from joining its ENRP server to the pool. TLS is used as the mutual authentication mechanism. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool.

ENRPサーバは、相互認証を実行しなければなりません。これは、プールへのENRPサーバへの参加から攻撃を防止するであろう。 TLSは、相互認証メカニズムとして使用されています。 PSKとTLSは、認証機構として実装するために必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。

2.6. Registration/De-Registration with Malicious ENRP Server
2.6. 悪質なENRPサーバへの登録/登録解除
2.6.1. Threat
2.6.1. 脅威

A PE unknowingly registers/de-registers with a malicious ENRP server.

PEは、無意識のうちに悪意のあるENRPサーバとデ登録/登録します。

2.6.2. Effect
2.6.2. 効果

The registration might not be properly processed or it might be ignored. A rogue ENRP server has the ability to return any address to a user requesting service; this ability could result in denial of service or connection to a rogue PE that is the attacker's choice for service.

登録が適切に処理されないことがありますか、それは無視される可能性があります。不正なENRPサーバがサービスを要求するユーザに任意のアドレスを返す機能を持っています。この能力は、サービスまたはサービスのために攻撃者が選択され、不正なPEへの接続の拒否につながる可能性があります。

2.6.3. Requirement
2.6.3. 要求

The PE MUST authenticate the ENRP server. TLS is the mechanism used for the authentication. TLS with PSK is mandatory to implement as the authentication mechanism. For PSK, having a pre-shared-key constitutes authorization. The network administrators of a pool need to decide which nodes are authorized to participate in the pool. This requirement prevents malicious outsiders and insiders from adding their own ENRP server to the pool.

PEはENRPサーバを認証する必要があります。 TLSは、認証のために使用されるメカニズムです。 PSKとTLSは、認証機構として実装するために必須です。 PSKのために、事前共有キーを有する許可を構成しています。プールのネットワーク管理者は、プールに参加することを許可されているノードを決定する必要があります。この要件は、プールに、独自のENRPサーバを追加することから悪意のある部外者とインサイダーを防ぐことができます。

2.7. Malicious ENRP Handlespace Resolution
2.7. 悪質なENRP Handlespace決議
2.7.1. Threat
2.7.1. 脅威

The ASAP protocol receives a handlespace resolution response from an ENRP server, but the ENRP server is malicious and returns random IP addresses or an inaccurate list in response to the pool handle.

できるだけ早くプロトコルはENRPサーバからhandlespace解決応答を受信しますが、ENRPサーバは、悪意のあるで、プール・ハンドルに応じてランダムなIPアドレスまたは不正確なリストを返します。

2.7.2. Effect
2.7.2. 効果

The PU application communicates with the wrong PE or is unable to locate the PE since the response is incorrect in saying that a PE with that handle did not exist. A rogue ENRP server has the ability to return any address to ASAP requesting an address list that could result in denial of service or connection to a rogue PE of the attacker's choice for service. From the PE, the attacker could eavesdrop or tamper with the application.

PUアプリケーションは、間違ったPEと通信したり、応答がそのハンドルを持つPEが存在しなかったと言っで間違っているので、PEを見つけることができません。不正なENRPサーバは、できるだけ早くサービスまたはサービスのために攻撃者が選択した不正なPEへの接続拒否が発生する可能性がアドレスリストを要求する任意のアドレスを返す機能を持っています。 PEからは、攻撃者が盗聴可能性やアプリケーションを改ざん。

2.7.3. Requirement
2.7.3. 要求

ASAP SHOULD authenticate the ENRP server. TLS with certificates is the mandatory-to-implement mechanism used for authentication. The administrator uses a centralized Certificate Authority (CA) to generate and sign certificates. The certificate is stored on the ENRP server. A CA trusted root certification authority certificate is sent to the client out of band, and the certificate signature on the ENRP server certificate is checked for validity during the TLS handshake. This authentication prevents malicious outsiders and insiders from adding an ENRP server to the pool that may be accessed by ASAP.

できるだけ早くENRPサーバを認証する必要があります。証明書とTLSは、認証に使用実装に必須のメカニズムです。管理者は、集中型の認証局(CA)が生成し、証明書に署名するために使用しています。証明書は、ENRPサーバに格納されています。 CAの信頼されたルート証明機関の証明書は、帯域外のクライアントに送信され、ENRPサーバ証明書の証明書の署名は、TLSハンドシェイク中に妥当性がチェックされます。この認証は、ASAPによってアクセスすることができるプールにENRPサーバを追加することから悪意のある外部とインサイダーを防止します。

2.8. Malicious Node Performs a Replay Attack
2.8. 悪意のあるノードは、リプレイ攻撃を実行します
2.8.1. Threat
2.8.1. 脅威

A malicious node could replay the entire message previously sent by a legitimate entity. This could create false/unnecessary state in the ENRP servers when the replay is for registration/de-registration or update.

悪意のあるノードは、以前に正当なエンティティによって送信されたメッセージ全体を再生することができました。リプレイは、登録/登録解除や更新のためであるとき、これはENRPサーバに偽/不要な状態を作成することができます。

2.8.2. Effect
2.8.2. 効果

The result is that false/extra state is maintained by ENRP servers. This would most likely be used as a denial-of-service attack if the replay is used to de-register all PEs.

結果は偽/余分な状態はENRPサーバによって維持されていることです。リプレイは、すべてのPEを登録解除するために使用されている場合、これは最も可能性の高いサービス拒否攻撃として使用されます。

2.8.3. Requirement
2.8.3. 要求

The protocol MUST prevent replay attacks. The replay attack prevention mechanism in TLS meets this requirement.

プロトコルは、リプレイ攻撃を防止しなければなりません。 TLSでのリプレイ攻撃防止機構は、この要件を満たしています。

2.9. Re-Establishing PU-PE Security during Failover
2.9. フェイルオーバー時にPU-PEのセキュリティを再確立
2.9.1. Threat
2.9.1. 脅威

The PU fails over from PE A to PE B. In the case that the PU had a trusted relationship with PE A, the PU will likely not have the same relationship established with PE B.

PUは、PUは、PE Aとの信頼関係を持っていた場合、PE BにPE Aからフェールオーバーし、PUは、おそらくPE B.で確立同様の関係を持っていません。

2.9.2. Effect
2.9.2. 効果

If there was a trust relationship involving security context between PU and PE A, the equivalent trust relationship will not exist between PU and PE B. This will violate security policy. For example, if the security context with A involves encryption and the security context with B does not, then an attacker could take advantage of the change in security.

PUとPE A間のセキュリティコンテキストを含む信頼関係があった場合、同等の信頼関係は、これがセキュリティポリシーに違反することになりますPUとPE Bの間に存在しません。 AとセキュリティコンテキストがBとの暗号化とセキュリティコンテキストを必要とする場合、例えば、攻撃者は、セキュリティの変化を利用することができません。

2.9.3. Requirement
2.9.3. 要求

The application SHOULD be notified when failover occurs so the application can take appropriate action to establish a trusted relationship with PE B. ENRP has a mechanism to perform this function.

アプリケーションは、フェイルオーバーが非常に発生したときに、アプリケーションがPE B. ENRPとの信頼関係は、この機能を実行するための機構を有している確立するために適切な行動をとることができる通知する必要があります。

2.10. Integrity
2.10. 整合性
2.10.1. Threat
2.10.1. 脅威

The following are all instances of the same class of threats, and all have similar effects.

以下の脅威の同じクラスのすべてのインスタンスがあり、すべてが同様の効果を持っています。

a. ENRP response to pool handle resolution is corrupted during transmission.

A。プール・ハンドルの解像度にENRP応答が送信中に破損しています。

b. ENRP peer messages are corrupted during transmission.

B。 ENRPピアメッセージが送信中に破損しています。

c. PE sends an update for values, and that information is corrupted during transmission.

C。 PEは、値の更新を送信し、その情報が伝送中に破損しています。

2.10.2. Effect
2.10.2. 効果

The result is that ASAP receives corrupt information for pool handle resolution, which the PU believes to be accurate. This corrupt information could be an IP address that does not resolve to a PE so the PU would not be able to contact the server.

結果はできるだけ早くPUが正確であると信じているプール・ハンドルの解決のために破損した情報を受信することです。この壊れた情報は、PUは、サーバーに接続できないように、PEに解決されていないIPアドレスである可能性があります。

2.10.3. Requirement
2.10.3. 要求

An integrity mechanism MUST be present. Corruption of data that is passed to the PU means that the PU can't rely on it. The consequence of corrupted information is that the IP addresses passed to the PU might be wrong, in which case, it will not be able to reach the PE. The interfaces that MUST implement integrity are PE to ENRP server and ENRP to ENRP server. The integrity mechanism in TLS is used for this.

整合性のメカニズムが存在しなければなりません。 PUに渡されたデータの破損は、PUがそれに頼ることができないことを意味します。破損した情報の結果は、PUに渡されたIPアドレスは、間違っているかもしれない、その場合には、PEに達することができないということです。整合性を実装しなければならないインターフェイスは、PEがENRPサーバにサーバとENRPをENRPれます。 TLSでの整合性のメカニズムは、このために使用されます。

2.11. Data Confidentiality
2.11. データ機密性
2.11.1. Threat
2.11.1. 脅威

An eavesdropper capable of snooping on fields within messages in transit may be able to gather information, such as topology/location/IP addresses, etc., which may not be desirable to divulge.

輸送中のメッセージ内のフィールドにスヌーピング可能な盗聴者は、公表することが望ましくないかもしれない等トポロジー/位置/ IPアドレス、などの情報を収集することができるかもしれません。

2.11.2. Effect
2.11.2. 効果

Information that an administrator does not wish to divulge is divulged. The attacker gains valuable information that can be used for financial gain or attacks on hosts.

管理者は明かしたくない情報が公表されます。攻撃者は、金銭的な利益やホストへの攻撃のために使用することができる貴重な情報を得ます。

2.11.3. Requirement
2.11.3. 要求

A provision for data confidentiality service SHOULD be available. TLS provides data confidentiality in support of this mechanism.

データの機密性サービスの提供が利用可能であるべきです。 TLSは、このメカニズムのサポートでデータの機密性を提供します。

2.12. ENRP Server Discovery
2.12. ENRPサーバー検出
2.12.1. Threats
2.12.1. 脅威

a. Thwarting successful discovery: When a PE wishes to register with an ENRP server, it needs to discover an ENRP server. An attacker could thwart the successful discovery of ENRP server(s), thereby inducing the PE to believe that no ENRP server is available. For instance, the attacker could reduce the returned set of ENRP servers to null or a small set of inactive ENRP servers. The attacker performs a MITM attack to do this.

A。成功した発見を阻止:PEはENRPサーバに登録したい場合、それはENRPサーバを発見する必要があります。攻撃者はこれによって何らENRPサーバが利用できないことを信じるようにPEを誘導し、ENRPサーバ(複数可)の成功の発見を阻止できました。例えば、攻撃者はnullにENRPサーバの返されたセットまたは非アクティブENRPサーバの小さなセットを減らすことができます。攻撃者はこれを行うにはMITM攻撃を実行します。

b. A similar thwarting scenario also applies when an ENRP server or ASAP on behalf of a PU needs to discover ENRP servers.

B。 PUに代わってENRPサーバまたはできるだけ早くはENRPサーバを検出する必要がある場合にも、同様の阻止のシナリオにも適用されます。

c. Spoofing successful discovery: An attacker could spoof the discovery by claiming to be a legitimate ENRP server. When a PE wishes to register, it finds the spoofed ENRP server. An attacker can only make such a claim if no security mechanisms are used.

C。なりすましに成功発見:攻撃者は正当なENRPサーバであると主張することで発見をだますことができます。 PEは、登録を希望する場合は、偽装されたENRPサーバを発見します。何のセキュリティメカニズムが使用されていない場合、攻撃者は、このような請求を行うことができます。

d. A similar spoofing scenario also applies when an ENRP server or ASAP on behalf of a PU needs to discover ENRP servers.

D。 PUに代わってENRPサーバまたはできるだけ早くはENRPサーバを検出する必要がある場合にも、同様のなりすましのシナリオにも適用されます。

2.12.2. Effects (Letters Correlate with Threats above)
2.12.2. エフェクト(文字は上記の脅威と相関します)

a. A PE that could have been in an application server pool does not become part of a pool. The PE does not complete discovery operation. This is a DoS attack.

A。アプリケーションサーバプールにあったかもしれないPEは、プールの一部にはなりません。 PEは、ディスカバリー操作を完了しません。これは、DoS攻撃です。

b. An ENRP server that could have been in an ENRP server pool does not become part of a pool. A PU is unable to utilize services of ENRP servers.

B。 ENRPサーバプールであったかもしれないENRPサーバは、プールの一部にはなりません。 PUはENRPサーバのサービスを利用することができません。

c. This malicious ENRP would either misrepresent, ignore, or otherwise hide or distort information about the PE to subvert RSerPool operation.

C。この悪意のあるENRPいずれか、詐称無視する、またはそうでなければ非表示またはRSerPool操作を破壊するためのPEに関する情報を歪めることになります。

d. Same as above.

D。同上。

2.12.3. Requirement
2.12.3. 要求

A provision for authentication MUST be present and a provision for data confidentiality service SHOULD be present. TLS has a mechanism for confidentiality.

認証のための規定は存在しなければならないとデータの機密性サービスの提供が存在しなければなりません。 TLSは機密保持のための機構を有しています。

2.13. Flood of Endpoint-Unreachable Messages from the PU to the ENRP Server

2.13. ENRPサーバへのPUからエンドポイント到達不能メッセージの洪水

2.13.1. Threat
2.13.1. 脅威

Endpoint-unreachable messages are sent by ASAP to the ENRP server when it is unable to contact a PE. There is the potential that a PU could flood the ENRP server intentionally or unintentionally with these messages. The non-malicious case would require an incorrect implementation. The malicious case would be caused by writing code to flood the ENRP server with endpoint unreachable messages.

PEに接続できない場合、エンドポイント到達不能メッセージがENRPサーバに、ASAPによって送信されます。 PUは、これらのメッセージを意図的にまたは意図せずにENRPサーバをあふれさせる可能性が可能性があります。悪意のない場合は、間違った実装を必要とします。悪質な場合は、エンドポイント到達不能メッセージでENRPサーバをあふれさせるコードを書くに起因します。

2.13.2. Effect
2.13.2. 効果

The result is a DoS attack on the ENRP server. The ENRP server would not be able to service other PUs effectively and would not be able to take registrations from PEs in a timely manner. Further, it would not be able to communicate with other ENRP servers in the pool to update the database in a timely fashion.

その結果、ENRPサーバ上のDoS攻撃です。 ENRPサーバは、効果的に他のPUにサービスを提供することができないであろうし、適時にのPEからの登録を取ることができないだろう。さらに、タイムリーにデータベースを更新するために、プール内の他のENRPサーバと通信することができないであろう。

2.13.3. Requirement
2.13.3. 要求

The number of endpoint unreachable messages sent to the ENRP server from the PU SHOULD be limited. This mechanism is described in the ASAP [RFC5352] protocol document.

PUからENRPサーバに送信されたエンドポイント到達不能メッセージの数を制限する必要があります。このメカニズムは、ASAP [RFC5352]プロトコルの文書に記載されています。

2.14. Flood of Endpoint Keep-Alive Messages from the ENRP Server to a PE

2.14. エンドポイントの洪水は、キープアライブメッセージをENRPサーバからPEへ

2.14.1. Threat
2.14.1. 脅威

Endpoint Keep-Alive messages would be sent from the ENRP server to the PEs during the process of changing the Home ENRP server for this PE.

エンドポイントキープアライブメッセージは、このPEのホームENRPサーバを変更する過程でPEにENRPサーバから送信されます。

2.14.2. Effect
2.14.2. 効果

If the ENRP server maliciously sent a flood of endpoint Keep-Alive messages to the PE, the PE would not be able to service clients. The result is a DoS attack on the PE.

ENRPサーバは、悪意を持ってPEにエンドポイントキープアライブメッセージの洪水を送信した場合、PEは、サービスクライアントにことができません。結果は、PE上のDoS攻撃です。

2.14.3. Requirement
2.14.3. 要求

ENRP MUST limit the frequency of Keep-Alive messages to a given PE to prevent overwhelming the PE. This mechanism is described in the ENRP [RFC5353] protocol document.

ENRPはPEを圧倒防止するために、所与のPEにキープアライブメッセージの頻度を制限しなければなりません。このメカニズムはENRP [RFC5353]プロトコルの文書に記載されています。

2.15. Security of the ENRP Database
2.15. ENRPデータベースのセキュリティ
2.15.1. Threat
2.15.1. 脅威

Another consideration involves the security characteristics of the ENRP database. Suppose that some of the PEs register with an ENRP server using security and some do not. In this case, when a client requests handlespace resolution information from ENRP, it would have to be informed which entries are "secure" and which are not.

もう1つの考慮事項は、ENRPデータベースのセキュリティ特性を必要とします。 PEの一部は、セキュリティを使用してENRPサーバに登録し、一部にはないと仮定します。クライアントがENRPからhandlespace解決情報を要求すると、この場合、それはエントリが「安全」とされていないされて通知しなければならないであろう。

2.15.2. Effect
2.15.2. 効果

This would not only complicate the protocol, but actually bring into question the security and integrity of such a database. What can be asserted about the security of such a database is a very thorny question.

これは、プロトコルを複雑に、実際に質問に、このようなデータベースのセキュリティと整合性を持っていないでしょう。どのようなデータベースのセキュリティについてアサートすることができますすることは非常に厄介な問題です。

2.15.3. Requirement
2.15.3. 要求

The requirement is that either the entire ENRP server database MUST be secure; that is, it has registrations exclusively from PEs that have used security mechanisms, or the entire database MUST be insecure; that is, registrations are from PEs that have used no security mechanisms. ENRP servers that support security MUST reject any PE server registration that does not use the security mechanisms. Likewise, ENRP servers that support security MUST NOT accept updates from other ENRP servers that do not use security mechanisms. TLS is used as the security mechanism so any information not sent using TLS to a secure ENRP server MUST be rejected.

要件は、全体のENRPサーバのデータベースのいずれかが安全でなければならないということです。つまり、それは排他的にセキュリティ・メカニズムを使用している、またはデータベース全体が安全でないでなければならないのPEからの登録があります。つまり、登録には、セキュリティ・メカニズムを使用していないのPEからです。セキュリティをサポートするENRPサーバは、セキュリティ・メカニズムを使用していない任意のPEサーバーの登録を拒絶しなければなりません。同様に、セキュリティをサポートするENRPサーバは、セキュリティ・メカニズムを使用していない他のENRPサーバから更新を受け入れてはいけません。安全なENRPサーバにTLSを使用して送信されていない情報を拒絶しなければなりませんので、TLSは、セキュリティ・メカニズムとして使用されています。

2.16. Cookie Mechanism Security
2.16. クッキーメカニズムのセキュリティ

The application layer is out of scope for RSerPool. However, some questions have been raised about the security of the cookie mechanism, which will be addressed.

アプリケーション層はRSerPoolのための適用範囲外です。しかし、いくつかの質問が解決される予定クッキーメカニズムのセキュリティについて提起されています。

Cookies are passed via the ASAP control channel. If TCP is selected as the transport, then the data and control channel MUST be multiplexed. Therefore, the cases:

クッキーは、できるだけ早く制御チャネルを介して渡されます。 TCPをトランスポートとして選択された場合、データ及び制御チャネルが多重化されなければなりません。したがって、例:

a. control channel is secured; data channel is not b. data channel is secured; control channel is not

A。制御チャネルが確保されています。データチャネルはBではありません。データチャネルが確保されています。制御チャネルではありません

are not possible, as the multiplexing onto one TCP port results in security for both data and control channels or neither.

データ及び制御チャネルまたはどちらも両方のためのセキュリティで、1つのTCPポート結果の上に多重化として、可能ではありません。

The multiplexing requirement results in the following cases:

次の場合に多重化要件の結果:

1. the multiplexed control channel-data channel is secure; *or*
1.多重化された制御チャネルデータチャネルが安全です。 *または*
2. the multiplexed control channel-data channel is not secured.
前記多重化された制御チャネルデータチャネルが確保されていません。

This applies to cookies in the sense that, if you choose to secure your control-data channel, then the cookies are secured.

これは、あなたのコントロール・データ・チャネルを確保することを選択した場合は、クッキーが確保されている、という意味でクッキーに適用されます。

A second issue is that the PE could choose to sign and/or encrypt the cookie. In this case, it must share keys and other information with other PEs. This application-level state sharing is out of scope of RSerPool.

第二の問題は、PEが署名および/またはクッキーを暗号化することを選択することができるということです。この場合、それは他のPEとキーやその他の情報を共有する必要があります。このアプリケーションレベルの状態の共有はRSerPoolの範囲外です。

2.17. Potential Insider Attacks from Legitimate ENRP Servers
2.17. 正当なENRPサーバからの潜在的なインサイダー攻撃

The previous text does not address all byzantine attacks that could arise from legitimate ENRP servers. True protection against misbehavior by authentic (but rogue) servers is beyond the capability of TLS security mechanisms. Authentication using TLS does not protect against byzantine attacks, as authenticated ENRP servers might have been maliciously hacked. Protections against insider attacks are generally specific to the attack, so more experimentation is needed. For example, the following discusses two insider attacks and potential mitigations.

前のテキストは、正当なENRPサーバから発生する可能性があり、すべてのビザンチンの攻撃に対応していません。本格的な(しかし、不正な)サーバによって不正行為に対する真の保護は、TLSのセキュリティメカニズムの能力を超えています。認証されたENRPサーバが悪意を持ってハッキングされた可能性があるとして、TLSを使用した認証は、ビザンチン攻撃から保護することはできません。より多くの実験が必要とされているので、インサイダー攻撃に対する保護は、通常、攻撃に固有のものです。たとえば、次の例は、2回のインサイダー攻撃や潜在的な緩和策について説明します。

One issue is that legitimate users may choose not to follow the proposed policies regarding the choice of servers (namely, members in the pool). If the "choose a member at random" policy is employed, then a pool user can always set its "random choices" so that it picks a particular pool member. This bypasses the "load sharing" idea behind the policy. Another issue is that a pool member (or server) may report a wrong policy to a user.

1つの問題は、正当なユーザーにサーバー(プール内つまり、メンバー)の選択に関して提案された政策に従わないことを選択することができるということです。 「ランダムでメンバーを選択し、」政策が採用されている場合は、それが特定のプールのメンバーを選ぶように、その後、プールの利用者は、常に「ランダム選択項目」を設定することができます。これは、政策の背後にある「ロードシェアリング」のアイデアをバイパスします。もう一つの問題は、プールメンバー(またはサーバー)は、ユーザーに間違った政策を報告す​​ることがありますということです。

To mitigate the first attack, the protocol may require the pool user to "prove" to the pool member that the pool member was chosen "randomly", say by demonstrating that the random choice was the result of applying some hash function to a public nonce. Different methods may be appropriate for other member scheduling policies.

最初の攻撃を軽減するために、プロトコルは、プールのメンバーが「ランダム」に選ばれたプールのメンバーに「証明」するために、プールの利用者が必要な場合があり、ランダムな選択は公共ナンスにいくつかのハッシュ関数を適用した結果であったことを証明することによって言います。別の方法は、他のメンバースケジューリングポリシーに適切であり得ます。

To mitigate the second attack, the protocol might require the PE to sign the policy sent to the ENRP server. During pool handle resolution, the signed policy needs to be sent from an ENRP server to an ASAP endpoint in a way that will allow the user to later hold the server accountable to the policy.

第二の攻撃を軽減するために、プロトコルがENRPサーバに送信されたポリシーに署名するPEが必要になる場合があります。プールハンドル解決の際、署名ポリシーは、ユーザーが後でポリシーに責任サーバーを保持することを可能にする方法で、できるだけ早くエンドポイントにENRPサーバから送信される必要があります。

3. Security Considerations
3.セキュリティの考慮事項

This informational document characterizes potential security threats targeting the RSerPool architecture. The security mechanisms required to mitigate these threats are summarized for each architectural component. It will be noted which mechanisms are required and which are optional.

この情報のドキュメントはRSerPoolアーキテクチャをターゲットと潜在的なセキュリティ上の脅威を特徴付けます。これらの脅威を軽減するために必要なセキュリティメカニズムは、各アーキテクチャコンポーネントのために要約されています。メカニズムが必要とされる留意し、オプションであることになります。

From the threats described in this document, the security services required for the RSerPool protocol suite are given in the following table.

この文書で説明脅威から、RSerPoolプロトコルスイートに必要なセキュリティサービスを以下の表に示します。

   +--------------+----------------------------------------------------+
   |    Threat    |           Security mechanism in response           |
   +--------------+----------------------------------------------------+
   |  Section 2.1 |          ENRP server authenticates the PE.         |
   |  Section 2.2 |          ENRP server authenticates the PE.         |
   |  Section 2.3 |          ENRP server authenticates the PE.         |
   |  Section 2.4 |          ENRP server authenticates the PE.         |
   |  Section 2.5 |         ENRP servers mutually authenticate.        |
   |  Section 2.6 |          PE authenticates the ENRP server.         |
   |  Section 2.7 |    The PU authenticates the ENRP server.  If the   |
   |              |   authentication fails, it looks for another ENRP  |
   |              |                       server.                      |
   |  Section 2.8 | Security protocol that has protection from replay  |
   |              |                      attacks.                      |
   |  Section 2.9 |    Either notify the application when failover     |
   |              |   occurs so the application can take appropriate   |
   |              | action to establish a trusted relationship with PE |
   |              |        B *or* re-establish the security context    |
   |              |                   transparently.                   |
   | Section 2.10 |     Security protocol that supports integrity      |
   |              |                     protection.                    |
   | Section 2.12 |        Security protocol that supports data        |
   |              |                  confidentiality.                  |
   | Section 2.11 |    The PU authenticates the ENRP server.  If the   |
   |              |   authentication fails, it looks for another ENRP  |
   |              |                       server.                      |
   | Section 2.13 |      ASAP must control the number of endpoint      |
   |              |   unreachable messages transmitted from the PU to  |
   |              |                  the ENRP server.                  |
   | Section 2.14 |       ENRP server must control the number of       |
   |              |       Endpoint_KeepAlive messages to the PE.       |
   +--------------+----------------------------------------------------+
        

The first four threats, combined with the sixth threat, result in a requirement for mutual authentication of the ENRP server and the PE.

第六の脅威と組み合わせる最初の4つの脅威は、ENRPサーバとPEの相互認証のための要件をもたらします。

To summarize, the first twelve threats require security mechanisms that support authentication, integrity, data confidentiality, and protection from replay attacks. For RSerPool, we need to authenticate the following:

要約すると、最初の12本の脅威は、セキュリティ認証をサポートするメカニズムを、整合性、データの機密性、およびリプレイ攻撃からの保護を必要とします。 RSerPoolのために、私たちは次のことを認証する必要があります。

   o  PU -----> ENRP Server (PU authenticates the ENRP server)
        
   o  PE <----> ENRP Server (mutual authentication)
        
   o  ENRP server <-----> ENRP Server (mutual authentication)
        

Summary by component:

成分による概要:

RSerPool client -- mandatory-to-implement authentication of the ENRP server is required for accurate pool handle resolution. This is to protect against threats from rogue ENRP servers. In addition, confidentiality, integrity, and preventing replay attack are also mandatory to implement to protect from eavesdropping and data corruption or false data transmission. Confidentiality is mandatory to implement and is used when privacy is required.

RSerPoolクライアントは - ENRPサーバの実装に必須の認証は、正確なプールハンドル解決のために必要とされます。これは、不正なENRPサーバからの脅威から保護することです。また、機密性、完全性、およびリプレイ攻撃を防ぐことも盗聴やデータ破損やデータの誤送信から保護するために実装するために必須です。機密性は、実装が必須であり、プライバシーが必要な場合に使用されています。

PE to ENRP communications -- mandatory-to-implement mutual authentication, integrity, and protection from replay attack is required for PE to ENRP communications. This is to protect the integrity of the ENRP handlespace database. Confidentiality is mandatory to implement and is used when privacy is required.

PEは、通信をENRPするために実装に必須の相互認証、整合性、およびリプレイ攻撃からの保護を必要とする - PEは、通信がENRPします。これはENRPのhandlespaceデータベースの整合性を保護することです。機密性は、実装が必須であり、プライバシーが必要な場合に使用されています。

ENRP to ENRP communications -- mandatory-to-implement mutual authentication, integrity, and protection from replay attack is required for ENRP to ENRP communications. This is to protect the integrity of the ENRP handlespace database. Confidentiality is mandatory to implement and is used when privacy is required.

ENRPが通信をENRPするために実装に必須の相互認証、整合性、およびリプレイ攻撃からの保護を必要とする - ENRPは通信がENRPします。これはENRPのhandlespaceデータベースの整合性を保護することです。機密性は、実装が必須であり、プライバシーが必要な場合に使用されています。

4. Normative References
4.引用規格

[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月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(TLS)プロトコルバージョン1.2"、RFC 5246、2008年8月。

[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.

[RFC5352]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル(至急)"、RFC 5352、2008年9月。

[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.

[RFC5353]謝、Q.、スチュワート、R.、スティルマン、M.、Tuexen、M.、およびA.シルバー、 "エンドポイントHandlespace冗長プロトコル(ENRP)"、RFC 5353、2008年9月。

[RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, September 2008.

[RFC5351]レイ、P.、オング、L.、Tuexen、M.、およびT. Dreibholz、 "信頼できるサーバプーリングプロトコルの概要"、RFC 5351、2008年9月。

Authors' Addresses

著者のアドレス

Maureen Stillman, Ed. Nokia 1167 Peachtree Court Naperville, IL 60540 USA

モーリーンスティルマン、エド。ノキア1167ピーチツリー裁判所ネーパーヴィル、IL 60540 USA

EMail: maureen.stillman@nokia.com

メールアドレス:maureen.stillman@nokia.com

Ram Gopal Nokia Siemens Networks 12278 Scripps Summit Drive San Diego, CA 92131 USA

ラムゴパルノキア・シーメンス・ネットワークスクリップス12278サミットドライブサンディエゴ、CA 92131 USA

EMail: ram.gopal@nsn.com

メールアドレス:ram.gopal@nsn.com

Erik Guttman Sun Microsystems Eichhoelzelstrasse 7 74915 Waibstadt DE

エリック・グットマンSun MicrosystemsのEichhoelzelstrasse 7 74915ヴァイプシュタットDE

EMail: Erik.Guttman@sun.com

メールアドレス:Erik.Guttman@sun.com

Senthil Sengodan Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA

SenthilさんSengodanノキア・シーメンス・ネットワーク6000接続のドライブアーヴィング、TX 75039 USA

EMail: Senthil.sengodan@nsn.com

メールアドレス:Senthil.sengodan@nsn.com

Matt Holdrege

マット・ホールドレッジ

EMail: Holdrege@gmail.com

メールアドレス:Holdrege@gmail.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2008).

著作権(C)IETFトラスト(2008)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。