Network Working Group S. Bellovin
Request for Comments: 5406 Columbia University
BCP: 146 February 2009
Category: Best Current Practice
Guidelines for Specifying the Use of IPsec Version 2
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified.
多くのインターネットドラフトのセキュリティの考慮事項のセクションでは、実際には、「ただIPsecを使用」と言います。これは時々正しいですが、多くの場合それは本当の、相互運用可能なセキュリティ機構を持たないユーザを残します。このメモはIPsecのバージョン2は、指定するべきではない必要があるときにいくつかのガイダンスを提供しています。
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While the use of IPsec is sometimes the correct security solution, more information is needed to provide interoperable security solutions. In some cases, IPsec is unavailable in the likely endpoints. If IPsec is unavailable to -- and hence unusable by -- a majority of the users in a particular protocol environment, then the specification of IPsec is tantamount to saying "turn off security" within this community. Further, when IPsec is available, the implementation may not provide the proper granularity of protection. Finally, if IPsec is available and appropriate, the document mandating the use of IPsec needs to specify just how it is to be used.
多くのインターネットドラフトのセキュリティの考慮事項のセクションでは、実際には、「ただIPsecを使用」と言います。 IPsecの使用は時々正しいセキュリティソリューションですが、より多くの情報が相互運用可能なセキュリティ・ソリューションを提供するために必要とされます。いくつかのケースでは、IPsecはおそらく、エンドポイントでは使用できません。よるので、使用できない - - IPsecが使用できない場合に、特定のプロトコル環境でのユーザーの大多数は、IPsecの仕様は、このコミュニティ内の「セキュリティをオフ」ということに等しいです。 IPsecが利用可能になったときまた、実装は、保護の適切な粒度を提供することはできません。 IPsecが利用可能かつ適切であれば最後に、IPsecの使用を義務付ける文書は、それが使用されるだけの方法を指定する必要があります。
The goal of this document is to provide guidance to protocol designers on the specification of IPsec when it is the appropriate security mechanism. The protocol specification is expected to provide realistic, interoperable security. Therefore, guidance on the configuration of the various IPsec databases, such as the Security Policy Database (SPD), is often required.
このドキュメントの目標は、それが適切なセキュリティメカニズムであるときにIPsecの仕様上のプロトコル設計者へのガイダンスを提供することです。プロトコル仕様は現実的で、相互運用可能なセキュリティを提供することが期待されます。したがって、このようなセキュリティポリシーデータベース（SPD）など、さまざまなIPsecのデータベースの構成に関するガイダンスは、しばしば必要とされます。
This document describes how to specify the use of IPsec Version 2 [RFC2401] including the ESPv2 (Encapsulating Security Payload version 2) [RFC2406], AHv2 (Authentication Header version 2) [RFC2402], and IKEv1 (Internet Key Exchange version 1) [RFC2409]. A separate document will describe the IPsec Version 3 suite [RFC4301] [RFC4302] [RFC4303] [RFC4306].
この文書では、[ESPv2（カプセル化セキュリティペイロードのバージョン2）[RFC2406]、AHv2（認証ヘッダーバージョン2）[RFC2402]、およびIKEv1の（インターネット鍵交換バージョン1）を含む、IPsecのバージョン2 [RFC2401]の使用を指定する方法について説明しますRFC2409]。別の文書は、IPsecバージョン3スイート[RFC4301]、[RFC4302]、[RFC4303]、[RFC4306]を説明します。
For further guidance on security considerations (including discussion of IPsec), see [RFC3552].
（IPsecのの議論を含む）セキュリティの考慮事項に関する更なるガイダンスについては、[RFC3552]を参照してください。
NOTE: Many of the arguments below relate to the capabilities of current implementations of IPsec. These may change over time; this advice is based on the knowledge available to the IETF at publication time.
注：以下の引数の多くは、IPsecの現在の実装の能力に関係します。これらは、時間の経過とともに変更される可能性があり、このアドバイスは、発行時にIETFに利用可能な知識に基づいています。
The design of security protocols is a subtle and difficult art. The cautions here about specifying the use of IPsec should NOT be taken to mean that you should invent your own new security protocol for each new application. If IPsec is a bad choice, using another standardized, well-understood security protocol will almost always give the best results for both implementation and deployment. Security protocols are very hard to design; rolling out a new one will require extensive theoretical and practical work to confirm its security properties and will incur both delay and uncertainty.
セキュリティプロトコルの設計は微妙で難しい芸術です。ここでのIPsecの使用を指定に関する注意事項は、あなたがそれぞれの新しいアプリケーションのために、独自の新しいセキュリティプロトコルを発明する必要があることを意味すると解釈されるべきではありません。 IPsecは悪い選択である場合は、別の標準化され、十分に理解セキュリティプロトコルを使用すると、ほとんどの場合、実装と展開の両方のために最良の結果が得られます。セキュリティプロトコルは、設計することは非常に困難です。新しいものを展開すると、そのセキュリティプロパティを確認するために大規模な理論と実践的な作業が必要になりますし、遅延や不確実性の両方が発生します。
IPsec is composed of a number of different pieces. These can be used to provide confidentiality, integrity, and replay protection; though some of these can be configured manually, generally a key management component is used. Additionally, the decision about whether and how to use IPsec is controlled by a policy database of some sort.
IPsecが異なる部分の数で構成されています。これらは、機密性、完全性、および再生保護を提供するために使用することができます。これらのいくつかは手動で設定することができるが、一般的に鍵管理コンポーネントが使用されます。また、IPsecを使用するかどうか、どのようにについての決定は、ある種のポリシーデータベースによって制御されます。
The Authentication Header (AH) [RFC2402] and the Encapsulating Security Payload (ESP) [RFC2406] are the over-the-wire security protocols. Both provide (optional) replay protection. ESP typically is used to provide confidentiality (encryption), integrity, and authentication for traffic. ESP also can provide integrity and authentication without confidentiality, which makes it a good alternative to AH in most cases where confidentiality is not a required or desired service. Finally, ESP can be used to provide confidentiality alone, although this is not recommended [Bell96].
認証ヘッダ（AH）[RFC2402]およびカプセル化セキュリティペイロード（ESP）[RFC2406]はオーバーザワイヤセキュリティプロトコルです。どちらも、（オプション）リプレイ保護を提供します。 ESPは通常、トラフィックの機密性（暗号化）、整合性、および認証を提供するために使用されます。 ESPはまた、機密性が必要な又は所望のサービスではありませんほとんどの場合、AHに良い代替になりた、機密性なしに整合性と認証を提供することができます。これは[Bell96]推奨されていませんが、最後に、ESPは、単独の機密性を提供するために使用することができます。
The difference in integrity protection offered by AH is that AH protects portions of the preceding IP header, including the source and destination address. However, if ESP is used in tunnel mode (see Section 3.2) and integrity/authentication is enabled, the IP header seen by the source and destination hosts is completely protected anyway.
AHが提供する完全性保護の差は、AHは、ソースとデスティネーションアドレスを含む、先行するIPヘッダの部分を保護することです。 ESPトンネルモードで使用される場合は、（セクション3.2を参照）、完全性/認証がイネーブルされ、ソースおよび宛先ホストによって見られるIPヘッダは完全にとにかく保護されています。
AH can also protect those IP options that need to be seen by intermediate routers, but must be intact and authentic when delivered to the receiving system. At this time, use (and existence) of such IP options is extremely rare.
AHは、中間ルータによって見られることを必要とするIPオプションを保護することができますが、受信側システムに配信するとき無傷で、本格的でなければなりません。このとき、たとえば、IPオプションの使用（および存在）は非常にまれです。
If an application requires such protection, and if the information to be protected cannot be inferred from the key management process, AH must be used. (ESP is generally regarded as easier to implement; however, virtually all IPsec packages support both.) If confidentiality is required, ESP must be used. It is possible to use AH in conjunction with ESP, but this combination is rarely required.
アプリケーションは、このような保護を必要とする場合は、保護すべき情報が鍵管理プロセスから推測することができない場合、および、AHを使用する必要があります。 （ESPは、一般的に実装しやすいと考えているが、事実上すべてのIPsecパッケージは両方をサポートしています。）機密性が必要な場合は、ESPを使用する必要があります。 ESPと一緒にAHを使用することが可能であるが、この組み合わせはほとんど必要ありません。
All variants of IPsec have problems with NAT boxes -- see [RFC3715] for details -- but AH is considerably more troublesome. In environments where there is substantial likelihood that the two endpoints will be separated by a NAT box -- this includes almost all services involving user-to-server traffic, as opposed to server-to-server traffic -- NAT traversal [RFC3948] should be mandated and AH should be avoided. (Note that [RFC3948] is for ESP only, and cannot be used for AH.)
IPsecのすべての変異体がNATボックスに問題がある - 詳細については、[RFC3715]を見てください - しかし、AHはかなり面倒です。これは、ほとんどすべてのサーバ間トラフィックとは反対に、ユーザーからサーバーへのトラフィックを伴うサービス含まれています - - NATトラバーサル[RFC3948]をする必要があり、2つのエンドポイントがNAT箱によって分離されることにかなりの可能性がある環境では義務付けさとAHは避けるべきです。 （[RFC3948]は唯一のESPのためであり、AHのために使用することができないことに注意してください。）
AH and ESP can both be used in either transport mode or tunnel mode. In tunnel mode, the IPsec header is followed by an inner IP header. This is the normal usage for Virtual Private Networks (VPN) and is generally required whenever either end of the IPsec-protected path is not the ultimate IP destination, e.g., when IPsec is implemented in a firewall, router, etc.
AHとESPは、両方のトランスポートモードまたはトンネルモードのいずれかで使用することができます。トンネルモードでは、IPsecヘッダは、内側IPヘッダが続きます。これは、仮想プライベートネットワーク（VPN）のための通常の使用であり、IPsecは、ファイアウォール、ルータ、等に実装されたときにIPsec保護パスのいずれかの端部が、例えば、最終的なIP宛先ないときに一般に必要とされます
Transport mode is preferred for point-to-point communication, though tunnel mode can also be used for this purpose.
トンネルモードはまた、この目的のために使用することができるを通じて輸送モードは、ポイント・ツー・ポイント通信のために好ましいです。
Any cryptographic system requires key management. IPsec provides for both manual and automatic key management schemes. Manual key management is easy; however, it doesn't scale very well. Also, IPsec's replay protection mechanisms are not available if manual key management is used. The need for automatic key exchange is discussed in more detail in [RFC4107].
任意の暗号システムは、鍵管理が必要です。 IPsecは、手動と自動の鍵管理方式の両方を提供します。手動鍵管理が容易になります。しかし、それは非常にうまくスケールしません。手動鍵管理が使用されている場合も、IPsecのリプレイの保護メカニズムは使用できません。自動鍵交換の必要性は、[RFC4107]でより詳細に議論されます。
The primary automated key exchange mechanism for IPsec is the Internet Key Exchange (IKE) [RFC2409]. A new, simpler version of IKE has been approved [RFC4306], but many existing systems still use IKEv1. This document does not discuss IKEv2 and IPsecv3. A second mechanism, Kerberized Internet Negotiation of Keys (KINK) [RFC4430], has been defined. It, of course, uses Kerberos and is suitable if and only if a Kerberos infrastructure is available.
IPsecのための主要な自動化された鍵交換メカニズムは、インターネット鍵交換（IKE）[RFC2409]です。 IKEの新しい、簡単なバージョンは、[RFC4306]承認されていますが、多くの既存のシステムはまだのIKEv1を使用します。この文書では、IKEv2のとIPsecv3については説明しません。第二のメカニズム、キーのKerberos対応インターネットネゴシエーション（KINK）[RFC4430]は、定義されています。それは、もちろん、Kerberosを使用し、Kerberosのインフラが利用可能である場合にのみ場合に適しています。
If a decision to use IKE is made, the precise mode of operation must be specified as well. IKE can be used in main mode or aggressive mode; both support digital signatures, two different ways of using public key encryption, and shared secrets for authentication.
IKEを使用する決定がなされた場合、操作の正確なモードも同様に指定する必要があります。 IKEメインモードまたはアグレッシブモードで使用することができます。両方の認証にデジタル署名、公開鍵暗号を使用する2つの異なる方法、および共有秘密をサポートしています。
Shared secret authentication is simpler; however, it doesn't scale as well in many-to-many communication scenarios since each endpoint must share a unique secret with every peer with which it can communicate. Note, though, that using shared secrets in IKE is far preferable to manual keying.
共有秘密の認証は簡単です。各エンドポイントは、それが通信できるすべてのピアとのユニークな秘密を共有しなければならないので、しかし、それは、多対多通信のシナリオでも同様に拡張できません。 IKEで共有秘密を使用して手動キーイングはるかに好適であること、しかし、注意してください。
In most real-world situations where public key modes of IKE are used, locally issued certificates are employed. That is, the administrator of the system or network concerned will issue certificates to all authorized users. These certificates are useful only for IPsec.
IKEの公開鍵モードが使用されているほとんどの実世界の状況では、ローカルで発行された証明書が使用されています。つまり、関係するシステムやネットワークの管理者は、許可されたすべてのユーザーに証明書を発行します。これらの証明書はIPsecのに有用です。
It is sometimes possible to use certificates [RFC5280] from an existing Public Key Infrastructure (PKI) with IKE. In practice, this is rare. Furthermore, not only is there no global PKI covering most
IKEと既存の公開鍵インフラストラクチャ（PKI）からの証明書[RFC5280]を使用できる場合があります。実際には、これはまれです。さらに、だけでなく、ほとんどをカバーするグローバルなPKIはありません
Internet endpoints, there probably never will be. Designing a structure that assumes such a PKI is a mistake. In particular, assuming that an arbitrary node will have an "authentic" certificate, issued by a mutually trusted third party and vouching for that node's identity, is wrong. Again, such a PKI does not and probably will not exist. Public key IKE is generally a good idea, but should almost always be used with locally issued certificates as opposed to certificates from an existing PKI.
インターネットエンドポイントは、おそらく存在しませんでした。そのようなPKIを前提とした構造を設計することは間違いです。具体的には、任意のノードが相互に信頼できる第三者によって発行され、そのノードの識別のためにバウチング、「本物」の証明書を持っているだろうと仮定して、間違っています。また、このようなPKIは存在しませんしませんし、おそらく。公開鍵IKEは、一般的に良いアイデアですが、既存のPKIからの証明書とは対照的に、ほとんど常にローカルで発行された証明書を使用する必要があります。
Note that public key schemes require a substantial amount of computation. Protocol designers should consider whether or not such computations are feasible on devices of interest to their clientele. Using certificates roughly doubles the number of large exponentiations that must be performed, compared with shared secret versions of IKE.
公開鍵方式は、計算のかなりの量を必要とすることに注意してください。プロトコルの設計者は、このような計算は彼らの顧客への関心のデバイス上で実行可能であるかどうかを検討すべきです。証明書を使用しておおよそIKEの共有秘密のバージョンと比較し、実行されなければならない大きな累乗数を倍増します。
Today, even low-powered devices can generally perform enough computation to set up a limited number of security associations. Concentration points, such as firewalls or VoIP servers, may require hardware assists, especially if many peers are expected to create security associations at about the same time.
今日は、さえ低電力デバイスは、一般的にセキュリティアソシエーションの限られた数を設定するのに十分な計算を実行することができます。 、ファイアウォールまたはVoIPサーバなどの集中点は、多くのピアがほぼ同時にセキュリティアソシエーションを作成することが期待されている場合は特に、ハードウェア支援が必要な場合があります。
Using any automated key management mechanism can be difficult when trying to protect low-level protocols. For example, even though [RFC2461] specified the use of IPsec to protect IPv6 Neighbor Discovery, it was impossible to do key management: nodes couldn't use IKE because it required IP-level communication, and that isn't possible before Neighbor Discovery associations are set up.
低レベルのプロトコルを保護しようとすると、任意の自動化された鍵管理メカニズムを使用することが困難な場合があります。それはIPレベルの通信を必要とするので、ノードがIKEを使用することができなかった、そしてそれは、近隣探索の前には不可能である。例えば、[RFC2461]はIPv6の近隣探索を保護するためにIPsecを使用することを指定していても、鍵管理を行うことができませんでした関連付けが設定されています。
It is, in some sense, a misnomer to speak of the API as a part of IPsec since this piece is missing on many systems. To the extent that APIs exist, they aren't standardized. The problem is simple: there is no portable way (and often no way at all) for an application to request IPsec protection, or to tell if it was used for given inbound packets or connections.
この作品は、多くのシステムで不足しているので、IPsecの一部としてAPIの話をする、ある意味では、誤った名称です。 APIが存在する限り、それらが標準化されていません。問題は単純です：IPsec保護を要求する、またはそれが与えられた着信パケットまたは接続のために使用された場合伝えるために、アプリケーションのためのポータブルな方法（と、多くの場合、すべてでは全くない）がありません。
There are additional problems:
付加的な問題があります。
o Applications rarely have access to such APIs. Rather, IPsec is usually configured by a system or network administrator.
Oアプリケーションはほとんど、このようなAPIへのアクセスを持っていません。むしろ、IPsecのは、通常はシステム管理者またはネットワーク管理者によって設定されています。
o Applications are unable to verify that IPsec services are being used underneath.
Oアプリケーションは、IPsecサービスが下に使用されていることを確認することはできません。
o Applications are unaware of the specific identities and properties of the protected channel provided by IPsec. For instance, the IPsec key management mechanisms may be aware of the identity and authorization of the peer, but this information cannot be used by the application nor linked to application-level decisions, such as access to resources reserved to the entity identified by this identity.
Oアプリケーションは、特定のアイデンティティとIPsecが提供する保護されたチャネルの性質に気づいていません。例えば、IPsecの鍵管理メカニズムは、ピアの識別および認可を認識することができるが、この情報は、アプリケーションで使用も、そのようなこのアイデンティティによって識別されたエンティティに予約されたリソースへのアクセスのようなアプリケーション・レベルの決定にリンクすることができません。
Router- or firewall-based IPsec implementations pose even greater problems since there is no standardized over-the-wire protocol for communicating this information from outboard encryptors to hosts.
ホストの外側暗号からこの情報を通信するための標準化されたオーバー・ザ・ワイヤプロトコルが存在しないためRouter-またはファイアウォールベースのIPsec実装は、さらに大きな問題を提起します。
By contrast, higher-layer security services, such as TLS, are able to provide the necessary control and assurance.
対照的に、そのようなTLSなどの上位層のセキュリティサービスは、必要な制御および保証を提供することができます。
Although IPsec is now widely implemented and is available for current releases of most host operating systems, it is less available for embedded systems. Few hubs, network address translators, etc., implement it, especially at the low end. It is generally inappropriate to rely on IPsec when many of the endpoints are in this category.
IPsecが広く実装され、ほとんどのホストオペレーティングシステムの現在のリリースのために利用可能であるが、それは組み込みシステムにはあまり使用可能です。など、いくつかのハブ、ネットワークアドレス変換、特にローエンドで、それを実装。エンドポイントの多くは、このカテゴリにいるときには、IPsecに依存することが一般的に不適切です。
Even for host-to-host use, IPsec availability (and experience and ease of use) has generally been for VPNs. Hosts that support IPsec for VPN use frequently do not support it on a point-to-point basis, especially via a stable, well-defined API or user interface.
でも、ホスト間の使用のために、IPsecの可用性（と経験と使いやすさ）は、一般的にVPNのためになっています。 VPNを使用するためにIPsecをサポートするホストは、しばしば、特に安定した、明確に定義されたAPIまたはユーザインタフェースを介して、ポイント・ツー・ポイントベースでそれをサポートしていません。
Finally, few implementations support multiple layers of IPsec. If a telecommuter is using IPsec in VPN mode to access an organizational network, he or she may not be able to employ a second level of IPsec to protect an application connection to a host within the organization. (We note that such support is, in fact, mandated by Case 4 of Section 4.5 of [RFC2401]. Nevertheless, it is not widely available.) The likelihood of such deployment scenarios should be taken into account when deciding whether or not to mandate IPsec.
最後に、いくつかの実装では、IPsecの複数の層をサポートしています。在宅勤務は、組織のネットワークにアクセスするためにVPNモードでIPsecを使用している場合、彼または彼女は、組織内のホストへのアプリケーションの接続を保護するためにIPsecの第二のレベルを採用することができないかもしれません。 （私たちはそれにもかかわらず、それが広く利用可能ではありません、このようなサポートは、実際には、[RFC2401]のセクション4.5の場合4によって義務付けられていることに注意してください。）、このような展開シナリオの可能性を考慮すべきである強制するかどうかを決定する場合IPsecの。
[RFC2401] describes many different forms of endpoint identifier. These include source addresses (both IPv4 and IPv6), host names (possibly as embedded in X.500 certificates), and user IDs (again, possibly as embedded in a certificate). Not all forms of identifier are available on all implementations; in particular, user-granularity identification is not common. This is especially a concern for multi-user systems, where it may not be possible to use different certificates to distinguish between traffic from two different users.
[RFC2401]はエンドポイント識別子の多くの異なる形態を記載しています。これらは、ソース・アドレス（IPv4とIPv6の両方）、ホスト名（X.500証明書に埋め込まれた可能性のような）、及びユーザIDを含む（再び、証明書に埋め込まれた可能性として）。識別子のすべての形態は、すべての実装で使用可能なわけではありません。特に、ユーザ粒度識別は一般的ではありません。これは特に、2人の異なるユーザーからのトラフィックを区別するために異なる証明書を使用することはできないかもしれないマルチユーザシステムのための関心事です。
Again, we note that the ability to provide fine-grained protection, such as keying each connection separately and with per-user credentials, was one of the original design goals of IPsec. Nevertheless, only a few platforms support it. Indeed, some implementations do not even support using port numbers when deciding whether or not to apply IPsec protection.
繰り返しますが、私たちができることは、このような個別およびユーザごとの資格情報を使用して各接続をキーイングよう、きめ細かな保護を提供することに注意し、IPsecのの本来の設計目標の一つでした。それにもかかわらず、わずか数プラットフォームは、それをサポートしています。実際、いくつかの実装でもIPsec保護を適用するかどうかを決定する場合のポート番号を使用してサポートしていません。
Section 4.4 of [RFC2401] describes the Security Policy Database (SPD) and "selectors" used to decide what traffic should be protected by IPsec. Choices include source and destination addresses (or address ranges), protocol numbers (i.e., 6 for TCP and 17 for UDP), and port numbers for TCP and UDP. Protocols whose protection requirements cannot be described in such terms are poorer candidates for IPsec; in particular, it becomes impossible to apply protection at any finer grain than "destination host". Thus, traffic embedded in a Layer 2 Tunneling Protocol (L2TP) [RFC2661] session cannot be protected selectively by IPsec above the L2TP layer, because IPsec has no selectors defined that let it peer into the L2TP packet to find the TCP port numbers. Similarly, the Stream Control Transmission Protocol (SCTP) [RFC4960] did not exist when [RFC2401] was written; thus, protecting individual SCTP applications on the basis of port number could not be done until a new document was written [RFC3554] that defined new selectors for IPsec, and implementations appeared.
[RFC2401]のセクション4.4は、IPsecで保護すべきか、トラフィックを決定するために使用セキュリティポリシーデータベース（SPD）と「セレクタ」を記述する。選択肢は、送信元アドレスと宛先アドレス（またはアドレス範囲）、TCPおよびUDPのプロトコル番号（すなわち、TCP 6および17 UDPなど）、およびポート番号を含みます。その保護要件このような用語で説明することができないプロトコルは、IPsecのために貧しい候補です。特に、それは、「宛先ホスト」よりも任意の細かい粒で保護を適用することができなくなります。 IPsecはないセレクタはそれはそれはTCPポート番号を見つけるためにL2TPパケットにピアせ定義されていないので、このように、レイヤ2トンネリングプロトコル（L2TP）[RFC2661]セッション中に埋め込まれたトラフィックは、L2TP層の上にIPsecによって選択的に保護することができません。 [RFC2401]が書き込まれたとき同様に、ストリーム制御伝送プロトコル（SCTP）[RFC4960]は存在しませんでした。新しい文書が書き込まれるまでこのように、ポート番号に基づいて保護個々SCTPアプリケーションが行うことができなかった[RFC3554] IPsecのための新しいセレクタを定義し、実装が登場しています。
Furthermore, in a world that runs to a large extent on dynamically assigned addresses and often uses dynamically assigned port numbers as well, an all-or-nothing policy for VPNs can work well; other policies, however, can be difficult to create in any usable form.
さらに、動的に割り当てられたアドレスに大きく実行され、多くの場合、同様に動的に割り当てられたポート番号を使用してVPNの全か無かの政策がうまく機能することができ、世界で。他のポリシーは、しかし、任意の使用可能な形式で作成することが困難な場合があります。
The granularity of protection available may have side effects. If certain traffic between a pair of machines is protected by IPsec, does the implementation permit other traffic to be unprotected or protected by different policies? Alternatively, if the implementation is such that it is only capable of protecting all traffic or none, does the device have sufficient CPU capacity to encrypt everything? Note that some low-end devices may have limited secure storage capacity for keys, etc.
利用可能な保護の粒度は、副作用を有することができます。マシンのペア間の特定のトラフィックがIPSecで保護されている場合は、実装は保護されていないか、異なるポリシーによって保護されるように他のトラフィックを許可しますか？実装は、それがすべてのトラフィックまたはnoneを保護することができるだけであるようなものである場合には別の方法として、デバイスはすべてを暗号化するのに十分なCPU能力を持っているのですか？いくつかのローエンド装置はキーのセキュアな記憶容量が限られている場合があります、等
Implementation issues are also a concern here. As before, too many vendors have not implemented the full specification; too many IPsec implementations are not capable of using port numbers in their selectors. Protection of traffic between two hosts is thus on an all-or-nothing basis when these non-compliant implementations are employed.
実装上の問題はここにも懸念されます。前述のように、あまりにも多くのベンダーは、完全な仕様を実装していません。あまりにも多くのIPsec実装は、そのセレクタにポート番号を使用することができません。これらの非準拠の実装が使用されているときに、2つのホスト間のトラフィックの保護は、全か無かの基準であるため。
Although the designers of IPsec tried to leave room for protection of multicast traffic, a complete design wasn't finished until much later. As such, many IPsec implementations do not support multicast. [RFC5374] describes extensions to IPsec to support it. Other relevant documents include [RFC3830], [RFC3547], and [RFC4535].
IPsecのの設計者は、マルチキャストトラフィックの保護のための余地を残すことを試みたものの、完全なデザインがずっと後までに終了しませんでした。そのため、多くのIPsec実装は、マルチキャストをサポートしていません。 [RFC5374]は、それをサポートするためにIPsecに拡張機能について説明します。その他の関連文書は、[RFC3830]、[RFC3547]、および[RFC4535]を含んでいます。
Because of the delay, protocol designers who use multicast should consider the availability of these extensions in target platforms of interest.
そのため遅延のため、マルチキャストを使用するプロトコルの設計者は、関心のあるターゲットプラットフォームにおけるこれらの拡張機能の利用可能性を検討すべきです。
Despite all of the caveats given above, it may still be appropriate to use IPsec in particular situations. The range of choices makes it mandatory to define precisely how IPsec is to be used. Authors of standards documents that rely on IPsec must specify the following:
上記の注意事項の全てにもかかわらず、まだ特定の状況でIPsecを使用することが適切であり得ます。選択肢の範囲は、IPsecを使用する正確にどのように定義することが必須となります。 IPsecのに頼るの規格文書の作成者は、次のように指定する必要があります。
a. What selectors should the initiator of the conversation (the client, in client-server architectures) use? What addresses, port numbers, etc., are to be used?
A。 （クライアント・サーバー・アーキテクチャでは、クライアント、）会話のイニシエータはどのようなセレクタを使うべきでしょうか？何等のアドレス、ポート番号、使用することがありますか？
b. What IPsec protocol is to be used: AH or ESP? What mode is to be employed: transport mode or tunnel mode?
B。何のIPsecプロトコルを使用する：AHまたはESP？トランスポートモードまたはトンネルモードを：どのようなモードが採用されるのですか？
c. What form of key management is appropriate?
C。鍵管理のどのような形が適切ですか？
d. What form of identification should be used? Choices include IP address, DNS name with or without a user name, and X.500 distinguished name.
D。識別のどのような形を使用する必要がありますか？選択肢は、IPアドレス、ユーザー名の有無にかかわらずDNS名、およびX.500識別名が含まれます。
e. If the application server will switch user IDs (i.e., it is a login service of some sort) and user name identification is used, is a new security association negotiated that utilizes a user-granularity certificate? If so, when?
電子。アプリケーションサーバはユーザIDを切り替えます（すなわち、それはある種のログインサービスである）とユーザ名の識別が使用されている場合、ユーザー粒度の証明書を利用して交渉し、新しいセキュリティアソシエーションのですか？もしそうなら、とき？
f. What form of authentication should be used? Choices include pre-shared secrets and certificates.
F。認証のどのような形を使用する必要がありますか？選択肢は、事前共有秘密と証明書が含まれます。
g. How are the participants authorized to perform the operations that they request? For instance, are all devices with a certificate from a particular source allowed to use any application with IPsec or access any resource? (This problem can appear with any security service, of course.)
グラム。どのように参加者は、彼らが要求する操作を実行する権限を与えていますか？例えば、特定のソースからの証明書を持つすべてのデバイスは、IPsecで任意のアプリケーションを使用するか、任意のリソースにアクセスすることを許可されていますか？ （この問題はもちろんのすべてのセキュリティサービスを、と表示されます。）
h. Which of the many variants of IKE must be supported? Main mode? Aggressive mode?
時間。 IKEの多くの亜種のうちどれがサポートされなければなりませんか？メインモード？アグレッシブモード？
Note that there are two different versions of IKE: IKE and IKEv2.
IKEv2 is simpler and cleaner, but is not yet widely available.
You must specify which version of IKE you require.
i. Is suitable IPsec support available in likely configurations of the products that would have to employ IPsec?
私。適したIPsecサポートは、IPsecを採用しなければならない製品の可能性が高い構成で利用可能ですか？
Let us now work through an example based on these guidelines. We will use the Border Gateway Protocol (BGP) [RFC4271] to show how to evaluate and specify the use of IPsec for transmission security, rather than the mechanism described in [RFC2385]. Note carefully that we are not saying that IPsec is an appropriate choice here. Rather, we are demonstrating the necessary examination and specification process. Also note that the deeper security issues raised by BGP are not addressed by IPsec or any other transmission security mechanism; see [Kent00a] and [Kent00b] for more details.
私たちは今、これらのガイドラインに基づいた例を介して動作してみましょう。私たちは評価し、メカニズムは[RFC2385]で説明したのではなく、伝送セキュリティのためのIPsecの使用を指定する方法を示すために、ボーダーゲートウェイプロトコル（BGP）[RFC4271]を使用します。私たちは、IPsecが、ここで適切な選択であることを言っていないことを慎重に注意してください。むしろ、我々は必要な検査や仕様のプロセスを実証しています。また、BGPが提起した、より深いセキュリティ上の問題がIPSecまたは任意の他の伝送のセキュリティ・メカニズムによって対処されていないことに注意してください。詳細については、[Kent00a]を参照し、[Kent00b]。
Selectors BGP runs between manually configured pairs of hosts on TCP port 179. The appropriate selector would be the pair of BGP speakers, for that port only. Note that the router's "loopback address" is almost certainly the address to use.
セレクタBGPは、そのポートのために、BGPスピーカのペアであろう適切なセレクタ179 TCPポート上のホストの手動で設定対の間に実行されます。ルータの「ループバックアドレスは」ほぼ確実に使用するアドレスであることに注意してください。
Mode Transport mode would be the proper choice if IPsec were used. The information being communicated is generally not confidential, so encryption need not be used. Either AH or ESP can be used; if ESP is used, the sender's IP address would need to be checked against the IP address asserted in the key management exchange. (This check is mandated by [RFC2401].) For the sake of interoperability, either AH or ESP would need to be specified as mandatory to implement.
モードトランスポートモードは、IPsecを使用した場合の適切な選択だろう。通信されている情報は、一般的に機密ではないので、暗号化を使用する必要はありません。 AHまたはESPのどちらかを使用することができます。 ESPを使用する場合は、送信者のIPアドレスは、鍵管理引き換えにアサートIPアドレスと照合する必要があろう。 （このチェックは、[RFC2401]で義務付けられている。）の相互運用性のために、AHまたはESPのいずれかを実装するために必須として指定する必要があります。
Key Management To permit replay detection, an automated key management system should be used, most likely IKE. Again, the RFC author should pick one.
キー管理は、自動化された鍵管理システムを使用する必要があり、最も可能性の高いIKEをリプレイ検出を可能にします。ここでも、RFCの作者は、1を選択する必要があります。
Security Policy Connections should be accepted only from the designated peer. (Note that this restriction applies only to BGP. If the router -- or any IPsec host -- runs multiple services with different security needs, each such service requires its own security policy.)
セキュリティポリシーの接続は、指定されたピアからのみ受け入れるべきです。 （この制限は、BGPにのみ適用されることに注意してくださいルータ場合 - 。または任意のIPsecのホストが - 異なるセキュリティニーズを持つ複数のサービスを実行し、各そのようなサービスは、独自のセキュリティポリシーが必要です。）
Authentication Given the number of BGP-speaking routers used internally by large ISPs, it is likely that shared key mechanisms are inadequate. Consequently, certificate-based IKE must be supported. However, shared secret mode is reasonable on peering links or (perhaps) on links between ISPs and customers. Whatever scheme is used, it must tie back to a source IP address or Autonomous System (AS) number in some fashion, since other BGP policies are expressed in these terms. If certificates are used, would they use IP addresses or AS numbers? Which?
認証は、大規模なISPが内部で使用されるBGPスピーキングルータの数を考えると、共有鍵メカニズムが不十分である可能性が高いです。そのため、証明書ベースのIKEをサポートしなければなりません。しかし、共有シークレットモードは、リンクをピアリングか（多分）のISPと顧客の間のリンク上で合理的です。どのような手法が使用されている他のBGPポリシーは、これらの用語で表現されているので、それは、戻っていくつかの方法で送信元IPアドレスまたは自律システム（AS）番号に結びつける必要があります。証明書が使用されている場合は、IPアドレスを使用するか、AS番号のでしょうか？どちら？
Availability For this scenario, availability is the crucial question. Do likely BGP speakers -- both backbone routers and access routers -- support the profile of IPsec described above? Will use of IPsec, with its attendant expensive cryptographic operations, raise the issue of new denial-of-service attacks? The working group and the IESG must make these determinations before deciding to use IPsec to protect BGP.
このシナリオの入手可能性は、可用性は重要な問題です。おそらくBGPスピーカでください - バックボーンルータとアクセスルータの両方が - のIPsecのプロファイルは、上記サポートしていますか？新サービス拒否攻撃の問題を提起、それに付随高価な暗号化操作で、IPsecの使用のでしょうか？ワーキンググループとIESGは、BGPを保護するためにIPsecを使用することを決定する前に、これらの決定をしなければなりません。
IPsec provides transmission security and simple access control only. There are many other dimensions to protocol security that are beyond the scope of this memo, including most notably availability. For example, using IPsec does little to defend against denial-of-service attacks; in some situations, i.e., on CPU-limited systems, it may contribute to the attacks. Within its scope, the security of any resulting protocol depends heavily on the accuracy of the analysis that resulted in a decision to use IPsec.
IPsecは送信のみのセキュリティとシンプルなアクセス制御を提供します。最も顕著なの可用性を含め、このメモの範囲を超えているプロトコルのセキュリティには多くの他の寸法は、あります。例えば、使用してIPsecはサービス拒否（DoS）攻撃を防御するために少しありません。いくつかの状況では、すなわち、CPUが制限されたシステムでは、それが攻撃に寄与することができます。その範囲内で、任意の結果のプロトコルのセキュリティは、IPsecを使用するという決定の結果分析の精度に大きく依存しています。
Ran Atkinson, Lakshminath Dondeti, Barbara Fraser, Paul Hoffman, Russ Housley, Stephen Kent, Eric Fleischman, assorted members of the IESG, and a plethora of others have made many useful suggestions.
アトキンソン、Lakshminath Dondeti、バーバラ・フレイザー、ポール・ホフマン、ラスHousley、スティーブン・ケント、エリックFleischman、IESGの各種メンバーを走り、他の過多は、多くの有用な提案を行いました。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
"IPsecでストリーム制御伝送プロトコル（SCTP）の使用に" [RFC3554] Bellovin氏、S.、Ioannidis、J.、Keromytis、A.、およびR.スチュワート、RFC 3554、2003年7月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin氏、S.とR. Housley氏、 "暗号鍵管理のためのガイドライン"、BCP 107、RFC 4107、2005年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5374]ヴァイス、B.、グロス、G.、およびD. Ignjatic、 "インターネットプロトコルのためのセキュリティー体系へのマルチキャスト拡張機能"、RFC 5374、2008年11月。
[Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proc. Sixth Usenix Security Symposium, pp. 205-214, 1996.
[Bell96] Bellovin氏、S.、 "IPセキュリティプロトコルの問題エリア"、PROC。第六のUsenixセキュリティシンポジウム、PP。205-214、1996。
[Kent00a] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications, 18:4, pp. 582-592, 2000.
【Kent00a]ケント、S.、リン、C.、およびK.ソ、コミュニケーションズ、18で選択された領域に、IEEEジャーナル "ボーダーゲートウェイプロトコル（セキュアBGP）を確保"：4、頁582から592まで、2000年。
[Kent00b] Kent, S., Lynn, C., Mikkelson, J., and K. Seo, "Secure Border Gateway Protocol (Secure-BGP) -- Real World Performance and Deployment Issues", Proc. Network and Distributed System Security Symposium (NDSS), 2000.
[Kent00b]ケント、S.、リン、C.、Mikkelson、J.、およびK.ソは、 "セキュアボーダーゲートウェイプロトコル（セキュア-BGP） - 実世界のパフォーマンスと展開に関する問題"、PROC。ネットワークと分散システムセキュリティシンポジウム（NDSS）、2000。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006.
[RFC4430]坂根、S.、鎌田、K.、トーマス、M.、およびJ. Vilhuber、 "キーのケルベロスインターネットネゴシエーション（KINK）"、RFC 4430、2006年3月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]はハーニー、H.、メタ、U.、Colegrove、A.、およびG.グロスは、：RFC 4535、2006年6月、 "GSAKMPグループは、協会の鍵管理プロトコルをセキュア"。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
Author's Address
著者のアドレス
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
スティーブンM. Bellovin氏コロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、NY 10027米国
Phone: +1 212 939 7149 EMail: bellovin@acm.org
電話：+1 212 939 7149 Eメール：bellovin@acm.org