[要約] 要約：RFC 3586は、IPセキュリティポリシー（IPSP）の要件に関する情報を提供するものである。 目的：IPSPの要件を明確にし、ネットワークセキュリティの向上を図るためのガイドラインを提供する。
Network Working Group M. Blaze
Request for Comments: 3586 AT&T Labs - Research
Category: Standards Track A. Keromytis
Columbia University
M. Richardson
Sandelman Software Works
L. Sanchez
Xapiens Corporation
August 2003
IP Security Policy (IPSP) Requirements
IPセキュリティポリシー（IPSP）要件
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements.
このドキュメントでは、IPセキュリティポリシー（IPSP）構成および管理フレームワークを開発するための問題のスペースとソリューションの要件について説明します。IPSPアーキテクチャは、アクセス、承認、認証、機密性、データの整合性、その他のIPセキュリティプロパティを管理するホストおよびネットワークセキュリティポリシーを管理、発見、および交渉するためのスケーラブルで分散型フレームワークを提供します。このドキュメントは、そのようなアーキテクチャコンポーネントを強調し、機能的要件を提示します。
Table of Contents
目次
1. Introduction.................................................. 2
1.1. Terminology............................................. 2
1.2. Security Policy and IPsec............................... 2
2. The IP Security Policy Problem Space.......................... 3
3. Requirements for an IP Security Policy Configuration and
Management Framework.......................................... 5
3.1. General Requirements.................................... 5
3.2. Description and Justification........................... 5
3.2.1. Policy Model.................................... 5
3.2.2. Security Gateway Discovery...................... 6
3.2.3. Policy Specification Language................... 6
3.2.4. Distributed policy.............................. 6
3.2.5. Policy Discovery................................ 6
3.2.6. Security Association Resolution................. 6
3.2.7. Compliance Checking............................. 7
4. Security Considerations....................................... 7
5. IANA Considerations........................................... 7
6. Intellectual Property Statement............................... 7
7. References.................................................... 8
7.1. Normative References.................................... 8
7.2. Informative References.................................. 8
8. Disclaimer.................................................... 8
9. Acknowledgements.............................................. 8
10. Authors' Addresses............................................ 9
11. Full Copyright Statement...................................... 10
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommented "、" "、" optional "は、[RFC 2119]で説明されているように解釈されます。
Network-layer security now enjoys broad popularity as a tool for protecting Internet traffic and resources. Security at the network layer can be used as a tool for at least two kinds of security architecture:
ネットワーク層のセキュリティは、インターネットトラフィックとリソースを保護するためのツールとして、幅広い人気を獲得しています。ネットワークレイヤーのセキュリティは、少なくとも2種類のセキュリティアーキテクチャのツールとして使用できます。
a) Security gateways. Security gateways (including "firewalls") at the edges of networks use IPsec [RFC-2401] to enforce access control, protect the confidentiality and authenticity of network traffic entering and leaving a network, and to provide gateway services for virtual private networks (VPNs).
a) セキュリティゲートウェイ。ネットワークのエッジでのセキュリティゲートウェイ（「ファイアウォール」を含む）は、IPSEC [RFC-2401]を使用してアクセス制御を実施し、ネットワークに出入りするネットワークトラフィックの機密性と信頼性を保護し、仮想プライベートネットワークにゲートウェイサービスを提供します（VPNS）。
b) Secure end-to-end communication. Hosts use IPsec to implement host-level access control, to protect the confidentiality and authenticity of network traffic exchanged with the peer hosts with which they communicate, and to join virtual private networks.
b) エンドツーエンドのコミュニケーションを確保します。ホストはIPSECを使用してホストレベルのアクセス制御を実装し、通信するピアホストと交換されたネットワークトラフィックの機密性と信頼性を保護し、仮想プライベートネットワークに参加します。
On one hand, IPsec provides an excellent basis for a very wide range of protection schemes; on the other hand, this wide range of applications for IPsec creates complex management tasks that become especially difficult as networks scale up and require different security policies, and are controlled by different entities, for different kinds of traffic in different parts of the network.
一方では、IPSECは非常に幅広い保護スキームの優れた基盤を提供します。一方、IPSECのこの幅広いアプリケーションは、ネットワークがスケールアップし、異なるセキュリティポリシーを必要とするため、特に困難になる複雑な管理タスクを作成し、ネットワークのさまざまな部分のさまざまな種類のトラフィックに対して異なるエンティティによって制御されます。
As organizations deploy security gateways, the Internet divides into heterogeneous regions that enforce different access and security policies. Yet it is often still necessary for hosts to communicate across the network boundaries controlled by several different policies. The wide range of choices of cryptographic parameters (at multiple protocol layers) complicates matters and introduces the need for hosts and security gateways to identify and negotiate a set of security parameters that meets each party's requirements. Even more complexity arises as IPsec becomes the means through which firewalls enforce access control and VPN membership; two IPsec endpoints that want to establish a security association must identify, not only the mutually acceptable cryptographic parameters, but also exactly what kind of access the combined security policy provides.
組織がセキュリティゲートウェイを展開すると、インターネットは異なるアクセスとセキュリティポリシーを実施する不均一な地域に分かれています。しかし、多くの場合、ホストはいくつかの異なるポリシーによって制御されたネットワークの境界を越えて通信する必要があります。暗号化パラメーターの幅広い選択肢（複数のプロトコル層）は問題を複雑にし、各当事者の要件を満たす一連のセキュリティパラメーターを特定して交渉するためのホストとセキュリティゲートウェイの必要性を導入します。IPSECがファイアウォールがアクセス制御とVPNメンバーシップを実施する手段になるにつれて、さらに複雑さが生じます。セキュリティ協会を確立したい2つのIPSECエンドポイントは、相互に受け入れられる暗号化パラメーターだけでなく、組み合わせたセキュリティポリシーが提供するアクセスの種類を正確に特定する必要があります。
While the negotiation of cryptographic and other security parameters for IPsec security associations (SAs) is supported by key management protocols (e.g., ISAKMP [RFC-2408]), the IPsec key management layer does not provide a scheme for managing, negotiating, or enforcing the security policies under which SAs operate.
IPSECセキュリティ協会（SAS）の暗号化およびその他のセキュリティパラメーターの交渉は、主要な管理プロトコル（例：ISAKMP [RFC-2408]）によってサポートされていますが、IPSECキー管理レイヤーは、管理、交渉、または施行のスキームを提供しません。SASが動作するセキュリティポリシー。
IPSP provides the framework for managing IPsec security policy, negotiating security association (SA) parameters between IPsec endpoints, and distributing authorization and policy information among hosts that require the ability to communicate via IPsec.
IPSPは、IPSECセキュリティポリシーを管理し、IPSECエンドポイント間のセキュリティ協会（SA）のパラメーターを交渉し、IPSECを介して通信する能力を必要とするホスト間で承認とポリシー情報を配布するためのフレームワークを提供します。
IPSP aims to provide a scalable, decentralized framework for managing, discovering and negotiating the host and network IPsec policies that govern access, authorization, cryptographic mechanisms, confidentiality, data integrity, and other IPsec properties.
IPSPは、アクセス、承認、暗号化メカニズム、機密性、データの完全性、およびその他のIPSECプロパティを管理するホストおよびネットワークIPSECポリシーの管理、発見、交渉のためのスケーラブルで分散化されたフレームワークを提供することを目指しています。
The central problem solved by IPSP is that of controlling security policy in a manner that is useful for the wide range of IPsec applications and modes of operation. In particular:
IPSPによって解決される中心的な問題は、幅広いIPSECアプリケーションと動作モードに役立つ方法でセキュリティポリシーを制御することです。特に：
- IPSP hosts may serve as IPsec endpoints, security gateways, network management hubs, or a combination of these functions. IPSP will manage end-users computers (which may be fixed workstations controlled by a single organization or mobile laptops that require remote access to a corporate VPN), firewalls (which provide different services and allow different levels of access to different classes of traffic and users), VPN routers (which support links to other VPNs that might be controlled by a different organization's network policy), web and other servers (which might provide different services depending on where a client request came from), and so on.
- IPSPホストは、IPSECエンドポイント、セキュリティゲートウェイ、ネットワーク管理ハブ、またはこれらの機能の組み合わせとして機能する場合があります。IPSPは、エンドユーザーコンピューター（企業VPNへのリモートアクセスを必要とする単一の組織またはモバイルラップトップによって制御される固定ワークステーションを管理する場合があります）、ファイアウォール（異なるサービスを提供し、さまざまなクラスのトラフィックとユーザーへの異なるレベルのアクセスを可能にします）、VPNルーター（別の組織のネットワークポリシーによって制御される可能性のある他のVPNへのリンクをサポートする）、Webおよびその他のサーバー（クライアントリクエストがどこから来たのかによって異なるサービスを提供する可能性があります）など。
- IPSP administration will be inherently heterogeneous and decentralized. A basic feature of IPsec is that two hosts can establish a Security Association even though they might not share a common security policy, or, indeed, trust one another at all. This property of IPsec becomes even more pronounced at the higher level abstraction managed by IPSP.
- IPSP投与は本質的に不均一で分散化されます。IPSECの基本的な特徴は、2つのホストが共通のセキュリティポリシーを共有していない場合でも、実際に互いに信頼できる場合でも、セキュリティ協会を確立できることです。IPSECのこのプロパティは、IPSPによって管理されるより高いレベルの抽象化でさらに顕著になります。
- The SA parameters acceptable to any pair of hosts (operating under different policies) will often not be specified in advance. IPSP will often have to negotiate and discover the mutually-acceptable SA parameters on-the-fly when two hosts attempt to create a new SA.
- ホストのペア（異なるポリシーの下で動作する）に許容できるSAパラメーターは、事前に指定されないことがよくあります。IPSPは、2人のホストが新しいSAを作成しようとすると、相互に容認できるSAパラメーターを飛行中に交渉して発見する必要があることがよくあります。
- Some hosts will be governed by policies that are not directly specified in the IPSP language. For example, a host's IPsec policy might be derived from a more comprehensive higher-layer security policy managed by some other system. Similarly, some vendors might develop specialized (and proprietary) tools for managing policy in their products. In such cases, it is necessary to derive an IPSP policy specification for only those aspects of a host's policy that involve interoperability with other hosts running IPSP.
- 一部のホストは、IPSP言語で直接指定されていないポリシーによって管理されます。たとえば、ホストのIPSECポリシーは、他のシステムが管理するより包括的な高層セキュリティポリシーから導き出される場合があります。同様に、一部のベンダーは、製品のポリシーを管理するための専門的な（および独自の）ツールを開発する場合があります。そのような場合、IPSPを実行している他のホストとの相互運用性を含むホストのポリシーのこれらの側面のみについて、IPSPポリシー仕様を導き出す必要があります。
- IPSP must scale to support complex policy administration schemes. In even modest-size networks, one administrator must often control policy remotely, and must have the ability to change the policy on many different hosts at the same time. In larger networks (or those belonging to large organizations), a host's policy might be governed by several different authorities (e.g., several different departments might have the authority to add users to a firewall or open access to new services). Different parts of a policy might be "owned" by different entities in a complex hierarchy. IPSP must provide a mechanism for delegating specific kinds of authority to specific entities.
- IPSPは、複雑な政策管理スキームをサポートするためにスケーリングする必要があります。控えめなサイズのネットワークでさえ、1人の管理者が多くの場合ポリシーをリモートで制御する必要があり、多くの異なるホストのポリシーを同時に変更する能力を持たなければなりません。大規模なネットワーク（または大規模な組織に属するもの）では、ホストのポリシーがいくつかの異なる当局によって管理される可能性があります（たとえば、いくつかの異なる部門がユーザーをファイアウォールに追加したり、新しいサービスにオープンアクセスする権限を持っている可能性があります）。ポリシーのさまざまな部分は、複雑な階層内のさまざまなエンティティによって「所有」される場合があります。IPSPは、特定の種類の権限を特定のエンティティに委任するメカニズムを提供する必要があります。
- The semantics of IPSP must be well defined, particularly with respect to any security-critical aspects of the system.
- IPSPのセマンティクスは、特にシステムのセキュリティ批判的な側面に関して、明確に定義する必要があります。
- IPSP must be secure, sound, and comprehensible. It should be possible to understand what an IPSP policy does; the difficulty of understanding an IPSP policy should be somewhat proportional to the complexity of the problem it solves. It should also be possible to have confidence that an IPSP policy does what it claims, and that IPSP implementation is correct; architecturally, the security-critical parts of IPSP should be small and well-specified enough to allow verification of their correct operation. Ideally, IPSP should be compatible with formal methods, such as implementing security policies with provable properties.
- IPSPは安全で、健全で、理解できなければなりません。IPSPポリシーが何をするかを理解することが可能であるべきです。IPSPポリシーを理解することの難しさは、それが解決する問題の複雑さに多少比例する必要があります。また、IPSPポリシーが主張することを行うこと、およびIPSPの実装が正しいことを自信を持つことも可能です。建築的には、IPSPのセキュリティが批判的な部分は小さく、正しい操作の検証を可能にするのに十分十分に指定する必要があります。理想的には、IPSPは、証明可能なプロパティを使用してセキュリティポリシーを実装するなど、正式な方法と互換性がある必要があります。
An IPSP solution MUST include:
IPSPソリューションには以下を含める必要があります。
- A policy model with well-defined semantics that captures the relationship between IPsec SAs and higher-level security policies,
- IPSEC SASと高レベルのセキュリティポリシーとの関係を捉えた明確に定義されたセマンティクスを持つポリシーモデル、
- A gateway discovery mechanism that allows hosts to discover where to direct IPsec traffic intended for a specific endpoint,
- ホストが特定のエンドポイントを対象としたIPSECトラフィックをどこに向けるかを発見できるようにするゲートウェイディスカバリーメカニズム、
- A well-specified language for describing host policies,
- ホストポリシーを説明するための適切に指定された言語、
- A means for distributing responsibility for different aspects of policy to different entities,
- さまざまなエンティティにポリシーのさまざまな側面の責任を分配するための手段、
- A mechanism for discovering the policy of a host,
- ホストのポリシーを発見するためのメカニズム、
- A mechanism for resolving the specific IPsec parameters to be used between two hosts governed by different policies (and for determining whether any such parameters exist); and,
- 異なるポリシーによって支配された2つのホスト間で使用される特定のIPSECパラメーターを解決するためのメカニズム（およびそのようなパラメーターが存在するかどうかを判断するため）。そして、
- A well-specified mechanism for checking for compliance with a host's policy when SAs are created.
- SASが作成されたときに、ホストのポリシーのコンプライアンスをチェックするための適切に指定されたメカニズム。
The mechanisms used in IPSP must not require any protocol modifications in any of the IPsec standards (ESP [RFC-2406], AH, [RFC-2402], IKE [RFC-2409]). The mechanisms must be independent of the SA-negotiation protocol, but may assume certain functionality from such a protocol (this is to ensure that future SA-negotiation protocols are not incompatible with IPSP).
IPSPで使用されるメカニズムは、IPSEC標準（ESP [RFC-2406]、AH、[RFC-2402]、IKE [RFC-2409]）のいずれかのプロトコル変更を必要としない必要があります。メカニズムはSA交渉プロトコルとは無関係でなければなりませんが、そのようなプロトコルから特定の機能を想定する場合があります（これは、将来のSA交渉プロトコルがIPSPと互換性がないことを確認するためです）。
A Policy Model defines the semantics of IPsec policy. Policy specification, checking, and resolution should implement the semantics defined in the model. However, the model should be independent of the specific policy distribution mechanism and policy discovery scheme, to the extent possible.
ポリシーモデルは、IPSECポリシーのセマンティクスを定義します。ポリシーの仕様、チェック、および解像度は、モデルで定義されているセマンティクスを実装する必要があります。ただし、モデルは、可能な限り、特定のポリシー配布メカニズムとポリシー発見スキームとは無関係である必要があります。
The gateway discovery mechanism may be invoked by any host or gateway. Its goal is to determine what IPsec gateways exist between the initiator and the intended communication peer. The actual mechanism employed may be used to piggy-back information necessary by other components of the IPSP architecture (e.g., policy discovery, as is done in [SPP]). The discovery mechanism may have to be invoked at any time, independently of existing security associations or other communication, to detect topology changes.
ゲートウェイディスカバリーメカニズムは、任意のホストまたはゲートウェイによって呼び出される場合があります。その目標は、イニシエーターと意図した通信ピアの間にどのようなIPSECゲートウェイが存在するかを決定することです。採用されている実際のメカニズムは、IPSPアーキテクチャの他のコンポーネントが必要とするピギーバック情報に使用できます（たとえば、[SPP]で行われるように、ポリシーの発見）。トポロジの変更を検出するには、既存のセキュリティ協会またはその他のコミュニケーションとは無関係に、いつでも発見される必要がある場合があります。
In order to allow for policy discovery, compliance checking, and resolution across a range of hosts, a common language is necessary in which to express the policies of hosts that need to communicate with one another. Statements in this language are the output of policy discovery, and provide the input to the policy resolution and compliance checking systems. Note that a host's or network's security policy may be expressed in a vendor-specific way, but would be translated to the common language when it is to be managed by the IPSP services.
ポリシーの発見、コンプライアンスチェック、およびさまざまなホスト全体での解決を可能にするためには、相互に通信する必要があるホストのポリシーを表現するために共通言語が必要です。この言語の声明は、ポリシー発見の出力であり、ポリシー解決とコンプライアンスチェックシステムへの入力を提供します。ホストまたはネットワークのセキュリティポリシーは、ベンダー固有の方法で表現される場合がありますが、IPSPサービスによって管理される場合は共通言語に翻訳されることに注意してください。
As discussed above, it must be possible for all or part of a host's policy to be managed remotely, possibly by more than one entity. This is a basic requirement for large-scale networks and systems.
上記で説明したように、ホストのポリシーのすべてまたは一部が、おそらく複数のエンティティによってリモートで管理される可能性がある必要があります。これは、大規模なネットワークとシステムの基本的な要件です。
A policy discovery mechanism must provide the essential information that two IPsec endpoints can use to determine what kinds of SAs are possible between one another. This is especially important for hosts that are not controlled by the same entity, and that might not initially share any common information about one another. Note that a host need not reveal its entire security policy, only enough information to support the SA resolution system for hosts that might want to communicate with it.
ポリシー発見メカニズムは、2つのIPSECエンドポイントが互いにどのようなSASが可能かを判断するために使用できる重要な情報を提供する必要があります。これは、同じエンティティによって制御されていないホストにとって特に重要であり、最初は互いに一般的な情報を共有していない可能性があります。ホストは、セキュリティポリシー全体を明らかにする必要はなく、それと通信したいホストのSA解像度システムをサポートするのに十分な情報のみを明らかにする必要があることに注意してください。
Once two hosts have learned enough about each other's policies, it must be possible (and computationally feasible) to find an acceptable set of SA parameters that meets both host's requirements and will lead to the successful creation of a new SA.
2人のホストがお互いのポリシーについて十分に学んだら、ホストの要件の両方を満たし、新しいSAの作成に成功するSAパラメーターの許容可能なセットを見つけることが可能（および計算可能に実現可能）でなければなりません。
When a host proposes the output of the SA resolution scheme, it must be checked for compliance with the local security policy of each host. The security and soundness of the SAs created by IPSP-managed communication should depend only on the correctness of the compliance checking stage. In particular, even if the SA resolution scheme (which is likely to be computationally and conceptually complex) produces an incorrect result, it should still not be possible to violate the specified policy of either host.
ホストがSA解像度スキームの出力を提案する場合、各ホストのローカルセキュリティポリシーへのコンプライアンスを確認する必要があります。IPSPが管理した通信によって作成されたSASのセキュリティと健全性は、コンプライアンスチェック段階の正確性のみに依存する必要があります。特に、SA解像度スキーム（計算的および概念的に複雑である可能性が高い）が間違った結果を生み出す場合でも、いずれかのホストの指定されたポリシーに違反することは不可能です。
This document discusses the high-level requirements for a policy framework and architecture for IPsec. A justification for the various components is given.
このドキュメントでは、IPSECのポリシーフレームワークとアーキテクチャの高レベルの要件について説明します。さまざまなコンポーネントの正当化が与えられます。
No action is required by IANA.
IANAの措置は不要です。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。
Copies of claims of rights made available for publication 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 Secretariat.
出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]ケント、S。およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC-2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC-2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2408] Maughan、D.、Shertler、M.、Schneider、M.およびJ. Turner、「インターネットセキュリティ協会および主要管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[RFC-2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409] Harkins、DおよびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[SPP] Sanchez, L. and M. Condell, "The Security Policy Protocol", Work in Progress.
[spp] Sanchez、L。およびM. Condell、「セキュリティポリシープロトコル」、進行中の作業。
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
ここでの見解と仕様は著者のものであり、必ずしも雇用主の見解ではありません。著者とその雇用主は、この仕様の正しいまたは誤った実装または使用から生じる問題に対する責任を明確に否認します。
The authors thank the members of the IPsec Policy working group that contributed to this document.
著者は、この文書に貢献したIPSECポリシーワーキンググループのメンバーに感謝します。
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 USA
Matt Blaze AT＆T Labs -Research180 Park Avenue Florham Park、NJ 07932 USA
EMail: mab@crypto.com
Angelos D. Keromytis Computer Science Department Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027, USA
アンジェロスD.ケロミティコンピューターサイエンス部コロンビア大学1214アムステルダムアベニュー、M.C。0401ニューヨーク、ニューヨーク10027、米国
EMail: angelos@cs.columbia.edu
Michael C. Richardson Sandelman Software Works Corp. 470 Dawson Avenue Ottawa, ON K1Z 5V7 Canada
マイケルC.リチャードソンサンデルマンソフトウェアワークスコーポレーション470ドーソンアベニューオタワ、K1Z 5V7カナダ
Phone: +1 613 276-6809
EMail: mcr@sandelman.ottawa.on.ca
Luis A. Sanchez Xapiens Corporation PO Box 9023694 San Juan, PR 00902 USA
Luis A. Sanchez Xapiens Corporation PO Box 9023694 San Juan、PR 00902 USA
Phone: +1 (787) 832-4717
EMail: lsanchez@xapiens.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。