RFC2748 日本語訳
2748 The COPS (Common Open Policy Service) Protocol. D. Durham, Ed.,J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000. (Format: TXT=90906 bytes) (Updated by RFC4261) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Durham, Ed.
Request for Comments: 2748 Intel
Category: Standards Track J. Boyle
Level 3
R. Cohen
Cisco
S. Herzog
IPHighway
R. Rajan
AT&T
A. Sastry
Cisco
January 2000
ワーキンググループD.ダラム、エドをネットワークでつないでください。コメントのために以下を要求してください。 2748年のインテルカテゴリ: 標準化過程J.ボイルレベル3 R.コーエンコクチマスS.ハーツォグIPHighway R.Rajan AT&T A.Sastryコクチマス2000年1月
The COPS (Common Open Policy Service) Protocol
巡査(一般的なオープンポリシーサービス)は議定書を作ります。
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。
Conventions used in this document
本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
Abstract
要約
This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
このドキュメントは、QoSシグナリングプロトコルの方針コントロールをサポートするために簡単なクライアント/サーバモデルについて説明します。 モデルは、方針サーバのメソッドに関する少しの仮定もしませんが、方針要求とのサーバの戻っている決定に基づいています。 モデルは、将来他の種類の方針クライアントをサポートすることができるように広げることができるように設計されています。 しかしながら、このドキュメントはノークレームを将来のタイプの方針を実施するための唯一のアプローチか都合のよいアプローチにします。
Durham, et al. Standards Track [Page 1] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[1ページ]。
Table Of Contents
目次
1. Introduction....................................................3 1.1 Basic Model....................................................4 2. The Protocol....................................................6 2.1 Common Header..................................................6 2.2 COPS Specific Object Formats...................................8 2.2.1 Handle Object (Handle).......................................9 2.2.2 Context Object (Context).....................................9 2.2.3 In-Interface Object (IN-Int)................................10 2.2.4 Out-Interface Object (OUT-Int)..............................11 2.2.5 Reason Object (Reason)......................................12 2.2.6 Decision Object (Decision)..................................12 2.2.7 LPDP Decision Object (LPDPDecision).........................14 2.2.8 Error Object (Error)........................................14 2.2.9 Client Specific Information Object (ClientSI)...............15 2.2.10 Keep-Alive Timer Object (KATimer)..........................15 2.2.11 PEP Identification Object (PEPID)..........................16 2.2.12 Report-Type Object (Report-Type)...........................16 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 2.2.14 Last PDP Address (LastPDPAddr).............................17 2.2.15 Accounting Timer Object (AcctTimer)........................17 2.2.16 Message Integrity Object (Integrity).......................18 2.3 Communication.................................................19 2.4 Client Handle Usage...........................................21 2.5 Synchronization Behavior......................................21 3. Message Content................................................22 3.1 Request (REQ) PEP -> PDP.....................................22 3.2 Decision (DEC) PDP -> PEP....................................24 3.3 Report State (RPT) PEP -> PDP................................25 3.4 Delete Request State (DRQ) PEP -> PDP........................25 3.5 Synchronize State Request (SSQ) PDP -> PEP...................26 3.6 Client-Open (OPN) PEP -> PDP.................................26 3.7 Client-Accept (CAT) PDP -> PEP...............................27 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................28 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................28 3.10 Synchronize State Complete (SSC) PEP -> PDP..................29 4. Common Operation...............................................29 4.1 Security and Sequence Number Negotiation......................29 4.2 Key Maintenance...............................................31 4.3 PEP Initialization............................................31 4.4 Outsourcing Operations........................................32 4.5 Configuration Operations......................................32 4.6 Keep-Alive Operations.........................................33 4.7 PEP/PDP Close.................................................33 5. Security Considerations........................................33 6. IANA Considerations............................................34
1. 序論…3 1.1基本型…4 2. プロトコル…6 2.1の一般的なヘッダー…6 2.2 特定のオブジェクト形式を獲得します…8 2.2 .1 オブジェクト(ハンドル)を扱ってください…9 2.2 .2 文脈オブジェクト(文脈)…9 2.2 .3 インタフェースでは、反対してください(Intで)…10 2.2 .4 インタフェースから、反対してください(出ているInt)…11 2.2 .5 オブジェクト(理由)を推論してください…12 2.2 .6 決定オブジェクト(決定)…12 2.2 .7 LPDP決定オブジェクト(LPDPDecision)…14 2.2 .8 誤りオブジェクト(誤り)…14 2.2 .9 クライアント特殊情報オブジェクト(ClientSI)…15 2.2 .10 タイマオブジェクト(KATimer)を生かしてください…15 2.2 .11 識別オブジェクト(PEPID)を元気づけてください…16 2.2 .12 レポートタイプは反対します(レポートタイプ)…16 2.2 .13 PDPはアドレス(PDPRedirAddr)を転送します…16 2.2 .14 最後に、PDPは(LastPDPAddr)を扱います…17 2.2 .15 タイマを説明して、反対してください(AcctTimer)…17 2.2 .16 メッセージの保全オブジェクト(保全)…18 2.3コミュニケーション…19 2.4 クライアントハンドル用法…21 2.5 同期の振舞い…21 3. メッセージ内容…22 3.1 (REQ)気力->PDPを要求してください…22 3.2 決定(12月)PDP->は元気づけます…24 3.3 レポート州の(RPT)は->PDPを元気づけます…25 3.4 要求州(DRQ)の気力->PDPを削除してください…25 3.5 州の要求(SSQ)PDP->気力を同期させてください…26 3.6 オープンなクライアント(OPN)は->PDPを元気づけます…26 3.7 (猫)PDP->気力をクライアントと同じくらい受け入れてください…27 3.8 クライアント近い(CC)気力->PDP、PDP->気力…28 3.9 (ka)気力->PDP、PDP->気力を生かしてください…28 3.10 州の完全な(SSC)気力->PDPを連動させてください…29 4. 一般的な操作…29 4.1 セキュリティと一連番号交渉…29 4.2 主要なメインテナンス…31 4.3 初期設定を元気づけてください…31 4.4 アウトソーシング操作…32 4.5 構成操作…32 4.6 操作を生かしてください…33 4.7 気力/PDPは閉じます…33 5. セキュリティ問題…33 6. IANA問題…34
Durham, et al. Standards Track [Page 2] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[2ページ]。
7. References.....................................................35 8. Author Information and Acknowledgments.........................36 9. Full Copyright Statement.......................................38
7. 参照…35 8. 情報と承認を書いてください…36 9. 完全な著作権宣言文…38
1. Introduction
1. 序論
This document describes a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). One example of a policy client is an RSVP router that must exercise policy-based admission control over RSVP usage [RSVP]. We assume that at least one policy server exists in each controlled administrative domain. The basic model of interaction between a policy server and its clients is compatible with the framework document for policy based admission control [WRK].
このドキュメントは方針サーバ(方針Decision PointかPDP)とそのクライアント(方針Enforcement PointsかPEPs)の間の為替政策情報に使用できる簡単な質問と応答プロトコルについて説明します。 方針クライアントの1つの例がRSVP用法[RSVP]に方針ベースの入場コントロールを及ぼさなければならないRSVPルータです。 私たちは、少なくとも1つの方針サーバがそれぞれの制御管理ドメインに存在すると思います。 方針サーバとそのクライアントとの相互作用の基本型は方針のベースの入場コントロール[WRK]のためのフレームワークドキュメントと互換性があります。
A chief objective of this policy control protocol is to begin with a simple but extensible design. The main characteristics of the COPS protocol include:
初めに、この方針制御プロトコルのチーフ目的はそうです。簡単な、しかし、広げることができるデザイン。 COPSプロトコルの主な特性は:
1. The protocol employs a client/server model where the PEP sends
requests, updates, and deletes to the remote PDP and the PDP
returns decisions back to the PEP.
1. プロトコルは、PEPが要求、アップデートを送るクライアント/サーバモデルを雇って、リモートPDPとPDPリターンにPEPとの決定を削除します。
2. The protocol uses TCP as its transport protocol for reliable
exchange of messages between policy clients and a server.
Therefore, no additional mechanisms are necessary for reliable
communication between a server and its clients.
2. プロトコルは方針クライアントとサーバの間のメッセージの信頼できる交換にトランスポート・プロトコルとしてTCPを使用します。したがって、どんな追加メカニズムもサーバとそのクライアントとの信頼できるコミュニケーションに必要ではありません。
3. The protocol is extensible in that it is designed to leverage
off self-identifying objects and can support diverse client
specific information without requiring modifications to the
COPS protocol itself. The protocol was created for the general
administration, configuration, and enforcement of policies.
3. 自己を特定するオブジェクトで力を入れるように設計されていて、COPSプロトコル自体への変更を必要としないでさまざまのクライアント特殊情報をサポートすることができるので、プロトコルは広げることができます。 プロトコルは方針の一般管理、構成、および実施のために作成されました。
4. COPS provides message level security for authentication, replay
protection, and message integrity. COPS can also reuse existing
protocols for security such as IPSEC [IPSEC] or TLS to
authenticate and secure the channel between the PEP and the
PDP.
4. COPSはメッセージレベルセキュリティを認証、反復操作による保護、およびメッセージの保全に提供します。 また、IPSECなどのセキュリティ[IPSEC]かTLSがPEPとPDPの間のチャンネルを認証して、固定するように、COPSは既存のプロトコルを再利用できます。
5. The protocol is stateful in two main aspects: (1)
Request/Decision state is shared between client and server and
(2) State from various events (Request/Decision pairs) may be
inter-associated. By (1) we mean that requests from the client
PEP are installed or remembered by the remote PDP until they
are explicitly deleted by the PEP. At the same time, Decisions
from the remote PDP can be generated asynchronously at any time
5. プロトコルは2つの主な局面でstatefulです: (1) (2) 要求/決定状態はクライアントとサーバの間で共有されます、そして、様々なイベント(要求/決定組)からの状態は相互関連しているかもしれません。 (1)で、私たちは、それらがPEPによって明らかに削除されるまで、クライアントPEPからの要求がリモートPDPによってインストールされるか、または覚えていられると言っています。 同時に、いつでも、リモートPDPからのDecisionsを非同期に生成することができます。
Durham, et al. Standards Track [Page 3] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[3ページ]。
for a currently installed request state. By (2) we mean that
the server may respond to new queries differently because of
previously installed Request/Decision state(s) that are
related.
現在インストールされた要求状態に。 (2)で、私たちは、サーバが関係づけられる以前にインストールされたRequest/決定状態のために新しい質問に異なって反応するかもしれないと言っています。
6. Additionally, the protocol is stateful in that it allows the
server to push configuration information to the client, and
then allows the server to remove such state from the client
when it is no longer applicable.
6. さらに、プロトコルは、サーバがそれでクライアントに設定情報を押すことができるのでstatefulで、それがもう適切でないときに、次に、サーバがクライアントからそのような状態を取り除くのを許容します。
1.1 Basic Model
1.1 基本型
+----------------+
| |
| Network Node | Policy Server
| |
| +-----+ | COPS +-----+
| | PEP |<-----|-------------->| PDP |
| +-----+ | +-----+
| ^ |
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
+----------------+ | | | ネットワーク・ノード| 方針サーバ| | | +-----+ | 巡査+-----+ | | 気力| <、-、-、-、--、|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| PDP| | +-----+ | +-----+ | ^ | | | | | \-->+-----+ | | | LPDP| | | +-----+ | | | +----------------+
Figure 1: A COPS illustration.
図1: COPSイラスト。
Figure 1 Illustrates the layout of various policy components in a typical COPS example (taken from [WRK]). Here, COPS is used to communicate policy information between a Policy Enforcement Point (PEP) and a remote Policy Decision Point (PDP) within the context of a particular type of client. The optional Local Policy Decision Point (LPDP) can be used by the device to make local policy decisions in the absence of a PDP.
図1 Illustrates、典型的なCOPSの例([WRK]から、取る)における、様々な方針コンポーネントのレイアウト。 ここで、COPSは、特定のタイプのクライアントの文脈の中でPolicy Enforcement Point(PEP)とリモートPolicy Decision Point(PDP)の間の方針情報を伝えるのに使用されます。 任意のLocal Policy Decision Point(LPDP)はデバイスによって使用されて、PDPが不在のときローカルの政策決定をすることができます。
It is assumed that each participating policy client is functionally consistent with a PEP [WRK]. The PEP may communicate with a policy server (herein referred to as a remote PDP [WRK]) to obtain policy decisions or directives.
それぞれの配当付き保険証券クライアントがPEP[WRK]と機能上一致していると思われます。 PEPは、政策決定か指示を得るために方針サーバ(ここにリモートPDP[WRK]と呼ばれる)とコミュニケートするかもしれません。
The PEP is responsible for initiating a persistent TCP connection to a PDP. The PEP uses this TCP connection to send requests to and receive decisions from the remote PDP. Communication between the PEP and remote PDP is mainly in the form of a stateful request/decision exchange, though the remote PDP may occasionally send unsolicited
PEPは永続的なTCP接続をPDPに開始するのに責任があります。 PEPは、リモートPDPから要求を送って、決定を受けるのにこのTCP接続を使用します。 PEPとリモートPDPとのコミュニケーションが主にstateful要求/決定交換の形にあります、リモートPDPが時折発信するかもしれませんが求められていませんさ
Durham, et al. Standards Track [Page 4] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[4ページ]。
decisions to the PEP to force changes in previously approved request states. The PEP also has the capacity to report to the remote PDP that it has successfully completed performing the PDP's decision locally, useful for accounting and monitoring purposes. The PEP is responsible for notifying the PDP when a request state has changed on the PEP. Finally, the PEP is responsible for the deletion of any state that is no longer applicable due to events at the client or decisions issued by the server.
以前ににおける力の変化に承認されたPEPとの決定は州を要求します。 また、PEPには、局所的にPDPの決定を実行するのを首尾よく完成したとリモートPDPに報告する容量があります、会計とモニターしている目的の役に立ちます。 PEPは要求状態がPEPで変化したときPDPに通知するのに責任があります。 最終的に、PEPはどんなサーバによって発行されたクライアントか決定のときにイベントのためにもう適切でない状態の削除にも責任があります。
When the PEP sends a configuration request, it expects the PDP to continuously send named units of configuration data to the PEP via decision messages as applicable for the configuration request. When a unit of named configuration data is successfully installed on the PEP, the PEP should send a report message to the PDP confirming the installation. The server may then update or remove the named configuration information via a new decision message. When the PDP sends a decision to remove named configuration data from the PEP, the PEP will delete the specified configuration and send a report message to the PDP as confirmation.
PEPが構成要求を送るとき、それは、PDPが構成要求に適切であるとしての決定メッセージで命名されたユニットのコンフィギュレーション・データを絶え間なくPEPに送ると予想します。 命名されたコンフィギュレーション・データのユニットが首尾よくPEPの上にインストールされるとき、PEPはインストールを確認するPDPにレポートメッセージを送るはずです。 そして、サーバは、新しい決定メッセージで命名された設定情報をアップデートするか、または取り除くかもしれません。 PDPがPEPから命名されたコンフィギュレーション・データを取り除くという決定を送るとき、PEPは確認として指定された構成を削除して、レポートメッセージをPDPに送るでしょう。
The policy protocol is designed to communicate self-identifying objects which contain the data necessary for identifying request states, establishing the context for a request, identifying the type of request, referencing previously installed requests, relaying policy decisions, reporting errors, providing message integrity, and transferring client specific/namespace information.
方針プロトコルは要求州を特定するのに必要なデータを含む自己を特定するオブジェクトを伝えるように設計されています、要求のための文脈を確立して、要求のタイプを特定して、以前にインストールされた要求に参照をつけて、政策決定をリレーして、誤りを報告して、メッセージの保全を提供して、クライアント特定の/名前空間情報を移して。
To distinguish between different kinds of clients, the type of client is identified in each message. Different types of clients may have different client specific data and may require different kinds of policy decisions. It is expected that each new client-type will have a corresponding usage draft specifying the specifics of its interaction with this policy protocol.
異種のクライアントを見分けるために、クライアントのタイプは各メッセージで特定されます。 異なったタイプのクライアントは、異なったクライアント特定のデータを持って、異種の政策決定を必要とするかもしれません。 それぞれの新しいクライアントタイプが対応する用法草稿にこの方針プロトコルとの相互作用の詳細を指定させると予想されます。
The context of each request corresponds to the type of event that triggered it. The COPS Context object identifies the type of request and message (if applicable) that triggered a policy event via its message type and request type fields. COPS identifies three types of outsourcing events: (1) the arrival of an incoming message (2) allocation of local resources, and (3) the forwarding of an outgoing message. Each of these events may require different decisions to be made. The content of a COPS request/decision message depends on the context. A fourth type of request is useful for types of clients that wish to receive configuration information from the PDP. This allows a PEP to issue a configuration request for a specific named device or module that requires configuration information to be installed.
それぞれの要求の文脈はそれの引き金となったイベントのタイプに文通されます。 COPS Contextオブジェクトはメッセージタイプで方針イベントの引き金となって、タイプ分野を要求する要求とメッセージ(適切であるなら)のタイプを特定します。 COPSは3つのタイプのアウトソーシングイベントを特定します: (1) (3) ローカル資源の入力メッセージ(2)配分の到着、および送信されるメッセージの推進。 それぞれのこれらのイベントは作られているという異なった決定を必要とするかもしれません。 COPS要求/決定メッセージの内容は文脈によります。 4番目のタイプの要求はPDPから設定情報を受け取りたがっているクライアントのタイプの役に立ちます。 これで、PEPは設定情報がインストールされるのを必要とする特定の命名されたデバイスかモジュールを求める構成要求を出すことができます。
Durham, et al. Standards Track [Page 5] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[5ページ]。
The PEP may also have the capability to make a local policy decision via its Local Policy Decision Point (LPDP) [WRK], however, the PDP remains the authoritative decision point at all times. This means that the relevant local decision information must be relayed to the PDP. That is, the PDP must be granted access to all relevant information to make a final policy decision. To facilitate this functionality, the PEP must send its local decision information to the remote PDP via an LPDP decision object. The PEP must then abide by the PDP's decision as it is absolute.
また、PEPには、Local Policy Decision Pointを通したローカルの政策決定(LPDP)を[WRK]にする能力があるかもしれなくて、しかしながら、PDPはいつも正式の決定ポイントのままで残っています。 これは、関連ローカルの決定情報をPDPにリレーしなければならないことを意味します。 最終的な政策決定をするようにすべての関連情報へのアクセスをすなわち、PDPに承諾しなければなりません。 この機能性を容易にするために、PEPはLPDP決定オブジェクトを通してローカルの決定情報をリモートPDPに送らなければなりません。 そして、それが絶対ので、PEPはPDPの決定を守らなければなりません。
Finally, fault tolerance is a required capability for this protocol, particularly due to the fact it is associated with the security and service management of distributed network devices. Fault tolerance can be achieved by having both the PEP and remote PDP constantly verify their connection to each other via keep-alive messages. When a failure is detected, the PEP must try to reconnect to the remote PDP or attempt to connect to a backup/alternative PDP. While disconnected, the PEP should revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any deleted state or new events that passed local admission control after the connection was lost. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued). After failure and before the new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some limited amount of time. Sections 2.3 and 2.5 detail COPS mechanisms for achieving reliability.
最終的に、耐障害性はこのプロトコルのための必要な能力です、それが分配されたネットワークデバイスのセキュリティとサービス管理に関連しているという特に事実のため。 PEPとリモートPDPの両方に生きている生活費メッセージで彼らの接続について絶えず互いに確かめさせることによって、耐障害性を達成できます。 失敗が検出されるとき、PEPはバックアップ/代替手段PDPに接続するリモートPDPか試みに再接続しようとしなければなりません。 切断されている間、PEPはローカルの決定をするのに戻るはずです。 接続がいったん回復すると、PEPが接続が迷子になった後に地方の入場コントロールを通過したどんな削除された州や新しいイベントについてもPDPに通知すると予想されます。 さらに、リモートPDPは、PEPの内部の状態が再連動するよう要求するかもしれません(すべての以前にインストールされた要求は再発行されることです)。 失敗の後と新しい接続が機能的に完全になる前に、PEPが、以前にコミュニケートしている決定をキャッシュして、いつかの限られた時間それらを使用し続けているなら、サービスの分裂を最小にすることができます。 セクション2.3と2.5は、信頼性を獲得するためにCOPSメカニズムについて詳述します。
2. The Protocol
2. プロトコル
This section describes the message formats and objects exchanged between the PEP and remote PDP.
このセクションはPEPとリモートPDPの間で交換されたメッセージ・フォーマットとオブジェクトについて説明します。
2.1 Common Header
2.1 一般的なヘッダー
Each COPS message consists of the COPS header followed by a number of typed objects.
それぞれのCOPSメッセージは多くのタイプされたオブジェクトが支えたCOPSヘッダーから成ります。
0 1 2 3
+--------------+--------------+--------------+--------------+
|Version| Flags| Op Code | Client-type |
+--------------+--------------+--------------+--------------+
| Message Length |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ |バージョン| 旗| オペコード| クライアントタイプ| +--------------+--------------+--------------+--------------+ | メッセージ長| +--------------+--------------+--------------+--------------+
Global note: //// implies field is reserved, set to 0.
グローバルな注意: 0に設定されて、////は、分野が予約されているのを含意します。
Durham, et al. Standards Track [Page 6] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[6ページ]。
The fields in the header are:
Version: 4 bits
COPS version number. Current version is 1.
ヘッダーの分野は以下の通りです。 バージョン: 4ビットのCOPSバージョン番号。 最新版は1です。
Flags: 4 bits
Defined flag values (all other flags MUST be set to 0):
0x1 Solicited Message Flag Bit
This flag is set when the message is solicited by
another COPS message. This flag is NOT to be set
(value=0) unless otherwise specified in section 3.
旗: 4ビットのDefinedは値に旗を揚げさせます(他のすべての旗を0に設定しなければなりません): メッセージが別のCOPSメッセージによって請求されるとき、0×1の請求されたMessage Flag Bit This旗は設定されます。 別の方法でセクション3で指定されない場合、設定される(値の=0)ために、この旗はありません。
Op Code: 8 bits
The COPS operations:
1 = Request (REQ)
2 = Decision (DEC)
3 = Report State (RPT)
4 = Delete Request State (DRQ)
5 = Synchronize State Req (SSQ)
6 = Client-Open (OPN)
7 = Client-Accept (CAT)
8 = Client-Close (CC)
9 = Keep-Alive (KA)
10= Synchronize Complete (SSC)
オペコード: 8ビット、COPS操作: 1 (RPT)4=が削除する=レポート州が=が連動させる(DRQ)5が、クライアント近い(CC)9クライアントと同じくらい受け入れているオープンなクライアントReq(SSQ)6=(OPN)7=(猫)8==が(ka)10=を生かすと述べると述べるよう要求する3が完全な状態で同期するという=要求(REQ)2=決定(12月)(SSC)
Client-type: 16 bits
クライアントタイプ: 16ビット
The Client-type identifies the policy client. Interpretation of
all encapsulated objects is relative to the client-type. Client-
types that set the most significant bit in the client-type field
are enterprise specific (these are client-types 0x8000 -
0xFFFF). (See the specific client usage documents for particular
client-type IDs). For KA Messages, the client-type in the header
MUST always be set to 0 as the KA is used for connection
verification (not per client session verification).
Client-タイプは方針クライアントを特定します。 すべてのカプセル化オブジェクトの解釈はクライアントタイプに比例しています。 クライアントタイプ分野に最も重要なビットをはめ込むクライアントタイプは企業特有です。(これらはクライアントタイプ0×8000です--0xFFFF。) (特定のクライアントタイプIDのための特定のクライアント用法ドキュメントを見ます。) KA Messagesにおいて、KAが接続検証(クライアントセッション検証でないのあたりの)に使用されて、ヘッダーというクライアントタイプは0にいつも用意ができなければなりません。
Message Length: 32 bits
Size of message in octets, which includes the standard COPS
header and all encapsulated objects. Messages MUST be aligned on
4 octet intervals.
メッセージ長: 八重奏におけるメッセージの32ビットのSize、どれが標準のCOPSヘッダーを含むか、そして、およびすべてがオブジェクトをカプセルに入れりました。 4回の八重奏間隔にメッセージを並べなければなりません。
Durham, et al. Standards Track [Page 7] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[7ページ]。
2.2 COPS Specific Object Formats
2.2 特定のオブジェクトがフォーマットする巡査
All the objects follow the same object format; each object consists of one or more 32-bit words with a four-octet header, using the following format:
すべてのオブジェクトが同じオブジェクト形式に続きます。 以下の形式を使用して、各オブジェクトは4八重奏のヘッダーと共に1つ以上の32ビットの単語から成ります:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (octets) | C-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Object contents) //
| |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | 長さ(八重奏)| C-ヌム| C-タイプ| +-------------+-------------+-------------+-------------+ | | //(オブジェクトコンテンツ)//| | +-------------+-------------+-------------+-------------+
The length is a two-octet value that describes the number of octets (including the header) that compose the object. If the length in octets does not fall on a 32-bit word boundary, padding MUST be added to the end of the object so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. On the receiving side, a subsequent object boundary can be found by simply rounding up the previous stated object length to the next 32-bit boundary.
長さはオブジェクトを構成する八重奏(ヘッダーを含んでいる)の数について説明する2八重奏の値です。 八重奏における長さが32ビットの語境界の責任とならないなら、オブジェクトの端に詰め物を加えなければならないので、オブジェクトをワイヤに送ることができる前に、次の32ビットの境界にそれを並べます。 受信側では、単に一斉逮捕で前の述べられたオブジェクトの長さに次の32ビットの境界にその後のオブジェクト境界を見つけることができます。
Typically, C-Num identifies the class of information contained in the object, and the C-Type identifies the subtype or version of the information contained in the object.
通常、C-ヌムはオブジェクトに含まれた情報のクラスを特定します、そして、C-タイプはオブジェクトに含まれた情報の「副-タイプ」かバージョンを特定します。
C-num: 8 bits
1 = Handle
2 = Context
3 = In Interface
4 = Out Interface
5 = Reason code
6 = Decision
7 = LPDP Decision
8 = Error
9 = Client Specific Info
10 = Keep-Alive Timer
11 = PEP Identification
12 = Report Type
13 = PDP Redirect Address
14 = Last PDP Address
15 = Accounting Timer
16 = Message Integrity
C-num: 出ているInterface4の文脈3 8ビットの1本の=ハンドル2===Interface5は会計最後のレポート生きている生活費クライアントコード6=決定7=LPDP Decision8=誤り9=Specific Info10=Timer11=PEP Identification12=Type13=PDP Redirect Address14=PDP Address15=Timer16がメッセージIntegrityと等しい理由と等しいです。
C-type: 8 bits
Values defined per C-num.
C-タイプ: C-num単位で定義された8ビットのValues。
Durham, et al. Standards Track [Page 8] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[8ページ]。
2.2.1 Handle Object (Handle)
2.2.1 オブジェクトを扱ってください。(ハンドル)
The Handle Object encapsulates a unique value that identifies an installed state. This identification is used by most COPS operations. A state corresponding to a handle MUST be explicitly deleted when it is no longer applicable. See Section 2.4 for details.
Handle Objectはインストールされた状態を特定するユニークな値をカプセル化します。 この識別はほとんどのCOPS操作で使用されます。 それがもう適切でないときに、明らかにハンドルに対応する状態を削除しなければなりません。 詳細に関してセクション2.4を見てください。
C-Num = 1
C-ヌム=1
C-Type = 1, Client Handle.
C-タイプは1、クライアントハンドルと等しいです。
Variable-length field, no implied format other than it is unique from other client handles from the same PEP (a.k.a. COPS TCP connection) for a particular client-type. It is always initially chosen by the PEP and then deleted by the PEP when no longer applicable. The client handle is used to refer to a request state initiated by a particular PEP and installed at the PDP for a client-type. A PEP will specify a client handle in its Request messages, Report messages and Delete messages sent to the PDP. In all cases, the client handle is used to uniquely identify a particular PEP's request for a client-type.
可変長の分野、特定のクライアントタイプには、それ以外のどんな暗示している形式も同じPEP(通称COPS TCP接続)からの他のクライアントハンドルからユニークではありません。 もう適切でないときに、それは、初めは、いつもPEPによって選ばれていて、次に、PEPによって削除されます。 クライアントハンドルは、クライアントタイプのために特定のPEPによって開始されて、PDPにインストールされた要求状態について言及するのに使用されます。 PEPはPDPに送られたRequestメッセージ、Reportメッセージ、およびDeleteメッセージでクライアントハンドルを指定するでしょう。 すべての場合では、クライアントハンドルは、唯一クライアントタイプを求める特定のPEPの要求を特定するのに使用されます。
The client handle value is set by the PEP and is opaque to the PDP. The PDP simply performs a byte-wise comparison on the value in this object with respect to the handle object values of other currently installed requests.
クライアントハンドル価値は、PEPによって設定されて、PDPに不透明です。 PDPはこのオブジェクトで他の現在インストールされた要求のハンドルオブジェクト値に関して単にバイト的な比較を値に実行します。
2.2.2 Context Object (Context)
2.2.2 文脈オブジェクト(文脈)
Specifies the type of event(s) that triggered the query. Required for request messages. Admission control, resource allocation, and forwarding requests are all amenable to client-types that outsource their decision making facility to the PDP. For applicable client- types a PEP can also make a request to receive named configuration information from the PDP. This named configuration data may be in a form useful for setting system attributes on a PEP, or it may be in the form of policy rules that are to be directly verified by the PEP.
質問の引き金となったイベントのタイプを指定します。 要求メッセージのために、必要です。 彼らの意志決定施設をPDPに社外調達するクライアントタイプには、入場コントロール、資源配分、および推進要求はすべて従順です。 また、適切なクライアントタイプのために、PEPはPDPから命名された設定情報を受け取るという要求をすることができます。 コンフィギュレーション・データというこれがPEPにシステム属性を設定することの役に立つフォームにあるかもしれませんか、またはそれはPEPによって直接確かめられることになっている政策ルールの形にあるかもしれません。
Multiple flags can be set for the same request. This is only allowed, however, if the set of client specific information in the combined request is identical to the client specific information that would be specified if individual requests were made for each specified flag.
同じ要求に複数の旗を設定できます。 しかしながら、結合した要求におけるクライアント特殊情報のセットがそれぞれの指定された旗のために個々の要求をするなら指定するクライアント特殊情報と同じである場合にだけ、これは許容されています。
C-num = 2, C-Type = 1
C-numは2、C-タイプ=1と等しいです。
Durham, et al. Standards Track [Page 9] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[9ページ]。
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | R-タイプ| Mタイプ| +--------------+--------------+--------------+--------------+
R-Type (Request Type Flag)
R-タイプ(要求タイプ旗)
0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request
0x04 = Outgoing-Message request
0x08 = Configuration request
0×01 = 入って来るメッセージ/入場Controlは0×02=リソース配分要求0×04=送信するメッセージ要求0x08=構成要求を要求します。
M-Type (Message Type)
Mタイプ(メッセージタイプ)
Client Specific 16 bit values of protocol message types
クライアントSpecific16はプロトコルメッセージタイプの値に噛み付きました。
2.2.3 In-Interface Object (IN-Int)
2.2.3 インタフェースのオブジェクト(Int)です。
The In-Interface Object is used to identify the incoming interface on which a particular request applies and the address where the received message originated. For flows or messages generated from the PEP's local host, the loop back address and ifindex are used.
In-インタフェースObjectは、特定の要求が適用される入って来るインタフェースと受信されたメッセージが起因したアドレスを特定するのに使用されます。 PEPのローカル・ホストから生成された流れかメッセージに関しては、ループバックのアドレスとifindexは使用されています。
This Interface object is also used to identify the incoming (receiving) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
また、このInterfaceオブジェクトもifindexを通して(受信)入って来るインタフェースを特定するのにおいて使用されています。 ifindexは、サブインタフェースと無数のインタフェースを区別するのに使用されるかもしれません(例に関してRSVPのLIHを見てください)。 SNMPがPEPによってサポートされるとき、このifindex整数はSNMP MIB-IIインタフェース割り出しテーブルのインタフェースへの同じ整数値に対応しなければなりません。
Note: The ifindex specified in the In-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the interface on which the protocol message was received.
以下に注意してください。 In-インタフェースで指定されたifindexは通常基本的なプロトコルメッセージの流れに比例しています。 ifindexはプロトコルメッセージが受け取られたインタフェースです。
C-Num = 3
C-ヌム=3
C-Type = 1, IPv4 Address + Interface
C-タイプは1、IPv4アドレス+インタフェースと等しいです。
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | IPv4 Address形式| +--------------+--------------+--------------+--------------+ | ifindex| +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv4 address specifies the IP address that the incoming message came from.
For this type of the interface object, the IPv4 address specifies the IP address that the incoming message came from.
Durham, et al. Standards Track [Page 10] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 10] RFC 2748 COPS January 2000
C-Type = 2, IPv6 Address + Interface
C-Type = 2, IPv6 Address + Interface
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ifindex |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | | + + | | + IPv6 Address format + | | + + | | +--------------+--------------+--------------+--------------+ | ifindex | +--------------+--------------+--------------+--------------+
For this type of the interface object, the IPv6 address specifies the IP address that the incoming message came from. The ifindex is used to refer to the MIB-II defined local incoming interface on the PEP as described above.
For this type of the interface object, the IPv6 address specifies the IP address that the incoming message came from. The ifindex is used to refer to the MIB-II defined local incoming interface on the PEP as described above.
2.2.4 Out-Interface Object (OUT-Int)
2.2.4 Out-Interface Object (OUT-Int)
The Out-Interface is used to identify the outgoing interface to which a specific request applies and the address for where the forwarded message is to be sent. For flows or messages destined to the PEP's local host, the loop back address and ifindex are used. The Out- Interface has the same formats as the In-Interface Object.
The Out-Interface is used to identify the outgoing interface to which a specific request applies and the address for where the forwarded message is to be sent. For flows or messages destined to the PEP's local host, the loop back address and ifindex are used. The Out- Interface has the same formats as the In-Interface Object.
This Interface object is also used to identify the outgoing (forwarding) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
This Interface object is also used to identify the outgoing (forwarding) interface via its ifindex. The ifindex may be used to differentiate between sub-interfaces and unnumbered interfaces (see RSVP's LIH for an example). When SNMP is supported by the PEP, this ifindex integer MUST correspond to the same integer value for the interface in the SNMP MIB-II interface index table.
Note: The ifindex specified in the Out-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the one on which a protocol message is about to be forwarded.
Note: The ifindex specified in the Out-Interface is typically relative to the flow of the underlying protocol messages. The ifindex is the one on which a protocol message is about to be forwarded.
C-Num = 4
C-Num = 4
C-Type = 1, IPv4 Address + Interface
C-Type = 1, IPv4 Address + Interface
Same C-Type format as the In-Interface object. The IPv4 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
Same C-Type format as the In-Interface object. The IPv4 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
Durham, et al. Standards Track [Page 11] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 11] RFC 2748 COPS January 2000
C-Type = 2, IPv6 Address + Interface
C-Type = 2, IPv6 Address + Interface
Same C-Type format as the In-Interface object. For this type of the interface object, the IPv6 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
Same C-Type format as the In-Interface object. For this type of the interface object, the IPv6 address specifies the IP address to which the outgoing message is going. The ifindex is used to refer to the MIB-II defined local outgoing interface on the PEP.
2.2.5 Reason Object (Reason)
2.2.5 Reason Object (Reason)
This object specifies the reason why the request state was deleted. It appears in the delete request (DRQ) message. The Reason Sub-code field is reserved for more detailed client-specific reason codes defined in the corresponding documents.
This object specifies the reason why the request state was deleted. It appears in the delete request (DRQ) message. The Reason Sub-code field is reserved for more detailed client-specific reason codes defined in the corresponding documents.
C-Num = 5, C-Type = 1
C-Num = 5, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Reason-Code | Reason Sub-code |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | Reason-Code | Reason Sub-code | +--------------+--------------+--------------+--------------+
Reason Code:
1 = Unspecified
2 = Management
3 = Preempted (Another request state takes precedence)
4 = Tear (Used to communicate a signaled state removal)
5 = Timeout (Local state has timed-out)
6 = Route Change (Change invalidates request state)
7 = Insufficient Resources (No local resource available)
8 = PDP's Directive (PDP decision caused the delete)
9 = Unsupported decision (PDP decision not supported)
10= Synchronize Handle Unknown
11= Transient Handle (stateless event)
12= Malformed Decision (could not recover)
13= Unknown COPS Object from PDP:
Sub-code (octet 2) contains unknown object's C-Num
and (octet 3) contains unknown object's C-Type.
Reason Code: 1 = Unspecified 2 = Management 3 = Preempted (Another request state takes precedence) 4 = Tear (Used to communicate a signaled state removal) 5 = Timeout (Local state has timed-out) 6 = Route Change (Change invalidates request state) 7 = Insufficient Resources (No local resource available) 8 = PDP's Directive (PDP decision caused the delete) 9 = Unsupported decision (PDP decision not supported) 10= Synchronize Handle Unknown 11= Transient Handle (stateless event) 12= Malformed Decision (could not recover) 13= Unknown COPS Object from PDP: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type.
2.2.6 Decision Object (Decision)
2.2.6 Decision Object (Decision)
Decision made by the PDP. Appears in replies. The specific non- mandatory decision objects required in a decision to a particular request depend on the type of client.
Decision made by the PDP. Appears in replies. The specific non- mandatory decision objects required in a decision to a particular request depend on the type of client.
Durham, et al. Standards Track [Page 12] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 12] RFC 2748 COPS January 2000
C-Num = 6
C-Type = 1, Decision Flags (Mandatory)
C-Num = 6 C-Type = 1, Decision Flags (Mandatory)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Command-Code | Flags |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | Command-Code | Flags | +--------------+--------------+--------------+--------------+
Commands:
0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration)
2 = Remove (Remove request/Remove configuration)
Commands: 0 = NULL Decision (No configuration data available) 1 = Install (Admit request/Install configuration) 2 = Remove (Remove request/Remove configuration)
Flags:
0x01 = Trigger Error (Trigger error message if set)
Note: Trigger Error is applicable to client-types that
are capable of sending error notifications for signaled
messages.
Flags: 0x01 = Trigger Error (Trigger error message if set) Note: Trigger Error is applicable to client-types that are capable of sending error notifications for signaled messages.
Flag values not applicable to a given context's R-Type or
client-type MUST be ignored by the PEP.
Flag values not applicable to a given context's R-Type or client-type MUST be ignored by the PEP.
C-Type = 2, Stateless Data
C-Type = 2, Stateless Data
This type of decision object carries additional stateless
information that can be applied by the PEP locally. It is a
variable length object and its internal format SHOULD be
specified in the relevant COPS extension document for the given
client-type. This object is optional in Decision messages and is
interpreted relative to a given context.
This type of decision object carries additional stateless information that can be applied by the PEP locally. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. This object is optional in Decision messages and is interpreted relative to a given context.
It is expected that even outsourcing PEPs will be able to make
some simple stateless policy decisions locally in their LPDP. As
this set is well known and implemented ubiquitously, PDPs are
aware of it as well (either universally, through configuration,
or using the Client-Open message). The PDP may also include this
information in its decision, and the PEP MUST apply it to the
resource allocation event that generated the request.
It is expected that even outsourcing PEPs will be able to make some simple stateless policy decisions locally in their LPDP. As this set is well known and implemented ubiquitously, PDPs are aware of it as well (either universally, through configuration, or using the Client-Open message). The PDP may also include this information in its decision, and the PEP MUST apply it to the resource allocation event that generated the request.
C-Type = 3, Replacement Data
C-Type = 3, Replacement Data
This type of decision object carries replacement data that is to
replace existing data in a signaled message. It is a variable
length object and its internal format SHOULD be specified in the
relevant COPS extension document for the given client-type. It is
optional in Decision messages and is interpreted relative to a
given context.
This type of decision object carries replacement data that is to replace existing data in a signaled message. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
Durham, et al. Standards Track [Page 13] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 13] RFC 2748 COPS January 2000
C-Type = 4, Client Specific Decision Data
C-Type = 4, Client Specific Decision Data
Additional decision types can be introduced using the Client
Specific Decision Data Object. It is a variable length object and
its internal format SHOULD be specified in the relevant COPS
extension document for the given client-type. It is optional in
Decision messages and is interpreted relative to a given context.
Additional decision types can be introduced using the Client Specific Decision Data Object. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to a given context.
C-Type = 5, Named Decision Data
C-Type = 5, Named Decision Data
Named configuration information is encapsulated in this version
of the decision object in response to configuration requests. It
is a variable length object and its internal format SHOULD be
specified in the relevant COPS extension document for the given
client-type. It is optional in Decision messages and is
interpreted relative to both a given context and decision flags.
Named configuration information is encapsulated in this version of the decision object in response to configuration requests. It is a variable length object and its internal format SHOULD be specified in the relevant COPS extension document for the given client-type. It is optional in Decision messages and is interpreted relative to both a given context and decision flags.
2.2.7 LPDP Decision Object (LPDPDecision)
2.2.7 LPDP Decision Object (LPDPDecision)
Decision made by the PEP's local policy decision point (LPDP). May appear in requests. These objects correspond to and are formatted the same as the client specific decision objects defined above.
Decision made by the PEP's local policy decision point (LPDP). May appear in requests. These objects correspond to and are formatted the same as the client specific decision objects defined above.
C-Num = 7
C-Num = 7
C-Type = (same C-Type as for Decision objects)
C-Type = (same C-Type as for Decision objects)
2.2.8 Error Object (Error)
2.2.8 Error Object (Error)
This object is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client specific error codes. The appropriate Error Sub-codes for a particular client-type SHOULD be specified in the relevant COPS extensions document.
This object is used to identify a particular COPS protocol error. The error sub-code field contains additional detailed client specific error codes. The appropriate Error Sub-codes for a particular client-type SHOULD be specified in the relevant COPS extensions document.
C-Num = 8, C-Type = 1
C-Num = 8, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | Error-Code | Error Sub-code | +--------------+--------------+--------------+--------------+
Error-Code:
Error-Code:
1 = Bad handle
2 = Invalid handle reference
3 = Bad message format (Malformed Message)
4 = Unable to process (server gives up on query)
1 = Bad handle 2 = Invalid handle reference 3 = Bad message format (Malformed Message) 4 = Unable to process (server gives up on query)
Durham, et al. Standards Track [Page 14] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 14] RFC 2748 COPS January 2000
5 = Mandatory client-specific info missing
6 = Unsupported client-type
7 = Mandatory COPS object missing
8 = Client Failure
9 = Communication Failure
10= Unspecified
11= Shutting down
12= Redirect to Preferred Server
13= Unknown COPS Object:
Sub-code (octet 2) contains unknown object's C-Num
and (octet 3) contains unknown object's C-Type.
14= Authentication Failure
15= Authentication Required
5 = Mandatory client-specific info missing 6 = Unsupported client-type 7 = Mandatory COPS object missing 8 = Client Failure 9 = Communication Failure 10= Unspecified 11= Shutting down 12= Redirect to Preferred Server 13= Unknown COPS Object: Sub-code (octet 2) contains unknown object's C-Num and (octet 3) contains unknown object's C-Type. 14= Authentication Failure 15= Authentication Required
2.2.9 Client Specific Information Object (ClientSI)
2.2.9 Client Specific Information Object (ClientSI)
The various types of this object are required for requests, and used in reports and opens when required. It contains client-type specific information.
The various types of this object are required for requests, and used in reports and opens when required. It contains client-type specific information.
C-Num = 9,
C-Num = 9,
C-Type = 1, Signaled ClientSI.
C-Type = 1, Signaled ClientSI.
Variable-length field. All objects/attributes specific to a client's signaling protocol or internal state are encapsulated within one or more signaled Client Specific Information Objects. The format of the data encapsulated in the ClientSI object is determined by the client-type.
Variable-length field. All objects/attributes specific to a client's signaling protocol or internal state are encapsulated within one or more signaled Client Specific Information Objects. The format of the data encapsulated in the ClientSI object is determined by the client-type.
C-Type = 2, Named ClientSI.
C-Type = 2, Named ClientSI.
Variable-length field. Contains named configuration information useful for relaying specific information about the PEP, a request, or configured state to the PDP server.
Variable-length field. Contains named configuration information useful for relaying specific information about the PEP, a request, or configured state to the PDP server.
2.2.10 Keep-Alive Timer Object (KATimer)
2.2.10 Keep-Alive Timer Object (KATimer)
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
C-Num = 10,
C-Num = 10,
C-Type = 1, Keep-alive timer value
C-Type = 1, Keep-alive timer value
Durham, et al. Standards Track [Page 15] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 15] RFC 2748 COPS January 2000
Timer object used to specify the maximum time interval over which a COPS message MUST be sent or received. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity.
Timer object used to specify the maximum time interval over which a COPS message MUST be sent or received. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | KA Timer Value |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | ////////////// | KA Timer Value | +--------------+--------------+--------------+--------------+
2.2.11 PEP Identification Object (PEPID)
2.2.11 PEP Identification Object (PEPID)
The PEP Identification Object is used to identify the PEP client to the remote PDP. It is required for Client-Open messages.
The PEP Identification Object is used to identify the PEP client to the remote PDP. It is required for Client-Open messages.
C-Num = 11, C-Type = 1
C-Num = 11, C-Type = 1
Variable-length field. It is a NULL terminated ASCII string that is also zero padded to a 32-bit word boundary (so the object length is a multiple of 4 octets). The PEPID MUST contain an ASCII string that uniquely identifies the PEP within the policy domain in a manner that is persistent across PEP reboots. For example, it may be the PEP's statically assigned IP address or DNS name. This identifier may safely be used by a PDP as a handle for identifying the PEP in its policy rules.
Variable-length field. It is a NULL terminated ASCII string that is also zero padded to a 32-bit word boundary (so the object length is a multiple of 4 octets). The PEPID MUST contain an ASCII string that uniquely identifies the PEP within the policy domain in a manner that is persistent across PEP reboots. For example, it may be the PEP's statically assigned IP address or DNS name. This identifier may safely be used by a PDP as a handle for identifying the PEP in its policy rules.
2.2.12 Report-Type Object (Report-Type)
2.2.12 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle:
The Type of Report on the request state associated with a handle:
C-Num = 12, C-Type = 1
C-Num = 12, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | Report-Type | ///////////// | +--------------+--------------+--------------+--------------+
Report-Type:
1 = Success : Decision was successful at the PEP
2 = Failure : Decision could not be completed by PEP
3 = Accounting: Accounting update for an installed state
Report-Type: 1 = Success : Decision was successful at the PEP 2 = Failure : Decision could not be completed by PEP 3 = Accounting: Accounting update for an installed state
2.2.13 PDP Redirect Address (PDPRedirAddr)
2.2.13 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may optionally use this object to redirect the PEP to the specified PDP server address and TCP port number:
A PDP when closing a PEP session for a particular client-type may optionally use this object to redirect the PEP to the specified PDP server address and TCP port number:
Durham, et al. Standards Track [Page 16] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 16] RFC 2748 COPS January 2000
C-Num = 13,
C-Num = 13,
C-Type = 1, IPv4 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| IPv4 Address format |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 1, IPv4 Address + TCP Port 0 1 2 3 +--------------+--------------+--------------+--------------+ | IPv4 Address format | +--------------+--------------+--------------+--------------+ | ///////////////////////// | TCP Port Number | +-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| |
+ +
| |
+ IPv6 Address format +
| |
+ +
| |
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
C-Type = 2, IPv6 Address + TCP Port 0 1 2 3 +--------------+--------------+--------------+--------------+ | | + + | | + IPv6 Address format + | | + + | | +--------------+--------------+--------------+--------------+ | ///////////////////////// | TCP Port Number | +-----------------------------+-----------------------------+
2.2.14 Last PDP Address (LastPDPAddr)
2.2.14 Last PDP Address (LastPDPAddr)
When a PEP sends a Client-Open message for a particular client-type the PEP SHOULD specify the last PDP it has successfully opened (meaning it received a Client-Accept) since the PEP last rebooted. If no PDP was used since the last reboot, the PEP will simply not include this object in the Client-Open message.
When a PEP sends a Client-Open message for a particular client-type the PEP SHOULD specify the last PDP it has successfully opened (meaning it received a Client-Accept) since the PEP last rebooted. If no PDP was used since the last reboot, the PEP will simply not include this object in the Client-Open message.
C-Num = 14,
C-Num = 14,
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C-Type = 1, IPv4 Address (Same format as PDPRedirAddr)
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
C-Type = 2, IPv6 Address (Same format as PDPRedirAddr)
2.2.15 Accounting Timer Object (AcctTimer)
2.2.15 Accounting Timer Object (AcctTimer)
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
Times are encoded as 2 octet integer values and are in units of seconds. The timer value is treated as a delta.
C-Num = 15,
C-Num = 15,
C-Type = 1, Accounting timer value
C-Type = 1, Accounting timer value
Durham, et al. Standards Track [Page 17] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 17] RFC 2748 COPS January 2000
Optional timer value used to determine the minimum interval between periodic accounting type reports. It is used by the PDP to describe to the PEP an acceptable interval between unsolicited accounting updates via Report messages where applicable. It provides a method for the PDP to control the amount of accounting traffic seen by the network. The range of finite time values is 1 to 65535 seconds represented as an unsigned two-octet integer. A value of zero means there SHOULD be no unsolicited accounting updates.
Optional timer value used to determine the minimum interval between periodic accounting type reports. It is used by the PDP to describe to the PEP an acceptable interval between unsolicited accounting updates via Report messages where applicable. It provides a method for the PDP to control the amount of accounting traffic seen by the network. The range of finite time values is 1 to 65535 seconds represented as an unsigned two-octet integer. A value of zero means there SHOULD be no unsolicited accounting updates.
0 1 2 3
+--------------+--------------+--------------+--------------+
| ////////////// | ACCT Timer Value |
+--------------+--------------+--------------+--------------+
0 1 2 3 +--------------+--------------+--------------+--------------+ | ////////////// | ACCT Timer Value | +--------------+--------------+--------------+--------------+
2.2.16 Message Integrity Object (Integrity)
2.2.16 Message Integrity Object (Integrity)
The integrity object includes a sequence number and a message digest useful for authenticating and validating the integrity of a COPS message. When used, integrity is provided at the end of a COPS message as the last COPS object. The digest is then computed over all of a particular COPS message up to but not including the digest value itself. The sender of a COPS message will compute and fill in the digest portion of the Integrity object. The receiver of a COPS message will then compute a digest over the received message and verify it matches the digest in the received Integrity object.
The integrity object includes a sequence number and a message digest useful for authenticating and validating the integrity of a COPS message. When used, integrity is provided at the end of a COPS message as the last COPS object. The digest is then computed over all of a particular COPS message up to but not including the digest value itself. The sender of a COPS message will compute and fill in the digest portion of the Integrity object. The receiver of a COPS message will then compute a digest over the received message and verify it matches the digest in the received Integrity object.
C-Num = 16,
C-Num = 16,
C-Type = 1, HMAC digest
C-Type = 1, HMAC digest
The HMAC integrity object employs HMAC (Keyed-Hashing for Message Authentication) [HMAC] to calculate the message digest based on a key shared between the PEP and its PDP.
The HMAC integrity object employs HMAC (Keyed-Hashing for Message Authentication) [HMAC] to calculate the message digest based on a key shared between the PEP and its PDP.
This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular PEP and its PDP and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the PEP with corresponding keys on the PDP for the given PEPID. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 96-bits to calculate the message digest.
This Integrity object specifies a 32-bit Key ID used to identify a specific key shared between a particular PEP and its PDP and the cryptographic algorithm to be used. The Key ID allows for multiple simultaneous keys to exist on the PEP with corresponding keys on the PDP for the given PEPID. The key identified by the Key ID was used to compute the message digest in the Integrity object. All implementations, at a minimum, MUST support HMAC-MD5-96, which is HMAC employing the MD5 Message-Digest Algorithm [MD5] truncated to 96-bits to calculate the message digest.
This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is
This object also includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is
Durham, et al. Standards Track [Page 18] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 18] RFC 2748 COPS January 2000
sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero.
sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero.
The variable length digest is calculated over a COPS message starting with the COPS Header up to the Integrity Object (which MUST be the last object in a COPS message) INCLUDING the Integrity object's header, Key ID, and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
The variable length digest is calculated over a COPS message starting with the COPS Header up to the Integrity Object (which MUST be the last object in a COPS message) INCLUDING the Integrity object's header, Key ID, and Sequence Number. The Keyed Message Digest field is not included as part of the digest calculation. In the case of HMAC-MD5-96, HMAC-MD5 will produce a 128-bit digest that is then to be truncated to 96-bits before being stored in or verified against the Keyed Message Digest field as specified in [HMAC]. The Keyed Message Digest MUST be 96-bits when HMAC-MD5-96 is used.
0 1 2 3
+-------------+-------------+-------------+-------------+
| Key ID |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| ...Keyed Message Digest... |
+ +
| |
+-------------+-------------+-------------+-------------+
0 1 2 3 +-------------+-------------+-------------+-------------+ | Key ID | +-------------+-------------+-------------+-------------+ | Sequence Number | +-------------+-------------+-------------+-------------+ | | + + | ...Keyed Message Digest... | + + | | +-------------+-------------+-------------+-------------+
2.3 Communication
2.3 Communication
The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP implementation per server MUST listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP is responsible for initiating the TCP connection to a PDP. The location of the remote PDP can either be configured, or obtained via a service location mechanism [SRVLOC]. Service discovery is outside the scope of this protocol, however.
The COPS protocol uses a single persistent TCP connection between the PEP and a remote PDP. One PDP implementation per server MUST listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP is responsible for initiating the TCP connection to a PDP. The location of the remote PDP can either be configured, or obtained via a service location mechanism [SRVLOC]. Service discovery is outside the scope of this protocol, however.
If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client- type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from
If a single PEP can support multiple client-types, it may send multiple Client-Open messages, each specifying a particular client- type to a PDP over one or more TCP connections. Likewise, a PDP residing at a given address and port number may support one or more client-types. Given the client-types it supports, a PDP has the ability to either accept or reject each client-type independently. If a client-type is rejected, the PDP can redirect the PEP to an alternative PDP address and TCP port for a given client-type via COPS. Different TCP port numbers can be used to redirect the PEP to another PDP implementation running on the same server. Additional provisions for supporting multiple client-types (perhaps from
Durham, et al. Standards Track [Page 19] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 19] RFC 2748 COPS January 2000
independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform.
independent PDP vendors) on a single remote PDP server are not provided by the COPS protocol, but, rather, are left to the software architecture of the given server platform.
It is possible a single PEP may have open connections to multiple PDPs. This is the case when there are physically different PDPs supporting different client-types as shown in figure 2.
It is possible a single PEP may have open connections to multiple PDPs. This is the case when there are physically different PDPs supporting different client-types as shown in figure 2.
+----------------+
| |
| Network Node | Policy Servers
| |
| +-----+ | COPS Client Type 1 +-----+
| | |<-----|-------------------->| PDP1|
| + PEP + | COPS Client Type 2 +-----+
| | |<-----|---------\ +-----+
| +-----+ | \----------| PDP2|
| ^ | +-----+
| | |
| \-->+-----+ |
| | LPDP| |
| +-----+ |
| |
+----------------+
+----------------+ | | | Network Node | Policy Servers | | | +-----+ | COPS Client Type 1 +-----+ | | |<-----|-------------------->| PDP1| | + PEP + | COPS Client Type 2 +-----+ | | |<-----|---------\ +-----+ | +-----+ | \----------| PDP2| | ^ | +-----+ | | | | \-->+-----+ | | | LPDP| | | +-----+ | | | +----------------+
Figure 2: Multiple PDPs illustration.
Figure 2: Multiple PDPs illustration.
When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type containing an <Error> object indicating the "Communication Failure" Error-Code. Additionally, the PEP SHOULD continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a <Client-Close> message containing a <PDPRedirAddr> object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
When a TCP connection is torn down or is lost, the PDP is expected to eventually clean up any outstanding request state related to request/decision exchanges with the PEP. When the PEP detects a lost connection due to a timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type containing an <Error> object indicating the "Communication Failure" Error-Code. Additionally, the PEP SHOULD continuously attempt to contact the primary PDP or, if unsuccessful, any known backup PDPs. Specifically the PEP SHOULD keep trying all relevant PDPs with which it has been configured until it can establish a connection. If a PEP is in communication with a backup PDP and the primary PDP becomes available, the backup PDP is responsible for redirecting the PEP back to the primary PDP (via a <Client-Close> message containing a <PDPRedirAddr> object identifying the primary PDP to use for each affected client-type). Section 2.5 details synchronization behavior between PEPs and PDPs.
Durham, et al. Standards Track [Page 20] RFC 2748 COPS January 2000
Durham, et al. Standards Track [Page 20] RFC 2748 COPS January 2000
2.4 Client Handle Usage
2.4 Client Handle Usage
The client handle is used to identify a unique request state for a single PEP per client-type. Client handles are chosen by the PEP and are opaque to the PDP. The PDP simply uses the request handle to uniquely identify the request state for a particular Client-Type over a particular TCP connection and generically tie its decisions to a corresponding request. Client handles are initiated in request messages and are then used by subsequent request, decision, and report messages to reference the same request state. When the PEP is ready to remove a local request state, it will issue a delete message to the PDP for the corresponding client handle. A handle MUST be explicitly deleted by the PEP before it can be used by the PEP to identify a new request state. Handles referring to different request states MUST be unique within the context of a particular TCP connection and client-type.
The client handle is used to identify a unique request state for a single PEP per client-type. Client handles are chosen by the PEP and are opaque to the PDP. The PDP simply uses the request handle to uniquely identify the request state for a particular Client-Type over a particular TCP connection and generically tie its decisions to a corresponding request. Client handles are initiated in request messages and are then used by subsequent request, decision, and report messages to reference the same request state. When the PEP is ready to remove a local request state, it will issue a delete message to the PDP for the corresponding client handle. A handle MUST be explicitly deleted by the PEP before it can be used by the PEP to identify a new request state. Handles referring to different request states MUST be unique within the context of a particular TCP connection and client-type.
2.5 Synchronization Behavior
2.5 Synchronization Behavior
When disconnected from a PDP, the PEP SHOULD revert to making local decisions. Once a connection is reestablished, the PEP is expected to notify the PDP of any events that have passed local admission control. Additionally, the remote PDP may request that all the PEP's internal state be resynchronized (all previously installed requests are to be reissued) by sending a Synchronize State message.
PDPから切断されると、PEP SHOULDはローカルの決定をするのに戻ります。 接続がいったん回復すると、PEPが地方の入場コントロールを通過したどんなイベントについてもPDPに通知すると予想されます。 さらに、リモートPDPは、PEPの内部の状態がSynchronize州メッセージを送ることによって再連動するよう(すべての以前にインストールされた要求は再発行されることです)要求するかもしれません。
After a failure and before a new connection is fully functional, disruption of service can be minimized if the PEP caches previously communicated decisions and continues to use them for some appropriate length of time. Specific rules for such behavior are to be defined in the appropriate COPS client-type extension specifications.
失敗の後と新しい接続が機能的に完全になる前に、PEPが、以前にコミュニケートしている決定をキャッシュして、何らかの適当な時間にそれらを使用し続けているなら、サービスの分裂を最小にすることができます。 そのような振舞いのための特定の規則は適切なCOPSクライアントタイプファイル拡張仕様書で定義されることです。
A PEP that caches state from a previous exchange with a disconnected PDP MUST communicate this fact to any PDP with which it is able to later reconnect. This is accomplished by including the address and TCP port of the last PDP for which the PEP is still caching state in the Client-Open message. The <LastPDPAddr> object will only be included for the last PDP with which the PEP was completely in sync. If the service interruption was temporary and the PDP still contains the complete state for the PEP, the PDP may choose not to synchronize all states. It is still the responsibility of the PEP to update the PDP of all state changes that occurred during the disruption of service including any states communicated to the previous PDP that had been deleted after the connection was lost. These MUST be explicitly deleted after a connection is reestablished. If the PDP issues a synchronize request the PEP MUST pass all current states to the PDP followed by a Synchronize State Complete message (thus
キャッシュがこの事実を切断しているPDP MUSTとの前の交換から後でそれと再接続できるどんなPDPにも伝えると述べるPEP。 これは、PEPが開いているClientメッセージでまだ状態をキャッシュしている最後のPDPのアドレスとTCPポートを含んでいることによって、達成されます。 <LastPDPAddr>オブジェクトは完全な同時性にはPEPがあった最後のPDPのために含まれるだけでしょう。 停電が一時的であり、PDPがまだPEPのための完全な状態を含んでいて、PDPが、すべての州を連動させるというわけではないのを選ぶかもしれないなら。 それでも、接続が迷子になった後に削除された前のPDPに伝えられたどんな州も含むサービスの分裂の間、起こったのは、PEPがすべての州の変化のPDPをアップデートする責任です。 接続が回復した後に明らかにこれらを削除しなければなりません。 PDPがaを発行するならPEP MUSTがすべての現状にSynchronize州Completeメッセージがあとに続いたPDPに合格する要求を同時にさせてください、(このようにして。
Durham, et al. Standards Track [Page 21] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[21ページ]。
completing the synchronization process). If the PEP crashes and loses all cached state for a client-type, it will simply not include a <LastPDPAddr> in its Client-Open message.
同期の過程を完了します) PEPがクライアントタイプのためのすべてのキャッシュされた状態を墜落して、失うと、それは開いているClientメッセージに<LastPDPAddr>を絶対に含まないでしょう。
3. Message Content
3. メッセージ内容
This section describes the basic messages exchanged between a PEP and a remote PDP as well as their contents. As a convention, object ordering is expected as shown in the BNF for each COPS message unless otherwise noted. The Integrity object, if included, MUST always be the last object in a message. If security is required and a message was received without a valid Integrity object, the receiver MUST send a Client-Close message for Client-Type=0 specifying the appropriate error code.
このセクションはそれらのコンテンツと同様にPEPとリモートPDPの間で交換された基本のメッセージについて説明します。 コンベンション、別の方法で注意されない場合それぞれのCOPSメッセージのためにBNFに示されて、注文が予想されるオブジェクトとして。 含まれているなら、いつもIntegrityオブジェクトはメッセージで最後のオブジェクトであるに違いありません。 セキュリティを必要として、有効なIntegrityオブジェクトなしでメッセージを受け取ったなら、受信機は0Client-タイプ=指定へのClient近いメッセージに適切なエラーコードを送らなければなりません。
3.1 Request (REQ) PEP -> PDP
3.1 要求(REQ)気力->PDP
The PEP establishes a request state client handle for which the remote PDP may maintain state. The remote PDP then uses this handle to refer to the exchanged information and decisions communicated over the TCP connection to a particular PEP for a given client-type.
PEPはリモートPDPが状態を維持するかもしれない要求州のクライアントハンドルを設立します。 そして、リモートPDPは、与えられたクライアントタイプのためにTCP接続の上で特定のPEPに伝えられた交換された情報と決定を示すのにこのハンドルを使用します。
Once a stateful handle is established for a new request, any subsequent modifications of the request can be made using the REQ message specifying the previously installed handle. The PEP is responsible for notifying the PDP whenever its local state changes so the PDP's state will be able to accurately mirror the PEP's state.
新しい要求のためにいったんstatefulハンドルを設立すると、以前にインストールされたハンドルを指定するREQメッセージを使用することで要求のどんなその後の変更もすることができます。 PEPは地方の状態が変化するのでPDPの状態が正確にPEPの状態を反映できるときはいつも、PDPに通知するのに責任があります。
Durham, et al. Standards Track [Page 22] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[22ページ]。
The format of the Request message is as follows:
Requestメッセージの形式は以下の通りです:
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<要求メッセージ>:、:= 一般的な<の<クライアントハンドル><ヘッダー>文脈>[Int>の<][<の出ているIntの>][<ClientSI(s)>][<LPDPDecision(s)>][<保全>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<ClientSI(s)>:、:= <ClientSI>。| <ClientSI(s)><ClientSI>。
<LPDPDecision(s)> ::= <LPDPDecision> |
<LPDPDecision(s)> <LPDPDecision>
<LPDPDecision(s)>:、:= <LPDPDecision>。| <LPDPDecision(s)><LPDPDecision>。
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
<LPDPDecision>:、:= [<文脈>] <LPDPDecision: >[<LPDPDecision: 状態がないデータ>][<LPDPDecision: 交換データ>][<LPDPDecision: ClientSIデータ>]に旗を揚げさせます。[<LPDPDecision: 命名されたデータ>]
The context object is used to determine the context within which all the other objects are to be interpreted. It also is used to determine the kind of decision to be returned from the policy server. This decision might be related to admission control, resource allocation, object forwarding and substitution, or configuration.
文脈オブジェクトは、他のすべてのオブジェクトが解釈されることになっている文脈を決定するのに使用されます。 また、それは、方針サーバから返されるという決定の種類を決定するのに使用されます。この決定は入場コントロールか資源配分かオブジェクト推進と代替か、構成に関連するかもしれません。
The interface objects are used to determine the corresponding interface on which a signaling protocol message was received or is about to be sent. They are typically used if the client is participating along the path of a signaling protocol or if the client is requesting configuration data for a particular interface.
インタフェースオブジェクトは、シグナリングプロトコルメッセージを受け取ろうとしていたか、または送ろうとしている対応するインタフェースを決定するのに使用されます。 クライアントがシグナリングプロトコルの経路に沿って参加しているか、またはクライアントが特定のインタフェースにコンフィギュレーション・データを要求しているなら、それらは通常使用されます。
ClientSI, the client specific information object, holds the client- type specific data for which a policy decision needs to be made. In the case of configuration, the Named ClientSI may include named information about the module, interface, or functionality to be configured. The ordering of multiple ClientSIs is not important.
ClientSI(クライアント特殊情報オブジェクト)は、クライアントタイプが政策決定が作られている必要がある特定のデータであることを保持します。 構成の場合では、Named ClientSIは、構成されるためにモジュール、インタフェース、または機能性の命名された情報を含むかもしれません。 複数のClientSIsの注文は重要ではありません。
Finally, LPDPDecision object holds information regarding the local decision made by the LPDP.
最終的に、LPDPDecisionオブジェクトは、ローカルの決定の情報がLPDPによって作られているままにします。
Malformed Request messages MUST result in the PDP specifying a Decision message with the appropriate error code.
奇形のRequestメッセージは適切なエラーコードでDecisionメッセージを指定するPDPをもたらさなければなりません。
Durham, et al. Standards Track [Page 23] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[23ページ]。
3.2 Decision (DEC) PDP -> PEP
3.2 決定(12月)PDP->気力
The PDP responds to the REQ with a DEC message that includes the associated client handle and one or more decision objects grouped relative to a Context object and Decision Flags object type pair. If there was a protocol error an error object is returned instead.
PDPは関連クライアントハンドルを含んでいる12月のメッセージとContextオブジェクトとDecision Flagsオブジェクト・タイプ組に比例して分類された1個以上の決定オブジェクトでREQに応じます。 プロトコル誤りがあったなら、代わりに誤りオブジェクトを返します。
It is required that the first decision message for a new/updated request will have the solicited message flag set (value = 1) in the COPS header. This avoids the issue of keeping track of which updated request (that is, a request reissued for the same handle) a particular decision corresponds. It is important that, for a given handle, there be at most one outstanding solicited decision per request. This essentially means that the PEP SHOULD NOT issue more than one REQ (for a given handle) before it receives a corresponding DEC with the solicited message flag set. The PDP MUST always issue decisions for requests on a particular handle in the order they arrive and all requests MUST have a corresponding decision.
請求されたメッセージ旗が新しいかアップデートされた要求への最初の決定メッセージで(値=1)をCOPSヘッダーにはめ込むのが必要です。 これは特定の決定が対応しているという要求(すなわち、同じハンドルのために再発行された要求)をアップデートした動向をおさえる問題を避けます。 与えられたハンドルに関して、そこに、いてください。それが重要である、それ、高々1要求あたり1つの傑出している請求された決定。 これは、請求されたメッセージ旗のセットで対応する12月を受ける前にPEP SHOULD NOTが1REQ(与えられたハンドルのための)を発行することを本質的には意味します。 PDP MUSTはいつも到着して、すべての要求には対応する決定がなければならないというオーダーにおける特定のハンドルに関する要求のための決定を発行します。
To avoid deadlock, the PEP can always timeout after issuing a request that does not receive a decision. It MUST then delete the timed-out handle, and may try again using a new handle.
行き詰まりを避けるために、PEPはいつも決定を受けない要求を出した後のタイムアウトをそうすることができます。 それは、次に、調節されたハンドルを削除しなければならなくて、新しいハンドルを使用することで再試行するかもしれません。
The format of the Decision message is as follows:
Decisionメッセージの形式は以下の通りです:
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<決定メッセージ>:、:= 一般的な<の<クライアントハンドル><ヘッダー>決定>。| <誤り>。[<保全>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<決定>:、:= <決定>。| <決定><決定>。
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
[<Decision: Named Data>]
<決定>:、:= <文脈><決定: >[<決定: 状態がないデータ>][<決定: 交換データ>][<決定: ClientSIデータ>]に旗を揚げさせます。[<決定: 命名されたデータ>]
The Decision message may include either an Error object or one or more context plus associated decision objects. COPS protocol problems are reported in the Error object (e.g. an error with the format of the original request including malformed request messages, unknown COPS objects in the Request, etc.). The applicable Decision object(s) depend on the context and the type of client. The only ordering requirement for decision objects is that the required Decision Flags object type MUST precede the other Decision object types per context binding.
Decisionメッセージは1個以上の文脈とErrorオブジェクトか関連決定オブジェクトのどちらかを含むかもしれません。 COPSプロトコル問題はErrorオブジェクト(例えば、オリジナルの要求の形式が奇形の要求メッセージ、Requestの未知のCOPSオブジェクトなどを含んでいる誤り)で報告されます。 適切なDecisionオブジェクトは文脈とクライアントのタイプに頼っています。 決定オブジェクトのための唯一の注文要件は必要なDecision Flagsオブジェクト・タイプが他の文脈結合あたりのDecisionオブジェクト・タイプに先行しなければならないということです。
Durham, et al. Standards Track [Page 24] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[24ページ]。
3.3 Report State (RPT) PEP -> PDP
3.3 レポート州(RPT)の気力->PDP
The RPT message is used by the PEP to communicate to the PDP its success or failure in carrying out the PDP's decision, or to report an accounting related change in state. The Report-Type specifies the kind of report and the optional ClientSI can carry additional information per Client-Type.
RPTメッセージは、PDPの決定を行う際に成否をPDPに伝えるか、または会計が状態で変化を関係づけたと報告するのにPEPによって使用されます。 Report-タイプはレポートの種類を指定します、そして、任意のClientSIはClient-タイプあたりの追加情報を運ぶことができます。
For every DEC message containing a configuration context that is received by a PEP, the PEP MUST generate a corresponding Report State message with the Solicited Message flag set describing its success or failure in applying the configuration decision. In addition, outsourcing decisions from the PDP MAY result in a corresponding solicited Report State from the PEP depending on the context and the type of client. RPT messages solicited by decisions for a given Client Handle MUST set the Solicited Message flag and MUST be sent in the same order as their corresponding Decision messages were received. There MUST never be more than one Report State message generated with the Solicited Message flag set per Decision.
PEPによって受け取られる構成文脈を含むあらゆる12月のメッセージに関しては、PEP MUSTは、Solicited Message旗のセットが適用における成否について説明している対応するReport州メッセージが構成決定であると生成します。 さらに、PDP MAYからのアウトソーシング決定は文脈とクライアントのタイプに頼るPEPからの対応する請求されたReport州をもたらします。 決定で請求されたRPTメッセージは、与えられたClient HandleをSolicited Message旗を設定しなければならなくて、同じように送らなければならないので、それらの対応するDecisionメッセージを受け取ったように注文されます。 Decision単位で設定されたSolicited Message旗で生成された1つ以上のReport州メッセージが決してないに違いありません。
The Report State may also be used to provide periodic updates of client specific information for accounting and state monitoring purposes depending on the type of the client. In such cases the accounting report type should be specified utilizing the appropriate client specific information object.
また、Report州は、会計と状態のためのクライアント特殊情報の周期的なアップデートにクライアントのタイプに頼るモニターしている目的を提供するのに使用されるかもしれません。 そのような場合会計報告タイプは、適切なクライアント特殊情報オブジェクトを利用することで指定されるべきです。
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
<レポート州の>:、:== 一般的な<の<クライアントハンドル><ヘッダー>レポートタイプ>[<ClientSI>][<保全>]
3.4 Delete Request State (DRQ) PEP -> PDP
3.4は要求州(DRQ)の気力->PDPを削除します。
When sent from the PEP this message indicates to the remote PDP that the state identified by the client handle is no longer available/relevant. This information will then be used by the remote PDP to initiate the appropriate housekeeping actions. The reason code object is interpreted with respect to the client-type and signifies the reason for the removal.
PEPから送ると、このメッセージは、クライアントハンドルによって特定された状態がもう利用可能な/関連していないのをリモートPDPに示します。 そして、この情報は、適切な家事の動作を開始するのにリモートPDPによって使用されるでしょう。 理由コードオブジェクトは、クライアントタイプに関して解釈されて、取り外しの理由を意味します。
The format of the Delete Request State message is as follows:
Delete Request州メッセージの形式は以下の通りです:
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
<は要求>を削除します:、:= 一般的な<の<クライアントハンドル><ヘッダー>理由>。[<保全>]
Durham, et al. Standards Track [Page 25] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[25ページ]。
Given the stateful nature of COPS, it is important that when a request state is finally removed from the PEP, a DRQ message for this request state is sent to the PDP so the corresponding state may likewise be removed on the PDP. Request states not explicitly deleted by the PEP will be maintained by the PDP until either the client session is closed or the connection is terminated.
COPSのstateful自然を考えて、対応する状態がPEPから要求状態を最終的に取り除くとき、この要求状態へのDRQメッセージをPDPに送るのでPDPで同様に移されるのは、重要です。 クライアントセッションが閉じられるか、または接続が終えられるまでPEPによって明らかに削除されなかった州がPDPによって維持されるよう要求してください。
Malformed Decision messages MUST trigger a DRQ specifying the appropriate erroneous reason code (Bad Message Format) and any associated state on the PEP SHOULD either be removed or re-requested. If a Decision contained an unknown COPS Decision Object, the PEP MUST delete its request specifying the Unknown COPS Object reason code because the PEP will be unable to comply with the information contained in the unknown object. In any case, after issuing a DRQ, the PEP may retry the corresponding Request again.
奇形のDecisionメッセージは適切な誤った理由コード(悪いMessage Format)と取り外されるか、または再要求されたPEP SHOULDのどんな準国家も指定するDRQの引き金とならなければなりません。 Decisionが未知のCOPS Decision Objectを含んだなら、PEP MUSTはPEPが未知のオブジェクトに含まれている情報に応じることができないのでUnknown COPS Object理由コードを指定する要求を削除します。 どのような場合でも、DRQを発行した後に、PEPは再び対応するRequestを再試行するかもしれません。
3.5 Synchronize State Request (SSQ) PDP -> PEP
3.5は州の要求(SSQ)PDP->気力を同期させます。
The format of the Synchronize State Query message is as follows:
Synchronize州Queryメッセージの形式は以下の通りです:
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
<は州>を連動させます:、:= <の一般的なヘッダー>[<クライアントハンドル>][<保全>]
This message indicates that the remote PDP wishes the client (which appears in the common header) to re-send its state. If the optional Client Handle is present, only the state associated with this handle is synchronized. If the PEP does not recognize the requested handle, it MUST immediately send a DRQ message to the PDP for the handle that was specified in the SSQ message. If no handle is specified in the SSQ message, all the active client state MUST be synchronized with the PDP.
このメッセージは、リモートPDPが、クライアント(一般的なヘッダーに現れる)に状態を再送して欲しいのを示します。 任意のClient Handleが存在しているなら、このハンドルに関連している状態だけが同期します。 PEPが要求されたハンドルを認識しないなら、それはすぐに、SSQメッセージで指定されたハンドルのためにDRQメッセージをPDPに送らなければなりません。 ハンドルが全くSSQメッセージで指定されないなら、すべての活動的な属国がPDPに連動しなければなりません。
The client performs state synchronization by re-issuing request queries of the specified client-type for the existing state in the PEP. When synchronization is complete, the PEP MUST issue a synchronize state complete message to the PDP.
クライアントは、PEPで現状のための指定されたクライアントタイプの要求質問を再発行することによって、州の同期を実行します。 同期が完全であるときに、aが同期させるPEP MUST問題は完全なメッセージをPDPに述べます。
3.6 Client-Open (OPN) PEP -> PDP
3.6 オープンなクライアント(OPN)気力->PDP
The Client-Open message can be used by the PEP to specify to the PDP the client-types the PEP can support, the last PDP to which the PEP connected for the given client-type, and/or client specific feature negotiation. A Client-Open message can be sent to the PDP at any time and multiple Client-Open messages for the same client-type are allowed (in case of global state changes).
PEPは、PEPがサポートすることができるクライアントタイプ、PEPが与えられたクライアントタイプのために接続した最後のPDP、そして/または、クライアントの特定の特徴交渉をPDPに指定するのに開いているClientメッセージを使用できます。 いつでも開いているClientメッセージをPDPに送ることができます、そして、同じクライアントタイプにおいて複数の開いているClientメッセージを許容します(グローバルな州の変化の場合に)。
Durham, et al. Standards Track [Page 26] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[26ページ]。
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
<クライアント開いている>:、:= <の一般的なヘッダー><PEPID>[<ClientSI>][<LastPDPAddr>][<保全>]
The PEPID is a symbolic, variable length name that uniquely identifies the specific client to the PDP (see Section 2.2.11).
PEPIDは唯一特定のクライアントをPDPに特定するシンボリックで、可変な長さの名(セクション2.2.11を見る)です。
A named ClientSI object can be included for relaying additional global information about the PEP to the PDP when required (as specified in the appropriate extensions document for the client- type).
必要であると(適切な拡大ドキュメントでクライアントタイプに指定されるように)PEPの追加グローバルな情報をPDPにリレーするために命名されたClientSIオブジェクトを含むことができます。
The PEP may also provide a Last PDP Address object in its Client-Open message specifying the last PDP (for the given client-type) for which it is still caching decisions since its last reboot. A PDP can use this information to determine the appropriate synchronization behavior (See section 2.5).
また、PEPはそれがまだ最後のリブート以来の決定をキャッシュしている最後のPDP(与えられたクライアントタイプのための)を指定する開いているClientメッセージにLast PDP Addressオブジェクトを提供するかもしれません。 PDPは、適切な同期の振舞いを決定するのにこの情報を使用できます(セクション2.5を見てください)。
If the PDP receives a malformed Client-Open message it MUST generate a Client-Close message specifying the appropriate error code.
PDPが奇形の開いているClientメッセージを受け取るなら、それは適切なエラーコードを指定するClient近いメッセージを生成しなければなりません。
3.7 Client-Accept (CAT) PDP -> PEP
3.7は(猫)PDP->気力をクライアントと同じくらい受け入れます。
The Client-Accept message is used to positively respond to the Client-Open message. This message will return to the PEP a timer object indicating the maximum time interval between keep-alive messages. Optionally, a timer specifying the minimum allowed interval between accounting report messages may be included when applicable.
Client受け入れているメッセージは、明確に開いているClientメッセージに応じるのに使用されます。 このメッセージは生きている生活費メッセージの間で最大の時間間隔を示すタイマオブジェクトをPEPに返すでしょう。 適切であるときに、任意に、会計報告メッセージの最小の許容間隔を指定するタイマは含まれるかもしれません。
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
<は>をクライアントと同じくらい受け入れます:、:= <の一般的なヘッダー><kaタイマ>[<ACCTタイマ>][<保全>]
If the PDP refuses the client, it will instead issue a Client-Close message.
PDPがクライアントを拒否すると、それは代わりにClient近いメッセージを発行するでしょう。
The KA Timer corresponds to maximum acceptable intermediate time between the generation of messages by the PDP and PEP. The timer value is determined by the PDP and is specified in seconds. A timer value of 0 implies no secondary connection verification is necessary.
KA TimerはPDPとPEPによるメッセージの世代の間で最大の許容できる中間的時間に対応しています。 タイマ値は、PDPによって決定されて、秒に指定されます。 0のタイマ値は、どんなセカンダリ接続検証も必要でないことを含意します。
The optional ACCT Timer allows the PDP to indicate to the PEP that periodic accounting reports SHOULD NOT exceed the specified timer interval per client handle. This allows the PDP to control the rate at which accounting reports are sent by the PEP (when applicable).
任意のACCT Timerは周期的な会計報告SHOULD NOTがクライアントハンドルあたりの指定されたタイマ間隔を超えているのをPDPをPEPに示させます。 これで、PDPは会計報告がPEPによって送られるレートを制御できます(適切であるときに)。
Durham, et al. Standards Track [Page 27] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[27ページ]。
In general, accounting type Report messages are sent to the PDP when determined appropriate by the PEP. The accounting timer merely is used by the PDP to keep the rate of such updates in check (i.e. Preventing the PEP from blasting the PDP with accounting reports). Not including this object implies there are no PDP restrictions on the rate at which accounting updates are generated.
一般に、適切な状態でPEPによって決定されると、会計タイプReportメッセージをPDPに送ります。 会計タイマは、そのようなアップデートの速度を抑えること(会計報告でPDPを爆破するのからのすなわち、Preventing PEP)にPDPによって単に使用されます。 このオブジェクトを含んでいないのは、PDP制限が全く会計アップデートが発生しているレートにないのを含意します。
If the PEP receives a malformed Client-Accept message it MUST generate a Client-Close message specifying the appropriate error code.
PEPが奇形のClient受け入れているメッセージを受け取るなら、それは適切なエラーコードを指定するClient近いメッセージを生成しなければなりません。
3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP
3.8 クライアント近い(CC)気力->PDP、PDP->気力
The Client-Close message can be issued by either the PDP or PEP to notify the other that a particular type of client is no longer being supported.
PDPかPEPのどちらかが、特定のタイプのクライアントがもうサポートされていないようにもう片方に通知するためにClient近いメッセージを発行できます。
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
<クライアント近い>:、:= <の一般的なヘッダー><誤り>[<PDPRedirAddr>][<保全>]
The Error object is included to describe the reason for the close (e.g. the requested client-type is not supported by the remote PDP or client failure).
Errorオブジェクトは、閉鎖の理由について説明するために含まれています(例えば要求されたクライアントタイプはリモートPDPかクライアント失敗によってサポートされません)。
A PDP MAY optionally include a PDP Redirect Address object in order to inform the PEP of the alternate PDP it SHOULD use for the client- type specified in the common header.
PDP MAYは、代替のPDPについてPEPに知らせるために任意にPDP Redirect Addressオブジェクトを含んでいます。それは一般的なヘッダーで指定しましたクライアントのSHOULD使用が、タイプする。
3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP
3.9は(ka)気力->PDP、PDP->気力を生かします。
The keep-alive message MUST be transmitted by the PEP within the period defined by the minimum of all KA Timer values specified in all received CAT messages for the connection. A KA message MUST be generated randomly between 1/4 and 3/4 of this minimum KA timer interval. When the PDP receives a keep-alive message from a PEP, it MUST echo a keep-alive back to the PEP. This message provides validation for each side that the connection is still functioning even when there is no other messaging.
PEPはすべての受信されたCATメッセージで接続に指定されたすべてのKA Timer値の最小限によって定義された期間中に生きている生活費メッセージを送らなければなりません。 1/4とこの3/4回の最小のKAタイマ間隔の間で手当たりしだいにKAメッセージを生成しなければなりません。 PDPがPEPから生きている生活費メッセージを受け取るとき、それは生きている生活費をPEPにecho backでなければなりません。 このメッセージは、通信するどんな他のものもいないときさえ、機能しながら、それぞれの側のための接続がまだそうである合法化を提供します。
Note: The client-type in the header MUST always be set to 0 as the KA is used for connection verification (not per client session verification).
以下に注意してください。 KAが接続検証(クライアントセッション検証でないのあたりの)に使用されて、ヘッダーというクライアントタイプはいつも0に用意ができなければなりません。
<Keep-Alive> ::= <Common Header>
[<Integrity>]
生きている<生活費>:、:= <の一般的なヘッダー>。[<保全>]
Durham, et al. Standards Track [Page 28] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[28ページ]。
Both client and server MAY assume the TCP connection is insufficient for the client-type with the minimum time value (specified in the CAT message) if no communication activity is detected for a period exceeding the timer period. For the PEP, such detection implies the remote PDP or connection is down and the PEP SHOULD now attempt to use an alternative/backup PDP.
クライアントとサーバの両方が、最小の時間的価値によって、クライアントタイプに、コミュニケーション活動が全くしばらく検出されないならTCP接続がタイマの期間を超えるのにおいて不十分であると(CATメッセージで指定された)仮定するかもしれません。 PEPに関しては、そのような検出は、リモートPDPか接続が下がっていて、PEP SHOULDが、現在代替手段/バックアップPDPを使用するのを試みるのを含意します。
3.10 Synchronize State Complete (SSC) PEP -> PDP
3.10は州の完全な(SSC)気力->PDPを連動させます。
The Synchronize State Complete is sent by the PEP to the PDP after the PDP sends a synchronize state request to the PEP and the PEP has finished synchronization. It is useful so that the PDP will know when all the old client state has been successfully re-requested and, thus, the PEP and PDP are completely synchronized. The Client Handle object only needs to be included if the corresponding Synchronize State Message originally referenced a specific handle.
PDPがaを送った後に州CompleteがPDPへのPEPによって送られるSynchronizeは州の要求をPEPと同時にさせます、そして、PEPは同期を終えました。 それは、PDPがいつすべての古い属国が首尾よく再要求されていて、その結果、PEPとPDPが完全に連動するかを知るように、役に立ちます。 対応するSynchronize州Messageが元々特定のハンドルに参照をつけた場合にだけ、Client Handleオブジェクトは、含まれる必要があります。
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
<は州の完全な>を連動させます:、:= <の一般的なヘッダー>[<クライアントハンドル>][<保全>]
4. Common Operation
4. 一般的な操作
This section describes the typical exchanges between remote PDP servers and PEP clients.
このセクションはリモートPDPサーバとPEPクライアントの間の典型的な交換について説明します。
4.1 Security and Sequence Number Negotiation
4.1 セキュリティと一連番号交渉
COPS message security is negotiated once per connection and covers all communication over a particular connection. If COPS level security is required, it MUST be negotiated during the initial Client-Open/Client-Accept message exchange specifying a Client-Type of zero (which is reserved for connection level security negotiation and connection verification).
COPSメッセージセキュリティは、接続単位で一度交渉されて、特定の接続の上にすべてのコミュニケーションをカバーしています。 COPSの平らなセキュリティが必要であるなら、ゼロ(接続レベルセキュリティ交渉と接続検証のために予約される)Client-タイプを指定するクライアントと同じくらい初期の開いているClient/受け入れている交換処理の間、それを交渉しなければなりません。
If a PEP is not configured to use COPS security with a PDP it will simply send the PDP Client-Open messages for the supported Client- Types as specified in section 4.3 and will not include the Integrity object in any COPS messages.
PEPがPDPがあるCOPSセキュリティを使用するために構成されないと、それは、セクション4.3の指定されるとしてのサポートしているClientタイプのために単に開いているPDP Clientメッセージを送って、どんなCOPSメッセージにもIntegrityオブジェクトを含まないでしょう。
Otherwise, security can be initiated by the PEP if it sends the PDP a Client-Open message with Client-Type=0 before opening any other Client-Type. If the PDP receives a Client-Open with a Client-Type=0 after another Client-Type has already been opened successfully it MUST return a Client-Close message (for Client-Type=0) to that PEP. This first Client-Open message MUST specify a Client-Type of zero and MUST provide the PEPID and a COPS Integrity object. This Integrity object will contain the initial sequence number the PEP requires the
さもなければ、いかなる他のClient-タイプも開く前のClient-タイプ=0がある開いているClientメッセージをPDPに送るなら、PEPはセキュリティを開始できます。 別のClient-タイプが既に首尾よく開かれた後にPDPがClient-タイプ=0で開いているClientを受けるなら、それはClient近いメッセージ(Client-タイプ=0のための)をそのPEPに返さなければなりません。 この最初の開いているClientメッセージは、ゼロClient-タイプを指定しなければならなくて、PEPIDとCOPS Integrityオブジェクトを提供しなければなりません。 このIntegrityオブジェクトはPEPが必要とする初期シーケンス番号を含むでしょう。
Durham, et al. Standards Track [Page 29] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[29ページ]。
PDP to increment during subsequent communication after the initial Client-Open/Client-Accept exchange and the Key ID identifying the algorithm and key used to compute the digest.
交換を初期の開いているClientの後のその後のコミュニケーションの間、増加するか、またはクライアントと同じくらい受け入れるPDPとアルゴリズムとキーを特定するKey IDは以前はよくダイジェストを計算していました。
Similarly, if the PDP accepts the PEP's security key and algorithm by validating the message digest using the identified key, the PDP MUST send a Client-Accept message with a Client-Type of zero to the PEP carrying an Integrity object. This Integrity object will contain the initial sequence number the PDP requires the PEP to increment during all subsequent communication with the PDP and the Key ID identifying the key and algorithm used to compute the digest.
同様に、PDPが特定されたキーを使用することでメッセージダイジェストを有効にすることによってPEPのセキュリティキーとアルゴリズムを受け入れるなら、PDP MUSTはゼロClient-タイプでIntegrityオブジェクトを運ぶPEPにClient受け入れているメッセージを送ります。 このIntegrityオブジェクトはPDPが、PEPがダイジェストを計算するのに使用されるキーとアルゴリズムを特定するPDPとKey IDとのすべてのその後のコミュニケーションの間、増加するのを必要とする初期シーケンス番号を含むでしょう。
If the PEP, from the perspective of a PDP that requires security, fails or never performs the security negotiation by not sending an initial Client-Open message with a Client-Type=0 including a valid Integrity object, the PDP MUST send to the PEP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Similarly, if the PDP, from the perspective of a PEP that requires security, fails the security negotiation by not sending back a Client-Accept message with a Client-Type=0 including a valid Integrity object, the PEP MUST send to the PDP a Client-Close message with a Client-Type=0 specifying the appropriate error code. Such a Client-Close message need not carry an integrity object (as the security negotiation did not yet complete).
PEPがセキュリティを必要とするPDPの見解から失敗するか、またはClient-タイプ=0が有効なIntegrityオブジェクトを含んでいる初期の開いているClientメッセージを送らないことによってセキュリティ交渉を決して実行しないなら、PDP MUSTはPEPへのClient-タイプ=0が指定しているClient近いメッセージに適切なエラーコードを送ります。 同様に、Client-タイプ=0が有効なIntegrityオブジェクトを含んでいるClient受け入れているメッセージを返送しないことによってPDPがセキュリティを必要とするPEPの見解からセキュリティ交渉に失敗するなら、PEP MUSTはPDPへのClient-タイプ=0が指定しているClient近いメッセージに適切なエラーコードを送ります。 そのようなClient近いメッセージは保全オブジェクトを運ぶ必要はありません(セキュリティ交渉がまだ完全な状態でそうしていなかったように)。
The security initialization can fail for one of several reasons: 1. The side receiving the message requires COPS level security but an Integrity object was not provided (Authentication Required error code). 2. A COPS Integrity object was provided, but with an unknown/unacceptable C-Type (Unknown COPS Object error code specifying the unsupported C-Num and C-Type). 3. The message digest or Key ID in the provided Integrity object was incorrect and therefore the message could not be authenticated using the identified key (Authentication Failure error code).
セキュリティ初期化は個人的にはいくつかの理由をしそこなうことができます: 1. メッセージを受け取る側はCOPSの平らなセキュリティを必要としますが、(認証Requiredエラーコード)はIntegrityオブジェクトに提供されませんでした。 2. しかし、未知の、または、容認できないC-タイプ(サポートされないC-ヌムとC-タイプを指定する未知のCOPS Objectエラーコード)にCOPS Integrityオブジェクトを提供しました。 3. 提供されたIntegrityオブジェクトのメッセージダイジェストかKey IDが不正確でした、そして、したがって、特定されたキー(認証Failureエラーコード)を使用することでメッセージは認証できないでしょう。
Once the initial security negotiation is complete, the PEP will know what sequence numbers the PDP expects and the PDP will know what sequence numbers the PEP expects. ALL COPS messages must then include the negotiated Integrity object specifying the correct sequence number with the appropriate message digest (including the Client- Open/Client-Accept messages for specific Client-Types). ALL subsequent messages from the PDP to the PEP MUST result in an increment of the sequence number provided by the PEP in the Integrity object of the initial Client-Open message. Likewise, ALL subsequent messages from the PEP to the PDP MUST result in an increment of the sequence number provided by the PDP in the Integrity object of the initial Client-Accept message. Sequence numbers are incremented by one starting with the corresponding initial sequence number. For
初期のセキュリティ交渉がいったん完全になると、PEPは、PDPがどんな一連番号を予想するかを知るでしょう、そして、PDPはPEPがどんな一連番号を予想するかを知るでしょう。 そして、ALL COPSメッセージは適切なメッセージダイジェストで適度の一連番号を指定する交渉されたIntegrityオブジェクトを含まなければなりません(Clientの開いている/を含んでいると、特定のClient-タイプへのメッセージはクライアントと同じくらい受け入れられます)。 すべてのその後のPDPからPEP MUSTまでのメッセージが初期の開いているClientメッセージのIntegrityオブジェクトのPEPによって提供された一連番号の増分をもたらします。 同様に、すべてのその後のPEPからPDP MUSTまでのメッセージが初期のClient受け入れているメッセージのIntegrityオブジェクトのPDPによって提供された一連番号の増分をもたらします。 対応する初期シーケンス番号から始まって、一連番号は1つ増加されます。 for
Durham, et al. Standards Track [Page 30] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[30ページ]。
example, if the sequence number specified to the PEP by the PDP in the initial Client-Accept was 10, the next message the PEP sends to the PDP will provide an Integrity object with a sequence number of 11... Then the next message the PEP sends to the PDP will have a sequence number of 12 and so on. If any subsequent received message contains the wrong sequence number, an unknown Key ID, an invalid message digest, or is missing an Integrity object after integrity was negotiated, then a Client-Close message MUST be generated for the Client-Type zero containing a valid Integrity object and specifying the appropriate error code. The connection should then be dropped.
例、一連番号がPDPでPEPに指定したならイニシャルがClient受け入れるコネが10であった、PEPがPDPに送る次のメッセージは11の一連番号をIntegrityオブジェクトに提供するでしょう… そして、PEPがPDPに送る次のメッセージは12などの一連番号を持つでしょう。 何かその後の受信されたメッセージが間違った一連番号、未知のKey ID、無効のメッセージダイジェストを含んでいるか、または保全が交渉された後にIntegrityオブジェクトをなくしているなら、有効なIntegrityオブジェクトを含んでいて、適切なエラーコードを指定するClient-タイプゼロのためにClient近いメッセージを生成しなければなりません。 そして、接続は下げられるべきです。
4.2 Key Maintenance
4.2 主要なメインテナンス
Key maintenance is outside the scope of this document, but COPS implementations MUST at least provide the ability to manually configure keys and their parameters locally. The key used to produce the Integrity object's message digest is identified by the Key ID field. Thus, a Key ID parameter is used to identify one of potentially multiple simultaneous keys shared by the PEP and PDP. A Key ID is relative to a particular PEPID on the PDP or to a particular PDP on the PEP. Each key must also be configured with lifetime parameters for the time period within which it is valid as well as an associated cryptographic algorithm parameter specifying the algorithm to be used with the key. At a minimum, all COPS implementations MUST support the HMAC-MD5-96 [HMAC][MD5] cryptographic algorithm for computing a message digest for inclusion in the Keyed Message Digest of the Integrity object which is appended to the message.
このドキュメントの範囲の外に主要なメインテナンスがありますが、COPS実装は手動で局所的にキーとそれらのパラメタを構成する能力を少なくとも提供しなければなりません。 Integrityオブジェクトのメッセージダイジェストを作成するのに使用されるキーはKey ID分野によって特定されます。 したがって、Key IDパラメタは、PEPとPDPによって共有された潜在的に複数の同時のキーの1つを特定するのに使用されます。 PDPの上の特定のPEPIDに比例したPEPの上の特定のPDPにKey IDがあります。 また、期間のためのそれが有効である生涯パラメタとキーと共に使用されるためにアルゴリズムを指定する関連暗号アルゴリズムパラメタで各キーを構成しなければなりません。 最小限では、すべてのCOPS実装が、HMAC-MD5-96[HMAC][MD5]がメッセージに追加されるIntegrityオブジェクトのKeyed Message Digestでの包含のためのメッセージダイジェストを計算するための暗号アルゴリズムであるとサポートしなければなりません。
It is good practice to regularly change keys. Keys MUST be configurable such that their lifetimes overlap allowing smooth transitions between keys. At the midpoint of the lifetime overlap between two keys, senders should transition from using the current key to the next/longer-lived key. Meanwhile, receivers simply accept any identified key received within its configured lifetime and reject those that are not.
定期的に転調するのは、良い習慣です。 キーが構成可能であるに違いないので、彼らの寿命はキーの間のスムーズな移行を許容しながら、重なります。 2個のキーの間の生涯オーバラップの中点では、送付者は現在のキーを使用するのからの次の、または、より長く送られたキーへの変遷がそうするべきです。 その間、受信機は、単に構成された生涯中に受け取られたどんな特定されたキーも受け入れて、そうしないそれらを拒絶します。
4.3 PEP Initialization
4.3 気力初期設定
Sometime after a connection is established between the PEP and a remote PDP and after security is negotiated (if required), the PEP will send one or more Client-Open messages to the remote PDP, one for each client-type supported by the PEP. The Client-Open message MUST contain the address of the last PDP with which the PEP is still caching a complete set of decisions. If no decisions are being cached from the previous PDP the LastPDPAddr object MUST NOT be included in the Client-Open message (see Section 2.5). Each Client-Open message MUST at least contain the common header noting one client-type
接続がPEPとリモートPDPの間で確立されたいつか後と(必要なら、)セキュリティが交渉された後に、PEPはリモートPDP(PEPによってサポートされたそれぞれのクライアントタイプあたり1つ)に1つ以上の開いているClientメッセージを送るでしょう。 開いているClientメッセージはまだPEPと完全なセットの決定をキャッシュしている最後のPDPのアドレスを含まなければなりません。 決定が全く前のPDPからキャッシュされていないなら、開いているClientメッセージにLastPDPAddrオブジェクトを含んではいけません(セクション2.5を見てください)。 それぞれの開いているClientメッセージは1つのクライアントタイプに注意する一般的なヘッダーを少なくとも含まなければなりません。
Durham, et al. Standards Track [Page 31] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[31ページ]。
supported by the PEP. The remote PDP will then respond with separate Client-Accept messages for each of the client-types requested by the PEP that the PDP can also support.
PEPによってサポートされます。 そして、リモートPDPはまたPDPがサポートすることができるPEPによって要求されたクライアントタイプ各人のために別々のClient受け入れているメッセージで応じるでしょう。
If a specific client-type is not supported by the PDP, the PDP will instead respond with a Client-Close specifying the client-type is not supported and will possibly suggest an alternate PDP address and port. Otherwise, the PDP will send a Client-Accept specifying the timer interval between keep-alive messages and the PEP may begin issuing requests to the PDP.
特定のクライアントタイプがPDPによってサポートされないと、PDPは代わりにクライアントタイプがサポートされないClient近い指定で応じて、ことによると代替のPDPアドレスとポートを勧めるでしょう。 さもなければ、PDPは生きている生活費メッセージのタイマ間隔をClient受け入れている指定に送るでしょう、そして、PEPはPDPに要求を出し始めるかもしれません。
4.4 Outsourcing Operations
4.4 アウトソーシング操作
In the outsourcing scenario, when the PEP receives an event that requires a new policy decision it sends a request message to the remote PDP. What specifically qualifies as an event for a particular client-type SHOULD be specified in the specific document for that client-type. The remote PDP then makes a decision and sends a decision message back to the PEP. Since the request is stateful, the request will be remembered, or installed, on the remote PDP. The unique handle (unique per TCP connection and client-type), specified in both the request and its corresponding decision identifies this request state. The PEP is responsible for deleting this request state once the request is no longer applicable.
PEPが新しい政策決定を必要とするイベントを受けるとき、アウトソーシングシナリオでは、それはリモートPDPに要求メッセージを送ります。 指定されていて、特定のクライアントタイプSHOULDのためにそのクライアントタイプへの特定のドキュメントで明確にイベントの資格を得ること。 リモートPDPは次に、決定をして、決定メッセージをPEPに送り返します。 要求がstatefulであるので、要求は、リモートPDPに覚えていられるか、またはインストールされるでしょう。 (ユニークでTCP接続あたりクライアントと同じくらいタイプしています)の、そして、要求とその対応する決定の両方で指定されたユニークなハンドルはこの要求状態を特定します。 PEPは要求がいったんもう適切にならないとこの要求状態を削除するのに責任があります。
The PEP can update a previously installed request state by reissuing a request for the previously installed handle. The remote PDP is then expected to make new decisions and send a decision message back to the PEP. Likewise, the server MAY change a previously issued decision on any currently installed request state at any time by issuing an unsolicited decision message. At all times the PEP module is expected to abide by the PDP's decisions and notify the PDP of any state changes.
PEPは、以前にインストールされたハンドルを求める要求を再発行することによって、以前にインストールされた要求状態をアップデートできます。 そして、リモートPDPは新しい決定をして、決定メッセージをPEPに送り返すと予想されます。 同様に、サーバは、いつでも、求められていない決定メッセージを発行することによって、どんな現在インストールされた要求状態の以前に発行された決定も変えるかもしれません。 いつも、PEPモジュールは、PDPの決定を守って、どんな州の変化についてもPDPに通知すると予想されます。
4.5 Configuration Operations
4.5 構成操作
In the configuration scenario, as in the outsourcing scenario, the PEP will make a configuration request to the PDP for a particular interface, module, or functionality that may be specified in the named client specific information object. The PDP will then send potentially several decisions containing named units of configuration data to the PEP. The PEP is expected to install and use the configuration locally. A particular named configuration can be updated by simply sending additional decision messages for the same named configuration. When the PDP no longer wishes the PEP to use a piece of configuration information, it will send a decision message specifying the named configuration and a decision flags object with
構成シナリオでは、アウトソーシングシナリオのように、PEPは命名されたクライアント特殊情報オブジェクトで指定されるかもしれない特定のインタフェース、モジュール、または機能性のために構成要求をPDPにするでしょう。 そして、PDPはPEPへのユニットのコンフィギュレーション・データという含有を潜在的にいくつかの決定に送るでしょう。 PEPは局所的に構成をインストールして、使用すると予想されます。 単に同じ命名された構成への追加決定メッセージを送ることによって、特定の命名された構成をアップデートできます。 いつで、PDPは、もうPEPに1つの設定情報を使用して欲しくなく、決定メッセージはそれで命名された構成を指定して、決定はオブジェクトに旗を揚げさせますか。
Durham, et al. Standards Track [Page 32] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[32ページ]。
the remove configuration command. The PEP SHOULD then proceed to remove the corresponding configuration and send a report message to the PDP that specifies it has been deleted.
取り外し構成コマンド。 PEP SHOULDは対応する構成を取り除いて、そして、それを指定するPDPへのメッセージが削除されたというレポートを送りかけます。
In all cases, the PEP MAY notify the remote PDP of the local status of an installed state using the report message where appropriate. The report message is to be used to signify when billing can begin, what actions were taken, or to produce periodic updates for monitoring and accounting purposes depending on the client. This message can carry client specific information when needed.
すべての場合では、適切であるところでレポートメッセージを使用することでPEP MAYはインストールされた状態のローカルの状態のリモートPDPに通知します。 レポートメッセージが支払いが始まることができるとき、意味するのに使用されることであり、動作が何であるかということであったのは、クライアントに頼る目的を、取るか、または生産物周期的モニターと会計でアップデートします。 必要であると、このメッセージはクライアント特殊情報を運ぶことができます。
4.6 Keep-Alive Operations
4.6は操作を生かします。
The Keep-Alive message is used to validate the connection between the client and server is still functioning even when there is no other messaging from the PEP to PDP. The PEP MUST generate a COPS KA message randomly within one-fourth to three-fourths the minimum KA Timer interval specified by the PDP in the Client-Accept message. On receiving a Keep-Alive message from the PEP, the PDP MUST then respond to this Keep-Alive message by echoing a Keep-Alive message back to the PEP. If either side does not receive a Keep-Alive or any other COPS message within the minimum KA Timer interval from the other, the connection SHOULD be considered lost.
生きているKeepメッセージはPEPからPDPまで通信するどんな他のものもいないときさえそれでも、クライアントとサーバとの関係を有効にするのにおいて使用されているのが、機能することであるということです。 PEP MUSTは1/4の中で手当たりしだいに最小のKA Timer間隔がClient受け入れているメッセージのPDPで指定した3-4にCOPS KAメッセージを生成します。 そして、PEPから生きているKeepメッセージを受け取ると、PDP MUSTは、生きているKeepメッセージをPEPにecho backであることによって、この生きているKeepメッセージに応じます。 どちらの側も無くなった状態で考えられて、生きているKeepかいかなる他のCOPSももう片方からの最小のKA Timer間隔、接続SHOULDの中で通信するaを受けないなら。
4.7 PEP/PDP Close
4.7 気力/PDPは閉じます。
Finally, Client-Close messages are used to negate the effects of the corresponding Client-Open messages, notifying the other side that the specified client-type is no longer supported/active. When the PEP detects a lost connection due to a keep-alive timeout condition it SHOULD explicitly send a Client-Close message for each opened client-type specifying a communications failure error code. Then the PEP MAY proceed to terminate the connection to the PDP and attempt to reconnect again or try a backup/alternative PDP. When the PDP is shutting down, it SHOULD also explicitly send a Client-Close to all connected PEPs for each client-type, perhaps specifying an alternative PDP to use instead.
最終的に、Client近いメッセージは対応する開いているClientメッセージの効果を否定するのに使用されます、指定されたクライアントタイプがもう/能動態であることはサポートされないように反対側に通知して。 PEPが生きている生活費タイムアウト状態による迷子になった接続のためにそれを検出するとき、SHOULDはコミュニケーション失敗エラーコードを指定するそれぞれの開かれたクライアントタイプのために明らかにClient近いメッセージを送ります。 そして、PEP MAYは再び再接続するPDPと試みとの接続を終えかけるか、またはバックアップ/代替手段PDPを試みかけます。 PDPが停止していて、またそれがSHOULDである、明らかにaを送ってください、Client-Close、すべてがそれぞれのクライアントタイプのためにPEPsを接続しました、恐らく代わりに代替のPDPを使用に指定して。
5. Security Considerations
5. セキュリティ問題
The COPS protocol provides an Integrity object that can achieve authentication, message integrity, and replay prevention. All COPS implementations MUST support the COPS Integrity object and its mechanisms as described in this document. To ensure the client (PEP) is communicating with the correct policy server (PDP) requires authentication of the PEP and PDP using a shared secret, and consistent proof that the connection remains valid. The shared secret minimally requires manual configuration of keys (identified by a Key
COPSプロトコルは認証、メッセージの保全、および再生防止を達成できるIntegrityオブジェクトを提供します。 すべてのCOPS実装が本書では説明されるようにCOPS Integrityオブジェクトとそのメカニズムをサポートしなければなりません。 クライアント(PEP)が正しい方針サーバ(PDP)とコミュニケートしているのを保証するのが共有秘密キー、および接続が有効なままで残っているという一貫した証拠を使用することでPEPとPDPの認証を必要とします。 共有秘密キーがキーの手動の構成を最少量で必要とする、(Keyによって特定されます。
Durham, et al. Standards Track [Page 33] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[33ページ]。
ID) shared between the PEP and its PDP. The key is used in conjunction with the contents of a COPS message to calculate a message digest that is part of the Integrity object. The Integrity object is then used to validate all COPS messages sent over the TCP connection between a PEP and PDP.
ID) PEPとそのPDPの間で共有されています。 キーはIntegrityオブジェクトの一部であるメッセージダイジェストを計算するCOPSメッセージのコンテンツに関連して使用されます。 Integrityオブジェクトはその時、PEPとPDPとのTCP接続の上に送られたすべてのCOPSメッセージを有効にするのにおいて使用されています。
Key maintenance is outside the scope of this document beyond the specific requirements discussed in section 4.2. In general, it is good practice to regularly change keys to maintain security. Furthermore, it is good practice to use localized keys specific to a particular PEP such that a stolen PEP will not compromise the security of an entire administrative domain.
主要なメインテナンスはこのドキュメントの範囲の外にセクション4.2で議論した決められた一定の要求を超えています。 一般に、警備を維持するために定期的に転調するのは、良い習慣です。 その上、特定のPEPに特定のローカライズしているキーを使用するのは、盗まれたPEPが全体の管理ドメインのセキュリティに感染しないための良い習慣です。
The COPS Integrity object also provides sequence numbers to avoid replay attacks. The PDP chooses the initial sequence number for the PEP and the PEP chooses the initial sequence number for the PDP. These initial numbers are then incremented with each successive message sent over the connection in the corresponding direction. The initial sequence numbers SHOULD be chosen such that they are monotonically increasing and never repeat for a particular key.
また、COPS Integrityオブジェクトは、反射攻撃を避けるために一連番号を提供します。 PDPはPEPの初期シーケンス番号を選びます、そして、PEPはPDPの初期シーケンス番号を選びます。 そして、これらの初期の数は対応する方向でそれぞれの連続したメッセージを接続の上に送って増加されます。 初期の一連番号SHOULDは単調に増加しているようなものが選ばれていて、特定のキーのために決して繰り返しません。
Security between the client (PEP) and server (PDP) MAY be provided by IP Security [IPSEC]. In this case, the IPSEC Authentication Header (AH) SHOULD be used for the validation of the connection; additionally IPSEC Encapsulation Security Payload (ESP) MAY be used to provide both validation and secrecy.
クライアント(PEP)とサーバ(PDP)の間のセキュリティはIP Security[IPSEC]によって提供されるかもしれません。 この場合IPSEC Authentication Header(AH)SHOULD、接続の合法化には、使用されてください。 さらに、IPSEC Encapsulation Security有効搭載量(超能力)は、合法化と秘密保持の両方を提供するのに使用されるかもしれません。
Transport Layer Security [TLS] MAY be used for both connection-level validation and privacy.
輸送Layer Security[TLS]は接続レベル合法化とプライバシーの両方に使用されるかもしれません。
6. IANA Considerations
6. IANA問題
The Client-type identifies the policy client application to which a message refers. Client-type values within the range 0x0001-0x3FFF are reserved Specification Required status as defined in [IANA- CONSIDERATIONS]. These values MUST be registered with IANA and their behavior and applicability MUST be described in a COPS extension document.
Client-タイプはメッセージが参照される方針クライアントアプリケーションを特定します。 0×0001範囲0x3FFFの中のクライアントタイプ値は[IANA- CONSIDERATIONS]で定義されるように予約されたSpecification Required状態です。 これらの値をIANAに示さなければなりません、そして、COPS拡大ドキュメントで彼らの振舞いと適用性について説明しなければなりません。
Client-type values in the range 0x4000 - 0x7FFF are reserved for Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types are not tracked by IANA and are not to be used in standards or general-release products, as their uniqueness cannot be assured.
範囲0x4000のクライアントタイプ値--0x7FFFは兵士のUseのために[IANA-CONSIDERATIONS]で定義されるように予約されます。 これらのClient-タイプをIANAによって追跡されないで、規格か一般的なリリース製品の中に使用してはいけません、それらのユニークさを保証できないように。
Client-type values in the range 0x8000 - 0xFFFF are First Come First Served as defined in [IANA-CONSIDERATIONS]. These Client-types are tracked by IANA but do not require published documents describing their use. IANA merely assures their uniqueness.
範囲0x8000のクライアントタイプ値--0xFFFFは[IANA-CONSIDERATIONS]で定義されるようにFirst Come First Servedです。 これらのClient-タイプは、IANAによって追跡されますが、彼らの使用について説明する公表された文書を必要としません。 IANAは単にそれらのユニークさを保証します。
Durham, et al. Standards Track [Page 34] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[34ページ]。
Objects in the COPS Protocol are identified by their C-Num and C-Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] is required to introduce new values for these numbers and, therefore, new objects into the base COPS protocol.
COPSプロトコルのオブジェクトは彼らのC-ヌムとC-タイプ値によって特定されます。 [IANA-CONSIDERATIONS]で特定されるIETF Consensusがこれらの数としたがって、新しいオブジェクトのためにベースCOPSプロトコルに新しい値を取り入れるのが必要です。
Additional Context Object R-Types, Reason-Codes, Report-Types, Decision Object Command-Codes/Flags, and Error-Codes MAY be defined for use with future Client-types, but such additions require IETF Consensus as defined in [IANA-CONSIDERATIONS].
追加Context Object R-タイプ、Reason-コード、Report-タイプ、Decision Object Command-コード/旗、およびError-コードは使用のために将来のClient-タイプで定義されるかもしれませんが、そのような追加は[IANA-CONSIDERATIONS]で定義されるようにIETF Consensusを必要とします。
Context Object M-Types, Reason Sub-Codes, and Error Sub-codes MAY be defined relative to a particular Client-type following the same IANA considerations as their respective Client-type.
文脈Object Mタイプ、Reason Sub-コード、およびError Sub-コードは彼らのそれぞれのClient-タイプと同じIANA問題に従う特定のClient-タイプに比例して定義されるかもしれません。
7. References
7. 参照
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol
(RSVP) Version 1 - Functional Specification",
RFC 2205, September 1997.
[RSVP] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)バージョン1について議定書の中で述べます--機能的な仕様」、RFC2205、1997年9月。
[WRK] Yavatkar, R., Pendarakis, D. and R. Guerin, "A
Framework for Policy-Based Admission Control",
RFC 2753, January 2000.
[WRK] YavatkarとR.とPendarakisとD.とR.ゲラン、「方針ベースの入場コントロールのためのフレームワーク」、RFC2753、2000年1月。
[SRVLOC] Guttman, E., Perkins, C., Veizades, J. and M.
Day, "Service Location Protocol , Version 2",
RFC 2608, June 1999.
[SRVLOC]Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[INSCH] Shenker, S. and J. Wroclawski, "General
Characterization Parameters for Integrated
Service Network Elements", RFC 2215, September
1997.
[INSCH] ShenkerとS.とJ.Wroclawski、「統合サービスネットワークElementsへの一般的性質パラメタ」、RFC2215、1997年9月。
[IPSEC] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, August 1995.
[IPSEC] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1995年8月。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti,
"HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RSVPPR] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RSVPPR] ブレーデンとR.とL.チャン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1メッセージ処理は統治する」RFC2209、1997年9月。
Durham, et al. Standards Track [Page 35] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[35ページ]。
[TLS] Dierks T. and C. Allen, "The TLS Protocol
Version 1.0", RFC 2246, January 1999.
[TLS] Dierks T.とC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[IANA] http://www.isi.edu/in-
notes/iana/assignments/port-numbers
[IANA] http://www.isi.edu/in- 注意/iana/課題/ポートナンバー
[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. Author Information and Acknowledgments
8. 作者情報と承認
Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable contributions.
彼らの有価約因のための特別な感謝のアンドリュー・スミスとティモシー・オマリーへの私たちのWG Chairs、Raj Yavatkar、ラッセルFenger、フレッド・ベイカー、ローラカニンハム、Rochゲラン、Ping Pan、およびデーメートリオスPendarakis。
Jim Boyle Level 3 Communications 1025 Eldorado Boulevard Broomfield, CO 80021
ジムボイルLevel3 コミュニケーション1025エルドラドBoulevardブルームフィールド、CO 80021
Phone: 720.888.1192 EMail: jboyle@Level3.net
以下に電話をしてください。 720.888.1192 メールしてください: jboyle@Level3.net
Ron Cohen CISCO Systems 4 Maskit St. Herzeliya Pituach 46766 Israel
ロンコーエンコクチマスシステム4Maskit聖Herzeliya Pituach46766イスラエル
Phone: +972.9.9700064 EMail: ronc@cisco.com
以下に電話をしてください。 +972.9 .9700064はメールされます: ronc@cisco.com
David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124
第25デヴィッドダラムインテル2111Ne Avenueヒースボロー、または97124
Phone: 503.264.6232 EMail: David.Durham@intel.com
以下に電話をしてください。 503.264.6232 メールしてください: David.Durham@intel.com
Durham, et al. Standards Track [Page 36] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[36ページ]。
Raju Rajan AT&T Shannon Laboratory 180 Park Avenue P.O. Box 971 Florham Park, NJ 07932-0971
ラジュRajan AT&Tシャノン研究所180パーク・アベニュー私書箱971Florham公園、ニュージャージー07932-0971
EMail: rajan@research.att.com
メール: rajan@research.att.com
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
Arun Sastry Cisco Systems 4 The Square Stockley Park Uxbridge, Middlesex UB11 1BN UK
アルンSastryシスコシステムズ4正方形のストックリー・Parkアクスブリッジ、ミドルセックスUB11 1BNイギリス
Phone: +44-208-756-8693 EMail: asastry@cisco.com
以下に電話をしてください。 +44-208-756-8693 メールしてください: asastry@cisco.com
Durham, et al. Standards Track [Page 37] RFC 2748 COPS January 2000
ダラム、他 規格は2000年1月にRFC巡査2748部を追跡します[37ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Durham, et al. Standards Track [Page 38]
ダラム、他 標準化過程[38ページ]
一覧
スポンサーリンク
