RFC2962 日本語訳
2962 An SNMP Application Level Gateway for Payload AddressTranslation. D. Raz, J. Schoenwaelder, B. Sugla. October 2000. (Format: TXT=46803 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Raz
Request for Comments: 2962 Lucent Technologies
Category: Informational J. Schoenwaelder
TU Braunschweig
B. Sugla
ISPSoft Inc.
October 2000
Razがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2962年のルーセントテクノロジーズカテゴリ: 情報のJ.のSchoenwaelder TUブラウンシュバイクB.Sugla ISPSoft株式会社2000年10月
An SNMP Application Level Gateway for Payload Address Translation
有効搭載量アドレス変換のためのSNMPアプリケーションレベルゲートウェイ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
IESG Note
IESG注意
This document describes an SNMP application layer gateway (ALG), which may be useful in certain environments. The document does also list the issues and problems that can arise when used as a generic SNMP ALG. Specifically, when using SNMPv3's authentication and privacy mechanisms this approach may be very problematic and jeopardize the SNMP security. The reader is urged to carefully consider these issues before deciding to deploy this type of SNMP ALG.
このドキュメントはSNMP応用層ゲートウェイ(ALG)について説明します。(それは、ある環境で役に立つかもしれません)。 また、ドキュメントはジェネリックSNMP ALGとして使用されると起こることができる問題と問題を記載します。 明確に、SNMPv3の認証とプライバシーメカニズムを使用するとき、このアプローチは、非常に問題が多く、SNMPセキュリティを危険にさらすかもしれません。 読者が、展開すると決める前のこれらの問題がSNMP ALGのこのタイプであると慎重に考えるよう促されます。
Abstract
要約
This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15].
このドキュメントはSNMPパケットのペイロードのIP(インターネットプロトコル)アドレスが1つのグループから別のグループまで静的に写像されるSNMP(簡単なNetwork Managementプロトコル)のために、ALG(アプリケーションLevelゲートウェイ)について説明します。 SNMP ALGは[15]で説明されるようにApplication Levelゲートウェイの特定のケースです。
An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (Network Address Translator) in order to manage several potentially overlapping addressing realms.
SNMP ALGはネットワークマネージメントステーションにIPが扱う闘争を使用する複数のネットワークを経営させます。 NAT(ネットワークAddress Translator)によって、これはいくつかの潜在的に重なっているアドレシング分野を経営するためにSNMPを使用する必要があるところで環境で重要である場合があります。
Raz, et al. Informational [Page 1] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [1ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application Level Gateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms.
このドキュメントはSNMP Application Levelゲートウェイの実装のための要件と制限の詳述を含んでいます。 また、それは、分野に演説しながら闘争することの向こう側にSNMPパケットを交換するために他のアプローチについて議論します。
Table of Contents
目次
1. Introduction ..................................................2 2. Terminology and Concepts Used ................................5 3. Problem Scope and Requirements ................................5 3.1 IP Addresses in SNMP Messages ................................6 3.2 Requirements ..................................................7 4. Translating IP Addresses in SNMP Packets ......................7 4.1 Basic SNMP Application Level Gateway ..........................8 4.2 Advanced SNMP Application Level Gateway ......................8 4.3 Packet Size and UDP Checksum ..................................9 5. Limitations and Alternate Solutions .........................10 6. Security Considerations .....................................12 7. Summary and Recommendations .................................13 8. Current Implementations .....................................14 9. Acknowledgments .............................................14 10. References ...................................................14 11. Authors' Addresses ...........................................16 12. Description of the Encoding of SNMP Packets .................17 13. Full Copyright Statement .....................................20
1. 序論…2 2. 用語と使用される概念…5 3. 問題範囲と要件…5 3.1 IPはSNMPでメッセージを扱います…6 3.2の要件…7 4. IPを翻訳すると、SNMPでは、パケットは扱われます…7 4.1 基本的なSNMPアプリケーションレベルゲートウェイ…8 4.2 SNMPアプリケーションレベルゲートウェイを進めます…8 4.3 パケットサイズとUDPチェックサム…9 5. 制限と代替の解答…10 6. セキュリティ問題…12 7. 概要と推薦…13 8. 現在の実装…14 9. 承認…14 10. 参照…14 11. 作者のアドレス…16 12. SNMPパケットのコード化の記述…17 13. 完全な著作権宣言文…20
1. Introduction
1. 序論
The need for IP address translation arises when a network's internal IP addresses cannot be used outside the network. Using basic network address translation allows local hosts on such private networks (addressing realms) to transparently access the external global Internet and enables access to selective local hosts from the outside. In particular it is not unlikely to have several addressing realms that are using the same private IPv4 address space within the same organization.
ネットワークの外でネットワークの内部のIPアドレスを使用できないとき、IPアドレス変換の必要性は起こります。 基本的なネットワークアドレス変換を使用するのは、そのような私設のネットワーク(分野に演説する)のローカル・ホストが透過的に外部の世界的なインターネットにアクセスするのを許容して、外部から選択能力があるローカル・ホストへのアクセスを可能にします。 それには、特に、同じ組織の中で同じ個人的なIPv4アドレス空間を使用しているいくつかのアドレシング分野がなさそうにはありません。
In many of these cases, there is a need to manage the local addressing realm from a manager site outside the domain. However, managing such a network presents unique problems and challenges. Most available management applications use SNMP (Simple Network Management Protocol) to retrieve information from the network elements. For example, a router may be queried by the management application about the addresses of its neighboring elements. This information is then sent by the router back to the management
これらの場合の多くには、ドメインの外にマネージャサイトから地方のアドレシング分野を経営する必要があります。 しかしながら、そのようなネットワークを経営するのは、ユニークな問題を提示して、挑戦します。 ほとんどの利用可能な管理アプリケーションが、ネットワーク要素からの情報を検索するのに、SNMP(簡単なNetwork Managementプロトコル)を使用します。 例えば、ルータは隣接している要素のアドレスに関する管理アプリケーションで質問されるかもしれません。 そして、ルータはこの情報を管理に送って戻します。
Raz, et al. Informational [Page 2] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [2ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
station as part of the payload of an SNMP packet. In order to retain consistency in the view as seen by the management station we need to be able to locate and translate IP address related information in the payload of such packets.
SNMPパケットのペイロードの一部としてのステーション。 私たちが場所を見つけて、翻訳できる必要がある管理局によって見られるように視点における一貫性を保有するために、IPアドレスはそのようなパケットのペイロードの情報について話しました。
The SNMP Application Level Gateway for Payload Address Translation, or SNMP ALG, is a technique in which the payload of SNMP packets (PDUs) is scanned and IP address related information is translated if needed. In this context, an SNMP ALG can be an additional component in a NAT implementation, or it can be a separate entity, that may reside in the same gateway or even on a separate node. Note that in our context of management application all devices in the network are assumed to have a fixed IP address. Thus, SNMP ALG should only be combined with NAT that uses static address assignment for all the devices in the network.
有効搭載量Address Translation、またはSNMP ALGのためのSNMP Application LevelゲートウェイはSNMPパケット(PDUs)のペイロードがスキャンされて、必要であるならIPアドレス関連情報が翻訳されるテクニックです。 それが別々の実体であるかもしれない、このような関係においては、SNMP ALGはNAT実装で追加コンポーネントであるかもしれませんかそれが同じゲートウェイ、または、別々のノードの上にさえ住むかもしれません。 私たちのネットワークにおけるすべてのデバイスが固定IPアドレスを持っていると思われる管理アプリケーションの文脈でそれに注意してください。 したがって、SNMP ALGはネットワークにおけるすべてのデバイスに静的なアドレス課題を使用するNATに結合されるだけであるべきです。
A typical scenario where SNMP ALG is deployed as part of NAT is presented in figure Figure 1. A manager device is managing a remote stub, with translated IP addresses.
SNMP ALGがNATの一部として配布される典型的なシナリオは図図1に提示されます。 マネージャデバイスは翻訳されたIPアドレスでリモートスタッブを管理しています。
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
+---------------+ . +------------------------------+
| . |
| . | LAN
+----------+ . ---------------
| Manager | Stub border Managed network
+----------+
\ | / . +---------------+ WAN+------------------------------+ |地方のルータ|-----------------|NATとSNMP ALGがあるスタッブルータ| +---------------+ . +------------------------------+ | . | | . | LAN+----------+ . --------------- | マネージャ| スタッブ境界Managedネットワーク+----------+
Figure 1: SNMP ALG in a NAT configuration
図1: NAT構成のSNMP ALG
Raz, et al. Informational [Page 3] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [3ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
A similar scenario occurs when several subnetworks with private (and possibly conflicting) IP addresses are to be managed by the same management station. This scenario is presented in Figure 2.
個人的で(ことによると闘争しています)のIPアドレスがあるいくつかのサブネットワークが同じ管理局によって管理されることになっているとき、同様のシナリオは起こります。 このシナリオは図2に提示されます。
+---------------+ +-----------------+
| SNMP ALG |-----|Management device|
+---------------+ +-----------------+
T1 | | T1
| |
Stub A .............|.... ....|............ Stub B
| |
+---------------+ +----------------+
|Bi-directional | |Bi-directional |
|NAT Router w/ | |NAT Router w/ |
|static address | |static address |
|mapping | |mapping |
+---------------+ +---------------+
| |
| LAN LAN |
------------- -------------
192.10.x.y | | 192.10.x.y
/____\ /____\
+---------------+ +-----------------+ | SNMP ALG|-----|管理デバイス| +---------------+ +-----------------+ T1| | T1| | Aを…………引き抜いてください。|.... ....|............ スタッブB| | +---------------+ +----------------+ |双方向| |双方向| |NATルータ| |NATルータ| |静的なアドレス| |静的なアドレス| |マッピング| |マッピング| +---------------+ +---------------+ | | | ラン・ラン| ------------- ------------- 192.10. x.y| | 192.10. x.y/____\ /____\
Figure 2: Using external SNMP ALG to manage two private networks
図2: 2つの私設のネットワークを経営するのに外部のSNMP ALGを使用します。
Since the devices in the managed network are monitored by the manager device they must obtain a fixed IP address. Therefore, the NAT used in this case must be a basic NAT with a static one to one mapping.
管理されたネットワークにおけるデバイスがマネージャデバイスによってモニターされるので、それらは固定IPアドレスを得なければなりません。 したがって、この場合使用されているNATは静的な1〜1つのマッピングがある基本的なNATであるに違いありません。
An SNMP ALG is required to scan all the payload of SNMP packets, to detect IP address related data, and to translate this data if needed. This is a much more computationally involved process than the bi- directional NAT, however they both use the same translation tables. In many cases the router may be unable to handle SNMP ALG and retain acceptable performance. In these cases it may be better to locate the SNMP ALG outside the router, as described in Figure 2.
必要であるなら、SNMP ALGが、SNMPパケットのすべてのペイロードをスキャンして、IPのアドレスの関連するデータを検出して、このデータを翻訳するのに必要です。 これが両性愛者の方向のNATよりはるかに計算上かかわったプロセスである、しかしながら、それらの両方が同じ変換テーブルを使用します。 多くの場合、ルータは、SNMP ALGを扱って、許容性能を保有できないかもしれません。 これらの場合では、図2で説明されるようにルータの外でSNMP ALGの場所を見つけるほうがよいかもしれません。
Raz, et al. Informational [Page 4] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [4ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
2. Terminology and Concepts Used
2. 用語と使用される概念
In general we adapt the terminology defined in [15]. Our main concern are SNMP messages exchanged between SNMP engines. This document only discusses SNMP messages that are send over UDP, which is the preferred transport mapping for SNMP messages [5]. SNMP messages send over other transports can be handled in a similar way. Thus, the term SNMP packet is used throughout this document to refer to an SNMP message contained in an UDP packet.
一般に、私たちは[15]で定義された用語を適合させます。 私たちの主な関心事はSNMPエンジンの間で交換されたSNMPメッセージです。 このドキュメントはSNMPメッセージについて議論するだけです。UDP(SNMPのためにメッセージ[5]を写像する都合のよい輸送であるもの)を移動してください。 同様の方法で、メッセージが他の輸送の上で送るSNMPを扱うことができます。 したがって、用語SNMPパケットは、UDPパケットに含まれたSNMPメッセージを示すのにこのドキュメント中で使用されます。
SNMP messages contain SNMP PDUs (Protocol Data Units). An SNMP PDU defines the parameters for a specific SNMP protocol operation. The notion of flow is less relevant in this case, and hence we will focus on the information contained in a single SNMP packet.
SNMPメッセージはSNMP PDUs(プロトコルData Units)を含んでいます。 SNMP PDUは特定のSNMPプロトコル操作のためのパラメタを定義します。 流れの概念はこの場合それほど関連していません、そして、したがって、私たちは単一のSNMPパケットに含まれた情報に焦点を合わせるつもりです。
There are currently three versions of SNMP. SNMP version 1 (SNMPv1) protocol is defined in STD 15, RFC 1157 [2]. The SNMP version 2c (SNMPv2c) protocol is defined in RFC 1901 [3], RFC 1905 [4] and RFC 1906 [5]. Finally, the SNMP version 3 (SNMPv3) protocol is defined in RFC 1905 [4], 1906 [5], RFC 2572 [10] and RFC 2574 [12]. See RFC 2570 [9] for a more detailed overview over the SNMP standards. In the following, unless otherwise mentioned, we use the term SNMP in statements that are applicable to all three SNMP versions.
現在、SNMPの3つのバージョンがあります。 SNMPバージョン1(SNMPv1)プロトコルはSTD15、RFC1157[2]で定義されます。 SNMPバージョン2c(SNMPv2c)プロトコルはRFC1901[3]、RFC1905[4]、およびRFC1906[5]で定義されます。 最終的に、SNMPバージョン3(SNMPv3)プロトコルはRFC1905[4]、1906[5]、RFC2572[10]、およびRFC2574[12]で定義されます。 SNMP規格の上で、より詳細な概要のためのRFC2570[9]を見てください。 以下では、別の方法で言及されない場合、私たちはすべての3つのSNMPバージョンに適切な声明でSNMPという用語を使用します。
SNMP uses ASN.1 [13] to define the abstract syntax of the messages. The actual encoding of the messages is done by using the Basic Encoding Rules (BER) [14], which provide the transfer syntax.
SNMPは、メッセージの抽象構文を定義するのにASN.1[13]を使用します。 Basic Encoding Rules(BER)[14]を使用することによって、メッセージの実際のコード化をします。()は転送構文を提供します)。
We refer to packets that go from a management station to the network elements as "outgoing", and packets that go from the network elements to the management station as "incoming".
私たちは、管理局からネットワーク要素まで行くパケットを「送信する」と呼んで、「入来」としてネットワーク要素から管理局まで行くパケットを呼びます。
A basic SNMP ALG is an SNMP ALG implementation in which only IP address values encoded in the IpAddress type are translated. A basic SNMP ALG therefore does not need to be MIB aware.
基本的なSNMP ALGはIpAddressタイプでコード化されたIPアドレス値だけが翻訳されるSNMP ALG実装です。 したがって、基本的なSNMP ALGはMIB意識している必要はありません。
An advanced SNMP ALG is an SNMP ALG implementation which is capable of handling and replacing IP address values encoded in well known IP address data types and instance identifiers derived from those data types. This implies that an advanced SNMP ALG is MIB aware.
高度なSNMP ALGは取り扱いができるSNMP ALG実装とIPにアドレス値がよく知られているIPアドレスデータ型とそれらのデータ型から得られたインスタンス識別子でコード化した取って代わることです。 これは、高度なSNMP ALGがMIB意識しているのを含意します。
3. Problem Scope and Requirements
3. 問題範囲と要件
As mentioned before, in many cases, there is a need to manage a local addressing realm that is using NAT, from a manager site outside the realm. A particular important example is the case of network management service providers who provide network management services from a remote site. Such providers may have many customers, each
多くの場合、以前言及されるように、NATを使用している地方のアドレシング分野を経営する必要があります、分野の外のマネージャサイトから。 特定の重要な例はリモートサイトからネットワーク管理サービスを提供するネットワークマネージメントサービスプロバイダーに関するケースです。 そのようなプロバイダーには、それぞれ多くの顧客がいるかもしれません。
Raz, et al. Informational [Page 5] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [5ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
using the same private address space. When all these addressing realms are to be managed from a single management station address collision occurs. There are two straight forward ways to overcome the address collision. One can
同じプライベート・アドレススペースを使用します。 これらのすべてのアドレシング分野が単一の管理局から経営されることになっているとき、アドレス衝突は起こります。 アドレス衝突に打ち勝つ2つの連続の前進の方法があります。 1はそうすることができます。
1. reassign IP addresses to the different addressing realms, or
2. use static address NAT to hide the address collisions from the
network management application.
1. 異なったアドレシング分野にIPアドレスを再選任するか、または2 静的なアドレスNATを使用して、ネットワークマネージメントアプリケーションからアドレス衝突を隠してください。
The first solution is problematic as it requires both a potentially large set of IP addresses, and the reconfiguration of a large portion of the network. The problem with the second solution is that many network management applications are currently unaware of NAT, and because of the large investment needed in order to make them NAT aware are likely to remain so in the near future.
潜在的に大きいIPアドレスとネットワークの大半の再構成の両方を必要とするとき、最初のソリューションは問題が多いです。 2番目のソリューションに関する問題は多くのネットワークマネージメントアプリケーションが現在、NATに気づかなく、したがって、近い将来それらをNAT意識するようにするのに必要である多額の投資で残りそうであるということです。
Hence, there is a need for a solution that is transparent to the network management application (but not to the user), and that does not require a general reconfiguration of a large portion of the network (i.e. the addressing realm). The SNMP ALG described in this memo is such a solution.
したがって、ネットワークマネージメントアプリケーション(しかし、いずれのユーザにもそうしない)に透明であり、ネットワーク(すなわち、アドレシング分野)の大半の一般的な再構成を必要としないソリューションの必要があります。 このメモで説明されたSNMP ALGはそのようなソリューションです。
3.1 IP Addresses in SNMP Messages
3.1 IPはSNMPでメッセージを扱います。
SNMP messages can contain IP addresses in various places and formats. The following four categories have been identified:
SNMPメッセージは様々な場所と形式にIPアドレスを含むことができます。 以下の4つのカテゴリが特定されました:
1. IP version 4 addresses and masks stored in the IpAddress tagged
ASN.1 data type which are not part of an instance identifier. An
example is the ipAdEntNetMask object defined in the IP-MIB [6].
2. IP version 4 addresses contained in instance identifiers derived
from index objects using the IpAddress data type. An example is
the ipAdEntAddr index object of the IP-MIB [6].
3. IP addresses (any version) contained in OCTET STRINGS. Examples
include addressMapNetworkAddress object of the RMON2-MIB [7], and
IP addresses contained in OCTET STRINGS derived from well-known
textual conventions (e.g. TAddress [5] or Ipv6Address [8] or
InetAddress [19]).
4. IP addresses (any version) contained in instance identifiers
derived from OCTET STRINGS. This may derived from well-known
textual conventions (e.g. TAddress [5] or Ipv6Address [8] or
InetAddress [19]) like the ipv6AddrAddress index object of the
IPV6-MIB [8].
1. アドレスとマスクがIpAddressタグ付けをされたASN.1データ型に保存したインスタンス識別子の一部でないIPバージョン4。 例はIP-MIB[6]で定義されたipAdEntNetMaskオブジェクトです。 2. IPバージョン4アドレスはインスタンスにインデックスオブジェクトからIpAddressデータ型を使用することで得られた識別子を含みました。 例はIP-MIB[6]のipAdEntAddrインデックスオブジェクトです。 3. IPはOCTET STRINGSに含まれた(どんなバージョンも)を扱います。 例はアドレスがよく知られる原文のコンベンションから得られたOCTET STRINGSに含んだRMON2-MIB[7]、およびIPのaddressMapNetworkAddressオブジェクトを含んでいます。(例えば、TAddress[5]、Ipv6Address[8]またはInetAddress[19])。 4. IPはOCTET STRINGSから得られたインスタンス識別子に含まれた(どんなバージョンも)を扱います。 よく知られる原文のコンベンションから派生して、これは好きであるかもしれません。(例えば、TAddress[5]、Ipv6Address[8]またはInetAddress[19])がIPV6-MIB[8]のipv6AddrAddressインデックスオブジェクトが好きです。
Textual conventions that can contain IP addresses can be further divided in NAT friendly and NAT unfriendly ones. A NAT friendly textual convention ensures that the encoding on the wire contains
NATの好意的でNAT無愛想なものでIPアドレスを含むことができる原文のコンベンションはさらに分割できます。 好意的な原文のコンベンションが確実にするワイヤの上のコード化が含むNAT
Raz, et al. Informational [Page 6] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [6ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
sufficient information that an advanced SNMP ALG which understands the textual convention and which has the necessary MIB knowledge can do a proper translation. An example of this type is the Ipv6Address textual convention.
原文のコンベンションを理解していて、必要なMIB知識を持っている高度なSNMP ALGが適切な翻訳ができるという十分な情報。 このタイプに関する例はIpv6Addressの原文のコンベンションです。
A NAT unfriendly textual convention requires that an SNMP ALG, which understands the textual convention and which has the necessary MIB knowledge, has access to additional information in order to do a proper translation. Examples of this type are the TAddress and the InetAddress textual conventions which require that an additional varbind is present in an SNMP packet to determine what type of IP address a given value represents. Such a varbind may or may not be present depending on the way a management applications retrieves data.
NATの無愛想な原文のコンベンションは、SNMP ALG(原文のコンベンションを理解していて、必要なMIB知識を持っている)が適切な翻訳をするために追加情報に近づく手段を持っているのを必要とします。 このタイプに関する例は、与えられた値がどんなタイプのIPアドレスを表すかを決定するために追加varbindがSNMPパケットに存在しているのを必要とするTAddressとInetAddressの原文のコンベンションです。 そのようなvarbindが検索するかもしれませんか、またはアプリケーションは途中での現在の依存が管理であったかもしれないならデータを検索します。
3.2 Requirements
3.2 要件
An SNMP ALG should provide transparent IP address translation to management applications. An SNMP ALG must be compatible with the behavior of the SNMP protocol operations as defined by RFC 1157 [2] and RFC 1905 [4] and must not have negative impact on the security provided by the SNMP protocol. A fully transparent SNMP ALG must be able to translate all categories of IP addresses as described above, when provided with the specified OID's and the encoding details.
SNMP ALGは見え透いたIPアドレス変換を管理アプリケーションに提供するはずです。 SNMP ALGはRFC1157[2]とRFC1905[4]によって定義されるようにSNMPプロトコル操作の振舞いと互換性がなければならなくて、SNMPプロトコルでセキュリティへの負の衝撃を提供させてはいけません。 完全に透明なSNMP ALGは上で説明されるようにIPアドレスのすべてのカテゴリを翻訳できなければなりません、指定されたOIDのものとコード化の詳細を提供するとき。
The SNMP ALG requires bi-directional NAT devices enroute, that support static address mapping for all nodes in the respective private realms. When there are multiple private realms supported by a single SNMP ALG, the external addresses assumed by each of the NAT devices must not collide with each other.
SNMP ALGは途中で双方向のNATデバイスを必要として、そのサポートはそれぞれの私設の分野のすべてのノードのための静的なアドレス・マッピングです。独身のSNMP ALGによってサポートされた複数の私設の分野があるとき、それぞれのNATデバイスによって想定された外部アドレスは互いと衝突してはいけません。
4. Translating IP Addresses in SNMP Packets
4. SNMPパケットでIPアドレスを翻訳します。
This section describes several ways to translate IP addresses in SNMP packets.
このセクションはSNMPパケットでIPアドレスを翻訳するいくつかの方法を述べます。
A general SNMP ALG must be capable to translate IP addresses in outgoing and incoming SNMP packets.
一般的なSNMP ALGは送受信のSNMPパケットでIPアドレスを翻訳できなければなりません。
SNMP messages send over UDP may experience fragmentation at the IP layer. In an extreme case, fragmentation may cause an IP address type to be partitioned into two different fragments. In order to translate IP addresses in SNMP messages, the complete SNMP message must be available. As described in [18], fragments of UDP packets do not carry the destination/source port number with them. Hence, an SNMP ALG must reassemble IP packets which contain SNMP messages. The
メッセージがUDPの上で送るSNMPはIP層で断片化を経験するかもしれません。 はなはだしきに至っては、断片化で、IPアドレスタイプを2個の異なった断片に仕切るかもしれません。 SNMPメッセージのIPアドレスを翻訳するために、完全なSNMPメッセージは利用可能でなければなりません。 [18]で説明されるように、UDPパケットの断片はそれらで目的地/ソースポート番号を運びません。 したがって、SNMP ALGはSNMPメッセージを含むIPパケットを組み立て直さなければなりません。 The
Raz, et al. Informational [Page 7] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [7ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
good news is, however, that usually SNMP agents are aware of the MTU, and that SNMP packets are usually relatively small. Some SNMP implementations also set the don't fragment (DF) bit in the IP header [1] to avoid fragmentation.
朗報はしかしながら、そんなに通常、SNMPエージェントがMTUを意識していて、通常、SNMPパケットが比較的小さいということです。 また、いくつかのSNMP実装がセットした、断片化を避けるためにIPヘッダー[1]で噛み付かれた(DF)を断片化しないでください。
4.1 Basic SNMP Application Level Gateway
4.1 基本的なSNMPアプリケーションレベルゲートウェイ
A basic SNMP ALG is an SNMP ALG implementation in which only IP address values encoded in the IpAddress base type are translated. A basic SNMP ALG implementation parses an ASN.1/BER encoded SNMP packet looking for elements that are encoded using the IpAddress base type. Appendix A contains a more detailed description of the structure and encoding used by SNMP.
基本的なSNMP ALGはIpAddressベースタイプでコード化されたIPアドレス値だけが翻訳されるSNMP ALG実装です。 基本的なSNMP ALG実装はIpAddressベースタイプを使用することでコード化される要素を探すASN.1/BERのコード化されたSNMPパケットを分析します。 付録AはSNMPによって使用された構造とコード化の、より詳細な記述を含んでいます。
An IpAddress value can be identified easily by its tag value (0x40). Once an IpAddress has been detected, the SNMP ALG checks the translation table and decides whether the address should be translated. If the address needs translation, the 4 bytes representing the IPv4 address are replaced with the translated IPv4 address and the UDP checksum is adjusted. Section 4.3 describes an efficient algorithm to adjust the UDP checksum without recalculating it.
タグ値(0×40)で容易にIpAddress値を特定できます。 IpAddressがいったん検出されると、SNMP ALGは、変換テーブルをチェックして、アドレスが翻訳されるべきであるかどうか決めます。 アドレスが翻訳を必要とするなら、IPv4アドレスを表す4バイトを翻訳されたIPv4アドレスに取り替えます、そして、UDPチェックサムを調整します。 セクション4.3は、それについて再計算しないでUDPチェックサムを調整するために効率的なアルゴリズムを説明します。
The basic SNMP ALG does not require knowledge of any MIBs since it relies on the ASN.1/BER encoding of SNMP packets. It is therefore easy to implement. A basic SNMP ALG does not change the overall messages size and hence it does not cause translated messages to be lost due to message size constraints.
SNMPパケットのASN.1/BERコード化を当てにするので、基本的なSNMP ALGはどんなMIBsに関する知識も必要としません。 したがって、それは実装しやすいです。 基本的なSNMP ALGは総合的なメッセージサイズを変えません、そして、したがって、それはメッセージサイズ規制のため失われるべき翻訳されたメッセージを引き起こしません。
However, a basic SNMP ALG is only able to translate IPv4 addresses in objects that use the IpAddress base type. Furthermore, a basic SNMP ALG is not capable to translate IP addresses in objects that are index components of conceptual tables. This is especially problematic on index components that are not accessible. Hence, the basic SNMP ALG is restricted to the first out of the four possible ways to represent IP addresses in SNMP messages (see Section 3.1).
しかしながら、基本的なSNMP ALGはIpAddressベースタイプを使用するオブジェクトでIPv4アドレスを翻訳できるだけです。 その上、基本的なSNMP ALGは概念的なテーブルのインデックスの部品であるオブジェクトでIPアドレスを翻訳できません。 これはアクセスしやすくないインデックスコンポーネントで特に問題が多いです。 したがって、基本的なSNMP ALGはSNMPメッセージのIPアドレスを表す4つの可能な道から1日に制限されます(セクション3.1を見てください)。
4.2 Advanced SNMP Application Level Gateway
4.2 高度なSNMPアプリケーションレベルゲートウェイ
An advanced SNMP ALG is an SNMP ALG implementation which is capable of handling and replacing IP address values encoded in well known IP address data types and instance identifiers derived from those data types. Hence, an advanced SNMP ALG may be able to transparently map IP addresses that are in the format 1-4 as described in Section 3.1. This implies that an advanced SNMP ALG must be MIB aware.
高度なSNMP ALGは取り扱いができるSNMP ALG実装とIPにアドレス値がよく知られているIPアドレスデータ型とそれらのデータ型から得られたインスタンス識別子でコード化した取って代わることです。 したがって、高度なSNMP ALGは透過的に形式には1-4 セクション3.1で説明されるようにあるIPアドレスを写像できるかもしれません。 これは、高度なSNMP ALGがMIB意識しているに違いないのを含意します。
Raz, et al. Informational [Page 8] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [8ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID) translation table in order to identify IP addresses that are not encoded in an IpAddress base type. The OID translation table needs to maintain information about the OIDs where translation may be needed. Furthermore, the translation table needs to keep information about instance identifiers for conceptual tables that contain IP addresses. Such an OID translation table may be populated offline by using a MIB compiler which loads the MIBs used within an addressing realm and searches for types, textual conventions and table indexes that may contain IP addresses.
高度なSNMP ALGは、IpAddressベースタイプでコード化されないIPアドレスを特定するためにOBJECT IDENTIFIER(OID)変換テーブルを維持しなければなりません。 OID変換テーブルは、翻訳が必要であるかもしれないOIDsの情報を保守する必要があります。 その上、変換テーブルは、IPアドレスを含む概念的なテーブルのためのインスタンス識別子の情報を保つ必要があります。 IPアドレスを含むかもしれないアドレシング分野の中で使用されたMIBsを積み込んで、タイプを捜し求めるMIBコンパイラ、原文のコンベンション、およびテーブルインデックスを使用することによって、そのようなOID変換テーブルはオフラインで居住されるかもしれません。
The translation function scans the packet for these specific OIDs, checks the translation table and replaces the data if needed. Note that since OIDs do not have a fixed size this search is much more computationally consuming, and the lookup operation may be expensive.
必要であるなら、翻訳機能は、これらの特定のOIDsのためにパケットをスキャンして、変換テーブルをチェックして、データを置き換えます。 OIDsにはこの検索がはるかに計算上消費している固定サイズがないので、それに注意してください。そうすれば、ルックアップ操作は高価であってもよいです。
The ability to translate IP addresses that are part of the index of a conceptual table is a required feature of an advanced SNMP ALG. IP addresses embedded in an instance identifier are ASN.1/BER encoded according to the OID encoding rules. For example, the OID for the 10.1.2.3 instance of the ipAdEntIfIndex object of the IP-MIB [6] is encoded as 06 0D 2B 06 01 02 01 04 14 01 02 0A 01 02 03. Replacing the embedded private IPv4 address with 135.180.140.202 leads to the OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. This example shows that an advanced SNMP ALG may change the overall packet size since IP addresses embedded in an OID can change the size of the ASN.1/BER encoded OID.
概念的なテーブルのインデックスの一部であるIPアドレスを翻訳する能力は高度なSNMP ALGの必要な特徴です。 インスタンス識別子に埋め込まれたIPアドレスはOID符号化規則によると、コード化されたASN.1/BERです。 例えば、IP-MIB[6]のipAdEntIfIndexオブジェクトの10.1.2.3インスタンスのためのOIDは06 0D 2B06 01 02 01 04 14 01 02 0A01 02 03としてコード化されます。 埋め込まれた個人的なIPv4を取り替えて、135.180でOID06 11 2B06 01 02 01 04 14 01 02 81 07 81 34 81 0Cの81 4Aに.140の.202先導を扱ってください。 この例は、埋め込まれたIPアドレスがOIDでASN.1/BERのコード化されたOIDのサイズを変えることができるので高度なSNMP ALGが総合的なパケットサイズを変えるかもしれないのを示します。
Another effect of an advanced SNMP ALG is that it changes the lexicographic ordering of rows in conceptual tables as seen by the SNMP manager. This may have severe side-effects for management applications that use lexicographic ordering to retrieve only parts of a conceptual table. Many SNMP managers check lexicographic ordering to detect loops caused by broken agents. Such a manager will incorrectly report agents behind an advanced SNMP ALG as broken SNMP agents.
高度なSNMP ALGの別の効果はSNMPマネージャによって見られる概念的なテーブルでの行の辞書編集の注文を変えるということです。 これには、概念的なテーブルの唯一の部分を検索するのに辞書編集の注文を使用する管理アプリケーションのための厳しい副作用があるかもしれません。 多くのSNMPマネージャが、失意のエージェントによって引き起こされた輪を検出するために辞書編集の注文をチェックします。 そのようなマネージャは失意のSNMPエージェントとして高度なSNMP ALGの後ろで不当にエージェントを報告するでしょう。
4.3 Packet Size and UDP Checksum
4.3 パケットサイズとUDPチェックサム
Changing an IpAddress value in an SNMP packet does not change the size of the SNMP packet. A basic SNMP ALG does therefore never change the size of the underlying UDP packet.
SNMPパケットでIpAddress値を変える場合、SNMPパケットのサイズは変化しません。 したがって、基本的なSNMP ALGは基本的なUDPパケットのサイズを決して変えません。
An advanced SNMP ALG may change the size of an SNMP packet since a different number of bytes may be needed to encode a different IP address. This is highly undesirable but unavoidable in the general case. A change of the SNMP packet size requires additional changes in the UDP and IP headers. Increasing packet sizes are especially
異なった数のバイトが異なったIPアドレスをコード化するのに必要であるかもしれないので、高度なSNMP ALGはSNMPパケットのサイズを変えるかもしれません。 これは、一般的な場合において非常に望ましくないのですが、避けられません。 SNMPパケットサイズの変化はUDPとIPヘッダーで付加的な変化を必要とします。 増加するパケットサイズは特にそうです。
Raz, et al. Informational [Page 9] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [9ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
problematic with SNMPv3. The SNMPv3 message header contains the msgMaxSize field so that agents can generate Response PDUs for GetBulkRequest PDUs that are close to the maximum message size the receiver can handle. An SNMP ALG which increases the size of an SNMP packet may have the effect that the Response PDU can not be processed anymore. Thus, an advanced SNMP ALG may cause some SNMPv3 interactions to fail.
SNMPv3では、問題が多いです。 SNMPv3メッセージヘッダーは、エージェントが受信機が扱うことができる最大のメッセージサイズの近くにあるGetBulkRequest PDUsのためにResponse PDUsを生成することができるように、msgMaxSize分野を含んでいます。 SNMPパケットのサイズを増強するSNMP ALGはそれ以上Response PDUを処理できないという効果を持っているかもしれません。 したがって、高度なSNMP ALGはいくつかのSNMPv3相互作用に失敗されるかもしれません。
In both cases, the UDP checksum must be adjusted when making an IP address translation. We can use the algorithm from [18], but a small modification must be introduced as the modified bytes may start on an odd position. The C code shown in Figure 3 adjusts the checksum to a replacement of one byte in an odd or even position.
IPアドレス変換を作るとき、どちらの場合も、UDPチェックサムを調整しなければなりません。 私たちは[18]からアルゴリズムを使用できますが、変更されたバイトが変な位置を始めるとき、小さい変更を導入しなければなりません。 図3に示されたCコードは変であるか同等の位置での1バイトの交換にチェックサムを調整します。
void checksumbyte(unsigned char *chksum, unsigned char *optr,
unsigned char *nptr, int odd)
/* assuming: unsigned char is 8 bits, long is 32 bits,
we replace one byte by one byte in an odd position.
- chksum points to the chksum in the packet
- optr points to the old byte in the packet
- nptr points to the new byte in the packet
- odd is 1 if the byte is in an odd position 0 otherwise
*/
{ long x, old, new;
x=chksum[0]*256+chksum[1];
x=~x & 0xFFFF;
if (odd) old=optr[0]*256; else old=optr[0];
x-=old & 0xFFFF;
if (x<=0) { x--; x&=0xFFFF; }
if (odd) new=nptr[0]*256; else new=nptr[0];
x+=new & 0xFFFF;
if (x & 0x10000) { x++; x&=0xFFFF; }
x=~x & 0xFFFF;
chksum[0]=x/256; chksum[1]=x & 0xFF;
}
checksumbyte(未署名の炭*のchksum、未署名の炭*nptrの、そして、int変な未署名の炭*のoptr)/*仮定を欠如させてください: 未署名の炭は8ビットであり、長いのは、32ビット、私たちが変な位置で1バイトを×1バイト置き換えるということです。 - chksumはパケットにchksumを示します--optrはパケットに古いバイトを示します--nptrはパケットに新しいバイトを示します--そうでなければ、バイトが変な位置0にあるなら変であるのが、1である、*/切望..古い..新しい..変..老人..等しい..ほか..老人..等しい..等しい..老人..変..新しい..ほか..新しい..新しい..0×10000..等しい
5. Limitations and Alternate Solutions
5. 制限と代替策
Making SNMP ALGs completely transparent to all management applications is not an achievable task. The basic SNMP ALG described in Section 4.1 only translates IP addresses encoded in the IpAddress base type. Such an SNMP ALG achieves only very limited transparency since IP addresses are frequently used as part of an index into a conceptual table. A management application will therefore see both the translated as well as the original address, which can lead to
SNMP ALGsをすべての管理アプリケーションに完全に透明にするのは、達成可能なタスクではありません。 セクション4.1で説明された基本的なSNMP ALGはIpAddressベースタイプでコード化されたIPアドレスを翻訳するだけです。 IPアドレスがインデックスの一部として頻繁に概念的なテーブルに使用されるので、そのようなSNMP ALGは非常に限られた透明だけを達成します。 したがってアプリケーションが、翻訳とオリジナルのそうすることができるアドレスの両方が通じるのを見る管理
Raz, et al. Informational [Page 10] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [10ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
confusion and erroneous behavior of management applications. However, a certain class of management applications like e.g. network discovery tools may work pretty well across NATs with a basic SNMP ALG in place.
管理アプリケーションの混乱と誤った働き。 しかしながら、あるクラスの管理アプリケーションは基本的なSNMP ALGが適所にあった状態でツールがNATsの向こう側にかなりよく働くかもしれないという例えばネットワーク発見が好きです。
An advanced SNMP ALG described in Section 4.2 achieves better transparency. However, an advanced SNMP ALG can only claim to be transparent for the set of data types (textual conventions) understood by the advanced SNMP ALG implementation and for a given set of MIB modules. The price paid for better transparency is additional complexity, potentially increased SNMP packet sizes and mixed up lexicographic ordering. Especially with SNMPv3, there is an opportunity that communication fails due to increased packet sizes. Management applications that rely on lexicographic ordering will show erroneous behavior.
セクション4.2で説明された高度なSNMP ALGは、より良い透明を達成します。 しかしながら、高度なSNMP ALGは、高度なSNMP ALG実装に解釈されたデータ型(原文のコンベンション)のセットと与えられたセットのMIBモジュールに透明であると主張できるだけです。 より良い透明ために支払われた価格が追加複雑さである、潜在的に増強されたSNMPパケットは、辞書編集の注文に大きさで分けて、混入しました。 特にSNMPv3と共に、コミュニケーションが増強されたパケットサイズのため失敗する機会があります。 辞書編集の注文を当てにする管理アプリケーションが誤った振舞いを示すでしょう。
Both, basic and advanced SNMP ALGs, introduce problems when using SNMPv3 security features. The SNMPv3 authentication mechanism protects the whole SNMP message against modifications while the SNMPv3 privacy mechanism protects the payload of SNMPv3 messages against unauthorized access. Thus, an SNMP ALG must have access to all localized keys in use in order to modify SNMPv3 messages without invalidating them. Furthermore, the SNMP ALG must track any key changes in order to function. More details on the security implications of using SNMP ALGs can be found in Section 6.
SNMPv3セキュリティ機能を使用するとき、両方(基本的で高度なSNMP ALGs)が問題を紹介します。 SNMPv3プライバシーメカニズムは不正アクセスに対してSNMPv3メッセージのペイロードを保護しますが、SNMPv3認証機構は変更に対して全体のSNMPメッセージを保護します。 したがって、SNMP ALGはそれらを無効にしないでSNMPv3メッセージを変更するために使用中のキーであるとローカライズされたすべてに近づく手段を持たなければなりません。 その上、SNMP ALGは、機能するようにどんなキーチェンジも追跡しなければなりません。 セクション6でSNMP ALGsを使用するセキュリティ含意に関するその他の詳細を見つけることができます。
Finally, an SNMP ALG only deals with SNMP traffic and does not modify the payload of any other protocol. However, management systems usually use a set of protocols to manage a network. In particular the telnet protocol is often used to configure or troubleshoot managed devices. Hence, a management system and the human network operator must generally be aware that a network address translation is occurring, even in the presence of an SNMP ALG.
最終的に、SNMP ALGだけがSNMPトラフィックに対処して、いかなる他のプロトコルのペイロードも変更しません。 しかしながら、通常、マネージメントシステムは、ネットワークを経営するのに1セットのプロトコルを使用します。 特に、telnetプロトコルは、管理されたデバイスを構成するか、または障害調査するのにしばしば使用されます。 したがって、一般に、マネージメントシステムと人脈のオペレータはネットワークアドレス変換が起こっているのを意識していなければなりません、SNMP ALGの面前でさえ。
A possible alternative to SNMP ALGs are SNMP proxies, as defined in RFC 2573 [11]. An SNMP proxy forwarder application forwards SNMP messages to other SNMP engines according to the context, and irrespective of the specific managed object types being accessed. The proxy forwarder also forwards the response to such previously forwarded messages back to the SNMP engine from which the original message was received. Such a proxy forwarder can be used in a NAT environment to address SNMP engines with conflicting IP addresses. (Just replace the box SNMP ALG with a box labeled SNMP PROXY in Figure 2.) The deployment of SNMP proxys has the advantage that different security levels can be used inside and outside of the conflicting addressing realms.
SNMP ALGsへの可能な代替手段はRFC2573[11]で定義されるようにSNMPプロキシです。 アクセスされていて、SNMPのプロキシ混載業者のアプリケーションは文脈に従った他のSNMPエンジン、特定の管理オブジェクトタイプおよびの如何にかかわらずメッセージをSNMPに転送します。 また、プロキシ混載業者はそのような以前に転送されたメッセージへの応答をオリジナルのメッセージが受け取られたSNMPエンジンに送って戻します。 そのようなプロキシ混載業者はIPが扱う闘争でNAT環境でアドレスSNMPエンジンに慣れることができます。 (ただ箱のSNMP ALGを図2をSNMP PROXYとラベルされた箱に取り替えてください。) SNMP proxysの展開には、異なったセキュリティが平らにする利点が闘争の中古の内外がアドレシング分野であったかもしれないならあります。
Raz, et al. Informational [Page 11] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [11ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
The proxy solution, which is structurally preferable, requires that the management application is aware of the proxy situation. Furthermore, management applications have to use internal data structures for network elements that allow for conflicting IP addresses since conflicting IP addresses are not translated by the SNMP proxy. Deployment of proxies may also involve the need to reconfigure network elements and management stations to direct their traffic (notifications and requests) to the proxy forwarder.
プロキシソリューション(構造的に望ましい)は、管理アプリケーションがプロキシ状況を知っているのを必要とします。 その上、管理アプリケーションは闘争しているIPアドレスがSNMPプロキシによって翻訳されないので闘争するためにIPアドレスを許容するネットワーク要素に内部のデータ構造を使用しなければなりません。 また、プロキシの展開はそれらのトラフィック(通知と要求)をプロキシ混載業者に向けるためにネットワーク要素と管理局を再構成する必要性にかかわるかもしれません。
6. Security Considerations
6. セキュリティ問題
SNMPv1 and SNMPv2c have very week security services based on community strings. All management information is sent in cleartext without encryption and/or authentication. In such an environment, SNMP messages can be modified by any intermediate node and management application are not able to verify the integrity of SNMP messages. Furthermore, an SNMP ALG does not need to have knowledge of the community strings in order to translate embedded IP addresses. Thus, deployment of SNMP ALGs in an SNMPv1/SNMPv2c environment introduces no additional security problems.
SNMPv1とSNMPv2cはセキュリティー・サービスが共同体ストリングに基礎づけたまさしくその週を過します。 cleartextで暗号化、そして/または、認証なしですべての経営情報を送ります。 そのような環境で、どんな中間的ノードでもSNMPメッセージを変更できます、そして、管理アプリケーションはSNMPメッセージの保全について確かめることができません。 その上、SNMP ALGは、埋め込まれたIPアドレスを翻訳するために共同体ストリングに関する知識を必要としません。 したがって、SNMPv1/SNMPv2c環境における、SNMP ALGsの展開は追加担保問題を全く紹介しません。
SNMPv3 supports three security levels: no authentication and no encryption (noAuth/noPriv), authentication and no encryption (auth/noPriv), and authentication and encryption (auth/priv). SNMPv3 messages without authentication and encryption (noAuth/noPriv) are send in cleartext. In such a case the usage of SNMP ALGs introduces no additional security problems.
SNMPv3は3つのセキュリティー・レベルをサポートします: そして、いいえ、認証にもかかわらず、暗号化がない(noAuth/noPriv)、認証、および暗号化がない(auth/noPriv)、認証と暗号化(auth/priv)。 (noAuth/noPriv)があるという認証と暗号化のないSNMPv3メッセージはcleartextを送ります。 このような場合にはSNMP ALGsの使用法は追加担保問題を全く紹介しません。
However, the usage of SNMP ALG introduces new problems when SNMPv3 authentication and optionally encryption is used. First, SNMPv3 messages with authentication and optionally encryption (auth/noPriv and auth/priv) can only be processed by an SNMP ALG which supports the corresponding cryptographic algorithms and which has access to the keys in use. Furthermore, as keys may be updated, the SNMP ALG must have a mechanism that tracks key changes (either by analyzing the key change interactions or by propagating key changes by other mechanisms). Second, the computational complexity of processing SNMP messages may increase dramatically. The message has to be decrypted before the translation takes place. If any translation is done the hash signature used to authenticate the message and to protect its integrity must be recomputed.
しかしながら、SNMPv3認証であるときに、SNMP ALGの使用法は新しい問題を紹介します、そして、任意に、暗号化は使用されています。 まず最初に、SNMPv3は認証で通信します、そして、任意に、対応する暗号アルゴリズムをサポートして、使用中のキーに近づく手段を持っているSNMP ALGは暗号化(auth/noPrivとauth/priv)を処理できるだけです。 その上、キーをアップデートするとき、SNMP ALGにはキーチェンジ(キーチェンジ相互作用を分析するか、または他のメカニズムでキーチェンジを伝播するのによる)を追跡するメカニズムがなければなりません。 2番目に、処理SNMPメッセージの計算量は劇的に増加するかもしれません。 翻訳が行われる前にメッセージは解読されなければなりません。 メッセージを認証して、保護するのに使用されるハッシュ署名をどんな翻訳にもするなら、保全を再計算しなければなりません。
In general, key exchange protocols are complicated and designing an SNMP ALG which maintains the keys for a set of SNMP engines is a non-trivial task. The User-based Security Model for SNMPv3 [12] defines a mechanism which takes a password and generates localized
一般に、主要な交換プロトコルは複雑です、そして、1セットのSNMPエンジンのためにキーを維持するSNMP ALGを設計するのは、重要なタスクです。 そして、SNMPv3[12]のためのUserベースのSecurity Modelがパスワードを取るメカニズムを定義する、ローカライズされて、生成します。
Raz, et al. Informational [Page 12] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [12ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
keys for every SNMP engine. The localized keys have the property that a compromised single localized key does not automatically give an attacker access to other SNMP engines, even if the key for other SNMP engines is derived from the same password.
あらゆるSNMPエンジンのためのキー。 感染している単一のローカライズしているキーがする特性はローカライズしているキーで自動的に他のSNMPエンジンへの攻撃者アクセスを与えません、同じパスワードから他のSNMPエンジンのためのキーを得ても。
An SNMP ALG implementation which maintains lists of (localized) keys is a potential target to attack the security of all the systems which use these keys. An SNMP ALG implementation which maintains passwords in order to generate localized keys is a potential target to attack the security of all systems that use the same password. Hence, an SNMP ALG implementation must be properly secured so that people who are not authorized to access keys or passwords can not access them.
(ローカライズされます)キーのリストを維持するSNMP ALG実装はこれらのキーを使用するすべてのシステムのセキュリティを攻撃する仮想ターゲットです。 ローカライズしているキーを生成するためにパスワードを維持するSNMP ALG実装は同じパスワードを使用するすべてのシステムのセキュリティを攻撃する仮想ターゲットです。 したがって、アクセスキーかパスワードに権限を与えられない人々がそれらにアクセスできないように、適切にSNMP ALG実装を保証しなければなりません。
Finally, SNMP ALGs do not allow a network operator to use different security levels on both sides of the NAT. Using a secure SNMP version outside of a private addressing realm while the private addressing realm runs an unsecured version of SNMP may be highly desirable in many scenarios, e.g. management outsourcing scenarios. The deployment of SNMPv3 proxies instead of SNMP ALGs should be considered in these cases since SNMP proxies can be configured to use different security levels and parameters on both sides of the proxies.
最終的に、SNMP ALGsはネットワーク・オペレータにNATの両側で異なったセキュリティー・レベルを使用させません。 私設のアドレシング分野がSNMPの非機密保護しているバージョンを実行している間、私設のアドレシング分野の外で安全なSNMPバージョンを使用するのは多くのシナリオ(例えば、管理アウトソーシングシナリオ)で非常に望ましいかもしれません。 SNMPプロキシを構成できて以来のこれらの場合でSNMP ALGsの代わりにSNMPv3プロキシの展開がプロキシの両側で異なったセキュリティー・レベルとパラメタを使用すると考えられるべきです。
7. Summary and Recommendations
7. 概要と推薦
Several approaches to address SNMP agents across NAT devices have been discussed in this memo.
このメモでNATデバイスの向こう側にSNMPエージェントに演説するいくつかのアプローチについて議論しました。
1. Basic SNMP ALGs as described in Section 4.1 provide very limited
transparency since they only translate IPv4 addresses encoded in
the IpAddress base type. They are fast and efficient and may be
sufficient to execute simple management applications (e.g.
topology discovery applications) in a NAT environment. However,
other management applications are likely to fail due to the
limited transparency provided by a basic SNMP ALG. Basic SNMP
ALGs are problematic in a secure SNMP environment since they need
to maintain lists of keys or passwords in order to function.
2. Advanced SNMP ALGs as described in Section 4.2 provide better
transparency. They can be transparent for the set of data types
they understand and for a given set of MIB modules. However, an
advanced SNMP ALG is much more complex and less efficiency than a
basic SNMP ALG. An advanced SNMP ALG may break the lexicographic
ordering when IP addresses are used to index conceptual tables
and it may change the SNMP packet sizes. Especially with SNMPv3,
there is an opportunity that communication fails due to increased
message sizes. Advanced SNMP ALGs are problematic in a secure
SNMP environment, since they need to maintain lists of keys or
passwords in order to function.
1. 彼らがIpAddressベースタイプでコード化されたIPv4アドレスを翻訳するだけであるので、セクション4.1で説明される基本的なSNMP ALGsは非常に限られた透明を提供します。 それらは、速くて、効率的であり、NAT環境における簡単な管理アプリケーション(例えば、トポロジー発見アプリケーション)を作成するために十分であるかもしれません。 しかしながら、他の管理アプリケーションは基本的なSNMP ALGによって提供された限られた透明のため失敗しそうです。 彼らが、機能するようにキーかパスワードのリストを維持する必要があるので、基本的なSNMP ALGsは安全なSNMP環境で問題が多いです。 2. セクション4.2で説明される高度なSNMP ALGsは、より良い透明を提供します。 彼らが理解しているデータ型のセットと与えられたセットのMIBモジュールに、それらは透明である場合があります。 しかしながら、高度なSNMP ALGはずっと多くの複合体と基本的なSNMP ALGより少ない効率です。 IPアドレスが概念的なテーブルに索引をつけるのに使用されて、SNMPパケットサイズを変えるかもしれないなら、高度なSNMP ALGは辞書編集の注文を壊すかもしれません。 特にSNMPv3と共に、コミュニケーションが増強されたメッセージサイズのため失敗する機会があります。 高度なSNMP ALGsは安全なSNMP環境で問題が多いです、彼らが、機能するようにキーかパスワードのリストを維持する必要があるので。
Raz, et al. Informational [Page 13] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [13ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
3. SNMP proxies as described in RFC 2573 [11] allow management
applications to access SNMP agents with conflicting IP addresses.
No address translation is performed on the SNMP payload by an
SNMP proxy forwarder. Hence, management applications must be
able to deal with network elements that have conflicting IP
addresses. This solution requires that management applications
are aware of the proxy situation. Deployment of proxies may also
involve the need to reconfigure network elements and management
stations to direct their traffic (notifications and requests) to
the proxy forwarder. SNMP proxies have the advantage that they
allow to use different security levels inside and outside of a
given addressing realm.
3. RFC2573[11]で説明されるSNMPプロキシは管理アプリケーションをIPが扱う闘争でSNMPエージェントにアクセスさせます。 アドレス変換は全くSNMPプロキシ混載業者によってSNMPペイロードに実行されません。 したがって、管理アプリケーションはIPが扱う闘争を持っているネットワーク要素に対処できなければなりません。 このソリューションは、管理アプリケーションがプロキシ状況を知っているのを必要とします。 また、プロキシの展開はそれらのトラフィック(通知と要求)をプロキシ混載業者に向けるためにネットワーク要素と管理局を再構成する必要性にかかわるかもしれません。 SNMPプロキシには、彼らが与えられたアドレシング分野の異なったセキュリティー・レベル内外を使用させる利点があります。
It is recommended that network operators who need to manage networks in a NAT environment make a careful analysis before deploying a solution. In particular, it must be analyzed whether the management applications will work with the transparency and the side-effects provided by SNMP ALGs. Furthermore, it should be researched whether the management applications are able to deal with conflicting IP addresses for network devices. Finally, the additional complexity introduced to the over all management system by using SNMP ALGs must be compared to the complexity introduced by the structurally preferable SNMP proxy forwarders.
NAT環境でネットワークを経営する必要があるネットワーク・オペレータがソリューションを配布する前に慎重な分析をするのは、お勧めです。 透明と副作用がSNMP ALGsによって供給されている状態で管理アプリケーションが動作するか否かに関係なく、特に、それを分析しなければなりません。 その上、管理アプリケーションがIPがネットワークデバイスのために扱う闘争に対処できるか否かに関係なく、それは研究されるべきです。 最終的に、追加複雑さは構造的に望ましいSNMPプロキシ混載業者によって導入された複雑さと比べて、SNMP ALGsを使用するのによるマネージメントシステムがそうしなければならないすべてを終わるのに導入しました。
8. Current Implementations
8. 現在の実装
A basic SNMP ALG as described in Section 4.1 was implemented for SNMPv1 at Bell-Labs, running on a Solaris Machine. The solution described in Figure 2, where SNMP ALG was combined with the NAT implementation of Lucent's PortMaster3, was deployed successfully in a large network management service organization.
Solaris Machineの上で作業して、セクション4.1で説明される基本的なSNMP ALGはSNMPv1のためにベル研究所で実装されました。 図2で説明されたソリューションはSNMP ALGがLucentのPortMaster3のNAT実装に結合されたところで大きいネットワーク管理サービス組織で首尾よく配布されました。
9. Acknowledgments
9. 承認
We thank Pyda Srisuresh, for the support, encouragement, and advice throughout the work on this document. We also thank Brett A. Denison for his contribution to the work that led to this document. Additional useful comments have been made by members of the NAT working group.
私たちはこのドキュメントへの作業の間中サポート、奨励、およびアドバイスについてPyda Srisureshに感謝します。 また、私たちはこのドキュメントにつながった仕事への彼の貢献についてブレット・A.デニスンに感謝します。 追加役に立つコメントはNATワーキンググループのメンバーによってされました。
10. References
10. 参照
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[2] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
Raz, et al. Informational [Page 14] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [14ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
[3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[3]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[4] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[5]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[6] McCloghrie, K., "SNMPv2 Management Information Base for the
Internet Protocol using SMIv2", RFC 2011, November 1996.
[6]McCloghrie、K.、「1996年11月にSMIv2"、RFC2011を使用するインターネットプロトコルのためのSNMPv2管理情報ベース。」
[7] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[7]Waldbusser、S.、「1997年1月にSMIv2"、RFC2021を使用するリモートネットワーク監視管理情報ベースバージョン2。」
[8] Haskin, D. and S. Onishi, "Management Information Base for IP
Version 6: Textual Conventions and General Group", RFC 2465,
December 1998.
[8] ハスキン、D.、およびS.鬼石、「IPバージョン6のための管理情報ベース:」 「原文のコンベンションと一般は分類する」RFC2465、1998年12月。
[9] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[9] ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[10] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[10]ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
2573, April 1999.
[11] レビとD.とマイヤーとP.とB.スチュワート、「SNMPアプリケーション」、RFC2573、1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[12] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[13] ISO, "Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax Notation One
(ASN.1)", International Standard 8824, December 1987.
[13] ISO、「情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)の仕様」、国際規格8824(1987年12月)。
[14] ISO, "Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1)", International Standard
8825, December 1987.
[14] ISO、「情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)のためのBasic Encoding Rulesの仕様」、国際規格8825(1987年12月)。
[15] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[15]SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
Raz, et al. Informational [Page 15] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [15ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
[16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
[16] M. ミラー、MTの本、「SNMPと共にインターネットワークを管理すること」での1997。
[17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", Prentice
Hall, ISBN 0-13-437708-7, 1997.
[17] パーキンスとD.とE.マクギニス、「理解SNMP MIBs」新米のホール、ISBN0-13-437708-7 1997。
[18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", Work in Progress.
[18] 「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」というSrisuresh、P.、およびK.Egevangは進行中で働いています。
[19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder,
"Textual Conventions for Internet Network Addresses", RFC 2851,
June 2000.
[19] ダニエルとM.とハーバーマンとB.とRouthierとS.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」、RFC2851、2000年6月。
11. Authors' Addresses
11. 作者のアドレス
Danny Raz Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 USA
Crawfordsコーナー第Holmdel、ダニーRazルーセントテクノロジーズ101ニュージャージー07733-3030米国
Phone: +1 732 949-6712 Fax: +1 732 949-0399 EMail: raz@lucent.com URI: http://www.bell-labs.com/
以下に電話をしてください。 +1 732 949-6712Fax: +1 732 949-0399 メールしてください: raz@lucent.com ユリ: http://www.bell-labs.com/
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBueltenweg74/75 38106ブラウンシュバイクドイツ
Phone: +49 531 391-3266 Fax: +49 531 391-5936 EMail: schoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
以下に電話をしてください。 +49 531 391-3266Fax: +49 531 391-5936 メールしてください: schoenw@ibr.cs.tu-bs.de ユリ: http://www.ibr.cs.tu-bs.de/
Binay Sugla ISPSoft Inc. 106 Apple Street Tinton Falls, NJ 07724 USA
Binay Sugla ISPSoft Inc.106アップル通りTinton滝、ニュージャージー07724米国
Phone: +1 732 936-1763 EMail: sugla@ispsoft.com URI: http://www.ispsoft.com/
以下に電話をしてください。 +1 732 936-1763 メールしてください: sugla@ispsoft.com ユリ: http://www.ispsoft.com/
Raz, et al. Informational [Page 16] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [16ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
12. Appendix A. Description of the Encoding of SNMP Packets
12. SNMPパケットのコード化の付録A.記述
SNMP packets use the ASN.1/BER encoding. We will not cover the full details of this encoding in this document. These details can be found in the International Standards ISO-8824 [13] and ISO-8825 [14]. A good description of ASN.1/BER can be found in the book "Managing Internetworks with SNMP", by M. A. Miller [16], or in Appendix A of the book "Understanding SNMP MIBs", by D. Perkins, and E. McGinnis [17].
SNMPパケットはASN.1/BERコード化を使用します。 私たちは本書ではこのコード化の一部始終をカバーするつもりではありません。 国際Standards ISO-8824[13]とISO-8825[14]でこれらの詳細を見つけることができます。 ASN.1/BERの良い記述はM.A.ミラー[16]の近く、または、本の「理解SNMP MIBs」のAppendix Aに本に「SNMPがある管理インターネットワーク」を設立することであるかもしれません、D.パーキンス、およびE.マクギニス[17]。
Each variable that is referred to in an SNMP packet is uniquely identified by an OID (Object Identifier), usually written as a sequence of numbers separated by dots (e.g. 1.3.6.1.2.1.1.3.0). Each variable also has an associated base type (this is not very accurate but good enough for this level of description). One possible base type is the IpAddress type. The base type of each variable and its OID are conveyed by the ASN.1/BER encoding. Note that it is possible to associate additional type information with a variable by using textual conventions. The additional type semantics provided by textual conventions are not conveyed by the ASN.1/BER encoding.
SNMPパケットに示されるそれぞれの変数がOID(オブジェクトIdentifier)によって唯一特定されていて、通常、ドットによって切り離された数列として書かれている、(例えば、1.3 .6 .1 .2 .1 .1 .3 .0)。 また、各変数で、関連ベースはタイプされます(このレベルの記述には、これは非常に正確であるのではなく、十分良いです)。 1つの可能なベースタイプがIpAddressタイプです。 各変数とそのOIDのベースタイプはASN.1/BERコード化で伝えられます。 原文のコンベンションを使用することによって追加タイプ情報を変数に関連づけるのが可能であることに注意してください。 意味論が原文のコンベンションで提供した追加タイプはASN.1/BERコード化で伝えられません。
When a value of a variable is needed by a manager it sends a get- request PDU with the OID of that variable, and a NULL value. The managed element then responds by sending a get-response PDU that contains the same OID, the base type of the variable, and the current value. Figure 4 shows an example of real data contained in an SNMPv1 GetResponse PDU.
変数値がそれがaを送るマネージャによって必要とされたら、その変数のOID、およびNULL値で要求PDUを手に入れてください。 そして管理された要素は、同じOIDを含む応答を得ているPDU、変数のベースタイプ、および現行価値を送ることによって、応じます。 図4はSNMPv1 GetResponse PDUに含まれた本当のデータに関する例を示しています。
The first 20 bytes contain the IPv4 4 header. The next 8 bytes contain the UDP header. The last two bytes of the UDP header contain the UDP checksum (D3 65). The next four bytes 30 82 00 3E are the beginning of the SNMP message: 30 is SEQUENCE, and 82 00 3E is the length of the data in the SEQUENCE in bytes (62). The data in the SEQUENCE is the version (02 01 00) and the community string (04 06 70 75 62 6C 69 63). The last element in the SEQUENCE of the SNMPv1 message is the SNMP PDU.
最初の20バイトはIPv4 4ヘッダーを含んでいます。 次の8バイトはUDPヘッダーを含んでいます。 UDPヘッダーの最後の2バイトはUDPチェックサム(D3 65)を含んでいます。 次の4バイト30 82 00 3EがSNMPメッセージの始まりです: 30は、SEQUENCEと、82 00です。3Eがバイト(62)で表現されるSEQUENCEのデータの長さです。 SEQUENCEのデータは、バージョン(02 01 00)と共同体ストリング(04 06 70 75 62 6C69 63)です。 SNMPv1メッセージのSEQUENCEにおける最後の要素はSNMP PDUです。
Raz, et al. Informational [Page 17] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [17ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
+-----------------------------------------+
| IP Header | 45 00 00 5E
| | 47 40 00 00
| | 3F 11 39 00
| | 87 B4 8C CA
| | 87 B4 8C 16
+-----------------------------------------+
| UDP Header | 00 A1 05 F5
| | 00 4A D3 65
+-----------------------------------------+
| SNMP Message | 30 82 00 3E
| Version | | 02 01 00 04
| Community | 06 70 75 62
| | | 6C 69 63 A2
| PDU Type | | 82 00 2F 02
| Request ID | 04 6C F2 0C
| | Error Status | 5C 02 01 00
| Error Index | SEQUENCE | 02 01 00 30
| OF | SEQUENCE | 82 00 1F 30
| | OID | 82 00 1B 06
| | | 13 2B 06 01
| | 02 01 07 05
| | 01 01 81 40
| | 81 34 81 0C
| | 81 4A 84 08
| IpAddress | 135 | 180 | 40 04 87 B4
| 140 | 202 +-------------------+ 8C CA
+---------------------+
+-----------------------------------------+ | IPヘッダー| 45 00 00、5E| | 47 40 00 00 | | 3F11 39 00| | 87 B4 8Cカリフォルニア| | 87 B4 8C16+-----------------------------------------+ | UDPヘッダー| 00 A1 05F5| | 00 4A D3 65+-----------------------------------------+ | SNMPメッセージ| 30 82 00、3E| バージョン| | 02 01 00 04 | 共同体| 06 70 75 62 | | | 6 C69 63A2| PDUはタイプします。| | 82 00 2F02| IDを要求してください。| 04 6C F2 0C| | エラー状況| 5 C02 01 00| 誤りインデックス| 系列| 02 01 00 30 | of| 系列| 1 82 00F30| | OID| 82 00 1B06| | | 13 2B06 01| | 02 01 07 05 | | 01 01 81 40 | | 81 34 81、0C| | 81 4A84 08| IpAddress| 135 | 180 | 40 04 87B4| 140 | 202 +-------------------+ 8Cのカリフォルニア+---------------------+
The SNMP PDU itself is a tagged SEQUENCE: A2 indicates a GetResponse PDU and 82 00 2F is the length of the data in the GetResponse PDU in bytes (47). The data in the GetResponse PDU is the request-id (02 04 6C F2 0C 5C), the error-status (02 01 00), and the error-index (02 01 00). Now follow the variables which contain the real payload: A SEQUENCE OF of length 31 (30 82 00 1F) containing a SEQUENCE of length 27 (30 82 00 1B). In it, the first object is an OID of length 19 (06 13) with the value 1.3.6.1.2.1.7.5.1.1.192.180.140.202.520. The last 6 bytes 40 04 87 B4 8C CA represent an IpAddress: 40 is the identification of the base type IpAddress, 04 is the length, and the next four bytes are the IP address value (135.180.140.202).
SNMP PDU自身はタグ付けをされたSEQUENCEです: A2は、a GetResponse PDUと82 00 2Fがバイト(47)で表現されるGetResponse PDUのデータの長さであることを示します。 GetResponse PDUのデータは、要求イド(02 04 6C F2 0C5C)と、エラー状況(02 01 00)と、誤りインデックス(02 01 00)です。 今度は、本当のペイロードを含む変数に従ってください: 長さ31のSEQUENCE OF、(30 82 00、1F) 長さ27(30 82 00 1B)のSEQUENCEを含んでいます。 長さのOIDは値1.3がある19(06 13)です。それでは、1番目が反対する、.6 .1 .2 .1 .7 .5 .1 .1 .192 .180 .140 .202 .520。 最後の6バイトの40 04 87B4 8C CAはIpAddressを表します: 40がベースタイプIpAddressの識別であり、04が長さであり、次の4バイトがIPアドレス値である、(135.180 .140 .202)。
The example also shows an IP address embedded in an OID. The OID prefix resolves to the udpLocalAddress of the UDP-MIB, which is indexed by the udpLocalAddress 192.180.140.202 (81 40 81 34 81 0C 81
また、例はOIDに埋め込まれたIPアドレスを示しています。 OIDがudpLocalAddress192.180.140で索引をつけられるUDP-MIBのudpLocalAddressへ決心を前に置く、.202、(81 40 81 34 81 0C81
Raz, et al. Informational [Page 18] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [18ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
4A) and the udpLocalPort 520 (84 08). The SNMP packet actually shows an internal contradiction caused by a basic SNMP ALG since the udpLocalAddress encoded in the OID (192.180.140.202) is not equal to the value of the udpLocalAddress object instance (135.180.140.202).
4A)とudpLocalPort520(84 08)。 SNMPパケットが実際にOIDでコード化されたudpLocalAddress以来基本的なSNMP ALGによって引き起こされた内部の矛盾を示している、(192.180、.140、.202が)udpLocalAddressオブジェクトインスタンスの値と等しくない、(135.180 .140 .202)。
Raz, et al. Informational [Page 19] RFC 2962 SNMP Payload Address Translation October 2000
Raz、他 [19ページ]情報のRFC2962SNMP有効搭載量アドレス変換2000年10月
13. Full Copyright Statement
13. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Raz, et al. Informational [Page 20]
Raz、他 情報[20ページ]
一覧
スポンサーリンク
