[要約] RFC 5406は、IPsecバージョン2の使用方法を指定するためのガイドラインです。その目的は、IPsecの実装と展開に関する一貫性と互換性を確保することです。
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
IPSECバージョン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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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に代わる優れた代替手段となります。最後に、ESPを使用して機密性のみを提供するために使用できますが、これは推奨されません[Bell96]。
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はかなり面倒です。2つのエンドポイントがNATボックスによって分離される可能性がかなりある環境では、サーバーからサーバーへのトラフィックとは対照的に、ユーザーからサーバーへのトラフィックを含むほとんどすべてのサービスを含みます - NATトラバーサル[RFC3948]義務付けられ、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で保護されたパスのいずれかの端が究極のIP宛先ではない場合、たとえばIPSECがファイアウォール、ルーターなどに実装されている場合はいつでも必要です。
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については説明していません。2番目のメカニズム、Kerberized Internet Negatiation of Keys（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 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.
IKEを使用して、既存の公開キーインフラストラクチャ（PKI）から証明書[RFC5280]を使用することができる場合があります。実際には、これはまれです。さらに、ほとんどのインターネットエンドポイントをカバーするグローバルなPKIがないだけでなく、おそらく存在することはありません。そのようなPKIを想定する構造を設計することは間違いです。特に、任意のノードには、相互に信頼された第三者によって発行され、そのノードのIDを保証する「本物の」証明書があると仮定することは間違っています。繰り返しますが、そのようなPKIは存在せず、おそらく存在しません。一般に公開鍵は良い考えですが、既存の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の共有秘密バージョンと比較して、実行する必要がある大規模な指数の数をほぼ2倍にします。
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.
低レベルのプロトコルを保護しようとする場合、自動化された主要な管理メカニズムを使用することは困難です。たとえば、[RFC2461]がIPv6ネイバーディスカバリーを保護するためにIPSECの使用を指定したとしても、重要な管理を行うことは不可能でした。ノードはIPレベルの通信を必要とするため、IKEを使用できませんでした。協会が設定されています。
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キー管理メカニズムはピアの身元と承認を認識している可能性がありますが、この情報はアプリケーションで使用することも、このIDによって特定されたエンティティに予約されたリソースへのアクセスなど、アプリケーションレベルの決定にリンクすることもできません。。
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.
ルーターまたはファイアウォールベースの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の複数の層をサポートする実装はほとんどありません。TelecommuterがVPNモードでIPSECを使用して組織ネットワークにアクセスしている場合、組織内のホストへのアプリケーション接続を保護するために第2レベルの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の元の設計目標の1つであることに注意してください。それにもかかわらず、それをサポートしているプラットフォームはわずかです。実際、一部の実装は、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の場合は6、UDPで17）、およびTCPおよびUDPのポート番号が含まれます。保護要件をそのような用語で説明できないプロトコルは、IPSECの候補者が貧弱です。特に、「宛先ホスト」よりも細かい穀物で保護を適用することは不可能になります。したがって、IPSECにはL2TPパケットを覗き込んでTCPポート番号を見つけるためにL2TPパケットを覗き込むことができるため、レイヤー2トンネルプロトコル（L2TP）[RFC2661]セッションに埋め込まれたトラフィックは、L2TPレイヤーの上のIPSECによって選択的に保護できません。同様に、[RFC2401]が書かれたときに、ストリーム制御伝送プロトコル（SCTP）[RFC4960]は存在しませんでした。したがって、ポート番号に基づいて個々のSCTPアプリケーションを保護することは、IPSECの新しいセレクターを定義し、実装が登場する新しいドキュメント[RFC3554]が記述されるまで実行できませんでした。
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によって保護されている場合、実装により、他のトラフィックが異なるポリシーによって保護されていないか、保護されていますか？あるいは、実装がすべてのトラフィックを保護できるかどうかのみであるようなものである場合、デバイスはすべてを暗号化するのに十分な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?
e. アプリケーションサーバーがユーザー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.)
g. 参加者はどのように要求する操作を実行することを許可されていますか？たとえば、特定のソースからの証明書を持つすべてのデバイスは、IPSECを使用してアプリケーションを使用するか、リソースにアクセスすることを許可されていますか？（もちろん、この問題はどのセキュリティサービスにも表示されます。）
h. Which of the many variants of IKE must be supported? Main mode? Aggressive mode?
h. 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.
IKEにはIKEとIKEV2の2つの異なるバージョンがあることに注意してください。IKEV2はよりシンプルでクリーンですが、まだ広く利用できません。必要なIKEのバージョンを指定する必要があります。
i. Is suitable IPsec support available in likely configurations of the products that would have to employ IPsec?
i. 適切な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.
これらのガイドラインに基づいて例を挙げてみましょう。境界ゲートウェイプロトコル（BGP）[RFC4271]を使用して、[RFC2385]に記載されているメカニズムではなく、送信セキュリティのためのIPSECの使用を評価および指定する方法を示します。ここでは、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は、TCPポート179で手動で構成されたホストのペア間で実行されます。適切なセレクターは、そのポートのみのBGPスピーカーのペアです。ルーターの「ループバックアドレス」は、ほぼ間違いなく使用するアドレスであることに注意してください。
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.
リプレイの検出を許可するための主要な管理、自動化されたキー管理システムを使用する必要があります。繰り返しますが、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をサポートする必要があります。ただし、共有されたシークレットモードは、Peering Linksまたは（おそらく）ISPと顧客の間のリンクで合理的です。どんなスキームが使用されても、他のBGPポリシーがこれらの用語で表されるため、ソースIPアドレスまたは自律システム（AS）番号（AS）数（AS）数に関連する必要があります。証明書が使用されている場合、IPアドレスを使用しますか、それとも番号として使用しますか？どれの？
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を使用すると、サービス拒否攻撃から防御することはほとんどありません。状況によっては、つまり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.
ラン・アトキンソン、ラクシュミナート・ドンデティ、バーバラ・フレイザー、ポール・ホフマン、ラス・ハウズリー、スティーブン・ケント、エリック・フライシュマン、IESGのメンバーのメンバー、そして多くの人が多くの有用な提案をしました。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.
[RFC3554] Bellovin、S.、Ioannidis、J.、Keromytis、A。、およびR. Stewart、「IPSECを使用したストリーム制御伝送プロトコル（SCTP）の使用」、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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509 Parine Key Infrastructure証明書および証明書失効リスト（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] Weis、B.、Gross、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。Sixth Usenix Security Symposium、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] Kent、S.、Lynn、C。、およびK. Seo、「Secure Border Gateway Protocol（Secure-BGP）」、IEEE Journal CommunicationsのIEEEジャーナル、18：4、pp。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] Kent、S.、Lynn、C.、Mikkelson、J。、およびK. Seo、「Secure Border Gateway Protocol（Secure-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. Simpson、「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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" 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.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（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] Sakane、S.、Kamada、K.、Thomas、M。、およびJ. Vilhuber、「Kerberized Internet negotiation of Keys（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] Harney、H.、Meth、U.、Colegrove、A。、およびG. Gross、 "GSAKMP：Group Secure Association Key Management Protocol"、RFC 4535、2006年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
Author's Address
著者の連絡先
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US
スティーブンM.ベロビンコロンビア大学1214アムステルダムアベニューMC 0401ニューヨーク、ニューヨーク10027 US
Phone: +1 212 939 7149
EMail: bellovin@acm.org