Network Working Group D. Raz
Request for Comments: 2962 Lucent Technologies
Category: Informational J. Schoenwaelder
TU Braunschweig
B. Sugla
ISPSoft Inc.
October 2000
An SNMP Application Level Gateway for Payload Address Translation
ペイロード・アドレス変換のためのSNMPアプリケーションレベルゲートウェイ
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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（インターネットプロトコル）アドレスは静的に別のグループからマッピングされることにより、SNMP（簡易ネットワーク管理プロトコル）のためにALG（アプリケーションレベルゲートウェイ）について説明します。 SNMP ALGは、[15]に記載のようにアプリケーションレベルゲートウェイの特定の場合です。
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（ネットワークアドレス変換）とSNMPを使用する必要がある場合これは、環境において重要であり得ます。
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アプリケーションレベルゲートウェイの実装のための要件と制限の詳細な説明を含んでいます。また、アドレス範囲を越えて矛盾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
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 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（Simple Network Management Protocol）を使用します。例えば、ルータは、その隣接する要素のアドレスに関する管理アプリケーションによって照会することができます。この情報は、その後、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.
ペイロードアドレス変換のためのSNMPアプリケーションレベルゲートウェイ、またはSNMP ALGは、SNMPパケット（のPDU）のペイロードがスキャンされ、必要に応じて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の一部として展開されている典型的なシナリオは、マネージャ装置は、変換されたIPアドレスと、リモートスタブを管理している図図1に示されています。
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
+---------------+ . +------------------------------+
| . |
| . | LAN
+----------+ . ---------------
| Manager | Stub border Managed network
+----------+
Figure 1: SNMP ALG in a NAT configuration
図1：NAT設定でSNMP ALG
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
/____\ /____\
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つのマッピングに静的なものと基本的な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を配置する方がよいです。
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メッセージです。この文書では、[5] SNMPメッセージの優先トランスポートマッピングであるUDPを介して送信されているSNMPメッセージを、説明します。他のトランスポートは、同様の方法で処理することができます上の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のPDU（プロトコルデータユニット）を含有します。 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の）プロトコルはSTD 15で定義され、RFC 1157 [2]。 SNMPバージョン2cの（SNMPv2cの）プロトコルは、RFC 1901で定義されている[3]、RFC 1905 [4]及びRFC 1906 [5]。最後に、SNMPバージョン3（SNMPv3の）プロトコルは、RFC 1905で定義されている[4]、1906 [5]、RFC 2572 [10]およびRFC 2574 [12]。 [9] SNMP規格をより詳細な概要については、RFC 2570を参照してください。特に断りのない限り以下では、我々はすべての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]を使用しています。メッセージの実際の符号化は、転送構文を提供する基本符号化規則（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は、IPアドレスのタイプで符号化のみ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は、取り扱い、それらのデータ型に由来する周知のIPアドレスデータタイプとインスタンス識別子で符号化されたIPアドレス値を置き換えることが可能であるSNMP ALG実装です。これは、高度なSNMP ALGがMIB認識していることを意味します。
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 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
多くの場合、前述したように、領域外の管理サイトから、NATを使用しているローカルアドレス指定のレルムを管理する必要があります。特に重要な例は、リモートサイトからネットワーク管理サービスを提供するネットワーク管理サービス・プロバイダーの場合です。このようなプロバイダは、それぞれ同じプライベートアドレス空間を使用して、多くの顧客を有していても良いです。すべてのこれらのアドレス範囲は、単一の管理ステーションのアドレス衝突から管理する場合に発生します。アドレス衝突を克服するには、2つの単純な方法があります。一つの缶
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.異なるアドレス範囲、またはネットワーク管理アプリケーションからアドレス衝突を非表示にする2.使用静的アドレスをNATにIPアドレスを割り当て直します。
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アドレスの潜在的に大きなセット、およびネットワークの大部分の再構成の両方を必要とする第1の解決策は問題があります。第二の溶液の問題は、多くのネットワーク管理アプリケーションは、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はこのメモで説明するようなソリューションです。
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].
IPアドレスに格納されている1. IPバージョン4つのアドレスとマスクは、インスタンス識別子の一部ではないASN.1データ・タイプをタグ付け。例では、IP-MIB [6]で定義されたipAdEntNetMaskオブジェクトです。前記IPバージョン4つのアドレスは、IPアドレスデータタイプを使用して索引オブジェクトから派生したインスタンス識別子に含まれています。例では、IP-MIB [6]のipAdEntAddrインデックスオブジェクトです。 3. IPアドレス（任意のバージョン）オクテット文字列に含まれています。例としては、RMON2-MIB [7]のaddressMapNetworkAddressオブジェクト、及びよく知られたテキストの表記法から誘導されたオクテット文字列に含まれるIPアドレスを含む（例えばTAddress [5]又はIpv6Address [8]又はInetAddressの[19]）。 4. IPアドレス（任意のバージョン）OCTET文字列から派生したインスタンス識別子に含まれています。これは、（例えばTAddress [8]又はInetAddressの[19] [5]またはIpv6Address）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 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.
IPアドレスを含めることができるテキストの表記法は、さらにNATに優しいとNAT無愛想なものに分けることができます。 NATに優しいテキストの表記法は、ワイヤ上のエンコーディングがテキストの表記法を理解し、高度なSNMP ALGは、適切な翻訳を行うことができ、必要なMIBの知識を持っていることに十分な情報が含まれていることを保証します。このタイプの例は、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の知識を持って適切な翻訳を行うために追加情報へのアクセス権を持っていることが必要です。このタイプの例は、TAddressおよび追加のvarbindが所定の値が表すIPアドレスのタイプを決定するために、SNMPパケットに存在することを必要とするのInetAddressテキストの表記法です。そのようなVARBINDは、または管理アプリケーションがデータを取得する方法に依存して存在してもしなくてもよいです。
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アドレス変換を提供する必要があります。 RFC 1157によって定義されるSNMP ALGは、SNMPプロトコル操作の挙動と互換性がなければならない[2]及びRFC 1905 [4]、SNMPプロトコルによって提供されるセキュリティに悪影響を与えてはなりません。完全に透明なSNMP ALGは、指定されたOIDのとエンコードの詳細を提供する場合、上記のようにIPアドレスのすべてのカテゴリを変換することができなければなりません。
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デバイスのそれぞれが想定外のアドレスが互いに衝突してはなりません。
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 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メッセージは、IP層で断片化が発生する可能性がありUDPを介して送信します。極端な場合には、フラグメンテーションは、IPアドレスのタイプが2つの異なる断片に分割される可能性があります。 SNMPメッセージ内のIPアドレスを変換するためには、完全なSNMPメッセージが使用可能でなければなりません。 [18]に記載されているように、UDPパケットの断片は、それらとソース/宛先ポート番号を運びません。したがって、SNMP ALGはSNMPメッセージが含まれているIPパケットを再構成しなければなりません。良いニュースは、通常、SNMPエージェントがMTUを認識していること、しかし、であり、そのSNMPパケットは、通常は比較的小さいです。一部のSNMP実装はまた、[1]の断片化を避けるために、IPヘッダ内の（DF）を断片化していないビットを設定します。
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は、IPアドレスベースのタイプで符号化されたIPアドレスのみ値が変換されたSNMP ALG実装です。基本的なSNMP ALG実装はASN.1を解析/ BERは、IPアドレスベースのタイプを用いて符号化された要素を探している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.
IPアドレスの値は、そのタグ値（0x40の）によって容易に同定することができます。 IPアドレスが検出されると、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はどんなのMIBの知識を必要としません。実装するのが容易です。基本的な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はIPアドレスの基本型を使用するオブジェクトにIPv4アドレスを変換することができます。さらに、基本的なSNMP ALGは、概念的なテーブルのインデックスのコンポーネントであるオブジェクトにIPアドレスを変換することはできません。これはアクセスできませんインデックスコンポーネント上特に問題となります。したがって、基本的なSNMP ALGはSNMPメッセージ（3.1節を参照）でIPアドレスを表す4つの可能性のある方法のうち、最初に制限されています。
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は、取り扱い、それらのデータ型に由来する周知のIPアドレスデータタイプとインスタンス識別子で符号化されたIPアドレス値を置き換えることが可能であるSNMP ALG実装です。したがって、高度なSNMP ALGは透過セクション3.1に記載されるようにフォーマット1-4にあるIPアドレスをマップすることができてもよいです。これは、高度なSNMP ALGがMIBを認識しなければならないことを意味します。
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は、IPアドレスベースのタイプでエンコードされていないIPアドレスを特定するために、オブジェクト識別子（OID）変換テーブルを維持しなければなりません。 OID変換テーブルは、翻訳が必要な場合がありOIDの情報を維持する必要があります。さらに、変換テーブルは、IPアドレスが含まれている概念のテーブルのインスタンス識別子に関する情報を保持する必要があります。このようなOID変換テーブルは、IPアドレスが含まれていてもよい種類、テキストの規則とテーブルインデックスアドレッシング領域を探索内で使用されるMIBをロードするMIBコンパイラを使用してオフラインで埋めても良いです。
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.
翻訳機能は、これらの特定のOIDのためのパケットをスキャン変換テーブルをチェックし、必要に応じてデータを置き換えます。 OIDが一定の大きさを持っていないので、この検索がはるかに計算がかかり、ルックアップ操作が高価であってもよいことに注意してください。
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は、135.180で埋め込みプライベートIPv4アドレスを交換06 0D 2B 06 01 02 01 04 14 01 02 0A 01 02 03として符号化されます.140.202 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A OIDにつながります。この例では、OIDに埋め込まれたIPアドレスはASN.1のサイズを変更することができるので、高度なSNMP ALGは、全体的なパケットサイズを変更することができることを示している/ BERは、OIDをコードしていました。
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 ALG破損SNMPエージェントの背後にあるエージェントを報告します。
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パケット内のIPアドレスの値を変更すると、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 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.
バイトの異なる数が異なるIPアドレスを符号化するために必要とされるかもしれないので、高度なSNMP ALGはSNMPパケットのサイズを変更してもよいです。これは、一般的なケースでは非常に望ましくないが、避けられません。 SNMPパケットサイズの変更は、UDPおよびIPヘッダの追加の変更が必要です。増加するパケットサイズは、SNMPv3の場合に特に問題となります。エージェントは、受信機が処理できるメッセージの最大サイズに近いGetBulkRequest PDUに対する応答PDUを生成することができるように、SNMPv3のメッセージヘッダはmsgMaxSizeフィールドを含みます。 SNMPパケットのサイズを増加させるSNMP ALGは、応答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;
}
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 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は、完全に透明にすることは、達成可能な作業ではありません。基本的なSNMP ALGはIPアドレスベースのタイプで符号化されたIPアドレスを変換4.1節で説明しました。そのようなSNMP ALGは、IPアドレスが頻繁概念テーブルへのインデックスの一部として使用されているので、ごく限られた透明性を達成します。管理アプリケーションは、したがって、混乱と管理アプリケーションの誤った行動につながることができ、元のアドレス、としてだけでなく、翻訳の両方が表示されます。例えばのような管理アプリケーションが、特定のクラスネットワーク発見ツールは、所定の位置に基本的なSNMP ALGとNATを越えてかなりうまく動作する可能性があります。
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.
どちらも、基本および高度なSNMPのALG、SNMPv3のセキュリティ機能を使用する際に問題を引き起こします。 SNMPv3のプライバシーメカニズムは、不正アクセスに対するSNMPv3メッセージのペイロードを保護しながら、SNMPv3の認証メカニズムは、変更に対する全体SNMPメッセージを保護します。このように、SNMP ALGは、それらを無効にすることなく、SNMPv3メッセージを変更するために使用されているすべてのローカライズされたキーへのアクセスを持っている必要があります。さらに、SNMP ALGが機能するためには、いずれかのキーの変更を追跡する必要があります。 SNMPのALGを使用してのセキュリティへの影響についての詳細は、6章で見つけることができます。
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トラフィックを扱うと他のプロトコルのペイロードを変更しません。しかし、管理システムは、通常、ネットワークを管理するためのプロトコルのセットを使用します。特に、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のALGの可能な代替RFC 2573 [11]で定義されるように、SNMPプロキシです。他のSNMPエンジンにSNMPプロキシフォワーダアプリケーション転送SNMPメッセージを文脈に応じて、関係なくアクセスされている特定の管理対象オブジェクトタイプの。プロキシフォワーダはまた、元のメッセージが受信されたSNMPエンジンにかかる以前に転送されたメッセージへの応答を転送します。このようなプロキシフォワーダは、競合するIPアドレスを持つSNMPエンジンに対処するためにNAT環境で使用することができます。 （ちょうど図2にSNMPプロキシを標識したボックスとボックスSNMP ALGを置き換える）のSNMPのproxysの展開は異なるセキュリティレベルが内側と競合するアドレス範囲の外で使用することができるという利点を有します。
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アドレスの競合を可能にするネットワーク要素のための内部データ構造を使用する必要があります。プロキシの展開もプロキシフォワーダへのトラフィック（通知と要求）を指示するネットワーク要素と管理ステーションを再構成する必要性を伴うことがあります。
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では、コミュニティストリングに基づいて非常に週セキュリティサービスを持っています。すべての管理情報は、暗号化および/または認証なしでクリアテキストで送信されます。そのような環境では、SNMPメッセージは、任意の中間ノードと管理アプリケーションによって変更することができるSNMPメッセージの完全性を検証することができません。さらに、SNMP ALGは、埋め込まれたIPアドレスを変換するために、コミュニティストリングの知識を持っている必要はありません。このように、SNMPv1の/ SNMPv2cの環境でのSNMPのALGの展開には、追加のセキュリティ上の問題を紹介しません。
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.
認証なしおよび暗号化なし（NOAUTH / NOPRIV）、認証および暗号化なし（AUTH / NOPRIV）、および認証と暗号化（認証/ PRIV）：SNMPv3は、3つのセキュリティレベルをサポートしています。認証と暗号化（NOAUTH / NOPRIV）なしでSNMPv3メッセージはクリアテキストで送信されています。このような場合、SNMPのALGの利用には、追加のセキュリティ上の問題を紹介しません。
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の利用は新たな問題を紹介します。まず、認証および必要に応じて暗号化（AUTH / NOPRIV及びAUTH / PRIV）とSNMPv3メッセージは、対応する暗号化アルゴリズムをサポートし、使用中のキーへのアクセス権を持っているSNMP ALGによって処理することができます。キーを更新することができるようにまた、SNMP ALGは、（キー変更の相互作用を分析することにより、または他の機構によりキー変更を伝播させることによってのいずれか）鍵の変更を追跡する機構を有していなければなりません。第二に、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 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 ALGを設計することは非自明な課題です。 SNMPv3のユーザベースセキュリティモデル[12]は、パスワードをとり、すべての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のALGは、ネットワークオペレータは、NATの両側に異なるセキュリティレベルを使用することはできません。プライベートアドレス指定領域は、SNMPのセキュリティで保護されていないバージョンを実行しながら、プライベートアドレッシング領域の外側に安全なSNMPバージョンを使用すると、例えば、多くのシナリオにおいて非常に望ましいかもしれません管理アウトソーシングのシナリオ。 SNMPプロキシは、プロキシの両側に異なるセキュリティレベルとパラメータを使用するように構成することができるので、代わりにSNMPのALGのSNMPv3のプロキシの展開は、これらの場合に考慮されるべきです。
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.
彼らは唯一のIPアドレスベースのタイプで符号化されたIPv4アドレスを変換するため、4.1節で説明したように1.基本SNMPのALGは非常に限られた透明性を提供します。彼らは、迅速かつ効率的であり、NAT環境でシンプルな管理アプリケーション（例えば、トポロジ検出アプリケーション）を実行するのに十分であり得ます。しかし、他の管理アプリケーションは、基本的なSNMP ALGが提供する限定された透明性のために失敗する可能性があります。基本的なSNMPのALGそれらが機能するためには、キーやパスワードのリストを維持する必要があるため、安全なSNMP環境に問題があります。 4.2節で説明したように2高度なSNMPのALGは、より良い透明性を提供します。彼らは理解してデータ型のセットのためとMIBモジュールの特定のセットのために透明にすることができます。しかし、高度なSNMP ALGは、基本的なSNMP ALGよりもはるかに複雑で、あまり効率です。 IPアドレスはインデックス概念のテーブルに使用されている場合、高度なSNMP ALGは、辞書式順序を壊すことがあり、それはSNMPパケットサイズを変更することがあります。特にSNMPv3のと、通信が増加したメッセージサイズに起因する障害が発生したことを機会があります。高度なSNMPのALGそれらが機能するためには、キーやパスワードのリストを維持する必要があるため、安全なSNMP環境に問題があります。
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.
RFC 2573に記載されているように3 SNMPプロキシ[11]管理アプリケーションが競合する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のALGが提供する副作用で動作するかどうかを分析しなければなりません。また、管理アプリケーションは、ネットワークデバイスの競合IPアドレスに対処することができるかどうかを調査する必要があります。最後に、SNMPのALGを使用して、すべての管理システム上に導入された付加的な複雑さは、構造的に好ましいSNMPプロキシフォワーダによって導入された複雑さと比較されなければなりません。
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.
4.1節で説明したように、基本的なSNMP ALGは、Solarisマシン上で実行して、ベル研究所でのSNMPv1のために実施されました。 SNMP ALGは、LucentのPortMaster3のNATの実装と合わせた、図2に記載された解決策は、大規模なネットワーク管理サービス組織で正常に展開されました。
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ワーキンググループのメンバーによって行われています。
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[1]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、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）"、STD 15、RFC 1157、1990月。
[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の概要"、RFC 1901、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、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、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、RFC 1906、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのマッピングを輸送します"。
[6] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[6] McCloghrie、K.、 "SMIv2のを使用してインターネットプロトコルのためのSNMPv2管理情報ベース"、RFC 2011、1996年11月。
[7] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[7] Waldbusser、S.、 "リモートネットワーク監視管理情報ベースバージョン2がSMIv2のを使用して"、RFC 2021、1997年1月。
[8] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998.
[8] Haskin、D.とS.大西、 "IPバージョン6のための管理情報ベース：テキストの表記法と一般的なグループ"、RFC 2465、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への序論"、RFC 2570、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）のための派遣"、RFC 2572、1999年4月。
[11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[11]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPアプリケーション"、RFC 2573、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の、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、RFC 2574、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、「情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（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、「情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）のための基本的な符号化規則の仕様」、国際標準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.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
[16]ミラー、M.、 "SNMPによる管理インターネットワーク"、MTブックス、1997。
[17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", Prentice Hall, ISBN 0-13-437708-7, 1997.
[17]パーキンス、D.およびE.マクギニス、 "SNMP MIBを理解する"、プレンティスホール、ISBN 0-13-437708-7、1997。
[18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", Work in Progress.
[18] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）" が進行中で働いています。
[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、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 2851、2000年6月。
Danny Raz Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 USA
ダニー・ラズルーセント・テクノロジーズ101 CrawfordsコーナーRdのホルムデル、ニュージャージー州07733から3030 USA
Phone: +1 732 949-6712 Fax: +1 732 949-0399 EMail: raz@lucent.com URI: http://www.bell-labs.com/
電話：+1 732 949-6712ファックス：+1 732 949-0399 Eメール：raz@lucent.com URI：http://www.bell-labs.com/
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBültenweg75分の74 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-3266ファックス：+49 531 391-5936 Eメール：schoenw@ibr.cs.tu-bs.de URI：http://www.ibr.cs.tu-bs.de/
Binay Sugla ISPSoft Inc. 106 Apple Street Tinton Falls, NJ 07724 USA
IspsoftインチACCビナ。 106アップルストリートティントンフォールズ、NY 07724 USA
Phone: +1 732 936-1763 EMail: sugla@ispsoft.com URI: http://www.ispsoft.com/
電話：+1 732 936-1763 Eメール：sugla@ispsoft.com URI：http://www.ispsoft.com/
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エンコードを使用します。私たちは、この文書では、このエンコーディングの完全な詳細をカバーしています。これらの詳細は、国際規格ISO-8824 [13]とISO-8825 [14]に記載されています。 ASN.1 / BERの良い説明はMA・ミラー[16]によって、またはD.パーキンス、およびE.の著書「理解のSNMP MIB」の付録Aには、書籍「SNMPによる管理インターネットワーク」で見つけることができますマクギニス[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パケットで参照される各変数を一意に通常ドットで区切られた数字（例えば1.3.6.1.2.1.1.3.0）のシーケンスとして記述された、OID（オブジェクト識別子）によって識別されます。各変数は、関連する基本型（これは非常に正確ではなく、説明のこのレベルには十分ではない）を有しています。一つの可能な基本型は、IPアドレスのタイプです。各変数とその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.
変数の値は、管理者が必要とされている場合には、その変数のOID、およびNULL値を持つGET要求PDUを送信します。管理対象要素は、同じOID、変数の基本型、および現在の値が含まれていGET応答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は、配列され、そして82 00 3Eバイト（62）内のシーケンス内のデータの長さです。シーケンス内のデータは、バージョン（02 01 00）とコミュニティストリング（04 06 70 75 62 69 63 6C）です。 SNMPv1のメッセージのシーケンスの最後の要素はSNMP PDUです。
+-----------------------------------------+
| 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
+---------------------+
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自体がタグ付けされた配列である：A2は、のGetResponse PDUを示し、82 00 2Fは、バイト（47）内のGetResponse PDUのデータの長さです。 GetResponse PDUのデータは、リクエストID（02 04 6C F2 0C 5C）、エラーステータス（02 01 00）、およびエラー率（02 01 00）です。今実際のペイロードを含む変数は、次のとおり長さ31のシーケンス（30 82 00 1F）は、長さ27（30 82 00 1B）の配列を含みます。その中に、第一の目的は、値1.3.6.1.2.1.7.5.1.1.192.180.140.202.520と長さ19（06 13）のOIDです。最後の6バイト40 04 87 B4 8C CAがIPアドレスを表す：40は、基本タイプIPアドレスの識別であり、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プレフィックスはudpLocalAddress 192.180.140.202（81 40 81 34 81 0C 81によってインデックスされるUDP-MIBのudpLocalAddress、に解決します
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).
図4（a））とudpLocalPort 520（84 08）。 SNMPパケットが実際にOID（192.180.140.202）で符号化udpLocalAddressがudpLocalAddressオブジェクトインスタンス（135.180.140.202）の値に等しくないので、基本的なSNMP ALGによる内部矛盾を示しています。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。