[要約] RFC 2962は、SNMPアプリケーションレベルゲートウェイのためのペイロードアドレス変換に関する規格です。このRFCの目的は、異なるネットワーク間でのSNMP通信を可能にするために、ペイロードアドレスの変換を行う仕組みを提供することです。
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.
Copyright（c）The Internet Society（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アルグとして使用されたときに発生する可能性のある問題と問題もリストされています。具体的には、SNMPV3の認証とプライバシーメカニズムを使用する場合、このアプローチは非常に問題があり、SNMPセキュリティを危険にさらす可能性があります。読者は、このタイプのSNMPアルグを展開することを決定する前に、これらの問題を慎重に検討することをお勧めします。
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（Simple Network Management Protocol）のALG（アプリケーションレベルゲートウェイ）について説明します。SNMPアルグは、[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アドレスを使用する複数のネットワークを管理できます。これは、SNMPをNAT（ネットワークアドレス翻訳者）で使用する必要がある環境で重要になる可能性があり、いくつかの潜在的に重複するアドレスの領域を管理します。
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アルグは、SNMPパケット（PDU）のペイロードがスキャンされ、必要に応じてIPアドレス関連情報が翻訳される手法です。これに関連して、SNMPアルグは、NAT実装の追加コンポーネントになる可能性があります。または、同じゲートウェイまたは別のノードに存在する可能性のある別のエンティティである場合があります。管理アプリケーションのコンテキストでは、ネットワーク内のすべてのデバイスには固定IPアドレスがあると想定されていることに注意してください。したがって、SNMPアルグは、ネットワーク内のすべてのデバイスに対して静的アドレス割り当てを使用する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アルグがNATの一部として展開される典型的なシナリオを図1に示します。マネージャーデバイスは、翻訳されたIPアドレスを備えたリモートスタブを管理しています。
\ | / .
+---------------+ 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アルグ
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.
同様のシナリオは、プライベート（およびおそらく矛盾する）アドレスを持ついくつかのサブネットワークが同じ管理ステーションによって管理される場合に発生します。このシナリオを図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：外部SNMPアルグを使用して2つのプライベートネットワークを管理する
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パケットのすべてのペイロードをスキャンし、IPアドレス関連データを検出し、必要に応じてこのデータを翻訳するために、SNMPアルグが必要です。これは、双方向NATよりもはるかに計算上のプロセスですが、どちらも同じ翻訳テーブルを使用しています。多くの場合、ルーターはSNMPアルグを処理できず、許容可能なパフォーマンスを保持できない場合があります。これらの場合、図2で説明するように、ルーターの外側のSNMPアルグを見つける方が良いかもしれません。
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（プロトコルデータユニット）が含まれています。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]で定義されています。SNMP標準のより詳細な概要については、RFC 2570 [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]を使用して、メッセージの抽象的な構文を定義します。メッセージの実際のエンコードは、転送構文を提供する基本エンコードルール（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アルグは、iPaddressタイプでエンコードされたIPアドレス値のみが翻訳されるSNMPアルグ実装です。したがって、基本的なSNMPアルグは、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アルグは、よく知られているIPアドレスデータ型とそれらのデータ型から派生したインスタンス識別子にエンコードされたIPアドレス値を処理および置き換えることができるSNMPアルグ実装です。これは、高度なSNMPアルグが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. 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アルグは、そのような解決策です。
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に保存されているIPバージョン4アドレスとマスクは、インスタンス識別子の一部ではないASN.1データ型をタグ付けしました。例は、IP-MIB [6]で定義されているiPadentNetMaskオブジェクトです。2. iPaddressデータ型を使用してインデックスオブジェクトから派生したインスタンス識別子に含まれるIPバージョン4アドレス。例は、IP-MIBのiPadentADDRインデックスオブジェクトです[6]。3. Octet文字列に含まれるIPアドレス（任意のバージョン）。例には、rmon2-mib [7]のaddressmapnetworkaddressオブジェクト、およびよく知られているテキストの規則に由来するオクテット文字列に含まれるIPアドレス（例：taddress [5]またはIPv6address [8]またはInetAddress [19]）が含まれます。4.オクテット文字列から派生したインスタンス識別子に含まれるIPアドレス（任意のバージョン）。これは、IPv6-Mib [8]のIPv6Addraddressインデックスオブジェクトのように、よく知られているテキストの慣習（例：Taddress [5]またはIPv6Address [8]またはInetAddress [19]）から派生する可能性があります。
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フレンドリーなテキスト条約により、ワイヤー上のエンコードには、テキスト条約を理解し、必要なMIBの知識が適切な翻訳を行うことができる高度なSNMPアルグが十分な情報を含むことが保証されます。このタイプの例は、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の不親切なテキスト条約では、テキスト条約を理解し、必要なMIB知識を持っているSNMPアルグが、適切な翻訳を行うために追加情報にアクセスできることが必要です。このタイプの例は、TaddressとInetAddressのテキストコンベンションです。これには、特定の値が表すどのタイプのIPアドレスを決定するために、追加のVarbindがSNMPパケットに存在することが必要です。このような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アルグは、管理アプリケーションへの透明なIPアドレス変換を提供する必要があります。SNMP ALGは、RFC 1157 [2]およびRFC 1905 [4]で定義されているSNMPプロトコル操作の動作と互換性がなければならず、SNMPプロトコルによって提供されるセキュリティにマイナスの影響を与えてはなりません。完全に透明なSNMPアルグは、指定された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アルグには、それぞれのプライベートレルムのすべてのノードの静的アドレスマッピングをサポートする双方向NATデバイスが必要です。単一のSNMPアルグでサポートされている複数のプライベートレルがある場合、各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アルグは、発信および着信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.
UDPを介して送信されるSNMPメッセージは、IPレイヤーで断片化が発生する可能性があります。極端な場合、断片化によりIPアドレスタイプが2つの異なるフラグメントに分割される可能性があります。SNMPメッセージでIPアドレスを翻訳するには、完全なSNMPメッセージを使用できる必要があります。[18]で説明されているように、UDPパケットのフラグメントは、宛先/ソースポート番号を搭載していません。したがって、SNMPアルグは、SNMPメッセージを含むIPパケットを再組み立てする必要があります。しかし、良いニュースは、通常、SNMPエージェントがMTUを認識しており、SNMPパケットは通常比較的小さいことです。一部のSNMP実装は、断片化を避けるために、IPヘッダー[1]にDont Fragment（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アルグは、iPaddressベースタイプでエンコードされたIPアドレス値のみが翻訳されるSNMPアルグ実装です。基本的な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.
iPaddress値は、タグ値（0x40）で簡単に識別できます。iPaddressが検出されると、SNMPアルグは翻訳テーブルをチェックし、アドレスを翻訳する必要があるかどうかを決定します。アドレスに変換が必要な場合、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アルグは、SNMPパケットのASN.1/BERエンコードに依存しているため、MIBの知識を必要としません。したがって、実装は簡単です。基本的なSNMPアルグは、メッセージ全体のサイズを変更しないため、メッセージサイズの制約のために翻訳されたメッセージが失われることはありません。
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アルグは、iPaddressベースタイプを使用するオブジェクトにIPv4アドレスのみを変換することができます。さらに、基本的なSNMPアルグは、概念テーブルのインデックスコンポーネントであるオブジェクトにIPアドレスを変換することはできません。これは、アクセスできないインデックスコンポーネントで特に問題があります。したがって、基本的なSNMPアルグは、SNMPメッセージのIPアドレスを表す4つの可能な方法のうち最初のものに制限されています（セクション3.1を参照）。
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アルグは、よく知られているIPアドレスデータ型とそれらのデータ型から派生したインスタンス識別子にエンコードされたIPアドレス値を処理および置き換えることができるSNMPアルグ実装です。したがって、高度なSNMPアルグは、セクション3.1で説明されているように、1〜4形式のIPアドレスを透過的にマッピングできる場合があります。これは、高度なSNMPアルグが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アルグは、iPaddressベースタイプでエンコードされていないIPアドレスを識別するために、オブジェクト識別子（OID）翻訳テーブルを維持する必要があります。OID翻訳テーブルは、翻訳が必要なOIDに関する情報を維持する必要があります。さらに、翻訳テーブルは、IPアドレスを含む概念テーブルのインスタンス識別子に関する情報を保持する必要があります。このようなOID翻訳テーブルは、アドレス指定領域内で使用されているMIBSをロードし、IPアドレスを含む可能性のあるタイプ、テキストの規則、テーブルインデックスを検索する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アルグの必要な機能です。インスタンス識別子に埋め込まれたIPアドレスは、OIDエンコードルールに従ってエンコードされています。たとえば、ip-mib [6]のiPadentifindexオブジェクトの10.1.2.3インスタンスのoidは06 0d 2b 06 01 02 01 04 14 01 02 0a 01 02 03.埋め込まれたプライベートIPv4アドレスを135.1800に置き換える.140.202はOID 06 11 2b 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4aにつながります。この例は、OIDに埋め込まれたIPアドレスがASN.1/BERエンコードされたOIDのサイズを変更できるため、高度なSNMPアルグが全体のパケットサイズを変更する可能性があることを示しています。
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アルグのもう1つの効果は、SNMPマネージャーが見たように、概念テーブルの行の辞書的な順序を変更することです。これは、概念表の一部のみを取得するために辞書編集順序を使用する管理アプリケーションに深刻な副作用がある可能性があります。多くのSNMPマネージャーは、壊れたエージェントによって引き起こされるループを検出するために、辞書編集の注文をチェックします。このようなマネージャーは、壊れたSNMPエージェントとして高度な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パケットでiPaddress値を変更しても、SNMPパケットのサイズは変更されません。したがって、基本的なSNMPアルグは、基礎となる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.
高度なSNMPアルグは、異なる数のIPアドレスをエンコードするには異なる数のバイトが必要になる可能性があるため、SNMPパケットのサイズを変更する場合があります。これは非常に望ましくありませんが、一般的なケースでは避けられません。SNMPパケットサイズの変更には、UDPヘッダーとIPヘッダーに追加の変更が必要です。SNMPV3では、パケットサイズの増加に特に問題があります。SNMPV3メッセージヘッダーにはMSGMAXSIZEフィールドが含まれているため、エージェントは受信機が処理できる最大メッセージサイズに近いGetBulkRequest PDUの応答PDUを生成できます。SNMPパケットのサイズを大きくするSNMPアルグは、応答PDUをもはや処理できないという効果がある場合があります。したがって、高度なSNMPアルグにより、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アルグをすべての管理アプリケーションに対して完全に透過的にすることは、達成可能なタスクではありません。セクション4.1で説明されている基本的なSNMPアルグは、iPaddressベースタイプでエンコードされたIPアドレスのみを変換します。このようなSNMPアルグは、IPアドレスが概念テーブルへのインデックスの一部として頻繁に使用されるため、非常に限られた透明性のみを実現します。したがって、管理アプリケーションには、翻訳されたアドレスと元のアドレスの両方が表示され、管理アプリケーションの混乱と誤った動作につながる可能性があります。ただし、たとえばのような特定のクラスの管理アプリケーション。ネットワークディスカバリーツールは、基本的なSNMPアルグを配置して、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アルグは、より良い透明性を実現します。ただし、高度なSNMPアルグは、高度な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アルグの両方が、SNMPV3セキュリティ機能を使用する際に問題を導入します。SNMPV3認証メカニズムは、SNMPメッセージ全体を変更から保護しますが、SNMPV3プライバシーメカニズムはSNMPV3メッセージのペイロードを不正アクセスに対して保護します。したがって、SNMPアルグは、SNMPV3メッセージを無効にすることなく変更するために、使用中のすべてのローカライズされたキーにアクセスできる必要があります。さらに、SNMPアルグは、機能するために重要な変更を追跡する必要があります。SNMPアルグを使用することのセキュリティへの影響の詳細については、セクション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アルグはSNMPトラフィックのみを扱い、他のプロトコルのペイロードを変更しません。ただし、管理システムは通常、一連のプロトコルを使用してネットワークを管理します。特に、Telnetプロトコルは、管理されたデバイスの構成またはトラブルシューティングによく使用されます。したがって、管理システムとヒューマンネットワークオペレーターは、一般に、SNMPアルグが存在する場合でも、ネットワークアドレス変換が発生していることに注意する必要があります。
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.
RFC 2573 [11]で定義されているように、SNMPアルグに代わる可能性はSNMPプロキシです。SNMPプロキシフォワーダーアプリケーションは、コンテキストに従って、およびアクセスされる特定の管理されたオブジェクトタイプに関係なく、SNMPメッセージを他のSNMPエンジンに転送します。また、プロキシフォワーダーは、元のメッセージが受信されたSNMPエンジンに、以前に転送されたそのようなメッセージへの応答を転送します。このようなプロキシフォワーダーは、NAT環境で使用して、競合するIPアドレスを持つSNMPエンジンに対処できます。（Box SNMPアルグを図2のSNMPプロキシというラベルのあるボックスに置き換えるだけです。）SNMPプロキシの展開には、競合するアドレス指定領域の内外でさまざまなセキュリティレベルを使用できるという利点があります。
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には、コミュニティの文字列に基づいた非常に1週間のセキュリティサービスがあります。すべての管理情報は、暗号化や認証なしでクリアテキストで送信されます。このような環境では、SNMPメッセージは中間ノードによって変更でき、管理アプリケーションはSNMPメッセージの整合性を検証できません。さらに、SNMPアルグは、埋め込まれたIPアドレスを翻訳するために、コミュニティ文字列の知識を持つ必要はありません。したがって、SNMPV1/SNMPV2C環境でのSNMPアルグの展開は、追加のセキュリティ問題をもたらしません。
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は、認証と暗号化なし（NOAUTH/NOPRIV）、認証と暗号化なし（AUTH/NOPRIV）、認証と暗号化（AUTH/PRIV）の3つのセキュリティレベルをサポートしています。認証と暗号化のないSNMPV3メッセージ（noauth/nopriv）はクリアテキストで送信されます。そのような場合、SNMPアルグの使用には追加のセキュリティ問題が発生しません。
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.
ただし、SNMPアルグの使用は、SNMPV3認証とオプションの暗号化が使用されるときに新しい問題をもたらします。まず、認証とオプションの暗号化（Auth/NoprivおよびAuth/Priv）を備えたSNMPV3メッセージは、対応する暗号化アルゴリズムをサポートし、使用中のキーにアクセスできるSNMPアルグによってのみ処理できます。さらに、キーが更新される可能性があるため、SNMPアルグには、重要な変化を追跡するメカニズムが必要です（重要な変化の相互作用を分析するか、他のメカニズムによる重要な変化を伝播することにより）。第二に、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アルグを設計することは、非自明なタスクです。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アルグの実装を適切に保護する必要があります。
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アルグは、ネットワークオペレーターがNATの両側で異なるセキュリティレベルを使用することを許可しません。プライベートアドレス指定の領域外で安全なSNMPバージョンを使用すると、プライベートアドレス指定領域がSNMPの無担保バージョンを実行している間、多くのシナリオで非常に望ましい場合があります。管理アウトソーシングシナリオ。SNMPアルグの代わりにSNMPV3プロキシの展開は、SNMPプロキシをプロキシの両側で異なるセキュリティレベルとパラメーターを使用するように構成できるため、これらの場合に考慮する必要があります。
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. セクション4.1で説明されている基本的なSNMPアルグは、iPaddressベースタイプでエンコードされたIPv4アドレスのみを翻訳するため、非常に限られた透明性を提供します。それらは高速で効率的であり、NAT環境で簡単な管理アプリケーション（トポロジディスカバリーアプリケーションなど）を実行するのに十分な場合があります。ただし、基本的なSNMPアルグによって提供される透明性が限られているため、他の管理アプリケーションが失敗する可能性があります。基本的なSNMPアルグは、機能するためにキーまたはパスワードのリストを維持する必要があるため、安全なSNMP環境で問題があります。2.セクション4.2で説明されているように、高度なSNMPアルグはより良い透明性を提供します。それらは、彼らが理解している一連のデータ型と、特定のMIBモジュールのセットについて透過的である可能性があります。ただし、高度なSNMPアルグは、基本的なSNMPアルグよりもはるかに複雑で効率が低くなります。高度なSNMPアルグは、IPアドレスが概念テーブルのインデックスに使用され、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.
3. RFC 2573 [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プロキシフォワーダーによって導入された複雑さと比較する必要があります。
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アルグは、Solarisマシンで実行されているBell-LabsでSNMPV1に実装されました。SNMPアルグが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] Postel、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] Case、J.、Fedor、M.、Schoffstall、M。and J. Davin、「A Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月。
[3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[3] Case、J.、McCloghrie、K.、Rose、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2のプロトコル操作」、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2の輸送マッピング」、RFC 1906、1996年1月。
[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を使用したバージョン2」、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. Onishi、「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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン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] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、RFC 2572、1999年4月。
[11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[11] Levi、D.、Meyer、P。and B. Stewart、「SNMP Applications」、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] Blumenthal、U.およびB. Wijnen、「シンプルネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、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）の仕様」、1987年12月、国際標準8824。
[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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
[16] Miller、M。、「SNMPを使用したインターネットワークの管理」、Mt Books、1997。
[17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", Prentice Hall, ISBN 0-13-437708-7, 1997.
[17] Perkins、D。およびE. McGinnis、「Snmp Mibsの理解」、Prentice Hall、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] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキストコンベンション」、RFC 2851、2000年6月。
Danny Raz Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733-3030 USA
Danny Raz Lucent Technologies 101 Crawfords Corner Rd Holmdel、NJ 07733-3030 USA
Phone: +1 732 949-6712
Fax: +1 732 949-0399
EMail: raz@lucent.com
URI: http://www.bell-labs.com/
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
Juergen Schoenwaelder Tu Braunschweig Bueltenweg 74/75 38106 Braunschweigドイツ
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/
Binay Sugla ISPSoft Inc. 106 Apple Street Tinton Falls, NJ 07724 USA
Binay Sugla Ispsoft Inc. 106 Apple Street Tinton Falls、NJ 07724 USA
Phone: +1 732 936-1763
EMail: 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の適切な説明は、「SNMPを使用したインターネットワークの管理」、M。A。ミラー[16]、またはD. Perkins、およびEによる「Snmp Mibsの理解SNMP MIBS」の付録Aという本にあります。McGinnis [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（オブジェクト識別子）によって一意に識別されます（例：1.3.6.1.2.1.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.
マネージャーが変数の値を必要とする場合、その変数のOIDとnull値を備えたGet-Request PDUを送信します。次に、マネージド要素は、同じOID、変数のベースタイプ、および現在の値を含むGet-Response 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 6C 69 63）です。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はバイトのGetResponse PDUのデータの長さです（47）。GetResponse PDUのデータは、リクエストID（02 04 6C F2 0C 5C）、エラーステータス（02 01 00）、およびエラーインデックス（02 01 00）です。ここで、実際のペイロードを含む変数に従います。長さ27（30 82 00 1b）のシーケンスを含む長さ31（30 82 00 1F）のシーケンス。その中で、最初のオブジェクトは、値1.3.6.1.1.2.1.7.5.1.1.192.180.140.202.520の長さ19（06 13）のOIDです。最後の6バイト40 04 87 B4 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 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).
この例は、OIDに埋め込まれたIPアドレスも示しています。OIDプレフィックスは、UDPLocalAddress 192.180.140.202（81 40 81 34 81 0C 81 4A）およびUDPLOCALPORT 520（84 08）によってインデックス化されたUDP-MIBのUDplocalAddressに解決します。SNMPパケットは、OID（192.180.140.202）にエンコードされたUDplocalAddressがUDplocalAddressオブジェクトインスタンス（135.180.140.202）の値に等しくないため、基本的なSNMPアルグによって引き起こされる内部矛盾を実際に示しています。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。