RFC2207 日本語訳
2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. September 1997. (Format: TXT=30473 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Berger
Request for Comments: 2207 FORE Systems
Category: Standards Track T. O'Malley
BBN
September 1997
コメントを求めるワーキンググループL.バーガー要求をネットワークでつないでください: 2207年の前面のシステムカテゴリ: 標準化過程T.オマリーBBN1997年9月
RSVP Extensions for IPSEC Data Flows
IPSECデータフローのためのRSVP拡張子
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6.
このドキュメントはRSVPのバージョン1に拡大を提示します。 これらの拡大はRFC1826、IP Authentication Header(AH)またはRFC1827(IP Encapsulating Security有効搭載量(超能力))を使用する個々のデータフローのサポートを可能にします。 IPSECプロトコルをサポートしますが、現在指定されているとしてのRSVPバージョン1は1アドレスあたりのaだけでそうすることができます、流れ基礎あたりのaでないところのプロトコル基礎単位で。 IPv4とIPv6の両方と共に提示された拡張子を使用できます。
Berger & O'Malley Standards Track [Page 1] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[1ページ]。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 Overview of Extensions . . . . . . . . . . . . . . . . . . 3
3 Object Definition. . . . . . . . . . . . . . . . . . . . . 4
3.1 SESSION Class . . . . . . . . . . . . . . . . . . . . 5
3.2 FILTER_SPEC Class . . . . . . . . . . . . . . . . . . 5
3.3 SENDER_TEMPLATE Class . . . . . . . . . . . . . . . . 6
4 Processing Rules . . . . . . . . . . . . . . . . . . . . . 6
4.1 Required Changes. . . . . . . . . . . . . . . . . . . 6
4.2 Merging Flowspecs . . . . . . . . . . . . . . . . . . 7
4.2.1 FF and SE Styles. . . . . . . . . . . . . . . . . . 7
4.2.2 WF Styles . . . . . . . . . . . . . . . . . . . . . 8
5 IANA Considerations. . . . . . . . . . . . . . . . . . . . 8
6 Security Considerations. . . . . . . . . . . . . . . . . . 8
7 References . . . . . . . . . . . . . . . . . . . . . . . .10
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . .10
9 Authors' Addresses . . . . . . . . . . . . . . . . . . . .10
A Options Considered . . . . . . . . . . . . . . . . . . . .11
A.1 UDP Encapsulation . . . . . . . . . . . . . . . . . .11
A.2 FlowID Header Encapsulation . . . . . . . . . . . . .12
A.3 IPSEC Protocol Modification . . . . . . . . . . . . .12
A.4 AH Transparency . . . . . . . . . . . . . . . . . . .13
1 拡大. . . . . . . . . . . . . . . . . . 3 3オブジェクト定義の序論. . . . . . . . . . . . . . . . . . . . . . . 2 2概要。 . . . . . . . . . . . . . . . . . . . . 4 3.1 セッションのクラス. . . . . . . . . . . . . . . . . . . . 5 3.2フィルタ_仕様のクラス. . . . . . . . . . . . . . . . . . 5 3.3送付者_テンプレートのクラス. . . . . . . . . . . . . . . . 6 4処理は、.64.1が釣り銭がいたと裁決します。 . . . . . . . . . . . . . . . . . . 6 4.2 Flowspecs. . . . . . . . . . . . . . . . . . 7 4.2.1のffとSE様式を合併します。 . . . . . . . . . . . . . . . . . 7 4.2 .2 WFは.8 5のIANA問題を流行に合わせます。 . . . . . . . . . . . . . . . . . . . 8 6のセキュリティ問題。 . . . . . . . . . . . . . . . . . 8 7の参照箇所. . . . . . . . . . . . . . . . . . . . . . . .10 8の承認. . . . . . . . . . . . . . . . . . . . .10 9作者のアドレス… オプションが考えた.10… .11A.1 UDPカプセル化. . . . . . . . . . . . . . . . . .11A.2 FlowIDヘッダーカプセル化.12…………A.3 IPSECプロトコル変更.12…………A.4、ああ、透明.13………………
1 Introduction
1つの序論
Recently published Standards Track RFCs specify protocol mechanisms to provide IP level security. These IP Security, or IPSEC, protocols support packet level authentication, [RFC 1826], and integrity and confidentiality [RFC 1827]. A number of interoperable implementations already exist and several vendors have announced commercial products that will use these mechanisms.
最近発行されたStandards Track RFCsは、IPの平らなセキュリティを提供するためにプロトコルメカニズムを指定します。 これらのIP Security、またはIPSEC、プロトコルが、パケット・レベルが認証と、[RFC1826]と、保全と秘密性[RFC1827]であるとサポートします。 多くの共同利用できる実装が既に存在しています、そして、いくつかのベンダーがこれらのメカニズムを使用する商品を発表しました。
The IPSEC protocols provide service by adding a new header between a packet's IP header and the transport (e.g. UDP) protocol header. The two security headers are the Authentication Header (AH), for authentication, and the Encapsulating Security Payload (ESP), for integrity and confidentiality.
IPSECプロトコルは、新しいヘッダーを加えることによって、パケットのIPヘッダーと輸送(例えば、UDP)プロトコルヘッダーの間にサービスを供給します。 2個のセキュリティヘッダーがAuthentication Header(AH)です、認証、およびEncapsulating Security有効搭載量(超能力)のために、保全と秘密性のために。
RSVP is being developed as a resource reservation (dynamic QoS setup) protocol. RSVP as currently specified [RFC 2205] is tailored towards IP packets carrying protocols that have TCP or UDP-like ports. Protocols that do not have such UDP/TCP-like ports, such as the IPSEC protocols, can be supported, but only with limitations. Specifically, for flows of IPSEC data packets, flow definition can only be done on per IP address, per protocol basis.
RSVPは資源予約(ダイナミックなQoSセットアップ)プロトコルとして開発されています。 現在指定されているとしてのRSVP[RFC2205]はTCPを持っているプロトコルを運ぶIPパケットかUDPのようなポートに向かって仕立てられます。 そのようなUDP/TCPのようなポートを持っていないプロトコルは、IPSECプロトコルなどのようにサポートすることができますが、単に制限でサポートすることができます。 明確に、IPSECデータ・パケットの流れにおいて、フロー定義のときにプロトコル基礎あたりのIPアドレス単位ですることができるだけです。
Berger & O'Malley Standards Track [Page 2] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[2ページ]。
This memo proposes extensions to RSVP so that data flows containing IPSEC protocols can be controlled at a granularity similar to what is already specified for UDP and TCP. The proposed extensions can be used with both IPv4 and IPv6. Section 2 of this memo will provide an overview of extensions. Section 3 contains a description of extended protocol mechanisms. Section 4 presents extended protocol processing rules. Section 5 defines the additional RSVP data objects.
このメモは、既にUDPとTCPに指定されることと同様の粒状でIPSECプロトコルを含むデータフローは制御できるようにRSVPに拡大を提案します。 IPv4とIPv6の両方と共に提案された拡張子を使用できます。 このメモのセクション2は拡大の概要を提供するでしょう。 セクション3は拡張プロトコルメカニズムの記述を含みます。セクション4は拡張プロトコル処理規則を提示します。 セクション5は追加RSVPデータ・オブジェクトを定義します。
2 Overview of Extensions
拡大の2概要
The basic notion is to extend RSVP to use the IPSEC Security Parameter Index, or SPI, in place of the UDP/TCP-like ports. This will require a new FILTER_SPEC object, which will contain the IPSEC SPI, and a new SESSION object.
基本的な概念はIPSEC Security Parameter Index、またはSPIを使用するためにUDP/TCPのようなポートに代わってRSVPを広げることです。 これは新しいFILTER_SPECオブジェクトと新しいSESSIONオブジェクトを必要とするでしょう。(それは、IPSEC SPIを含むでしょう)。
While SPIs are allocated based on destination address, they will typically be associated with a particular sender. As a result, two senders to the same unicast destination will usually have different SPIs. In order to support the control of multiple independent flows between source and destination IP addresses, the SPI will be included as part of the FILTER_SPEC. When using WF, however, all flows to the same IP destination address using the same IP protocol ID will share the same reservation. (This limitation exists because the IPSEC transport headers do not contain a destination demultiplexing value like the UDP/TCP destination port.)
送付先アドレスに基づいてSPIsを割り当てる間、彼らは特定の送付者に通常関連するでしょう。 その結果、通常、同じユニキャストの目的地への2人の送付者が異なったSPIsを持つでしょう。 ソースと送付先IPアドレスの間の複数の独立している流れのコントロールをサポートするために、SPIはFILTER_SPECの一部として含まれるでしょう。 しかしながら、WFを使用するとき、同じIPプロトコルIDを使用する同じ受信者IPアドレスへのすべての流れが同じ予約を共有するでしょう。 (IPSEC輸送ヘッダーがUDP/TCP仕向港のような目的地逆多重化価値を含んでいないので、この制限は存在しています。)
Although the RESV message format will not change, RESV processing will require modification. Processing of the new IPSEC FILTER_SPEC will depend on the use of the new SESSION object and on the protocol ID contained in the session definition. When the new FILTER_SPEC object is used, the complete four bytes of the SPI will need to be extracted from the FILTER_SPEC for use by the packet classifier. The location of the SPI in the transport header of the IPSEC packets is dependent on the protocol ID field.
RESVメッセージ・フォーマットは変化しないでしょうが、RESV処理は変更を必要とするでしょう。 新しいIPSEC FILTER_SPECの処理は新しいSESSIONオブジェクトの使用と、そして、IDがセッション定義に含んだプロトコルによるでしょう。 新しいFILTER_SPECオブジェクトが使用されているとき、SPIの完全な4バイトは、使用のためにパケットクラシファイアによってFILTER_SPECから抽出される必要があるでしょう。 IPSECパケットの輸送ヘッダーのSPIの位置はプロトコルIDフィールドに依存しています。
The extension will also require a change to PATH processing, specifically in the usage of the port field in a session definition. An RSVP session is defined by the triple: (DestAddress, protocol ID, DstPort). [RFC 2205] includes the definition of one type of SESSION object, it contains UDP/TCP destination ports, specifically "a 16-bit quantity carried at the octet offset +2 in the transport header" or zero for protocols that lack such a field. The IPSEC protocols do
また、拡張子はPATH処理への変化を必要とするでしょう、特にセッション定義におけるポート分野の用法で。 RSVPセッションは三重によって定義されます: (DestAddress、プロトコルID、DstPort。) [RFC2205]は1つのタイプのSESSIONオブジェクトの定義を含んでいて、それはそのような分野を欠いているプロトコルのためのUDP/TCP仕向港、明確に「輸送ヘッダーで+2に相殺された八重奏のときに運ばれた16ビットの量」またはゼロを含んでいます。 プロトコルがするIPSEC
Berger & O'Malley Standards Track [Page 3] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[3ページ]。
not contain such a field, but there remains a requirement for demultiplexing sessions beyond the IP destination address. In order to satisfy this requirement, a virtual destination port, or vDstPort, is introduced. The vDstPort value will be carried in the new SESSION object but not in the IPSEC transport header. The vDstPort allows for the differentiation of multiple IPSEC sessions destined to the same IP address. See Section 5 for a discussion of vDstPort ranges.
そのような分野を含んでいませんが、受信者IPアドレスを超えて逆多重化セッションのための要件は残っています。 この要件を満たすために、仮想の仕向港、またはvDstPortを導入します。 vDstPort値は、新しいSESSIONオブジェクトで運ばれますが、IPSEC輸送ヘッダーで運ばれるというわけではないでしょう。 vDstPortは同じIPアドレスに運命づけられた複数のIPSECセッションの分化を考慮します。 vDstPortの議論のためのセクション5が及ぶのを確実にしてください。
In PATH messages, the SENDER_TEMPLATE for IPSEC flows will have the same format as the modified FILTER_SPEC. But, a new SESSION object will be used to unambiguously distinguish the use of a virtual destination port.
PATHメッセージでは、IPSECが流れるので、SENDER_TEMPLATEは変更されたFILTER_SPECと同じ形式を持つでしょう。 しかし、新しいSESSIONオブジェクトは、明白に仮想の仕向港の使用を区別するのに使用されるでしょう。
Traffic will be mapped (classified) to reservations based on SPIs in FILTER_SPECs. This, of course, means that when WF is used all flows to the same IP destination address and with the same IP protocol ID will share the same reservation.
トラフィックはFILTER_SPECsでSPIsに基づく予約に写像されるでしょう(分類されます)。 これ、もちろん、WFが使用されているとき同じ受信者IPアドレスと同じIPプロトコルIDですべて流れる手段は同じ予約を共有するでしょう。
The advantages to the described approach are that no changes to RFC1826 and 1827 are required and that there is no additional per data packet overhead. Appendix A contains a discussion of the advantages of this approach compared to several other alternatives. This approach does not take advantage of the IPv6 Flow Label field, so greater efficiency may be possible for IPv6 flows. The details of IPv6 Flow Label usage is left for the future.
説明されたアプローチの利点はRFC1826と1827への変化は全く必要でなく、データ・パケットオーバーヘッド単位で追加しているノーがあるということです。 他のいくつかの選択肢と比べて、付録Aはこのアプローチの利点の議論を含んでいます。 このアプローチがIPv6 Flow Label分野を利用しないので、IPv6流れに、より大きい効率は可能であるかもしれません。 IPv6 Flow Label用法の詳細は未来に残されます。
3 Object Definition
3 オブジェクト定義
The FILTER_SPEC and SENDER_TEMPLATE used with IPSEC protocols will contain a four byte field that will be used to carry the SPI. Rather than label the modified field with an IPSEC specific label, SPI, the label "Generalized Port Identifier", or GPI, will be so that these object may be reused for non-IPSEC uses in the future. The name for these objects are the IPv4/GPI FILTER_SPEC, IPv6/GPI FILTER_SPEC, IPv4/GPI SENDER_TEMPLATE, and IPv6/GPI SENDER_TEMPLATE. Similarly, the new SESSION objects will be the IPv4/GPI SESSION and the IPv6/GPI SESSION. When referring to the new objects, IP version will not be included unless a specific distinction between IPv4 and IPv6 is being made.
IPSECプロトコルと共に使用されるFILTER_SPECとSENDER_TEMPLATEはSPIを運ぶのに使用される4バイトの分野を含むでしょう。 むしろ、SPI(ラベルの「一般化されたポート識別子」、またはGPI)はIPSECの特定のラベルで変更された分野をラベルするよりあるので、これらが反対するのは将来、非IPSEC用途のために再利用されるかもしれません。 これらのオブジェクトのための名前は、IPv4/GPI FILTER_SPECと、IPv6/GPI FILTER_SPECと、IPv4/GPI SENDER_TEMPLATEと、IPv6/GPI SENDER_TEMPLATEです。 同様に、新しいSESSIONオブジェクトは、IPv4/GPI SESSIONとIPv6/GPI SESSIONになるでしょう。 新しいオブジェクトについて言及して、IPv4とIPv6の特定の区別をしていないと、IPバージョンを含まないでしょう。
Berger & O'Malley Standards Track [Page 4] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[4ページ]。
3.1 SESSION Class
3.1 セッションのクラス
SESSION Class = 1.
セッションのクラス=1。
o IPv4/GPI SESSION object: Class = 1, C-Type = 3
o IPv4/GPI SESSIONは反対します: クラスは1、C-タイプ=3と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 DestAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Protocol ID | Flags | vDstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 DestAddress(4バイト)| +-------------+-------------+-------------+-------------+ | プロトコルID| 旗| vDstPort| +-------------+-------------+-------------+-------------+
o IPv6/GPI SESSION object: Class = 1, C-Type = 4
o IPv6/GPI SESSIONは反対します: クラスは1、C-タイプ=4と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 DestAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Protocol ID | Flags | vDstPort |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | プロトコルID| 旗| vDstPort| +-------------+-------------+-------------+-------------+
3.2 FILTER_SPEC Class
3.2 フィルタ_仕様のクラス
FILTER_SPEC class = 10.
FILTER_SPECのクラス=10。
o IPv4/GPI FILTER_SPEC object: Class = 10, C-Type = 4
o IPv4/GPI FILTER_SPECは反対します: クラスは10、C-タイプ=4と等しいです。
+-------------+-------------+-------------+-------------+
| IPv4 SrcAddress (4 bytes) |
+-------------+-------------+-------------+-------------+
| Generalized Port Identifier (GPI) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | IPv4 SrcAddress(4バイト)| +-------------+-------------+-------------+-------------+ | 一般化されたポート識別子(GPI)| +-------------+-------------+-------------+-------------+
Berger & O'Malley Standards Track [Page 5] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[5ページ]。
o IPv6/GPI FILTER_SPEC object: Class = 10, C-Type = 5
o IPv6/GPI FILTER_SPECは反対します: クラスは10、C-タイプ=5と等しいです。
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ IPv6 SrcAddress (16 bytes) +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| Generalized Port Identifier (GPI) |
+-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress(16バイト)+| | + + | | +-------------+-------------+-------------+-------------+ | 一般化されたポート識別子(GPI)| +-------------+-------------+-------------+-------------+
3.3 SENDER_TEMPLATE Class
3.3 送付者_テンプレートのクラス
SENDER_TEMPLATE class = 11.
SENDER_TEMPLATEのクラス=11。
o IPv4/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 4
o IPv4/GPI SENDER_TEMPLATEは反対します: クラスは11、C-タイプ=4と等しいです。
Definition same as IPv4/GPI FILTER_SPEC object.
IPv4/GPI FILTER_SPECが反対するのと同じ定義。
o IPv6/GPI SENDER_TEMPLATE object: Class = 11, C-Type = 5
o IPv6/GPI SENDER_TEMPLATEは反対します: クラスは11、C-タイプ=5と等しいです。
Definition same as IPv6/GPI FILTER_SPEC object.
IPv6/GPI FILTER_SPECが反対するのと同じ定義。
4 Processing Rules
4 処理規則
This section presents additions to the Processing Rules presented in [RFC 2209]. These additions are required in order to properly process the GPI SESSION and FILTER_SPEC objects. Values for referenced error codes can be found in [RFC 2205]. As in with the other RSVP documents, values for internally reported (API) errors are not defined.
このセクションは[RFC2209]で寄贈されたProcessing Rulesに追加を提示します。 これらの追加が、適切にGPI SESSIONとFILTER_SPECオブジェクトを処理するのに必要です。 [RFC2205]で参照をつけられたエラーコードのための値を見つけることができます。 他のRSVPドキュメントとのコネには、内部的に報告された(API)誤りのための値は定義されません。
4.1 Required Changes
4.1 必要な変化
Both RESV and PATH processing will need to be changed to support the new objects. The changes ensure consistency and extend port processing.
RESVとPATH処理の両方が、新しいオブジェクトを支えるために変えられる必要があるでしょう。 変化は、一貫性があることを保証して、ポート処理を広げています。
The following PATH message processing changes are required:
以下のPATHメッセージ処理変化が必要です:
o When a session is defined using the GPI SESSION object, only
the GPI SENDER_TEMPLATE may be used. When this condition is
violated, end-stations should report a "Conflicting C-Type" API
error to the application.
o セッションがGPI SESSIONオブジェクトを使用することで定義されるとき、GPI SENDER_TEMPLATEだけを使用してもよいです。 この状態が違反されるとき、端ステーションは「闘争して、Cでタイプしてください」というAPI誤りをアプリケーションに報告するべきです。
Berger & O'Malley Standards Track [Page 6] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[6ページ]。
o For PATH messages that contain the GPI SESSION object,
end-stations must verify that the protocol ID corresponds to a
protocol known to use the GPI SESSION object. Values 51 (AH)
or 50 (ESP) must be supported by implementations supporting
the described IPSEC extensions. If an unknown protocol ID is
used, then the API should report an "API Error" to the
application.
o GPI SESSIONオブジェクトを含むPATHメッセージに関しては、端ステーションは、プロトコルIDがGPI SESSIONオブジェクトを使用するのが知られているプロトコルに対応することを確かめなければなりません。 説明されたIPSEC拡張子をサポートする実装で値51(AH)か50(超能力)をサポートしなければなりません。 未知のプロトコルIDが使用されているなら、APIは「API誤り」をアプリケーションに報告するはずです。
o For such messages, the vDstPort value should be recorded.
The vDstPort value forms part of the recorded state and is used
to match Resv messages, but it is not passed to traffic control.
Non-zero values of vDstPort are required. This requirement
ensures that a non-GPI SESSION object will never merge with a
GPI SESSION object. Violation of this condition causes an
"Invalid Destination Port" API error.
o そのようなメッセージに関しては、vDstPort値は記録されるべきです。 vDstPort値は、記録された状態の一部を形成して、Resvメッセージを合わせるのに使用されますが、それはトラフィックコントロールに通過されません。 vDstPortの非ゼロ値が必要です。 この要件は、非GPI SESSIONオブジェクトがGPI SESSIONオブジェクトと決して合併しないのを確実にします。 この状態の違反は「無効の仕向港」API誤りを引き起こします。
The changes to RESV message processing are:
RESVメッセージ処理への変化は以下の通りです。
o When a RESV message contains a GPI FILTER_SPEC, the session
must be defined using the GPI SESSION object. Otherwise, this is
a message formatting error.
o RESVメッセージがGPI FILTER_SPECを含むとき、GPI SESSIONオブジェクトを使用することでセッションを定義しなければなりません。 さもなければ、これはメッセージ形式誤りです。
o The GPI contained in the FILTER_SPEC must match the GPI
contained in the SENDER_TEMPLATE. Otherwise, a "No sender
information for this Resv message" error is generated.
o FILTER_SPECに含まれたGPIはSENDER_TEMPLATEに含まれたGPIに合わなければなりません。 さもなければ、「このResvメッセージのための送付者情報がありません」誤りは発生しています。
o When the GPI FILTER_SPEC is used, each node must create
a data classifier for the flow described by the quadruple:
(DestAddress, protocol ID, SrcAddress, GPI). The data classifier
will need to look for the four byte GPI at transport header
offset +4 for AH, and at transport header offset +0 for ESP.
o GPI FILTER_SPECが使用されているとき、各ノードは4倍によって説明された流れのためにデータ分類装置を創造しなければなりません: (DestAddress、プロトコルID、SrcAddress、GPI。) データ分類装置は、AHのための輸送ヘッダーオフセット+4において超能力のための輸送ヘッダーオフセット+0において4バイトのGPIを探す必要があるでしょう。
4.2 Merging Flowspecs
4.2 Flowspecsを合併すること。
When using this extension for IPSEC data flows, RSVP sessions are defined by the triple: (DestAddress, protocol Id, vDstPort). Similarly, a sender is defined by the tuple: (SrcAddress, GPI), where the GPI field will be a four byte representation of a generalized source port. These extensions have some ramifications depending upon the reservation style.
IPSECデータフローにこの拡張子を使用するとき、RSVPセッションは三重によって定義されます: (DestAddress、プロトコルId、vDstPort。) 同様に、送付者はtupleによって定義されます: (SrcAddress、GPI), GPI分野が一般化されたソースポートの4バイトの表現になるところ。 これらの拡大には、予約スタイルに依存するいくつかの分岐があります。
4.2.1 FF and SE Styles
4.2.1 ffとSE様式
In the FF and SE Styles, the FILTER_SPEC object contains the (SrcAddress, GPI) pair. This allows the receiver to uniquely identify senders based on both elements of the pair. When merging explicit sender descriptors, the senders may only be considered identical when both elements are identical.
FFとSE様式では、FILTER_SPECオブジェクトは(SrcAddress、GPI)組を含んでいます。 これで、受信機は唯一組の両方の要素に基づく送付者を特定できます。 明白な送付者記述子を合併するとき、両方の要素が同じであるときにだけ、送付者は同じであると考えられるかもしれません。
Berger & O'Malley Standards Track [Page 7] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[7ページ]。
4.2.2 WF Styles
4.2.2 WF様式
These extensions provide very limited service when used with WF style reservations. As described, the SENDER_TEMPLATE and FILTER_SPEC each contain the GPI. In a WF style reservation, the RESV message does NOT contain a FILTER_SPEC (after all, it is a wildcard filter), and the SENDER_TEMPLATE is ignored (again, because any sender is allowed). As a result, classifiers may match all packets which contain both the session's destination IP address and protocol ID to such WF reservations.
WFスタイルの予約と共に使用されると、これらの拡大は非常に限られたサービスを提供します。 説明されるように、SENDER_TEMPLATEとFILTER_SPECはそれぞれGPIを含んでいます。 WFスタイルの予約で、RESVメッセージはFILTER_SPECを含んでいません、そして、(結局、それはワイルドカードフィルタです)SENDER_TEMPLATEは無視されます(どんな送付者も再び許容されているので)。 その結果、クラシファイアはセッションの送付先IPアドレスとプロトコルIDの両方をそのようなWFの予約に含むすべてのパケットに合うかもしれません。
Although a solution for this limitation is not proposed, this issue is not seen as significant since IPSEC applications are less likely to use WF style reservations.
この制限のためのソリューションは提案されませんが、IPSECアプリケーションがWFスタイルの予約をより使用しそうにないので、この問題は重要であるとみなされません。
5 IANA Considerations
5 IANA問題
The range of possible vDstPort values is broken down into sections, in a fashion similar to the UDP/TCP port ranges.
可能なvDstPort値の範囲はUDP/TCPポート範囲と同様のファッションでセクションへ砕けています。
0 Illegal Value
1 - 10 Reserved. Contact authors.
11 - 8191 Assigned by IANA
8192 - 65535 Dynamic
0 1--10が予約した不法な値。 作者に連絡してください。 11--8191はIANAで8192--65535動力を割り当てました。
IANA is directed to assign the well-known vDstPorts using the following criteria: Anyone who asks for an assigned vDstPort must provide a) a Point of Contact, b) a brief description of intended use, and c) a short name to be associated with the assignment (e.g. "ftp").
IANAが以下の評価基準を使用することでよく知られるvDstPortsを割り当てるよう指示されます: 割り当てられたvDstPortを求めるだれでも、課題(例えば、"ftp")に関連しているようにa) Contact、b)のPointに意図している使用の簡単な説明を提供して、c)に省略名を提供しなければなりません。
6 Security Considerations
6 セキュリティ問題
The same considerations stated in [RFC 2205], [RFC 1826], and [RFC 1827] apply to the extensions described in this note. There are two additional issue related to these extensions.
[RFC2205]、[RFC1826]、および[RFC1827]に述べられた同じ問題はこの注意で説明された拡大に適用されます。 追加設定がこれらの拡大に関係づけた2があります。
First, the vDstPort mechanism represents another data element about the IP Flow that might be available to an adversary. Such data might be useful to an adversary engaging in traffic analysis by monitoring not only the data packets of the IP Flow but also the RSVP control messages associated with that Flow. Protection against traffic analysis attacks is outside the scope of this mechanism. One possible approach to precluding such attacks would be deployment and use of appropriate link-layer confidentiality mechansisms, such as encryption.
まず最初に、vDstPortメカニズムは敵にとって、利用可能であるかもしれないIP Flowに関する別のデータ要素を表します。 そのようなデータはIP Flowのデータ・パケットだけではなく、そのFlowに関連しているRSVPコントロールメッセージもモニターすることによってトラヒック分析に従事している敵の役に立つかもしれません。 このメカニズムの範囲の外にトラヒック分析攻撃に対する保護があります。 そのような攻撃を排除することへの1つの可能なアプローチは、暗号化などの適切なリンクレイヤ秘密性mechansismsの展開と使用でしょう。
Berger & O'Malley Standards Track [Page 8] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[8ページ]。
Secondly, Changes in SPI values for a given flow will affect RSVP flows and reservations. Changes will happen whenever that flow changes its Security Association. Such changes will occur when a flow is rekeyed (i.e. to use a new key). Rekeying intervals are typically set based on traffic levels, key size, threat environment, and crypto algorithm in use. When an SPI change occurs it will, in most cases, be necessary to update (send) the corresponding SENDER_TEMPLATEs and FILTER_SPECs. IPSEC implementations, RSVP applications, and RSVP end-station implementations will need to take the possibility of changes of SPI into account to ensure proper reservation behavior. This issue is likely to be a tolerable, since rekeying intervals are under the control of local administrators.
第二に、与えられた流れのためのSPI値におけるChangesはRSVP流れと予約に影響するでしょう。 その流れがSecurity Associationを変えるときはいつも、変化は起こるでしょう。 流れが「再-合わせ」られると(すなわち、新しいキーを使用する)、そのような変化は起こるでしょう。 間隔をRekeyingするのはトラフィックレベル、主要なサイズ、脅威環境、および暗号アルゴリズムに基づいて使用中に通常設定されています。 SPI変化が起こると、それは多くの場合、対応するSENDER_TEMPLATEsとFILTER_SPECsをアップデートすること(発信する)に必要であるために望んでいます。 IPSEC実装、RSVPアプリケーション、およびRSVP端ステーション実装は、適切な予約の振舞いを確実にするためにSPIの変化の可能性を考慮に入れる必要があるでしょう。 この問題は許容できて、以来「再-合わせ」ている間隔が地元の管理者のコントロールの下にあるということである傾向があります。
Many, if not most, RSVP sessions will not need to deal with this rekeying issue. For those applications that do need to deal with changes of SPIs during a session, the impact of sending new PATH and RESV messages will vary based on the reservation style being used. Builders of such applications may want to select reservation style based on interaction with SPI changes.
多く、または大部分、RSVPセッションがこの「再-合わせ」る問題に対処する必要はないでしょう。 セッションの間、SPIsの変化に対処する必要があるそれらのアプリケーションのために、新しいPATHとRESVにメッセージを送る影響は使用される予約スタイルに基づいて異なるでしょう。 そのようなアプリケーションのビルダーはSPI変化との相互作用に基づく予約スタイルを選択したがっているかもしれません。
The least impact of an SPI change will be to WF style reservations. For such reservations, a new SENDER_TEMPLATE will need to be sent, but no new RESV is required. For SE style reservations, both a new SENDER_TEMPLATE and a new RESV will need to be sent. This will result in changes to state, but should not affect data packet delivery or actual resource allocation in any way. The FF style will be impacted the most. Like with SE, both PATH and RESV messages will need to be sent. But, since FF style reservations result in sender receiving its own resource allocation, resources will be allocated twice for a period of time. Or, even worse, there won't be enough resources to support the new flow without first freeing the old flow.
WFスタイルの予約にはSPI変化の最少の影響があるでしょう。 そのような予約のために、新しいSENDER_TEMPLATEは、送られる必要があるでしょうが、どんな新しいRESVも必要ではありません。 SEスタイルの予約のために、新しいSENDER_TEMPLATEと新しいRESVの両方が、送られる必要があるでしょう。 これは、述べる変化をもたらしますが、何らかの方法でデータパケット配信か実際の資源配分に影響するべきではありません。 FFスタイルに最も影響を与えるでしょう。 SE、PATHとメッセージが送られる必要があるRESVの両方で、好きです。 しかし、FFスタイルの予約がそれ自身の資源配分を受ける送付者をもたらすので、しばらく、二度リソースを割り当てるでしょう。 または、さらにひどく、最初に古い流れを解放しないで新しい流れをサポートすることができるくらいのリソースがないでしょう。
A way around this FF/SPI-change problem does exist. Applications that want FF style reservations can use multiple SE reservations. Each real sender would have a separate SESSION (vDstPort) definition. When it came time to switch SPIs, a shared reservation could be made for the new SPI while the old SPI was still active. Once the new SPI was in use, the old reservation could be torn down. This is less than optimal, but will provide uninterrupted service for a set of applications.
このFF/SPI-変化問題の周りの道は存在しています。 FFスタイルの予約を必要とするアプリケーションは複数のSEの予約を使用できます。 それぞれの本当の送付者には、別々のSESSION(vDstPort)定義があるでしょう。 来たとき、古いSPIがまだアクティブであった間、新しいSPIのためにSPIs、共有された予約を切り換える時間を作ることができました。 新しいSPIがいったん使用中になると、古い予約を取りこわすことができます。 これは、あまり最適ではありませんが、1セットのアプリケーションのためのとぎれないサービスを提供するでしょう。
Berger & O'Malley Standards Track [Page 9] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[9ページ]。
7 References
7つの参照箇所
[RFC 2205] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、R.(エド)、チャン、L.、Estrin、D.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC 2209] Braden, R., Ed., Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2209] ブレーデン、R.、エド、チャン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1は処理規則を通信する」RFC2209、9月1997日
[RFC 1825] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, NRL, August 1995.
[RFC1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、NRL、1995年8月。
[RFC 1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[RFC1826] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、NRL、1995年8月。
[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
1827, NRL, August 1995.
[RFC1827] アトキンソン、R.、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC1827、NRL、1995年8月。
8 Acknowledgments
8つの承認
This note includes ideas originated and reviewed by a number of individuals who did not participate in this note's writing. The authors would like to acknowledge their contribution. We thank Ran Atkinson <rja@cisco.com>, Fred Baker <fred@cisco.com>, Greg Troxel <gdt@bbn.com>, John Krawczyk <jkrawczyk@BayNetworks.com> for much appreciated input and feedback. Special appreciation goes to Bob Braden <braden@isi.edu> for his detailed editorial and technical comments. We also thank Buz Owen, Claudio Topolcic, Andy Veitch, and Luis Sanchez for their help in coming up with the proposed approach. If any brain-damage exists in this note, it originated solely from the authors.
この注意はこの注意が書くことに参加しなかった多くの個人によって溯源されて、見直された考えを含んでいます。 作者は彼らの貢献を承諾したがっています。 私たちがRan Atkinson <rja@cisco.com に感謝する、gt;、フレッド Baker <fred@cisco.com 、gt;、グレッグ Troxel <gdt@bbn.com 、gt;、ジョン Krawczyk <jkrawczyk@BayNetworks.com 、gt;、多くの感謝している入力とフィードバックのために。 特別な感謝がボブ Braden <braden@isi.edu に行く、gt;、彼の詳細な社説と技術的なコメントのために。 また、私たちは彼らの助けについて提案されたアプローチを思いつく際にBuzオーエン、クラウディオTopolcic、アンディ・ビーチ、およびルイス・サンチェスに感謝します。 何か脳傷害がこの注意に存在しているなら、それは唯一作者から発しました。
9 Authors' Addresses
9人の作者のアドレス
Lou Berger Tim O'Malley FORE Systems BBN Corporation 6905 Rockledge Drive 10 Moulton Street Suite 800 Cambridge, MA 02138 Bethesda, MD 20817
ルウバーガーティムオマリー前面のシステムBBN社6905のRockledgeドライブ10モールトン通りスイート800ケンブリッジ(MA)02138ベセスダ(MD)20817
Phone: 301-571-2534 Phone: 617-873-3076 EMail: lberger@fore.com EMail: timo@bbn.com
以下に電話をしてください。 301-571-2534 以下に電話をしてください。 617-873-3076 メールしてください: lberger@fore.com メール: timo@bbn.com
Berger & O'Malley Standards Track [Page 10] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[10ページ]。
A Options Considered
考えられたオプション
This sections reviews other approaches that were explored in developing the described extensions. They are included here to provide additional context into the general problem. All listed options were rejected by the working group.
このセクションは説明された拡大を発生する際に調査された他のアプローチを見直します。 それらは、追加文脈を一般的問題に提供するためにここに含まれています。 すべての記載されたオプションがワーキンググループによって拒絶されました。
Four other options were considered:
4つの別の選択肢が考えられました:
1. UDP Encapsulation
Add a UDP header between the IP and the IPSEC AH or ESP
headers.
1. UDP Encapsulation AddのIPの間のUDPヘッダーとIPSEC AHか超能力ヘッダー。
2. FlowID Header Encapsulation
Add a new type of header between the IP and the IPSEC AH or
ESP headers.
2. FlowID Header Encapsulation AddのIPの間のヘッダーの新しいタイプとIPSEC AHか超能力ヘッダー。
3. IPSEC modification
Modify IPSEC headers so that there are appropriate fields in
same location as UDP and TCP ports.
3. IPSEC変更Modify IPSECヘッダー、適切な分野がUDPと同じ位置とTCPポートにあるように。
4. AH Transparency
Skip over the Authentication Header packet classifier
processing.
4. Authentication Headerパケットクラシファイア処理の上のAH Transparency Skip。
A.1 UDP Encapsulation
A.1 UDPカプセル化
Since current SESSION and FILTER object expect UDP or TCP ports, this proposal says let's just give it to them. The basic concept is to add a UDP port between the IP and AH/ESP headers. The UDP ports would provide the granularity of control that is need to associate specific flows with reservations.
現在のSESSIONとFILTERが反対するので、UDPかTCPポートを予想してください、そして、ただそれをそれらに与えましょうこの提案が、言う。 基本概念はIPとAH/超能力ヘッダーの間のUDPポートを加えることです。 UDPポートは特定の流れを予約に関連づける必要性であるコントロールの粒状を提供するでしょう。
Source and destination ports would be used, as normal, in RSVP session definition and control. The port fields would also need to be used to identify the real transport level protocol (e.g. ESP) being used. Also since many UDP ports are assigned as well known ports, use of port numbers would be limited. So, the port fields would need to be used to unambiguously identify 1) the next level protocol, 2) the RSVP session, and 3) the RSVP reservation.
ソースと仕向港は、RSVPセッション定義とコントロールで中古であって、普通でしょう。 また、ポート分野は、使用される全く輸送平らなプロトコル(例えば、超能力)を特定するのに使用される必要があるでしょう。 また、知られているポートがまた、多くのUDPポートに割り当てられるので、ポートナンバーの使用は制限されるでしょう。 そのように、分野が明白に1を特定するのに使用されるために必要とするポート) 次の平らなプロトコル、2) RSVPセッション、および3、)RSVPの予約。
The advantages of this option is that no RSVP changes are required. The disadvantages is that, since the headers aren't in the expected location, RFC 1826 and RFC 1827 are violated.
このオプションの利点はRSVP変化が全く必要でないということです。 損失はヘッダーが予想された位置にないのでRFC1826とRFC1827が違反されるということです。
Berger & O'Malley Standards Track [Page 11] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[11ページ]。
A.2 FlowID Header Encapsulation
A.2 FlowIDヘッダーカプセル化
[This option was originally proposed by Greg Troxel <gdt@bbn.com>.]
[このオプションが元々グレッグ Troxel <gdt@bbn.com によって提案された、gt;、]。
This option is very similar to option 1, but is more generic and could be adopted as a standard solution. The notion is to use UDP like ports for the sole purpose of flow identification. RSVP would treat this new protocol exactly the same as UDP.
このオプションは、オプション1と非常に同様ですが、より多くのジェネリックであり、標準液として採用できました。 概念は流れ識別の唯一の目的のためのポートのようにUDPを使用することです。 RSVPはまさにUDPとして同じようにこの新しいプロトコルを扱うでしょう。
The difference between this and UDP encapsulation is in destination host processing. The destination host would essentially ignore port information and use a new field, protocol ID, to identify which protocol should process the packet next. Some examples of protocol IDs correspond to TCP, UDP, ESP, or AH.
これとUDPカプセル化の違いは目的地ホスト・プロセッシング中です。 あて先ホストは、どのプロトコルが次にパケットを処理するべきであるかを特定するのに本質的にはポート情報を無視して、新しい分野、プロトコルIDを使用するでしょう。 プロトコルIDに関するいくつかの例がTCP、UDP、超能力、またはAHに対応しています。
The format of the FlowID Header would be:
FlowID Headerの形式は以下の通りでしょう。
+---------------+---------------+---------------+---------------+ | Source Port | Dest Port | +---------------+---------------+---------------+---------------+ | Ver | Len | Protocol ID | Checksum | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+ | ソースポート| Destポート| +---------------+---------------+---------------+---------------+ | Ver| レン| プロトコルID| チェックサム| +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
2 bytes source port 4 bits length-32 (2)
2 bytes dest port 8 bits protocol ID
4 bits version (1) 16 bits checksum
8ビットの2バイトのソースポートの長さ-32の(2)のdestのポートのプロトコルのIDの4ビットの4ビットの2バイトのバージョン(1)16ビットのチェックサム
The advantage of this protocol is that flow identification is separated from all other protocol processing. The disadvantage is that the addition of a header violates RFC 1826 and 1827, and also that applications using RSVP will need to add this extra header on all data packets whose transport headers do not have UDP/TCP like ports.
このプロトコルの利点は流れ識別が他のすべてのプロトコル処理と切り離されるということです。 不都合はヘッダーの追加がRFC1826と1827に違反して、また、RSVPを使用するアプリケーションが、輸送ヘッダーがポートのようにUDP/TCPを持っていないすべてのデータ・パケットの上でこの付加的なヘッダーを加える必要があるということです。
A.3 IPSEC Protocol Modification
A.3 IPSECプロトコル変更
The basic notion of this option is to leave RSVP as currently specified and use the Security Association Identifier (SPI) found in the IPSEC headers for flow identification. There are two issues with using the SPI. The first is that the SPI is located in the wrong location when using Authentication (AH). The second issue is how to make use of the SPI.
このオプションの基本的な概念は、現在指定されているとしてRSVPを残して、流れ識別にIPSECヘッダーで見つけられたSecurity Association Identifier(SPI)を使用することです。 SPIを使用する2冊があります。 1番目はAuthentication(AH)を使用するとき、SPIが間違った位置に位置しているということです。 第2刷はどうSPIを利用するかということです。
The first issue is easy to fix, but violates RFC 1826. UDP and TCP have port assignments in the first 4 bytes of their headers, each is two bytes long, source comes first, then destination. The ESP header has the SPI in the same location as UDP/TCP ports, the AH doesn't.
創刊号は、修理するのが簡単ですが、RFC1826に違反します。 それぞれが2バイト長である、UDPとTCPには、彼らのヘッダーの最初の4バイトにおけるポート課題があって、ソースは一番になって、その時は目的地です。 超能力ヘッダーはUDP/TCPポートと同じ位置にSPIを持って、AHはそうしません。
Berger & O'Malley Standards Track [Page 12] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[12ページ]。
The IP Authentication Header has the following syntax:
IP Authentication Headerには、以下の構文があります:
+---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | Security Parameters Index | +---------------+---------------+---------------+---------------+ | | + Authentication Data (variable number of 32-bit words) | | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+ | 次のヘッダー| 長さ| 予約されます。| +---------------+---------------+---------------+---------------+ | セキュリティパラメタインデックス| +---------------+---------------+---------------+---------------+ | | + 認証Data(可変数の32ビットの単語)| | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
Simply reversing the first 4 bytes with the SPI we will have the SPI in the location that RSVP expects. This would be non-standard, or require a major (i.e. not backward compatible) change to RSVP 1826.
SPIと共に最初の4バイトを単に逆にして、私たちはRSVPが予想する位置にSPIを持つつもりです。 これが標準的でないか、または少佐を必要とするだろう、(すなわち、後方でない、コンパチブル、)、RSVP1826に変化してください。
The second issue is how to make use of the SPI. Per the current RSVP specification, the first two bytes of a flow's SPI will need to be carried in the PATH message and the second two bytes in the RESV message. The biggest problem is that the SPI is normally selected by the receiver and is likely to be different for EACH sender. (There is a special case where the same SPI is used by all senders in a multicast group. But this is a special case.) It is possible to have the SPI selected prior to starting the RSVPsession. This will work for unicast and the special multicast case. But using this approach means that setup time will usually be extended by at least 1 round trip time. Its not clear how to support SE and WF style reservations.
第2刷はどうSPIを利用するかということです。 現在のRSVP仕様に従って、流れの最初の2バイトのSPIは、RESVメッセージのPATHメッセージと2番目の2バイトで運ばれる必要があるでしょう。 最も大きい問題は、通常、SPIが受信機によって選択されるということであり、EACH送付者にとって異なる傾向があります。 (特別なケースが同じSPIがマルチキャストグループのすべての送付者によって使用されるところにあります。 しかし、これは特別なそうです。) RSVPsessionを始動する前にSPIを選択させるのは可能です。 これはユニキャストと特別なマルチキャストケースのために働くでしょう。 しかし、このアプローチを使用するのは、通常、準備時間が少なくとも1周遊旅行時間によって延ばされることを意味します。 その明確でなくてSEをサポートする方法をWFスタイルの予約。
The advantage of this approach is no change to RSVP. The disadvantages are modification to RFC1827 and limited support of RSVP reservation styles.
このアプローチの利点はRSVPへの変化ではありません。 損失はRSVP予約スタイルのRFC1827と限定的なサポートへの変更です。
A.4 AH Transparency
A.4、ああ、透明
The source of the RSVP support of IPSEC protocols problem is that the real transport header is not in the expected location. With ESP packets, the real source and destination ports are encrypted and therefore useless to RSVP. This is not the case for authentication. For AH, the real header just follows the Authentication Header. So, it would be possible to use the real transport header for RSVP session definition and reservation.
IPSECプロトコル問題のRSVPサポートの源は本当の輸送ヘッダーが予想された位置にないということです。 超能力パケットはあるので、本当のソースと仕向港は、暗号化されていてしたがって、RSVPに無駄です。 これは認証のためのそうではありません。 AHに関しては、本当のヘッダーはただAuthentication Headerの後をつけます。 それで、RSVPセッション定義と予約に本当の輸送ヘッダーを使用するのは可能でしょう。
To use the transport header, all that would need to be done is for the flow classifier to skip over AHs before classifying packets. No modification to RSVP formats or setup processing would be required. Applications would make reservations based on transport (i.e., UDP or
輸送ヘッダーを使用するために、する必要があるすべてはパケットを分類する前に流れクラシファイアがAHsを飛ばすことです。 RSVP形式かセットアップ処理への変更は全く必要でないでしょう。 またはアプリケーションが輸送に基づく予約をするだろう、(すなわち、UDP。
Berger & O'Malley Standards Track [Page 13] RFC 2207 RSVP Extensions for IPSEC September 1997
バーガーとオマリーStandardsは1997年9月にIPSECのためにRFC2207RSVP拡張子を追跡します[13ページ]。
TCP) ports as usual.
TCP) 通常通りのポート。
The advantages of this approach are no changes to either IPSEC protocols or RSVP formats. The major disadvantage is that routers and hosts must skip all AHs before classifying packets. The working group decided that it was best to have a consistent solution for both AH and ESP.
このアプローチの利点はIPSECプロトコルかRSVP形式のどちらかへの変化ではありません。 主要な不都合はパケットを分類する前にルータとホストがすべてのAHsをスキップしなければならないということです。 ワーキンググループは、AHと超能力の両方のための一貫したソリューションを持っているのが最も良いと決めました。
Berger & O'Malley Standards Track [Page 14]
バーガーとオマリー標準化過程[14ページ]
一覧
スポンサーリンク
