RFC2750 日本語訳
2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. (Format: TXT=26379 bytes) (Updates RFC2205) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Herzog Request for Comments: 2750 IPHighway Updates: 2205 January 2000 Category: Standards Track
コメントを求めるワーキンググループS.ハーツォグ要求をネットワークでつないでください: 2750のIPHighwayアップデート: 2205 2000年1月のカテゴリ: 標準化過程
RSVP Extensions for Policy Control
方針コントロールのための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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP]
このメモはRSVPでジェネリック方針がベースの入場コントロールであるとサポートするための1セットの拡大を提示します。 それは拡大としてRSVPの機能的な仕様に知覚されるべきです。[RSVP]
These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events.
これらの拡大はPOLICY_DATAオブジェクトの標準書式、および方針イベントのRSVPの取り扱いの記述を含んでいます。
This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].
このドキュメントは特定の方針制御機構を支持しません。 しかしながら、[RAP、COPS、COPS-RSVP]でこれらの拡大のためのRouter/サーバPolicyプロトコル記述を見つけることができます。
Herzog Standards Track [Page 1] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[1ページ]。
Table of Contents
目次
1 Introduction.......................................................2 2 A Simple Scenario..................................................3 3 Policy Data Objects................................................3 3.1 Base Format.....................................................4 3.2 Options.........................................................4 3.3 Policy Elements.................................................7 3.4 Purging Policy State............................................7 4 Processing Rules...................................................8 4.1 Basic Signaling.................................................8 4.2 Default Handling for PIN nodes..................................8 4.3 Error Signaling.................................................9 5 IANA Considerations................................................9 6 Security Considerations............................................9 7 References........................................................10 8 Acknowledgments...................................................10 9 Author Information................................................10 Appendix A: Policy Error Codes......................................11 Appendix B: INTEGRITY computation for POLICY_DATA objects...........12 Full Copyright Statement ...........................................13
1つの序論…簡単なシナリオあたり2 2…3 3個の方針データ・オブジェクト…3 3.1 形式を基礎づけてください…4 3.2のオプション…4 3.3 Policy Elements…7 3.4 パージ方針状態…7 4処理は統治されます…8 4.1 基本的なシグナリング…8 4.2 暗証番号ノードのためのデフォルトHandling…8 4.3 誤りシグナリング…9 5のIANA問題…9 6のセキュリティ問題…9 7の参照箇所…10 8つの承認…10 9 情報を書いてください…10 付録A: 方針エラーコード…11 付録B: POLICY_DATAオブジェクトのためのINTEGRITY計算…12 完全な著作権宣言文…13
1 Introduction
1つの序論
RSVP, by definition, discriminates between users, by providing some users with better service at the expense of others. Therefore, it is reasonable to expect that RSVP be accompanied by mechanisms for controlling and enforcing access and usage policies. Version 1 of the RSVP Functional Specifications [RSVP] left a placeholder for policy support in the form of POLICY_DATA object.
RSVPは、定義上他のものを犠牲にして、より良いサービスを何人かのユーザに提供することによって、ユーザを区別します。 したがって、RSVPがアクセスと用法方針を制御して、実施するためにメカニズムによって同伴されると予想するのは妥当です。 [RSVP]が方針のためのプレースホルダを残したRSVP Functional Specificationsのバージョン1は、POLICYの形で_DATAがオブジェクトであるとサポートします。
The current RSVP Functional Specification describes the interface to admission (traffic) control that is based "only" on resource availability. In this document we describe a set of extensions to RSVP for supporting policy based admission control as well. The scope of this document is limited to these extensions and does not advocate specific architectures for policy based controls.
現在のRSVP Functional Specificationはリソースの有用性だけに基づいている承認(トラフィック)コントロールにインタフェースについて説明します。 本書では私たちは、方針がまた、ベースの入場コントロールであるとサポートするために1セットの拡大についてRSVPに説明します。 このドキュメントの範囲は、これらの拡大に制限されて、方針に基づいているコントロールのために特定のアーキテクチャを支持しません。
For the purpose of this document we do not differentiate between Policy Decision Point (PDP) and Local Decision Point (LDPs) as described in [RAP]. The term PDP should be assumed to include LDP as well.
このドキュメントの目的のために、私たちは[RAP]で説明されるようにPolicy Decision Point(PDP)とLocal Decision Point(LDPs)を区別しません。 PDPという用語がまた、自由民主党を含んでいると思われるべきです。
Herzog Standards Track [Page 2] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[2ページ]。
2 A Simple Scenario
2 簡単なシナリオ
It is generally assumed that policy enforcement (at least in its initial stages) is likely to concentrate on border nodes between autonomous systems.
一般に、方針実施(少なくとも初期の)が自律システムの間の境界ノードに集中しそうであると思われます。
Figure 1 illustrates a simple autonomous domain with two boundary nodes (A, C) which represent PEPs controlled by PDPs. A core node (B) represents an RSVP capable policy ignorant node (PIN) with capabilities limited to default policy handling (Section 4.2).
図1はPDPsによって制御されたPEPsを表す2つの境界ノード(A、C)を簡単な自治のドメインに入れます。 能力がデフォルト方針取り扱い(セクション4.2)に制限されている状態で、コアノード(B)はRSVPのできる方針無知なノード(暗証番号)を表します。
PDP1 PDP2
| |
| |
+---+ +---+ +---+
| A +---------+ B +---------+ C |
+---+ +---+ +---+
PEP2 PIN PEP2
PDP1 PDP2| | | | +---+ +---+ +---+ | +---------+ B+---------+ C| +---+ +---+ +---+ PEP2暗証番号PEP2
Figure 1: Autonomous Domain scenario
図1: 自治のDomainシナリオ
Here, policy objects transmitted across the domain traverse an intermediate PIN node (B) that is allowed to process RSVP message but considered non-trusted for handling policy information.
ここに、ドメインの向こう側に伝えられた政策目的はRSVPメッセージを処理するのが許容されていますが、取り扱いのために非信じられた方針情報であると考えられる中間的暗証番号ノード(B)を横断します。
This document describes processing rules for both PEP as well as PIN nodes.
このドキュメントは、PEPと暗証番号ノードの両方のために規則を処理すると説明します。
3 Policy Data Objects
3 方針データ・オブジェクト
POLICY_DATA objects are carried by RSVP messages and contain policy information. All policy-capable nodes (at any location in the network) can generate, modify, or remove policy objects, even when senders or receivers do not provide, and may not even be aware of policy data objects.
POLICY_DATAオブジェクトは、RSVPメッセージによって運ばれて、方針情報を含んでいます。 すべての方針できるノード(ネットワークにおけるどんな位置のも)が、政策目的を生成するか、変更するか、または取り除くことができます、送付者か受信機が提供しないで、また方針データ・オブジェクトを意識してさえいないとき。
The exchange of POLICY_DATA objects between policy-capable nodes along the data path, supports the generation of consistent end-to-end policies. Furthermore, such policies can be successfully deployed across multiple administrative domains when border nodes manipulate and translate POLICY_DATA objects according to established sets of bilateral agreements.
POLICY_DATAの交換は、データ経路に沿った方針できるノードの間で反対して、終わりから終わりへの一貫した方針の世代をサポートします。 境界ノードがPOLICY_DATAオブジェクトを操作して、設立されたセットの二国間条約通りに翻訳するとき、その上、複数の管理ドメインの向こう側に首尾よくそのような方針を配布することができます。
The following extends section A.13 in [RSVP].
以下は[RSVP]でセクションA.13を広げています。
Herzog Standards Track [Page 3] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[3ページ]。
3.1 Base Format
3.1 基地の形式
POLICY_DATA class=14
POLICY_DATAのクラス=14
o Type 1 POLICY_DATA object: Class=14, C-Type=1
o 1個のPOLICY_DATAオブジェクトをタイプしてください: クラス=14、C-タイプ=1
+-------------+-------------+-------------+-------------+
| Length | POLICY_DATA | 1 |
+---------------------------+-------------+-------------+
| Data Offset | 0 (reserved) |
+---------------------------+-------------+-------------+
| |
// Option List //
| |
+-------------------------------------------------------+
| |
// Policy Element List //
| |
+-------------------------------------------------------+
+-------------+-------------+-------------+-------------+ | 長さ| 方針_データ| 1 | +---------------------------+-------------+-------------+ | データは相殺されます。| 0(予約されます)| +---------------------------+-------------+-------------+ | | //オプションリスト//| | +-------------------------------------------------------+ | | //方針要素リスト//| | +-------------------------------------------------------+
Data Offset: 16 bits
データは相殺されます: 16ビット
The offset in bytes of the data portion (from the first
byte of the object header).
データ部(オブジェクトヘッダーの最初のバイトからの)のバイトにおけるオフセット。
Reserved: 16 bits
予約される: 16ビット
Always 0.
いつも0。
Option List: Variable length
オプションリスト: 可変長
The list of options and their usage is defined in Section
3.2.
オプションのリストとそれらの用法はセクション3.2で定義されます。
Policy Element List: Variable length
方針要素リスト: 可変長
The contents of policy elements is opaque to RSVP. See more
details in Section 3.3.
方針要素のコンテンツはRSVPに不透明です。 セクション3.3でその他の詳細を見てください。
3.2 Options
3.2 オプション
This section describes a set of options that may appear in POLICY_DATA objects. All policy options appear as RSVP objects but their semantic is modified when used as policy data options.
このセクションはPOLICY_DATAオブジェクトに現れるかもしれない1セットのオプションについて説明します。 しかし、RSVPが反対するようにすべての政策選択が見える、それら、意味、方針データオプションとして使用されると、変更されます。
Herzog Standards Track [Page 4] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[4ページ]。
FILTER_SPEC object (list) or SCOPE object
FILTER_SPECオブジェクト(リスト)かSCOPEが反対します。
These objects describe the set of senders associated with the POLICY_DATA object. If none is provided, the policy information is assumed to be associated with all the flows of the session. These two types of objects are mutually exclusive, and cannot be mixed.
これらのオブジェクトはPOLICY_DATAオブジェクトに関連している送付者のセットについて説明します。 なにも提供されないなら、方針情報がセッションのすべての流れに関連させていると思われます。 これらの2つのタイプのオブジェクトは、互いに排他的であり、混ぜることができません。
In Packed FF Resv messages, this FILTER_SPEC option provides association between a reserved flow and its POLICY_DATA objects.
Packed FF Resvメッセージに、このFILTER_SPECオプションは予約された流れとそのPOLICY_DATAオブジェクトとの協会を提供します。
In WF or SE styles, this option preserves the original flow/POLICY_DATA association as formed by PDPs, even across RSVP capable PINs. Such preservation is required since PIN nodes may change the list of reserved flows on a per-hop basis, irrespective of legitimate Edge-to-Edge PDP policy considerations.
WFかSEスタイルでは、PDPsによって形成されるようにこのオプションはオリジナルの流れ/POLICY_DATA協会を保存します、RSVPのできる暗証番号の向こう側にさえ。 暗証番号ノードが1ホップあたり1個のベースで予約された流れのリストを変えるかもしれないので、そのような保存が必要です、Edgeから縁へのPDP方針正統の問題の如何にかかわらず。
Last, the SCOPE object should be used to prevent "policy loops" in a manner similar to the one described in [RSVP], Section 3.4. When PIN nodes are part of a WF reservation path, the RSVP SCOPE object is unable to prevent policy loops and the separate policy SCOPE object is required.
最後に、SCOPEオブジェクトは[RSVP]で説明されたものと同様の方法で「方針輪」を防ぐのに使用されるべきです、セクション3.4。 暗証番号ノードがWF予約経路の一部であるときに、RSVP SCOPEオブジェクトは方針輪を防ぐことができません、そして、別々の方針SCOPEオブジェクトが必要です。
Note: using the SCOPE option may have significant impact on scaling and size of POLICY_DATA objects.
以下に注意してください。 SCOPEオプションを使用すると、重要な影響はPOLICY_DATAオブジェクトのスケーリングとサイズで与えられるかもしれません。
Originating RSVP_HOP
_RSVPを溯源して、跳んでください。
The RSVP_HOP object identifies the neighbor/peer policy-capable node that constructed the policy object. When policy is enforced at border nodes, peer policy nodes may be several RSVP hops away from each other and the originating RSVP_HOP is the basis for the mechanism that allows them to recognize each other and communicate safely and directly.
RSVP_HOPオブジェクトは政策目的を組み立てた隣人/同輩の方針できるノードを特定します。 それらが互いを見分けて、安全に直接交信するメカニズムの方針が境界ノードで励行されるとき、同輩方針ノードは互いから遠くのいくつかのRSVPホップであるかもしれなく、起因しているRSVP_HOPは基礎です。
If no RSVP_HOP object is present, the policy data is implicitly assumed to have been constructed by the RSVP_HOP indicated in the RSVP message itself (i.e., the neighboring RSVP node is policy- capable).
どんなRSVP_HOPオブジェクトも存在していないなら、方針データはRSVPメッセージ自体で示されたRSVP_HOPによって組み立てられたとそれとなく思われます(すなわち、隣接しているRSVPノードは方針できます)。
Destination RSVP_HOP
目的地RSVP_ホップ
A second RSVP_HOP object may follow the originating RSVP_HOP object. This second RSVP_HOP identifies the destination policy node. This is used to ensure the POLICY_DATA object is delivered to targeted policy nodes. It may be used to emulate unicast delivery in multicast Path messages. It may also help prevent using a policy object in other parts of the network (replay attack).
2番目のRSVP_HOPオブジェクトは起因しているRSVP_HOPオブジェクトに続くかもしれません。 この第2RSVP_HOPは目的地方針ノードを特定します。 これは、POLICY_DATAオブジェクトが狙っている方針ノードに提供されるのを保証するのに使用されます。 それは、マルチキャストPathメッセージにおけるユニキャスト配送を見習うのに使用されるかもしれません。 また、それは、ネットワーク(反射攻撃)の他の部分で政策目的を使用するのを防ぐのを助けるかもしれません。
Herzog Standards Track [Page 5] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[5ページ]。
On the receiving side, a policy node should ignore any POLICY_DATA that includes a destination RSVP_HOP that doesn't match its own IP address.
受信側では、方針ノードがそれ自身のIPアドレスに合っていない目的地RSVP_HOPを含んでいるどんなPOLICY_DATAも無視するはずです。
INTEGRITY Object
保全オブジェクト
Figure 1 (Section 2) provides an example where POLICY_DATA objects are transmitted between boundary nodes while traversing non-secure PIN nodes. In this scenario, the RSVP integrity mechanism becomes ineffective since it places policy trust with intermediate PIN nodes (which are trusted to perform RSVP signaling but not to perform policy decisions or manipulations).
図1(セクション2)はPOLICY_DATAオブジェクトが非安全な暗証番号ノードを横断している間に境界ノードの間に伝えられる例を提供します。 このシナリオでは、中間的暗証番号ノード(政策決定か操作を実行するのではなく、RSVPシグナリングを実行すると信じられる)に方針信頼を置くので、RSVP保全メカニズムは効力がなくなります。
The INTEGRITY object option inside POLICY_DATA object creates direct secure communications between non-neighboring PEPs (and their controlling PDPs) without involving PIN nodes.
暗証番号ノードにかかわらないで、INTEGRITYオブジェクトオプション内部のPOLICY_DATAオブジェクトは非隣接しているPEPs(そして、彼らはPDPsを制御する)のダイレクト安全なコミュニケーションを作成します。
This option can be used at the discretion of PDPs, and is computed in a manner described in Appendix B.
このオプションは、PDPsの裁量に使用できて、Appendix Bで説明された方法で計算されます。
Policy Refresh TIME_VALUES (PRT)
方針は時間_値をリフレッシュします。(PRT)
The Policy Refresh TIME_VALUES (PRT) option is used to slow policy refresh frequency for policies that have looser timing constraints relative to RSVP. If the PRT option is present, policy refreshes can be withheld as long as at least one refresh is sent before the policy refresh timer expires. A minimal value for PRT is R; lower values are assumed to be R (neither error nor warning should be triggered).
使用されるPolicy Refreshタイム誌_VALUES(PRT)オプションはRSVPに比例して、よりゆるいタイミング規制を持っている方針のために遅い方針に頻度をリフレッシュします。 PRTオプションがプレゼント、方針がリフレッシュするということであるなら、少なくとも1つがリフレッシュするとき方針がリフレッシュする前に長さ送るので差し控えられて、タイマが期限が切れるということであることができます。 PRTのための最小量の値はRです。 下側の値はRであると思われます(誤りも警告も引き起こすべきではありません)。
To simplify RSVP processing, time values are not based directly on the PRT value, but on a Policy Refresh Multiplier N computed as N=Floor(PRT/R). Refresh and cleanup rules are derived from [RSVP] Section 3.7 assuming the refresh period for PRT POLICY DATA is R' computed as R'=N*R. In effect, both the refresh and the state cleanup are slowed by a factor of N).
RSVP処理を簡素化するために、時間的価値は直接PRT値に基づいているのではなく、Nが床(PRT/R)と等しいので計算されたPolicy Refresh Multiplier Nに基づいています。 'リフレッシュしてください。そうすれば、クリーンアップ規則が[RSVP]セクション3.7仮定によって引き出している、Rが'Rとして、計算される'というPRT POLICY DATA=N*Rのために期間をリフレッシュしてください。 事実上と、両方、リフレッシュしてください。そうすれば、州のクリーンアップはN)の要素によって遅くされます。
The refresh multiplier applies to no-change periodic refreshes only (rather than updates). For example, a policy being refreshed at time T, T+N, T+2N,... may encounter a route change detected at T+X. In this case, the event would force an immediate policy update and would reset srfresh times to T+X+N, T+X+2N,...
乗数は、周期的に変化しないのに申し込みます。リフレッシュ、唯一で(アップデートよりむしろ)、リフレッシュします。 例えば、方針が時間T、T+N、T+2Nでリフレッシュされる場合、…はT+Xに検出されたルート変化に遭遇するかもしれません。 T+X+2N、この場合、イベントは即座の方針アップデートを強制して、T+X+Nにsrfresh回をリセットするでしょう…
When network nodes restart, RSVP messages between PRT policy refreshes may be rejected since they arrive without necessary POLICY_DATA objects. This error situation would clear with the next periodic policy refresh or with a policy update triggered by ResvErr or PathErr messages.
ネットワーク・ノードが再開するとき、必要なPOLICY_DATAオブジェクトなしで到着するので、方針がリフレッシュするPRTの間のRSVPメッセージは拒絶されるかもしれません。 このエラー状態はResvErrによってリフレッシュしたか、または方針アップデートで引き起こされた次の周期的な方針かPathErrメッセージでクリアされるでしょう。
Herzog Standards Track [Page 6] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[6ページ]。
This option is especially useful to combine strong (high overhead) and weak (low overhead) authentication certificates as policy data. In such schemes the weak certificate can support admitting a reservation only for a limited time, after which the strong certificate is required.
このオプションは、方針データとして強さであっ(高いオーバーヘッド)て弱い(低いオーバーヘッド)認証証明書を結合するために特に役に立ちます。 そのような体系では、弱い証明書は、認めるのが限られた時だけの予約であるとサポートすることができます。(その時、強い証明書が必要でした後)。
This approach may reduce the overhead of POLICY_DATA processing. Strong certificates could be transmitted less frequently, while weak certificates are included in every RSVP refresh.
このアプローチはPOLICY_DATA処理のオーバーヘッドを下げるかもしれません。 どんなより頻繁にも強い証明書を伝えることができませんでしたが、含まれていた弱い証明書はあらゆるRSVPでリフレッシュします。
3.3 Policy Elements
3.3 Policy Elements
The content of policy elements is opaque to RSVP; their internal format is understood by policy peers e.g. an RSVP Local Decision Point (LDP) or a Policy Decision Point (PDP) [RAP]. A registry of policy element codepoints and their meaning is maintained by [IANA- CONSIDERATIONS] (also see Section 5).
方針要素の内容はRSVPに不明瞭です。 それらの内部の形式は例えば、方針同輩RSVP Local Decision Point(自由民主党)かPolicy Decision Pointに解釈されます(PDP)[RAP]。 方針要素codepointsとそれらの意味の登録は[IANA- CONSIDERATIONS]によって維持されます(また、セクション5を見てください)。
Policy Elements have the following format:
Policy Elementsには、以下の形式があります:
+-------------+-------------+-------------+-------------+ | Length | P-Type | +---------------------------+---------------------------+ | | // Policy information (Opaque to RSVP) // | | +-------------------------------------------------------+
+-------------+-------------+-------------+-------------+ | 長さ| P-タイプ| +---------------------------+---------------------------+ | | //方針情報(RSVPに不透明な)//| | +-------------------------------------------------------+
3.4 Purging Policy State
3.4 パージ方針状態
Policy state expires in the granularity of Policy Elements (POLICY_DATA objects are mere containers and do not expire as such).
政策ポジションはPolicy Elementsの粒状で期限が切れます(POLICY_DATAオブジェクトは、単なるコンテナであり、そういうものとして期限が切れません)。
Policy elements expire in the exact manner and time as the RSVP state received in the same message (see [RSVP] Section 3.7). PRT controlled state expires N times slower (see Section 3.2).
RSVP状態が同じメッセージで受信されたので([RSVP]セクション3.7を見てください)、方針要素は正確な方法と時間で期限が切れます。 PRTは制御しました。状態はN倍より遅く期限が切れます(セクション3.2を見てください)。
Only one policy element of a certain P-Type can be active at any given time. Therefore, policy elements are instantaneously replaced when another policy element of the same P-Type is received from the same PDP (previous or next policy RSVP_HOP). An empty policy element of a certain P-Type is used to delete (rather than a replace) all policy state of the same P-Type.
あるP-タイプの1つの方針要素だけがその時々で活性である場合があります。 したがって、同じPDP(前であるか次の方針RSVP_HOP)から同じP-タイプの別の方針要素を受け取るとき、即座に方針要素を取り替えます。 あるP-タイプの空の方針要素が削除するのにおいて使用されている、(むしろ、aが取り替える、)、同じP-タイプのすべての政策ポジション。
Herzog Standards Track [Page 7] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[7ページ]。
4 Processing Rules
4 処理規則
These sections describe the minimal required policy processing rules for RSVP.
これらのセクションはRSVPのために最小量の必要な方針処理規則について説明します。
4.1 Basic Signaling
4.1 基本的なシグナリング
This memo mandates enforcing policy control for Path, Resv, PathErr, and ResvErr messages only. PathTear and ResvTear are assumed not to require policy control based on two main presumptions. First, that Integrity verification [MD5] guarantee that the Tear is received from the same node that sent the installed reservation, and second, that it is functionally equivalent to that node holding-off refreshes for this reservation.
このメモはPathのために方針コントロールを実施する、Resv、PathErr、およびResvErrメッセージだけを強制します。 PathTearとResvTearが2つの主な推定に基づく方針コントロールを必要としないと思われます。 まず最初に、そのIntegrity検証[MD5]はインストールされた予約、および2番目を送ったのと同じノードからTearを受け取って、それが距離を保つのがこの予約のためにリフレッシュするそのノードに機能上同等であることを保証します。
4.2 Default Handling for PIN nodes
4.2 暗証番号ノードのためのデフォルトHandling
Figure 1 illustrates an example of where policy data objects traverse PIN nodes in transit from one PEP to another.
図1は方針データ・オブジェクトが1PEPから別のPEPまでのトランジットで暗証番号ノードを横断するところに関する例を例証します。
A PIN node is required at a minimum to forward the received POLICY_DATA objects in the appropriate outgoing messages according to the following rules:
暗証番号ノードが以下の規則に従って適切な送信されるメッセージで容認されたPOLICY_DATAオブジェクトを進めるのに最小限で必要です:
o POLICY_DATA objects are to be forwarded as is, without any
modifications.
o POLICY_DATAオブジェクトは少しも変更なしでそのままで進められることになっています。
o Multicast merging (splitting) nodes:
o ノードを合併する(分かれます)マルチキャスト:
In the upstream direction:
上流の方向に:
When multiple POLICY_DATA objects arrive from downstream, the
RSVP node should concatenate all of them (as a list of the
original POLICY_DATA objects) and forward them with the
outgoing (upstream) message.
複数のPOLICY_DATAオブジェクトが川下から届くとき、RSVPノードは、それら(オリジナルのPOLICY_DATAオブジェクトのリストとしての)を皆、連結して、送信する(上流の)メッセージと共にそれらを進めるはずです。
On the downstream direction:
川下の方向に関して:
When a single incoming POLICY_DATA object arrives from
upstream, it should be forwarded (copied) to all downstream
branches of the multicast tree.
単一の入って来るPOLICY_DATAオブジェクトが上流から届くとき、マルチキャスト木のすべての川下の枝にそれを送るべきです(コピーされます)。
The same rules apply to unrecognized policies (sub-objects) within the POLICY_DATA object. However, since this can only occur in a policy-capable node, it is the responsibility of the PDP and not RSVP.
同じ規則はPOLICY_DATAオブジェクトの中の認識されていない方針(サブオブジェクト)に適用されます。 しかしながら、これが方針できるノードに起こることができるだけであるので、それはRSVPではなく、PDPの責任です。
Herzog Standards Track [Page 8] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[8ページ]。
4.3 Error Signaling
4.3 誤りシグナリング
Policy errors are reported by either ResvErr or PathErr messages with a policy failure error code in the ERROR_SPEC object. Policy error message must include a POLICY_DATA object; the object contains details of the error type and reason in a P-Type specific format (See Section 3.3).
政策の失敗エラーコードがERROR_SPECオブジェクトにある状態で、方針誤りはResvErrかPathErrメッセージのどちらかによって報告されます。 方針エラーメッセージはPOLICY_DATAオブジェクトを含まなければなりません。 オブジェクトはP-タイプの特定の形式の誤りタイプと理由の詳細を含んでいます(セクション3.3を見てください)。
If a multicast reservation fails due to policy reasons, RSVP should not attempt to discover which reservation caused the failure (as it would do for Blockade State). Instead, it should attempt to deliver the policy ResvErr to ALL downstream hops, and have the PDP (or LDP) decide where messages should be sent. This mechanism allows the PDP to limit the error distribution by deciding which "culprit" next-hops should be informed. It also allows the PDP to prevent further distribution of ResvErr or PathErr messages by performing local repair (e.g. substituting the failed POLICY_DATA object with a different one).
マルチキャストの予約が方針理由のため失敗するなら、RSVPは、どの予約が失敗を引き起こしたかを発見するのを試みるはずがありません(それがBlockade州のために大丈夫であるように)。 代わりに、それは、すべての川下のホップに方針ResvErrを提供するのを試みて、PDP(または、自由民主党)は、メッセージがどこに送られるべきであるかを決めるべきです。 このメカニズムで、次のホップがどの「罪人」であるべきであるかと決めることによって、PDPは知識があった状態で誤差分布を制限できます。 また、それで、PDPは、局部的修繕(例えば、異なったもので、失敗したPOLICY_DATAオブジェクトを置換する)を実行することによって、ResvErrかPathErrメッセージのさらなる分配を防ぐことができます。
Error codes are described in Appendix Appendix A.
エラーコードはAppendix Appendix Aで説明されます。
5 IANA Considerations
5 IANA問題
RSVP Policy Elements (P-Types)
RSVP Policy Elements(P-タイプ)
Following the policies outlined in [IANA-CONSIDERATIONS],numbers 0-49151 are allocated as standard policy elements by IETF Consensus action, numbers in the range 49152-53247 are allocated as vendor specific (one per vendor) by First Come First Serve, and numbers 53248-65535 are reserved for private use and are not assigned by IANA.
[IANA-CONSIDERATIONS]に概説された方針に従って、IETF Consensus動作による標準約款要素、範囲49152-53247の数がベンダー特有であるとしてFirst Come First Serveによって割り当てられて(1ベンダーあたり1つ)、No.53248-65535を私的使用目的で予約して、IANAが割り当てないとき、No.0-49151を割り当てます。
6 Security Considerations
6 セキュリティ問題
This memo describes the use of POLICY_DATA objects to carry policy- related information between RSVP nodes. Two security mechanisms can be optionally used to ensure the integrity of the carried information. The first mechanism relies on RSVP integrity [MD5] to provide a chain of trust when all RSVP nodes are policy capable. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between non-neighboring RSVP PEPs (see Sections 2 and 3.2).
このメモは、RSVPノードの間まで方針関連情報を運ぶためにPOLICY_DATAオブジェクトの使用について説明します。 運ばれた情報の保全を確実にするのに任意に2台のセキュリティー対策を使用できます。 最初のメカニズムは、すべてのRSVPノードが方針できるとき、信頼のチェーンを提供するために、RSVP保全[MD5]を当てにします。 2番目のメカニズムは、非隣接しているRSVP PEPsの間の保全を保証するためにPOLICY_DATAオブジェクトの中にINTEGRITYオブジェクトを当てにします(セクション2と3.2を見てください)。
Herzog Standards Track [Page 9] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[9ページ]。
7 References
7つの参照箇所
[RAP] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy Based Admission Control",
RFC 2753, January 2000.
[叩きます] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針のベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Raja, R. and A. Sastry, "The COPS (Common Open
Policy Service) Protocol", RFC 2748, January
2000.
[巡査]ボイル、J.、コーエン、R.、ダラム、D.、ハーツォグ、S.、王侯、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Raja, R. and A. Sastry, "COPS Usage for RSVP",
RFC 2749, January 2000.
[巡査-RSVP] ボイル(J.、コーエン、R.、ダラム、D.、ハーツォグ、S.、王侯、R.、およびA.Sastry)は、「RSVPのために用法を獲得します」、RFC2749、2000年1月。
[RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog,
S. and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Functional Specification", RFC 2205,
September 1997.
[RSVP]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--機能的な仕様」、RFC2205、1997年9月。
[MD5] Baker, F., Lindell B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747,
January 2000.
[MD5] ベイカーとF.とリンデルB.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[IANA-問題]Alvestrand、H.、およびT.Narten、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
8 Acknowledgments
8つの承認
This document incorporates inputs from Lou Berger, Bob Braden, Deborah Estrin, Roch Guerin, Timothy O'Malley, Dimitrios Pendarakis, Raju Rajan, Scott Shenker, Andrew Smith, Raj Yavatkar, and many others.
このドキュメントはルウ・バーガー、ボブ・ブレーデン、デボラEstrin、Rochゲラン、ティモシー・オマリー、デーメートリオスPendarakis、ラジュRajan、スコットShenker、アンドリュー・スミス、Raj Yavatkar、および多くの他のものからの入力を取り入れます。
9 Author Information
9 作者情報
Shai Herzog IPHighway, Inc. 55 New York Avenue Framingham, MA 01701
ShaiハーツォグIPHighway Inc.55ニューヨークAvenueフレイミングハム、MA 01701
Phone: (508) 620-1141 EMail: herzog@iphighway.com
以下に電話をしてください。 (508) 620-1141 メールしてください: herzog@iphighway.com
Herzog Standards Track [Page 10] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[10ページ]。
Appendix A: Policy Error Codes
付録A: 方針エラーコード
This Appendix extends the list of error codes described in Appendix B of [RSVP].
このAppendixは[RSVP]のAppendix Bで説明されたエラーコードのリストを広げています。
Note that Policy Element specific errors are reported as described in Section 4.3 and cannot be reported through RSVP (using this mechanism). However, this mechanism provides a simple, less secure mechanism for reporting generic policy errors. Most likely the two would be used in concert such that a generic error code is provided by RSVP, while Policy Element specific errors are encapsulated in a return POLICY_DATA object (as in Section 4.3).
Policy Elementの特定の誤りはセクション4.3で説明されるように報告して、RSVPを通して報告できないことに注意してください(このメカニズムを使用して)。 しかしながら、このメカニズムは簡単で、より少ない安全なメカニズムをジェネリック方針誤りを報告するのに提供します。 たぶん、2はコンサートに使用されるでしょう、したがって、ジェネリックエラーコードがRSVPが提供されます、Policy Elementの特定の誤りがリターンPOLICY_DATAオブジェクトでカプセル化されますが(セクション4.3のように)。
ERROR_SPEC class = 6
ERROR_SPECのクラス=6
Error Code = 02: Policy Control failure
誤りコード=02: 方針Controlの故障
Error Value: 16 bit
誤り値: 16ビット
0 = ERR_INFO : Information reporting 1 = ERR_WARN : Warning 2 = ERR_UNKNOWN : Reason unknown 3 = ERR_REJECT : Generic Policy Rejection 4 = ERR_EXCEED : Quota or Accounting violation 5 = ERR_PREEMPT : Flow was preempted 6 = ERR_EXPIRED : Previously installed policy expired (not refreshed) 7 = ERR_REPLACED: Previous policy data was replaced & caused rejection 8 = ERR_MERGE : Policies could not be merged (multicast) 9 = ERR_PDP : PDP down or non functioning 10= ERR_SERVER : Third Party Server (e.g., Kerberos) unavailable 11= ERR_PD_SYNTX: POLICY_DATA object has bad syntax 12= ERR_PD_INTGR: POLICY_DATA object failed Integrity Check 13= ERR_PE_BAD : POLICY_ELEMENT object has bad syntax 14= ERR_PD_MISS : Mandatory PE Missing (Empty PE is in the PD object) 15= ERR_NO_RSC : PEP Out of resources to handle policies. 16= ERR_RSVP : PDP encountered bad RSVP objects or syntax 17= ERR_SERVICE : Service type was rejected 18= ERR_STYLE : Reservation Style was rejected 19= ERR_FL_SPEC : FlowSpec was rejected (too large)
0=が間違える、_インフォメーション: 1を報告する情報がERR_WARNと等しいです: 2が等しいと警告して、_未知で間違えてください: 未知の3=ERR_REJECTを推論してください: ジェネリック方針拒絶4=は間違えます。_は以下を超えています。 割当てかAccounting違反5がERR_PREEMPTと等しいです: 流れは先取りされた6=ERR_EXPIREDでした: 以前インストールされた方針は(リフレッシュされません)7=ERR_REPLACEDを吐き出しました: 前の方針データは取り替えられて、拒絶8=ERR_MERGEを引き起こされました: 方針は合併している(マルチキャスト)9=ERR_PDPであることができませんでした: PDPの下がっているか非機能している10はERR_SERVERと等しいです: 第3パーティServer(例えば、ケルベロス)の入手できない11はERR_PD_SYNTXと等しいです: POLICY_DATAオブジェクトは誤りのある構文12がERR_PD_INTGRとの等しさにします: POLICY_DATAオブジェクトはERR_PE_Integrity Check13=BADに失敗しました: POLICY_ELEMENTオブジェクトには、誤りのある構文14=ERR_PD_さんがいます: _義務的なPE Missing(空のPEがPDオブジェクトにある)15=ERR_ノーRSC: 方針を扱うリソースのPEP Out。 16=が間違える、_RSVP: PDPは悪いRSVPオブジェクトに遭遇したか、または構文17はERR_SERVICEと等しいです: サービスタイプは拒絶された18=ERR_様式でした: 予約様式は拒絶された19=_ERR_フロリダSPECでした: FlowSpecは拒絶されました。(大き過ぎます)です。
Values between 2^15 and 2^16-1 can be used for site and/or vendor error values.
サイト、そして/または、ベンダー誤り値に2^15と2^16-1の間の値を使用できます。
Herzog Standards Track [Page 11] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[11ページ]。
Appendix B: INTEGRITY computation for POLICY_DATA objects
付録B: POLICY_DATAオブジェクトのためのINTEGRITY計算
Computation of the INTEGRITY option is based on the rules set forth in [MD5], with the following modifications:
INTEGRITYオプションの計算は[MD5]に以下の変更で詳しく説明された規則に基づいています:
Section 4.1:
セクション4.1:
Rather than computing digest for an RSVP message, a digest is computed for a POLICY_DATA object in the following manner:
RSVPメッセージのためにダイジェストを計算するよりむしろ、ダイジェストはPOLICY_DATAオブジェクトのために以下の方法で計算されます:
(1) The INTEGRITY object is inserted in the appropriate place in
the POLICY_DATA object, and its location in the message is
remembered for later use.
(1) INTEGRITYオブジェクトはPOLICY_DATAオブジェクトの適切な場所に挿入されます、そして、メッセージの位置は後の使用のために覚えていられます。
(2) The PDP, at its discretion, and based on destination PEP/PDP
or other criteria, selects an Authentication Key and the hash
algorithm to be used.
(2) 思慮深さにおける目的地PEP/PDPに基づいたPDPか他の評価基準が、Authentication Keyとハッシュアルゴリズムが使用されるのを選択します。
(3) A copy of RSVP SESSION object is temporarily appended to the
end of the PD object (for the computation purposes only,
without changing the length of the POLICY_DATA object). The
flags field of the SESSION object is set to 0. This
concatenation is considered as the message for which a digest
is to be computed.
(3) PDオブジェクト(POLICY_DATAオブジェクトの長さを変えることのない計算目的だけのための)の端まで一時RSVP SESSIONオブジェクトのコピーを追加します。 SESSIONオブジェクトの分野が0に設定される旗 この連結は計算されるダイジェストがことであるメッセージであるとみなされます。
(4) The rest of the steps in Section 4.1 ((4)..(9)) remain
unchanged when computed over the concatenated message.
(4) 連結されたメッセージに関して計算される場合、((4) セクション4.1..(9))における、ステップの残りは変わりがありません。
Note: When the computation is complete, the SESSION object is ignored and is not part of the POLICY_DATA object.
以下に注意してください。 計算が完全であるときに、SESSION目的は、無視されて、POLICY_DATAオブジェクトの一部ではありません。
Other Provisions:
他の条項:
The processing of a received POLICY_DATA object as well as a challenge-response INTEGRITY object inside a POLICY_DATA object is performed in the manner described in [MD5]. This processing is subject to the modified computation algorithm as described in the beginning of this appendix (for Section 4.1 of [MD5]).
POLICY_DATAオブジェクトの中のチャレンジレスポンスINTEGRITYオブジェクトと同様に容認されたPOLICY_DATAオブジェクトの処理は[MD5]で説明された方法で実行されます。 この処理はこの付録([MD5]のセクション4.1のための)の始めに説明されるように変更された計算アルゴリズムを受けることがあります。
Herzog Standards Track [Page 12] RFC 2750 RSVP Extensions for Policy Control January 2000
ハーツォグ規格は2000年1月に方針コントロールのためのRFC2750RSVP拡張子を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Herzog Standards Track [Page 13]
ハーツォグ標準化過程[13ページ]
一覧
スポンサーリンク
