RFC5343 日本語訳
5343 Simple Network Management Protocol (SNMP) Context EngineIDDiscovery. J. Schoenwaelder. September 2008. (Format: TXT=19938 bytes) (Updates RFC3411) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Schoenwaelder Request for Comments: 5343 Jacobs University Bremen Updates: 3411 September 2008 Category: Standards Track
Schoenwaelderがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5343のジェイコブズ大学ブレーメンアップデート: 3411 2008年9月のカテゴリ: 標準化過程
Simple Network Management Protocol (SNMP) Context EngineID Discovery
簡単なネットワーク管理プロトコル(SNMP)文脈EngineID発見
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
Simple Network Managementプロトコル(SNMP)バージョンthree(SNMPv3)は、アプリケーションがリモートSNMP実体で維持されたオブジェクトを検索するか、または操作するために、リモートSNMPプロトコルエンジンに関する識別子(snmpEngineID)を知っているのを必要とします。
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
このドキュメントはリモートSNMPプロトコルエンジンのsnmpEngineIDを学ぶのに使用できるよく知られるlocalEngineIDと発見メカニズムを紹介します。 提案されたメカニズムは、SNMP機密保護モデルによって提供された特徴から独立していて、また、管理オブジェクトへのアクセスを提供する他のプロトコルインタフェースによって使用されるかもしれません。
This document updates RFC 3411.
このドキュメントはRFC3411をアップデートします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4
3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 手順. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1。 地方のEngineID. . . . . . . . . . . . . . . . . . . . . . 4 3.2。 EngineID発見. . . . . . . . . . . . . . . . . . . . 4 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 6。 承認. . . . . . . . . . . . . . . . . . . . . . . . 7 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 7 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 7
Schoenwaelder Standards Track [Page 1] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[1ページ]。
1. Introduction
1. 序論
To retrieve or manipulate management information using the third version of the Simple Network Management Protocol (SNMPv3) [RFC3410], it is necessary to know the identifier of the remote SNMP protocol engine, the so-called snmpEngineID [RFC3411]. While an appropriate snmpEngineID can in principle be configured on each management application for each SNMP agent, it is often desirable to discover the snmpEngineID automatically.
Simple Network Managementプロトコル(SNMPv3)[RFC3410]の第3バージョンを使用することで経営情報を検索するか、または操るのに、リモートSNMPプロトコルエンジンに関する識別子を知るのが必要です、いわゆるsnmpEngineID[RFC3411]。 それぞれのSNMPエージェントのそれぞれの管理アプリケーションのときに原則として適切なsnmpEngineIDを構成できますが、自動的にsnmpEngineIDを発見するのはしばしば望ましいです。
This document introduces a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models. The mechanism has been designed to coexist with discovery mechanisms that may exist in SNMP security models, such as the authoritative engine identifier discovery of the User-based Security Model (USM) of SNMP [RFC3414].
このドキュメントはリモートSNMPプロトコルエンジンのsnmpEngineIDを学ぶのに使用できる発見メカニズムを紹介します。 提案されたメカニズムはSNMP機密保護モデルによって提供された特徴から独立しています。 メカニズムはSNMP機密保護モデルに存在するかもしれない発見メカニズムと共存するように設計されています、SNMP[RFC3414]のUserベースのSecurity Model(USM)の正式のエンジン識別子発見などのように。
This document updates RFC 3411 [RFC3411] by clarifying the IANA rules for the maintenance of the SnmpEngineID format registry.
このドキュメントは、SnmpEngineID形式登録のメインテナンスのためのIANA規則をはっきりさせることによって、RFC3411[RFC3411]をアップデートします。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Background
2. バックグラウンド
Within an administrative domain, an SNMP engine is uniquely identified by an snmpEngineID value [RFC3411]. An SNMP entity, which consists of an SNMP engine and several SNMP applications, may provide access to multiple contexts.
管理ドメインの中では、snmpEngineID値[RFC3411]によってSNMPエンジンは唯一特定されます。 SNMP実体(SNMPエンジンといくつかのSNMPアプリケーションから成る)は複数の文脈へのアクセスを提供するかもしれません。
An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts [RFC3411]. A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).
SNMP文脈はSNMP実体によってアクセス可能な経営情報の収集です。 経営情報の項目は1つ以上の文脈に存在するかもしれません、そして、SNMP実体は潜在的に、多くの文脈[RFC3411]に近づく手段を持っています。 文脈は特定の文脈(また、contextNameと呼ばれる)を特定する経営情報(また、contextEngineIDと呼ばれる)をホスティングして、文脈が命名する実体のsnmpEngineID値によって特定されます。
To identify an individual item of management information within an administrative domain, a four tuple is used consisting of
a4tupleが中古の成ることであるという管理ドメインの中では、経営情報の個別品目を特定します。
1. a contextEngineID,
1. contextEngineID
2. a contextName,
2. contextName
Schoenwaelder Standards Track [Page 2] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[2ページ]。
3. an object type, and
そして3. オブジェクト・タイプ。
4. its instance identification.
4. そのインスタンス識別。
The last two elements are encoded in an object identifier (OID) value. The contextName is a character string (following the SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB [RFC3411]) while the contextEngineID is an octet string constructed according to the rules defined as part of the SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB [RFC3411].
最後の2つの要素がオブジェクト識別子(OID)値でコード化されます。 contextEngineIDはSNMP-FRAMEWORK-MIB[RFC3411]のSnmpEngineIDの原文のコンベンションの一部と定義された規則に従って構成された八重奏ストリングですが、contextNameは文字列(SNMP-FRAMEWORK-MIB[RFC3411]のSnmpAdminStringの原文のコンベンションに続く)です。
The SNMP protocol operations and the protocol data units (PDUs) operate on OIDs and thus deal with object types and instances [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of a scopedPDU as a data structure containing a contextEngineID, a contextName, and a PDU. The SNMP version 3 (SNMPv3) message format uses ScopedPDUs to exchange management information [RFC3412].
SNMPプロトコル操作とプロトコルデータ単位(PDUs)は、OIDsを作動させて、その結果、オブジェクト・タイプとインスタンス[RFC3416]に対処します。 SNMPアーキテクチャ[RFC3411]はcontextEngineID、contextName、およびPDUを含むデータ構造としてscopedPDUの概念を紹介します。 SNMPバージョン3(SNMPv3)メッセージ・フォーマットは、経営情報[RFC3412]を交換するのにScopedPDUsを使用します。
Within the SNMP framework, contextEngineIDs serve as end-to-end identifiers. This becomes important in situations where SNMP proxies are deployed to translate between protocol versions or to cross middleboxes such as network address translators. In addition, snmpEngineIDs separate the identification of an SNMP engine from the transport addresses used to communicate with an SNMP engine. This property can be used to correlate management information easily, even in situations where multiple different transports were used to retrieve the information or where transport addresses can change dynamically.
SNMPフレームワークの中では、contextEngineIDsは終わりから終わりへの識別子として機能します。 これはSNMPプロキシがプロトコルバージョンの間で翻訳するか、またはネットワークアドレス変換機構などのmiddleboxesに交差するように配布される状況で重要になります。 さらに、snmpEngineIDsはSNMPエンジンとコミュニケートするのに使用される輸送アドレスとSNMPエンジンの識別を切り離します。 経営情報を容易に関連させるのにこの特性を使用できます、複数の異なった輸送が情報を検索するのに使用されたか、または輸送アドレスがダイナミックに変化できる状況でさえ。
To retrieve data from an SNMPv3 agent, it is necessary to know the appropriate contextEngineID. The User-based Security Model (USM) of SNMPv3 provides a mechanism to discover the snmpEngineID of the remote SNMP engine, since this is needed for security processing reasons. The discovered snmpEngineID can subsequently be used as a contextEngineID in a ScopedPDU to access management information local to the remote SNMP engine. Other security models, such as the Transport Security Model (TSM) [TSM], lack such a procedure and may use the discovery mechanism defined in this memo.
SNMPv3エージェントからのデータを検索するために、適切なcontextEngineIDを知るのが必要です。 SNMPv3のUserベースのSecurity Model(USM)はリモートSNMPエンジンのsnmpEngineIDを発見するためにメカニズムを提供します、これがセキュリティ処理理由に必要であるので。 次に、リモートSNMPエンジンへのローカルの経営情報にアクセスするのにcontextEngineIDとしてScopedPDUで発見されたsnmpEngineIDを使用できます。 Transport Security Modelなどの他の機密保護モデル(TSM)[TSM]は、そのような手順を欠いて、このメモで定義された発見メカニズムを使用するかもしれません。
3. Procedure
3. 手順
The proposed discovery mechanism consists of two parts, namely (i) the definition of a special well-known snmpEngineID value, called the localEngineID, which always refers to a local default context, and (ii) the definition of a procedure to acquire the snmpEngineID scalar of the SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known local localEngineID value.
提案された発見メカニズムは、特別なよく知られる地方のlocalEngineID値を使用することでSNMP-FRAMEWORK-MIB[RFC3411]のsnmpEngineIDスカラを取得するために2つの部品、(i) すなわち、いつもローカルのデフォルト関係について言及するlocalEngineIDと呼ばれる特別なよく知られるsnmpEngineID価値の定義、および手順の(ii)定義から成ります。
Schoenwaelder Standards Track [Page 3] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[3ページ]。
3.1. Local EngineID
3.1. 地方のEngineID
An SNMP command responder implementing this specification MUST register their pduTypes using the localEngineID snmpEngineID value (defined below) by invoking the registerContextEngineID() Abstract Service Interface (ASI) defined in RFC 3412 [RFC3412]. This registration is done in addition to the normal registration under the SNMP engine's snmpEngineID. This is consistent with the SNMPv3 specifications since they explicitly allow registration of multiple engineIDs and multiple pduTypes [RFC3412].
RFC3412[RFC3412]で定義されたregisterContextEngineID()の抽象的なService Interface(ASI)を呼び出すことによってlocalEngineID snmpEngineID値(以下では、定義される)を使用して、この仕様を履行するSNMPコマンド応答者はそれらのpduTypesを登録しなければなりません。 SNMPエンジンのsnmpEngineIDの下の通常の登録に加えてこの登録をします。 明らかに複数のengineIDsと複数のpduTypes[RFC3412]の登録を許すので、これはSNMPv3仕様と一致しています。
The SnmpEngineID textual convention [RFC3411] defines that an snmpEngineID value MUST be between 5 and 32 octets long. This specification proposes to use the variable length format 3) of the SnmpEngineID textual convention and to allocate the reserved, unused format value 6, using the enterprise ID 0 for the localEngineID. An ASN.1 definition for localEngineID would look like this:
原文のコンベンション[RFC3411]が定義する5と32の八重奏の間にsnmpEngineID値が長い間あるに違いないSnmpEngineID。 この仕様は、SnmpEngineIDの原文のコンベンションの可変長形式3)を使用して、予約されて、未使用の形式値6を割り当てるよう提案します、localEngineIDに企業ID0を使用して。 localEngineIDのためのASN.1定義はこれに似ているでしょう:
localEngineID OCTET STRING ::= '8000000006'H
localEngineID八重奏は以下を結びます:= '8000000006'H
The localEngineID value always provides access to the default context of an SNMP engine. Note that the localEngineID value is intended to be used as a special value for the contextEngineID field in the ScopedPDU. It MUST NOT be used as a value to identify an SNMP engine; that is, this value MUST NOT be used in the snmpEngineID.0 scalar [RFC3418] or in the msgAuthoritativeEngineID field in the securityParameters of the User-based Security Model (USM) [RFC3414].
localEngineID値はいつもSNMPエンジンのデフォルト文脈へのアクセスを提供します。 ScopedPDUのcontextEngineID分野に特別な値としてlocalEngineID値が使用されることを意図することに注意してください。 SNMPエンジンを特定するのに値としてそれを使用してはいけません。 snmpEngineID.0スカラ[RFC3418]かUserベースのSecurity Model(USM)のsecurityParametersのmsgAuthoritativeEngineID分野[RFC3414]ですなわち、この値を使用してはいけません。
3.2. EngineID Discovery
3.2. EngineID発見
Discovery of the snmpEngineID is done by sending a Read Class protocol operation (see Section 2.8 of [RFC3411]) to retrieve the snmpEngineID scalar using the localEngineID defined above as a contextEngineID value. Implementations SHOULD only perform this discovery step when it is needed. In particular, if security models are used that already discover the remote snmpEngineID (such as USM), then no further discovery is necessary. The same is true in situations where the application already knows a suitable snmpEngineID value.
上でcontextEngineID値と定義されたlocalEngineIDを使用することでsnmpEngineIDスカラを検索するために、Read Classプロトコル操作([RFC3411]のセクション2.8を見る)を送ることによって、snmpEngineIDの発見をします。 それが必要であるときにだけ、実装SHOULDはこの発見ステップを実行します。 機密保護モデルが使用されているなら、特に、それは既に、リモートsnmpEngineID(USMなどの)を発見して、次に、さらなるどんな発見も必要ではありません。 同じくらいはアプリケーションが既に適当なsnmpEngineID値を知っているところで状況で本当です。
The procedure to discover the snmpEngineID of a remote SNMP engine can be described as follows:
以下の通りリモートSNMPエンジンのsnmpEngineIDを発見する手順について説明できます:
1. Check whether a suitable contextEngineID value is already known.
If yes, use the provided contextEngineID value and stop the
discovery procedure.
1. 適当なcontextEngineID値が既に知られているかどうかチェックしてください。 はいなら、提供されたcontextEngineID値を使用してください、そして、発見手順を止めてください。
Schoenwaelder Standards Track [Page 4] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[4ページ]。
2. Check whether the selected security model supports discovery of
the remote snmpEngineID (e.g., USM with its discovery mechanism).
If yes, let the security model perform the discovery. If the
remote snmpEngineID value has been successfully determined,
assign it to the contextEngineID and stop the discovery
procedure.
2. 選択された機密保護モデルがリモートsnmpEngineID(例えば、発見メカニズムがあるUSM)の発見をサポートするかどうかチェックしてください。 はいなら、機密保護モデルに発見を実行させてください。 リモートsnmpEngineID値が首尾よく決定したなら、それをcontextEngineIDに割り当ててください、そして、発見手順を止めてください。
3. Send a Read Class operation to the remote SNMP engine using the
localEngineID value as the contextEngineID in order to retrieve
the scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411].
If successful, set the contextEngineID to the retrieved value and
stop the discovery procedure.
3. SNMP-FRAMEWORK-MIB[RFC3411]のスカラのsnmpEngineID.0を検索するのにcontextEngineIDとしてlocalEngineID値を使用して、リモートSNMPエンジンにRead Class操作を送ってください。 うまくいくなら、検索された値にcontextEngineIDを設定してください、そして、発見手順を止めてください。
4. Return an error indication that a suitable contextEngineID could
not be discovered.
4. 発見されていた状態で適当なcontextEngineIDがそうであることができなかったという誤り表示を返してください。
The procedure outlined above is an example and can be modified to retrieve more variables in step 3, such as the sysObjectID.0 scalar or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418].
上に概説された手順は、例であり、ステップ3における、より多くの変数を検索するように変更できます、SNMPv2-MIB[RFC3418]のsysObjectID.0スカラやsnmpSetSerialNo.0スカラのように。
4. IANA Considerations
4. IANA問題
RFC 3411 requested that IANA create a registry for SnmpEngineID formats. However, RFC 3411 did not ask IANA to record the initial assignments made by RFC 3411 nor did RFC 3411 spell out the precise allocation rules. To address this issue, the following rules are hereby established.
RFC3411は、IANAがSnmpEngineID形式のための登録を作成するよう要求しました。 しかしながら、RFC3411は、RFC3411によってされた初期の課題を記録するようにIANAに頼みませんでした、そして、RFC3411は正確な配分規則について詳しく説明しませんでした。 この問題を扱うために、以下の規則はこれにより確立されます。
IANA maintains a registry for SnmpEngineID formats. The first four octets of an SnmpEngineID carry an enterprise number, while the fifth octet in a variable length SnmpEngineID value, called the format octet, indicates how the following octets are formed. The following format values were allocated in [RFC3411]:
IANAはSnmpEngineID形式のために登録を維持します。 SnmpEngineIDの最初の4つの八重奏が企業番号を運びます、形式八重奏と呼ばれる可変長SnmpEngineID価値における5番目の八重奏は以下の八重奏がどう形成されるかを示しますが。 [RFC3411]に以下の形式値を割り当てました:
Format Description References
------- ----------- ----------
0 reserved, unused [RFC3411]
1 IPv4 address [RFC3411]
2 IPv6 address [RFC3411]
3 MAC address [RFC3411]
4 administratively assigned text [RFC3411]
5 administratively assigned octets [RFC3411]
6-127 reserved, unused [RFC3411]
128-255 enterprise specific [RFC3411]
書式の記述参照------- ----------- ---------- 0 予約されて、未使用の[RFC3411]1IPv4アドレス[RFC3411]2IPv6アドレス[RFC3411]3MACアドレス[RFC3411]4は行政上[RFC3411]5が行政上割り当てたテキストに[RFC3411]6-127が控えた八重奏を割り当てました、未使用の[RFC3411]128-255企業特有です。[RFC3411]
IANA can assign new format values out of the originally assigned and reserved number space 1-127. For new assignments in this number
IANAは元々、割り当てられて、予約された数のスペース1-127から新しい形式値を割り当てることができます。 この数における新しい課題のために
Schoenwaelder Standards Track [Page 5] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[5ページ]。
space, a specification is required as per [RFC5226]. The number space 128-255 is enterprise specific and is not controlled by IANA.
スペース、仕様が[RFC5226]に従って必要です。 数のスペース128-255は、企業特有であり、IANAによって制御されません。
Per this document, IANA has made the following assignment:
このドキュメントに従って、IANAは以下の課題をしました:
Format Description References
------- ----------- ----------
6 local engine [RFC5343]
書式の記述参照------- ----------- ---------- 6の地方のエンジン[RFC5343]
5. Security Considerations
5. セキュリティ問題
SNMP version 3 (SNMPv3) provides cryptographic security to protect devices from unauthorized access. This specification recommends use of the security services provided by SNMPv3. In particular, it is RECOMMENDED to protect the discovery exchange.
SNMPバージョン3(SNMPv3)は、不正アクセスからデバイスを保護するために暗号のセキュリティを提供します。 この仕様はSNMPv3によって提供されたセキュリティー・サービスの使用を推薦します。 それは特に、発見交換を保護するRECOMMENDEDです。
An snmpEngineID can contain information such as a device's MAC address, IPv4 address, IPv6 address, or administratively assigned text. An attacker located behind a router / firewall / network address translator may not be able to obtain this information directly, and he therefore might discover snmpEngineID values in order to obtain this kind of device information.
snmpEngineIDはデバイスのMACアドレス、IPv4アドレス、IPv6アドレス、または行政上割り当てられたテキストなどの情報を含むことができます。 ルータ/ファイアウォール/ネットワークアドレス変換機構の後ろに位置する攻撃者は直接この情報を得ることができないかもしれません、そして、したがって、彼はこの種類のデバイス情報を得るためにsnmpEngineID値を発見するかもしれません。
In many environments, making snmpEngineID values accessible via a security level of noAuthNoPriv will benefit legitimate tools that try to algorithmically determine some basic information about a device. For this reason, the default View-based Access Control Model (VACM) configuration in Appendix A of RFC 3415 [RFC3415] gives noAuthNoPriv read access to the snmpEngineID. Furthermore, the USM discovery mechanism defined in RFC 3414 [RFC3414] uses unprotected messages and reveals snmpEngineID values.
多くの環境で、snmpEngineID値をnoAuthNoPrivのセキュリティー・レベルでアクセスしやすくすると、algorithmicallyにデバイスに関する何らかの基本情報を決定しようとする正統のツールがためになるでしょう。 この理由で、RFC3415[RFC3415]のAppendix AでのデフォルトViewベースのAccess Control Model(VACM)構成はsnmpEngineIDへのアクセスが読まれたnoAuthNoPrivに与えます。 その上、RFC3414[RFC3414]で定義されたUSM発見メカニズムは、保護のないメッセージを使用して、snmpEngineID値を明らかにします。
In highly secure environments, snmpEngineID values can be protected by using the discovery mechanism described in this document together with a security model that does not exchange cleartext SNMP messages, such as the Transport Security Model (TSM) [TSM].
非常に安全な環境で、本書ではcleartext SNMPメッセージを交換しない機密保護モデルと共に説明された発見メカニズムを使用することによって、snmpEngineID値を保護できます、Transport Security Model(TSM)[TSM]などのように。
The isAccessAllowed() abstract service primitive of the SNMP access control subsystem does not take the contextEngineID into account when checking access rights [RFC3411]. As a consequence, it is not possible to define a special view for context engineID discovery. A request with a localEngineID is thus treated like a request with the correct snmpEngineID by the access control subsystem. This is inline with the SNMPv3 design where the authenticated identity is the securityName (together with the securityModel and securityLevel information), and transport addresses or knowledge of contextEngineID values do not impact the access-control decision.
アクセス権[RFC3411]をチェックするとき、SNMPアクセス制御サブシステムにおける原始のisAccessAllowed()抽象的なサービスはcontextEngineIDを考慮に入れません。 結果として、文脈engineID発見のために特別な眺めを定義するのは可能ではありません。 localEngineIDとの要求は正しいsnmpEngineIDとの要求のようにアクセス制御サブシステムでこのようにして扱われます。 これは認証されたアイデンティティがsecurityName(securityModelとsecurityLevel情報に伴う)であるSNMPv3デザインでインラインです、そして、contextEngineID値に関する輸送アドレスか知識がアクセス制御決定に影響を与えません。
Schoenwaelder Standards Track [Page 6] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[6ページ]。
6. Acknowledgments
6. 承認
Dave Perkins suggested the introduction of a "local" contextEngineID during the interim meeting of the ISMS (Integrated Security Model for SNMP) working group in Boston, 2006. Joe Fernandez, David Harrington, Dan Romascanu, and Bert Wijnen provided helpful review and feedback, which helped to improve this document.
デーヴ・パーキンスはボストン、2006年のISMS(SNMPのための統合Security Model)ワーキンググループの当座のミーティングの間、「地方」のcontextEngineIDの導入を勧めました。 ジョー・フェルナンデス、デヴィッド・ハリントン、ダンRomascanu、およびバートWijnenは役立っているレビューとフィードバックを提供しました。(それは、このドキュメントを改良するのを助けました)。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3411] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3412] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
[RFC3416]Presuhn、R.、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3418] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」、STD62、RFC3418、2002年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
7.2. Informative References
7.2. 有益な参照
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
Schoenwaelder Standards Track [Page 7] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[7ページ]。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002.
[RFC3415] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
[TSM] Harrington, D., "Transport Security Model for SNMP", Work
in Progress, July 2008.
[TSM] ハリントン、D.、「SNMPの輸送機密保護モデル」が進歩、2008年7月に働いています。
Author's Address
作者のアドレス
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ユルゲン・Schoenwaelderジェイコブズ・大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
Phone: +49 421 200-3587 EMail: j.schoenwaelder@jacobs-university.de
以下に電話をしてください。 +49 421 200-3587 メールしてください: j.schoenwaelder@jacobs-university.de
Schoenwaelder Standards Track [Page 8] RFC 5343 SNMP Context EngineID Discovery September 2008
Schoenwaelder規格はSNMP文脈EngineID発見2008年9月にRFC5343を追跡します[8ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Schoenwaelder Standards Track [Page 9]
Schoenwaelder標準化過程[9ページ]
一覧
スポンサーリンク
