RFC1503 日本語訳
1503 Algorithms for Automating Administration in SNMPv2 Managers. K.McCloghrie, M. Rose. August 1993. (Format: TXT=33542 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. McCloghrie
Request for Comments: 1503 Hughes LAN Systems
M. Rose
Dover Beach Consulting, Inc.
August 1993
McCloghrieがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1503台のヒューズLANシステムM.がドーヴァービーチコンサルティングInc.1993年8月に上昇しました。
Algorithms for Automating Administration
in SNMPv2 Managers
SNMPv2マネージャで政権を自動化するためのアルゴリズム
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction .......................................... 1 2. Implementation Model .................................. 1 3. Configuration Assumptions ............................. 3 4. Normal Operations ..................................... 4 4.1 Getting a Context Handle ............................. 4 4.2 Requesting an Operation .............................. 7 5. Determining and Using Maintenance Knowledge ........... 8 5.1 Determination of Synchronization Knowledge ........... 9 5.2 Use of Clock Synchronization Knowledge ............... 10 5.3 Determination of Secret Update Knowledge ............. 11 5.4 Use of Secret Update Knowledge ....................... 13 6. Other Kinds and Uses of Maintenance Knowledge ......... 13 7. Security Considerations ............................... 13 8. Acknowledgements ...................................... 13 9. References ............................................ 14 10. Authors' Addresses ................................... 14
1. 序論… 1 2. 実装モデル… 1 3. 構成仮定… 3 4. 通常の操作… 4 4.1 文脈ハンドルを手に入れます… 4 4.2 操作を要求します… 7 5. メインテナンス知識を決定して、使用します… 8 5.1 同期知識の決断… 9 5.2 時計同期知識の使用… 10 5.3 秘密のアップデート知識の決断… 11 5.4 秘密のアップデート知識の使用… 13 6. メインテナンス知識の他の種類と用途… 13 7. セキュリティ問題… 13 8. 承認… 13 9. 参照… 14 10. 作者のアドレス… 14
1. Introduction
1. 序論
When a user invokes an SNMPv2 [1] management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal.
ユーザがSNMPv2[1]管理アプリケーションを呼び出すとき、ユーザがSNMPv2コミュニケーションを確立して、維持するのに必要な最小の情報量を指定するのは、望ましいかもしれません。 このメモは、この目標を達成するためにアプローチを示します。
2. Implementation Model
2. 実装モデル
In order to discuss the approach outlined in this memo, it is useful to have a model of how the various parts of an SNMPv2 manager fit together. The model assumed in this memo is depicted in Figure 2.1. This model is, of course, merely for expository purposes, and the
このメモに概説されたアプローチについて議論するために、SNMPv2マネージャの様々な部分がどう一緒に合うかに関するモデルがあるのは、役に立ちます。 このメモで思われたモデルは図2.1に表現されます。 そしてこのモデルがもちろん単に解説の目的に賛成する。
McCloghrie & Rose [Page 1] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[1ページ]RFC1503
approach should be readily adaptable to other models.
他のモデルにおいて、アプローチは容易に融通がきくべきです。
(Human) User
*
*
===========User Interface (UI)===========
*
+--------------------------+
... | Management Application N |
+---------------------------+ |
| Management Application 2 |-----+
+--------------------------+ | *
| Management Application 1 |----+ *
+--------------------------+ * *
* * *
========Management API======================
* *
* ________ *
+-------------+ / Local \ +---------------+
| Context |***/ Party \***| SNMP protocol |
| Resolver(s) | \ Database / | engine(s) |
+-------------+ \________/ +---------------+
*
*
===========Transport APIs============
*
+---------------------------------+
| Transport Stacks (e.g., UDP/IP) |
+---------------------------------+
*
Network(s)
(人間)ユーザ**===========ユーザーインタフェース(UI)=========== * +--------------------------+ ... | 管理アプリケーションN| +---------------------------+ | | 管理アプリケーション2|-----+ +--------------------------+ | * | 管理アプリケーション1|----+ * +--------------------------+ * * * * * ========管理API====================== * * * ________ * +-------------+/地方の\+---------------+ | 文脈|***/パーティ\***| SNMPプロトコル| | レゾルバ| \データベース/| エンジン| +-------------+ \________/ +---------------+ * * ===========輸送API============ * +---------------------------------+ | 輸送スタック(例えば、UDP/IP)| +---------------------------------+ *ネットワーク(s)
Figure 2.1 SNMPv2 Manager Implementation Model
図2.1 SNMPv2マネージャ実装モデル
Note that there might be just one SNMP protocol engine and one "context resolver" which are accessed by all local management applications, or, each management application might have its own SNMP protocol engine and its own "context resolver", all of which have shared access to the local party database [2].
すべての現地管理職者アプリケーションでアクセスされるちょうど1台のSNMPプロトコルエンジンと1「文脈レゾルバ」があるかもしれないか、またはそれぞれの管理アプリケーションにはそれ自身のSNMPプロトコルエンジンとそれ自身の「文脈レゾルバ」があるかもしれないというメモ。それのすべてが地方政党データベース[2]へのアクセスを共有しました。
In addition to the elements shown in the figure, there would need to be an interface for the administrator to access the local party database, e.g., for configuring initial information, including secrets. There might also be facilities for different users to have different access privileges, and/or other reasons for there to be multiple (coordinated) subsets of the local party database.
図に示された要素に加えて、管理者が地方政党データベースにアクセスするのにそこでは、インタフェースであることが必要でしょう、例えば、初期の情報を構成するために、秘密を含んでいて。 また、異なったユーザが異なったアクセス権を持つ施設、そして/または、地方政党データベースの複数の(連携する)の部分集合であるそこの他の理由があるかもしれません。
McCloghrie & Rose [Page 2] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[2ページ]RFC1503
3. Configuration Assumptions
3. 構成仮定
Now, let's assume that the administrator has already configured a local party database for the management application, e.g.,
今、管理者が例えば既に管理アプリケーションのための地方政党データベースを構成したと仮定しましょう。
partyIdentifier: initialPartyId.a.b.c.d.1
partyIndex: 1
partyTAddress: a.b.c.d:161
partyLocal: false
partyAuthProtocol: noAuth
partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.1 partyIndex: 1partyTAddress: a. b. c. d: 161partyLocal: 偽のpartyAuthProtocol: noAuth partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.2
partyIndex: 2
partyTAddress: local address
partyLocal: true
partyAuthProtocol: noAuth
partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.2 partyIndex: 2partyTAddress: ローカルアドレスpartyLocal: 本当のpartyAuthProtocol: noAuth partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.3
partyIndex: 3
partyTAddress: a.b.c.d:161
partyLocal: false
partyAuthProtocol: md5Auth
partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.3 partyIndex: 3partyTAddress: a. b. c. d: 161partyLocal: 偽のpartyAuthProtocol: md5Auth partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.4
partyIndex: 4
partyTAddress: local address
partyLocal: true
partyAuthProtocol: md5Auth
partyPrivProtocol: noPriv
partyIdentifier: initialPartyId.a.b.c.d.4 partyIndex: 4partyTAddress: ローカルアドレスpartyLocal: 本当のpartyAuthProtocol: md5Auth partyPrivProtocol: noPriv
contextIdentifier: initialContextId.a.b.c.d.1
contextIndex: 1
contextLocal: false
textual handle: router.xyz.com-public
contextIdentifier: initialContextId.a.b.c.d.1 contextIndex: 1contextLocal: 偽の原文のハンドル: router.xyz.com公共です。
contextIdentifier: initialContextId.a.b.c.d.2
contextIndex: 2
contextLocal: false
textual handle: router.xyz.com-all
contextIdentifier: initialContextId.a.b.c.d.2 contextIndex: 2contextLocal: 偽の原文のハンドル: router.xyz.comすべて、
aclTarget (dest. party): 1
aclSubject (src party): 2
aclResources (context): 1
aclPrivileges: get, get-next, get-bulk
aclTarget(destパーティー): 1aclSubject(srcパーティー): 2 aclResources(文脈): 1aclPrivileges: 気付いて、嵩を得るのに得てください。
McCloghrie & Rose [Page 3] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[3ページ]RFC1503
aclTarget (dest. party): 3
aclSubject (src party): 4
aclResources (context): 2
aclPrivileges: get, get-next, get-bulk, set
aclTarget(destパーティー): 3aclSubject(srcパーティー): 4 aclResources(文脈): 2aclPrivileges: 設定されて、気付いて、嵩を得るのに得てください。
Note that each context has associated with it a "textual handle". This is simply a string chosen by the administrator to aid in selecting a context.
各文脈が「原文のハンドル」をそれに関連づけたことに注意してください。 これは単に文脈を選択する際に支援する管理者によって選ばれたストリングです。
4. Normal Operations
4. 通常操作
When the user tells the management application to do something, the user shouldn't have to specify party or context information.
ユーザが、何かをするように管理アプリケーションに言うとき、ユーザはパーティーか文脈情報を指定する必要はないはずです。
One approach to achieve this is as follows: the user provides a textual string indicating the managed objects to be manipulated, and the management application invokes the "context resolver" to map this into a "context handle", and later, when an SNMPv2 operation is performed, the "context handle" and a minimal set of security requirements are provided to the management API.
これを達成する1つのアプローチは以下の通りです: ユーザは操られるために管理オブジェクトを示す原文のストリングを提供します、そして、管理アプリケーションは「文脈ハンドル」にこれを写像するために「文脈レゾルバ」を呼び出します、そして、後でSNMPv2操作を実行するとき、「文脈ハンドル」と1人の極小集合のセキュリティ要件を管理APIに提供します。
4.1. Getting a Context Handle
4.1. 文脈ハンドルを手に入れます。
A "context handle" is created when the management application supplies a textual string, that was probably given to it by the user. The "context resolver" performs these steps based on the application's input:
管理アプリケーションが原文のストリングを供給するとき、「文脈ハンドル」は作成されて、それはたぶんユーザによってそれに与えられました。 「文脈レゾルバ」はアプリケーションの入力に基づくこれらのステップを実行します:
(1) In the local party database, each context has associated
with it a unique string, termed its "textual handle". If
a context in the local database has a textual handle
which exactly matches the textual string, then the
"context resolver" returns a handle identifying that
context.
(1) 地方政党データベースでは、各文脈は「原文のハンドル」と呼ばれたユニークなストリングをそれに関連づけました。 ローカルのデータベースの文脈にまさに原文のストリングに合っている原文のハンドルがあるなら、「文脈レゾルバ」はその文脈を特定するハンドルを返します。
So, if the application supplies "router.xyz.com-public",
then the "context resolver" returns a handle to the first
context; instead, if the application supplies
"router.xyz.com-all", then the "context resolver" returns
a handle to the second context.
それで、アプリケーションが「router.xyz.com-公衆」を供給するなら、「文脈レゾルバ」は最初の文脈にハンドルを返します。 代わりに、アプリケーションが「router.xyz.comすべて、」を供給するなら、「文脈レゾルバ」は2番目の文脈にハンドルを返します。
(2) Otherwise, if any contexts are present whose textual
handle is longer than the textual string, and whose
initial characters exactly match the entire textual
string, then the "context resolver" returns a handle
identifying all of those contexts.
(2) 何か文脈が別の方法で原文のハンドルが原文のストリングより長く、初期のキャラクタがまさに全体の原文のストリングに合っているプレゼント、次に、「文脈レゾルバ」がそれらの文脈のすべてを特定するハンドルを返すということであるなら。
So, if the application supplies "router.xyz.com", then
そのように次に、アプリケーションが"router.xyz.com"を供給するなら
McCloghrie & Rose [Page 4] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[4ページ]RFC1503
the "context resolver" returns a handle to both contexts.
「文脈レゾルバ」は両方の文脈にハンドルを返します。
(3) Otherwise, if the textual string specifies an IP address
or a domain name which resolves to a single IP address,
then the "context resolver" adds to the local party
database, a volatile noAuth/noPriv party pair, a volatile
context, and a volatile access control entry allowing
interrogation operations, using the "initialPartyId" and
"initialContextId" conventions. The "context resolver"
returns a handle identifying the newly created context.
(3) 原文のストリングが単一のIPへの決議が扱うIPアドレスかドメイン名を指定するなら、さもなければ、「文脈レゾルバ」は査問操作を許す地方政党データベース、揮発性のnoAuth/noPrivパーティー組、揮発性の関係、および揮発性のアクセス制御エントリーの一助となります、"initialPartyId"と"initialContextId"コンベンションを使用して。 「文脈レゾルバ」は新たに作成された文脈を特定するハンドルを返します。
So, if the application supplies "89.0.0.1", then the
"context resolver" adds the following information to the
local party database:
そのように、アプリケーション供給であるなら「89.0 .0 次に、何0.1インチも、「文脈レゾルバ」は以下の情報を地方政党データベースに追加します:、」
partyIdentifier: initialPartyId.89.0.0.1.1
partyIndex: 101
partyTAddress: 89.0.0.1:161
partyLocal: false
partyAuthProtocol: noAuth
partyPrivProtocol: noPriv
partyStorageType: volatile
partyIdentifier: initialPartyId、.89 .0 .0 .1 .1partyIndex: 101partyTAddress: 89.0.0.1 : 161partyLocal: 偽のpartyAuthProtocol: noAuth partyPrivProtocol: noPriv partyStorageType: 揮発性
partyIdentifier: initialPartyId.89.0.0.1.2
partyIndex: 102
partyTAddress: local address
partyLocal: true
partyAuthProtocol: noAuth
partyPrivProtocol: noPriv
partyStorageType: volatile
partyIdentifier: initialPartyId、.89 .0 .0 .1 .2partyIndex: 102partyTAddress: ローカルアドレスpartyLocal: 本当のpartyAuthProtocol: noAuth partyPrivProtocol: noPriv partyStorageType: 揮発性
contextIdentifier: initialContextId.89.0.0.1.1
contextIndex: 101
contextLocal: false
contextStorageType: volatile
textual handle: 89.0.0.1
contextIdentifier: initialContextId、.89 .0 .0 .1 .1contextIndex: 101contextLocal: 偽のcontextStorageType: 揮発性の原文のハンドル: 89.0.0.1
aclTarget (dest. party): 101
aclSubject (src party): 102
aclResources (context): 101
aclPrivileges: get, get-next, get-bulk
aclStorageType: volatile
aclTarget(destパーティー): 101aclSubject(srcパーティー): 102 aclResources(文脈): 101aclPrivileges: 得てください、気付いていて、嵩を得ているaclStorageType: 揮発性
and the "context resolver" returns a handle to the newly
created context.
そして、「文脈レゾルバ」は新たに作成された文脈にハンドルを返します。
(4) Otherwise, if the textual string specifies a domain name
which resolves to multiple IP addresses, then for each
(4) さもなければ、原文のストリングがドメイン名を指定するなら、どれがそして、それぞれのために複数のIPにアドレスを決議しますか?
McCloghrie & Rose [Page 5] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[5ページ]RFC1503
such IP address, the "context resolver" adds to the local
party database, a volatile noAuth/noPriv party pair, a
volatile context, and a volatile access control entry
allowing interrogation operations, using the
"initialPartyId" and "initialContextId" conventions.
Then, the "context resolver" returns a handle identifying
all of those newly created contexts.
そのようなIPアドレス、「文脈レゾルバ」は査問操作を許す地方政党データベース、揮発性のnoAuth/noPrivパーティー組、揮発性の関係、および揮発性のアクセス制御エントリーの一助となります、"initialPartyId"と"initialContextId"コンベンションを使用して。 そして、「文脈レゾルバ」はそれらの新たに作成された文脈のすべてを特定するハンドルを返します。
(5) Otherwise, if the textual string contains a '/'-
character, and everything to the left of the first
occurrence of this character specifies an IP address or a
domain name which resolves to a single IP address, then
the "context resolver" adds to the local party database,
a volatile SNMPv1 party, a volatile context, and a
volatile access control entry allowing interrogation
operations. (The SNMPv1 community string consists of any
characters following the first occurrence of the '/'-
character in the textual string.) Then, the "context
resolver" returns a handle identifying the newly created
context.
'(5) さもなければ、原文のストリングがa'/'--キャラクタを含んでいて、このキャラクタの最初の発生の左へのすべてが単一のIPへの決議が扱うIPアドレスかドメイン名を指定するなら、「文脈レゾルバ」は査問操作を許す地方政党データベース、揮発性のSNMPv1パーティー、揮発性の関係、および揮発性のアクセス制御エントリーの一助となります。 '(SNMPv1共同体ストリングは'/'の最初の発生の後をつけるどんなキャラクタからも成ります--原文のストリングのキャラクタ。) そして、「文脈レゾルバ」は新たに作成された文脈を特定するハンドルを返します。
So, if the application supplied "89.0.0.2/public", then
the "context resolver" adds the following information to
the local party database:
そのように、アプリケーションであるなら供給、「89.0、.0.2/公衆、」、次に、「文脈レゾルバ」は以下の情報を地方政党データベースに追加します:
partyIdentifier: initialPartyId.89.0.0.2.1
partyIndex: 201
partyTDomain: rfc1157Domain
partyTAddress: 89.0.0.2:161
partyLocal: false
partyAuthProtocol: rfc1157noAuth
partyAuthPrivate: public
partyPrivProtocol: noPriv
partyStorageType: volatile
partyIdentifier: initialPartyId、.89 .0 .0 .2 .1partyIndex: 201partyTDomain: rfc1157Domain partyTAddress: 89.0.0.2 : 161partyLocal: 偽のpartyAuthProtocol: rfc1157noAuth partyAuthPrivate: 公共のpartyPrivProtocol: noPriv partyStorageType: 揮発性
contextIdentifier: initialContextId.89.0.0.2.1
contextIndex: 201
contextLocal: false
contextStorageType: volatile
textual handle: 89.0.0.2
contextIdentifier: initialContextId、.89 .0 .0 .2 .1contextIndex: 201contextLocal: 偽のcontextStorageType: 揮発性の原文のハンドル: 89.0.0.2
aclTarget (dest. party): 201
aclSubject (src party): 201
aclResources (context): 201
aclPrivileges: get, get-next, get-bulk
aclStorageType: volatile
aclTarget(destパーティー): 201aclSubject(srcパーティー): 201 aclResources(文脈): 201aclPrivileges: 得てください、気付いていて、嵩を得ているaclStorageType: 揮発性
and the "context resolver" returns a handle to the the
そして、「文脈レゾルバ」はハンドルを返します。
McCloghrie & Rose [Page 6] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[6ページ]RFC1503
newly created context.
新たに作成された文脈。
(6) Otherwise, if the textual string contains a '/'-
character, and everything to the left of the first
occurrence of this character specifies a domain name
which resolves to multiple IP addresses, then for each
such IP address, the "context resolver" adds to the local
party database, a volatile SNMPv1 party, a volatile
context, and a volatile access control entry allowing
interrogation operations. (The SNMPv1 community string
consists of any characters following the first occurrence
of the '/'-character in the textual string.) Then, the
"context resolver" returns a handle identifying all of
those newly created contexts.
'(6) さもなければ、原文のストリングがa'/'--キャラクタを含んでいて、このキャラクタの最初の発生の左へのすべてが複数のIPにアドレスを決議するドメイン名を指定するなら、そのようなそれぞれのIPアドレスのために、「文脈レゾルバ」は査問操作を許す地方政党データベース、揮発性のSNMPv1パーティー、揮発性の関係、および揮発性のアクセス制御エントリーの一助となります。 '(SNMPv1共同体ストリングは原文のストリングにおける、'/'キャラクタの最初の発生の後をつけるどんなキャラクタからも成ります。) そして、「文脈レゾルバ」はそれらの新たに作成された文脈のすべてを特定するハンドルを返します。
(7) Otherwise, an error is raised.
(7) さもなければ、誤りは高くしています。
4.2. Requesting an Operation
4.2. 操作を要求します。
Later, when an SNMPv2 operation is to be performed, the management application supplies a "context handle" and a minimal set of security requirements to the management API:
その後SNMPv2操作が実行されることであるときに、管理アプリケーションは「文脈ハンドル」と1人の極小集合のセキュリティ要件を管理APIに提供します:
(1) If the "context handle" refers to a single context, then
all access control entries having that context as its
aclResources, allowing the specified operation, having a
non-local SNMPv2 party as its aclTarget, which satisfies
the privacy requirements, and having a local party as its
aclSubject, which satisfies the authentication
requirements, are identified.
(1) 「文脈ハンドル」がただ一つの文脈を示すなら、すべてがaclResourcesとしてその文脈を持っているコントロールエントリーにアクセスします、指定された操作を許して、aclTargetとしての非地元のSNMPv2パーティーを開いて、aclSubject(認証要件を満たす)が特定されるので地方政党を開いて。aclTargetはプライバシー要件を満たします。
So, if the application wanted to issue a get-next
operation, with no security requirements, and supplied a
"context handle" identifying context #1, then acl #1
would be identified.
それで、アプリケーションがセキュリティ要件なしで気付いている操作を発行したくて、文脈#1を特定しながら「文脈ハンドル」を供給するなら、acl#1は特定されるでしょうに。
(2) For each such access control entry, the one which
minimally meets the security requirements is selected for
use. If no such entry is identified, and authentication
requirements are present, then the operation will be not
performed.
(2) そのようなそれぞれのアクセス制御エントリーにおいて、セキュリティ必要条件を最少量で満たすものは使用のために選択されます。 どんなそのようなエントリーも特定されないで、認証要件が存在していると、操作は実行されないでしょう。
So, if the application requests a get-next operation,
with no security requirements, and supplies a "context
handle" identifying context #1, and step 1 above
identified acl #1, then because acl #1 satisfies the no-
security requirements, the operation would be generated
using acl #1, i.e., using party #1, party #2, and context
それで、アプリケーションがセキュリティ要件なしで気付いている操作を要求して、特定されたacl#1の上で文脈#1、およびステップ1を特定しながら「文脈ハンドル」を供給するなら、acl#1がいいえセキュリティ要件を満たすので、操作はすなわち、パーティー#1、パーティー#2を使用することでacl#1を使用して、文脈であると生成されるでしょう。
McCloghrie & Rose [Page 7] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[7ページ]RFC1503
#1.
#1.
(3) Otherwise, all access control entries having the (single)
context as its aclResources, allowing the specified
operation, and having a non-local SNMPv1 party as its
aclTarget, are identified. If no such entry is
identified, then the operation will not performed.
Otherwise, any of the identified access control entries
may be selected for use.
(3) さもなければ、すべてがaclTargetとして指定された操作を許して、非地元のSNMPv1パーティーを開いて、aclResourcesが特定されるので(単一)の文脈を持っているコントロールエントリーにアクセスします。 どれかそのようなエントリーが特定されないと、実行されないで、操作はそうするでしょう。 さもなければ、特定されたアクセス制御エントリーのいずれも使用のために選択されるかもしれません。
The effect of separating out step 3 is to prefer SNMPv2
communications over SNMPv1 communications.
ステップ3を分離するという効果はSNMPv1コミュニケーションよりSNMPv2コミュニケーションを好むことです。
(4) If the "context handle" refers to more than one context,
then all access control entries whose aclResources refers
any one of the contexts, are identified. For each such
context, step 2 is performed, and any (e.g., the first)
access control entry identified is selected for use. If
no access control entry is identified, then step 3 is
performed for each such context, and any (e.g., the
first) access control entry identified is selected for
use.
(4) 「文脈ハンドル」が1以上を示すなら、文脈(当時のaclResourcesが文脈のいずれも参照するすべてのアクセス制御エントリー)は特定されます。 そのような各文脈に関しては、ステップ2は実行されます、そして、エントリーが特定したどんな(例えば、1番目)アクセス制御も使用のために選択されます。 アクセス制御エントリーが全く特定されないなら、ステップ3はそのような各文脈のために実行されます、そして、エントリーが特定したどんな(例えば、1番目)アクセス制御も使用のために選択されます。
So, if the application wanted to issue a get-bulk
operation, with no security requirements, and supplied a
"context handle" identifying contexts #1 and #2, then
acls #1 and #2 would be identified in step 1; and, in
step 2, party #1, party #2, and context #1 would be
selected.
それで、アプリケーションがセキュリティ要件なしで嵩を得ている操作を発行したくて、文脈#1、と#2を特定しながら「文脈ハンドル」を供給するなら、acls#1、と#2、はステップ1で特定されるでしょうに。 そして、ステップ2、パーティー#1では、パーティー#2、および文脈#1は選択されるでしょう。
However, if the application wanted to issue an
authenticated get-bulk operation, and supplied a "context
handle" identifying contexts #1 and #2, then acls #1 and
#2 would still be identified in step 1; but, in step 2,
only acl #2 satisfies the security requirement, and so,
party #3, party #4, and context #2 would be selected.
しかしながら、アプリケーションが認証された嵩を得ている操作を発行したくて、文脈#1、と#2を特定しながら「文脈ハンドル」を供給するなら、acls#1、と#2、はステップ1でまだ特定されているでしょうに。 しかし、ステップ2では、acl#2だけがセキュリティ要件を満たすので、パーティー#3、パーティー#4、および文脈#2は選択されるでしょう。
(5) If no access control entry is identified, then an error
is raised.
(5) アクセス制御エントリーが全く特定されないなら、誤りは高くしています。
Note that for steps 1 and 3, an implementation might choose to pre- compute (i.e., cache) for each context those access control entries having that context as its aclResources.
ステップ1と3のために、実装がaclResourcesとしてその文脈を持っているものがアクセスする各文脈のためにあらかじめ計算している(すなわち、キャッシュ)コントロールエントリーに選ばれるかもしれないことに注意してください。
5. Determining and Using Maintenance Knowledge
5. メインテナンス知識を決定して、使用します。
When using authentication services, two "maintenance" tasks may have to be performed: clock synchronization and secret update. These
認証サービスを使用するとき、2つの「メインテナンス」タスクが実行されなければならないかもしれません: 同期と秘密のアップデートの時間を計ってください。 これら
McCloghrie & Rose [Page 8] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[8ページ]RFC1503
tasks should be performed transparently, independent of the management applications, and without user/administrator intervention. In order to operate transparently, the SNMP protocol engine must maintain "maintenance knowledge" (knowledge of which parties and contexts to use). It is useful for this maintenance knowledge to be determined at run-time, rather than being directly configured by an administrator.
タスクは管理アプリケーションの如何にかかわらずユーザ/管理者介入なしで透過的に実行されるべきです。 透過的に作動するために、SNMPプロトコルエンジンは「メインテナンス知識」(どのパーティーと文脈を使用したらよいかに関する知識)を維持しなければなりません。 このメインテナンス知識がランタイムのときに管理者によって直接構成されるよりむしろ決定しているのは、役に立ちます。
One approach to achieve this is as follows: the first time that the SNMP protocol engine determines that it will be communicating with another SNMPv2 entity, the SNMP protocol engine first consults its local party database and then interrogates its peer, before engaging in the actual communications.
これを達成する1つのアプローチは以下の通りです: SNMPプロトコルエンジンは、SNMPプロトコルエンジンが、それが別のSNMPv2実体で交信することを決定する1回目に最初に、地方政党データベースに相談して、次に、同輩について査問します、実際のコミュニケーションに従事する前に。
Note that with such an approach, both the clock synchronization knowledge, and the secret update knowledge, associated with a party, can each be represented as (a pointer to) an access control entry. Further note that once an implementation has computed this knowledge, it might choose to retain this knowledge across restarts.
そのようなアプローチでそれに注意してください、時計同期知識、および秘密のアップデート知識をパーティーに関連づけて、それぞれ表すことができる両方、(指針、)、アクセス制御エントリー。 実装がいったんこの知識を計算する後、再開の向こう側にこの知識を保有するのを選ぶかもしれないことにさらに注意してください。
5.1. Determination of Synchronization Knowledge
5.1. 同期知識の決断
To determine maintenance knowledge for clock synchronization:
時計同期のためのメインテナンス知識を決定するために:
(1) The SNMP protocol engine examines each active, non-local,
noAuth party.
(1) SNMPプロトコルエンジンはそれぞれのアクティブで、非地元のnoAuthパーティーを調べます。
So, this would be party #1.
それで、これはパーティー#1でしょう。
(2) For each such party, P, all access control entries having
that party as its aclTarget, and allowing the get-bulk
operation, are identified.
そのような各パーティーのための(2)、P、aclTargetと、嵩を得ている操作を許すのが特定されるとき、それを持っているすべてのアクセス制御エントリーがパーティーへ行きます。
So, for party #1, this would be acl #1.
それで、パーティー#1のために、これはacl#1でしょう。
(3) For each such access control entry, A, at least one
active, non-local, md5Auth party, Q, must be present
which meets the following criteria:
そのようなそれぞれのアクセス制御エントリーへの(3)、A、少なくともある能動態、非地方です、md5Authパーティー(Q)は出席しているに違いありません(以下の評価基準を満たします):
- the transport domain and address of P and Q are
identical;
- PとQの輸送ドメインとアドレスは同じです。
- an access control entry, B, exists having either: Q as
its aclTarget and a local party, R, as its aclSubject,
or, Q as its aclSubject and a local party, R, as its
aclTarget; and,
- アクセス制御エントリー(B)はどちらかを持ちながら、存在しています: aclTargetと地方政党、R、aclSubjectとしたQ、aclSubjectとしてのQとローカルはパーティーへ行きます、R、aclTargetとして。 そして
- no clock synchronization knowledge is known for R.
- 時計同期知識は全くRで知られていません。
McCloghrie & Rose [Page 9] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[9ページ]RFC1503
So, for acl #1, party #3 is identified as having the same
transport domain and address as party #1, and being
present as the aclTarget in acl #2, which has local party
#4 as the aclSubject.
それで、acl#に関して、1、パーティー#3はパーティー#1として同じ輸送ドメインとアドレスを持っていて、aclSubjectとして地方政党#4を持っているacl#2におけるaclTargetとして存在しているとして特定されます。
(4) Whenever such a party, Q, is present, then all instances
of the "partyAuthProtocol" and "partyAuthClock" objects
are retrieved via the get-bulk operator using the parties
and context identified by the access control entry, A.
そして、(4) そのようなパーティー(Q)が出席しているときはいつも、"partyAuthProtocol"と"partyAuthClock"オブジェクトのすべてのインスタンスがアクセス制御エントリー(A)で特定されたパーティーと文脈を使用している嵩を得ているオペレータで検索されます。
So, party #1, party #2, and context #1 would be used to
sweep these two columns on the agent.
それで、パーティー#1、パーティー#2、および文脈#1は、これらの2つのコラムをエージェントに掃くのに使用されるでしょう。
(5) Only those instances corresponding to parties in the
local database, which have no clock synchronization
knowledge, and are local mdAuth parties, are examined.
(5) ローカルのデータベースにおけるパーティーにおいて、対応するそれらのインスタンス(時計同期知識を全く持たないで、地元のmdAuthパーティーである)だけが調べられます。
So, only instances corresponding to party #4 are
examined.
それで、パーティー#4に対応するインスタンスだけが調べられます。
(6) For each instance of "partyAuthProtocol", if the
corresponding value does not match the value in the local
database, then a configuration error is signalled, and
the corresponding party is marked as being unavailable
for maintenance knowledge.
(6) "partyAuthProtocol"の各インスタンスにおいて、換算値がローカルのデータベースの値に合っていないなら、構成誤りは合図されて、対応するパーティーはメインテナンス知識を入手できないとしてマークされます。
So, we make sure that the manager and the agent agree
that party #4 is an md5Auth party.
それで、私たちは、マネージャとエージェントが、パーティー#4がmd5Authパーティーであるのに同意するのを確実にします。
(7) For each instance of "partyAuthClock", if the
corresponding value is greater than the value in the
local database, then the authentication clock of the
party is warped according to the procedures defined in
Section 5.3 of [3]. Regardless, A is recorded as the
clock synchronization knowledge for the corresponding
party.
(7) "partyAuthClock"の各インスタンスにおいて、換算値がローカルのデータベースの値より大きいなら、[3]のセクション5.3で定義された手順によると、パーティーの認証時計はゆがんでいます。 不注意に、Aは対応するパーティーへの時計同期知識として記録されます。
So, if the column sweep returns information for party #4,
then party #4's authentication clock is advanced if
necessary, and the clock synchronization knowledge for
party #4 is recorded as acl #1.
それで、コラム一掃がパーティー#4のための情報を返すなら、必要なら、パーティー#4認証時計は進められます、そして、パーティー#4のための時計同期知識はacl#1として記録されます。
5.2. Use of Clock Synchronization Knowledge
5.2. 時計同期知識の使用
Whenever a response to an authenticated operation is not received, the SNMP protocol engine may suspect that a clock synchronization problem for the source party is the cause [3]. The SNMP protocol engine may use different criteria when making this determination; for
認証された操作への応答が受け取られていないときはいつも、SNMPプロトコルエンジンは、ソースパーティーのための時計同期問題が原因[3]であると疑うかもしれません。 この決断をするとき、SNMPプロトコルエンジンは異なった評価基準を使用するかもしれません。 for
McCloghrie & Rose [Page 10] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[10ページ]RFC1503
example: on a retrieval operation, the operation might be retried using an exponential back-off algorithm; in contrast, on a modification operation, the operation would not be automatically retried.
例: 検索操作のときに、操作は指数の下に後部アルゴリズムを使用することで再試行されるかもしれません。 対照的に、変更操作のときに、操作は自動的に再試行されないでしょう。
When clock mis-synchronization for a source party, S, is suspected, if clock synchronization knowledge for S is present, then this knowledge is used to perform steps 4-7 above, which should retrieve the instances of the "partyAuthProtocol" and "partyAuthClock" objects which correspond to S (and perhaps other parties as well). If information on these objects cannot be determined, then S is marked as no longer having clock synchronization knowledge. Otherwise, if the value of the corresponding instance of "partyAuthClock" is greater than the value in the local database, then the authentication clock of the party is warped according to the procedures defined in Section 5.3 of [3], and the original operation is retried, if appropriate.
ソースパーティーのための時計誤同期(S)が疑われるとき、Sのための時計同期知識が存在しているなら、この知識は、上のステップ4-7を実行するのに使用されます。(ステップはS(そして、恐らくまた、相手)に対応する"partyAuthProtocol"と"partyAuthClock"物の例を検索するべきです)。 これらの物の情報が決定できないなら、Sは、もう時計同期知識を持っていないので、著しいです。 オリジナルの操作は、さもなければ、"partyAuthClock"の対応する例の値がローカルのデータベースの値より大きいなら、[3]のセクション5.3で定義された手順によって、パーティーの認証時計はゆがんでいて、再試行されていて、適切です。
So, if traffic from party #4 times out, then a column sweep is automatically initiated, using acl #1 (party #1, party #2, context #1).
それで、コラム一掃はパーティー#4回のアウトからの交通であるなら自動的に開始されます、acl#1(パーティー#1、パーティー#2、文脈#1)を使用して。
When clock mis-synchronization for a source party, S, is suspected, and clock synchronization knowledge for S is not present, then the full algorithm above can be used. In this case, if clock synchronization knowledge for S can be determined, and as a result, "partyAuthClock" value for S in the local database is warped according to the procedures defined in Section 5.3 of [3], then the original operation is retried, if appropriate.
ソースパーティーのための時計誤同期(S)が疑われて、Sのための時計同期知識が存在していないと、上の完全なアルゴリズムを使用できます。 この場合、Sのための時計同期知識が決定できて、その結果、[3]のセクション5.3で定義された手順によると、ローカルのデータベースのSのための"partyAuthClock"値がゆがんでいるなら、オリジナルの操作は、再試行されていて、適切です。
5.3. Determination of Secret Update Knowledge
5.3. 秘密のアップデート知識の決断
To determine maintenance knowledge for secret update:
秘密のための維持知識を決定するために、以下をアップデートしてください。
(1) The SNMP protocol engine examines each active, non-local,
md5Auth party.
(1) SNMPプロトコルエンジンはそれぞれのアクティブで、非地元のmd5Authパーティーを調べます。
So, this would be party #3.
それで、これはパーティー#3でしょう。
(2) For each such party, P, all access control entries having
that party as its aclTarget, and allowing the get-bulk
and set operations, are identified.
そのような各パーティーのための(2)、P、aclTargetと、嵩を得て、セット操作を許すのが特定されるとき、それを持っているすべてのアクセス管理エントリーがパーティーへ行きます。
So, for party #3, this would be acl #2.
それで、パーティー#3のために、これはacl#2でしょう。
(3) For each such access control entry, A, at least one
active, non-local, md5Auth party, Q, must be present
which meets the following criteria:
そのようなそれぞれのアクセス管理エントリーへの(3)、A、少なくともある能動態、非地方です、md5Authパーティー(Q)は出席しているに違いありません(以下の評価基準を満たします):
McCloghrie & Rose [Page 11] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[11ページ]RFC1503
- the transport domain and address of P and Q are
identical;
- PとQの輸送ドメインとアドレスは同じです。
- an access control entry, B, exists having either: Q as
its aclTarget and a local party, R, as its aclSubject,
or, Q as its aclSubject and a local party, R, as its
aclTarget; and,
- アクセス管理エントリー(B)はどちらかを持ちながら、存在しています: aclTargetと地方政党、R、aclSubjectとしたQ、aclSubjectとしてのQとローカルはパーティーへ行きます、R、aclTargetとして。 そして
- no secret update knowledge is known for R.
- どんな秘密のアップデート知識もRで知られていません。
So, for acl #2, party #3 is (redundantly) identified as
having the same transport domain and address as party #3,
and being present as the aclTarget in acl #2, which has
local party #4 as the aclSubject.
それで、acl#に関して、2、パーティー#3はパーティー#3として同じ輸送ドメインとアドレスを持っていて、aclSubjectとして地方政党#4を持っているacl#2におけるaclTargetとして存在しているとして(冗長に)特定されます。
(4) Whenever such a party, Q, is present, then all instances
of the "partyAuthProtocol", "partyAuthClock", and
"partyAuthPrivate" objects are retrieved via the get-bulk
operator using the parties and context identified by the
access control entry, A.
そして、(4) そのようなパーティー(Q)が出席しているときはいつも、"partyAuthProtocol"、"partyAuthClock"、および"partyAuthPrivate"物のすべての例がアクセス管理エントリー(A)で特定されたパーティーと文脈を使用している嵩を得ているオペレータで検索されます。
So, party #3, party #4, and context #2 would be used to
sweep these three columns on the agent.
それで、パーティー#3、パーティー#4、および文脈#2は、これらの3つのコラムをエージェントに掃くのに使用されるでしょう。
(5) Only those instances corresponding to parties in the
local database, which have no secret update knowledge,
and are md5Auth parties, are examined.
(5) ローカルのデータベースにおけるパーティーにおいて、対応するそれらの例(どんな秘密のアップデート知識も持たないで、md5Authパーティーである)だけが調べられます。
So, only instances corresponding to parties #3 and #4 are
examined.
それで、パーティー#3、と#4において、対応する例だけが調べられます。
(6) For each instance of "partyAuthProtocol", if the
corresponding value does not match the value in the local
database, then a configuration error is signalled, and
this party is marked as being unavailable for maintenance
knowledge.
(6) "partyAuthProtocol"の各例において、換算値がローカルのデータベースの値に合っていないなら、構成誤りは合図されて、このパーティーは維持知識を入手できないとしてマークされます。
So, we make sure that the manager and the agent agree
that both party #3 and #4 are md5Auth parties.
それで、私たちは、マネージャとエージェントが、パーティー#3、と#4の両方がmd5Authパーティーであるのに同意するのを確実にします。
(7) For each instance of "partyAuthPrivate", if a
corresponding instance of "partyAuthClock" was also
returned, then A is recorded as the secret update
knowledge for this party.
(7) "partyAuthPrivate"の各例において、また、"partyAuthClock"の対応する例を返したなら、このパーティーへの秘密のアップデート知識としてAを記録します。
So, if the column sweep returned information on party #3,
then the clock synchronization knowledge for party #3
would be recorded as acl #2. Further, if the column
それで、コラム一掃がパーティー#3の情報を返すなら、パーティー#3のための時計同期知識はacl#2として記録されるでしょうに。 さらにコラムです。
McCloghrie & Rose [Page 12] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[12ページ]RFC1503
sweep returned information on party #4, then the clock
synchronization knowledge for party #4 would be recorded
as acl #2.
パーティー#4の返された情報を掃いてください、そして、次に、パーティー#4のための時計同期知識はacl#2として記録されるでしょう。
5.4. Use of Secret Update Knowledge
5.4. 秘密のアップデート知識の使用
Whenever the SNMP protocol engine determines that the authentication clock of a party, S, is approaching an upper limit, and secret update knowledge for S is present, then this knowledge is used to modify the current secret of S and reset the authentication clock of S, according to the procedures defined in Section 5.4 of [3].
SNMPプロトコルエンジンがパーティーの認証時計(S)が上限にアプローチしていて、Sのための秘密のアップデート知識が存在していることを決定するときはいつも、次に、この知識はSの現在の秘密を変更して、Sの認証時計をリセットするのに使用されます、[3]のセクション5.4で定義された手順によると。
So, whenever the SNMP protocol engine decides to update the secrets for party #4, it can automatically use acl #2 (party #3, party #4, context #2) for this purpose.
それで、SNMPプロトコルエンジンが、パーティー#4のための秘密をアップデートすると決めるときはいつも、それは自動的に、このために、acl#2(パーティー#3、パーティー#4、文脈#2)を使用できます。
6. Other Kinds and Uses of Maintenance Knowledge
6. 維持知識の他の種類と用途
Readers should note that there are other kinds of maintenance knowledge that an SNMPv2 manager could derive and use. In the interests of brevity, one example is now considered: when an SNMPv2 manager first communicates with an agent, it may wish to synchronize the maximum-message size values held by itself and the agent.
読者は、他の種類のSNMPv2マネージャが引き出すことができた維持知識と使用があることに注意するべきです。 簡潔さのために、1つの例が現在、考えられます: SNMPv2マネージャが最初にエージェントとコミュニケートするとき、それはそれ自体とエージェントによって保持された最大のメッセージサイズ値を同期させたがっているかもしれません。
For those parties that execute at the agent, the manager retrieves the corresponding instances of partyMaxMessageSize (preferrably using authentication), and, if need be, adjusts the values held in the manager's local party database. Thus, the maintenance knowledge to be determined must allow for retrieval of partyMaxMessageSize.
それがエージェントで処刑するそれらのパーティーに関しては、マネージャは、partyMaxMessageSize(認証を使用することで、preferrablyする)の対応する例を検索して、必要なら、マネージャの地方政党データベースに保持された値を調整します。 したがって、断固とする維持知識はpartyMaxMessageSizeの検索を考慮しなければなりません。
For those parties that execute at the manager, the manager retrieves the corresponding instances of partyMaxMessageSize (using authentication), and, if need be, adjusts the values held in the agent's local party database using the set operation. Thus, the maintenance knowledge to be determined must allow both for retrieval and modification of partyMaxMessageSize.
それがマネージャで処刑するそれらのパーティーに関しては、マネージャは、partyMaxMessageSize(認証を使用する)の対応する例を検索して、必要なら、集合演算を使用することでエージェントの地方政党データベースに保持された値を調整します。 したがって、断固とする維持知識はともにpartyMaxMessageSizeの検索と変更を考慮しなければなりません。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Acknowledgements
8. 承認
Jeffrey D. Case of SNMP Research and the University of Tennessee, and Robert L. Stewart of Xyplex, both provided helpful comments on the ideas contained in this document and the presentation of those ideas.
SNMP Researchとテネシー大学のジェフリーD.Case、およびXyplexのロバート・L.スチュワートは本書では含まれた考えとそれらの考えのプレゼンテーションのときにともに役に立つコメントを提供しました。
McCloghrie & Rose [Page 13] RFC 1503 Automating Administration in SNMPv2 Manager August 1993
マネージャ1993年8月にSNMPv2の政権を自動化するMcCloghrieとローズ[13ページ]RFC1503
9. References
9. 参照
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to version 2 of the Internet-standard Network
Management Framework", RFC 1441, SNMP Research, Inc., Hughes LAN
Systems, Dover Beach Consulting, Inc., Carnegie Mellon
University, April 1993.
[1]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネット標準Network Management Frameworkのバージョン2への序論」、RFC1441、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[2] McCloghrie, K., and J. Galvin, "Party MIB for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes
LAN Systems, Trusted Information Systems, April 1993.
[2]McCloghrie、K.、およびJ.ガルビン、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのパーティMIB」、RFC1447、ヒューズLAN Systems、Trusted情報システム(1993年4月)。
[3] Galvin, J., and K. McCloghrie, "Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1446,
Trusted Information Systems, Hughes LAN Systems, April 1993.
[3] ガルビン、J.、およびK.McCloghrie、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのセキュリティプロトコル」、RFC1446、Trusted情報システム、ヒューズLAN Systems(1993年4月)。
10. Authors' Addresses
10. 作者のアドレス
Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 US
キースMcCloghrieヒューズLANシステム1225チャールストンRoadカリフォルニア94043マウンテンビュー(米国)
Phone: +1 415 966 7934 EMail: kzm@hls.com
以下に電話をしてください。 +1 7934年の415 966メール: kzm@hls.com
Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 US
Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 1052年の415 968メール: mrose@dbc.mtview.ca.us
McCloghrie & Rose [Page 14]
McCloghrieとローズ[14ページ]
一覧
スポンサーリンク
