RFC 2962
An SNMP Application Level Gateway for Payload Address Translation
An SNMP Application Level Gateway for Payload Address Translation ✨🎀
Okay so this is RFC 2962 🦋, written by D. Raz (Lucent Technologies), J. Schoenwaelder (TU Braunschweig), and B. Sugla (ISPSoft Inc.) 💜. It came out in October 2000 in the Network Working Group, and its category is Informational, so it shares useful info rather than setting an official Internet standard 🌸. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅.
Status of this Memo 📋
This memo gives info to the Internet community. It isn't an Internet standard of any kind, and it can be shared freely with no limits on distribution 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 💖
IESG Note 🚨
okay bestie, read this part carefully 🙈 This document describes an SNMP application layer gateway (ALG) that might be useful in certain environments. It also lists the issues and problems that can pop up when you use it as a generic SNMP ALG. The big warning is that when you use SNMPv3's authentication and privacy mechanisms, this approach can be super problematic and could jeopardize SNMP security 💀. The reader is strongly encouraged to think hard about these issues before deciding to deploy this type of SNMP ALG 🫶.
Abstract ✨
So this doc describes the ALG (Application Level Gateway) for SNMP (Simple Network Management Protocol), which statically maps IP (Internet Protocol) addresses found in the payload of SNMP packets from one group to another 🧚. The SNMP ALG is a specific case of an Application Level Gateway, as described in [15] 💅.
An SNMP ALG lets network management stations manage multiple networks that use conflicting IP addresses. That's a big deal in environments where you need SNMP to work with NAT (Network Address Translator) so you can manage several potentially overlapping addressing realms 🦋.
The doc also includes a detailed description of the requirements and limitations for an SNMP Application Level Gateway implementation, and it talks about other ways to exchange SNMP packets across conflicting addressing realms 🌸.
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 .....................................201. Introduction 🌸
okay so the need for IP address translation pops up when a network's internal IP addresses can't be used outside that network 💖. Basic network address translation lets local hosts on these private networks (addressing realms) reach the global Internet transparently, and it also lets outside parties reach selected local hosts 🫶. It's not unlikely to have several addressing realms using the same private IPv4 address space inside one organization, and honestly that's where things get messy 🙈.
In lots of these cases, you need to manage the local addressing realm from a manager site outside the domain. But managing a network like that comes with its own unique problems and challenges 😭. Most management apps use SNMP (Simple Network Management Protocol) to pull info from network elements 💅. For example, a router might get asked by the management app about the addresses of its neighboring elements. The router then sends that info back to the management station inside the payload of an SNMP packet 🧚. To keep the management station's view consistent, we need to be able to find and translate the IP address info in the payload of those packets 🎀.
The SNMP Application Level Gateway for Payload Address Translation, or SNMP ALG, is a technique where the payload of SNMP packets (PDUs) gets scanned, and any IP address related info gets translated if needed ✨. In this context, an SNMP ALG can be an extra component in a NAT implementation, or it can be a separate entity that lives in the same gateway or even on a separate node 🦋. Also, since we're talking about a management app, all devices in the network are assumed to have a fixed IP address 💜. So the SNMP ALG should only be combined with NAT that uses static address assignment for all the devices in the network 🔥.
A typical scenario where the SNMP ALG is deployed as part of NAT is shown in Figure 1 🌈. A manager device is managing a remote stub with translated IP addresses 🍓.
\ | / .
+---------------+ WAN . +------------------------------+
|Regional Router|-----------------|Stub Router w/NAT and SNMP ALG|
+---------------+ . +------------------------------+
| . |
| . | LAN
+----------+ . ---------------
| Manager | Stub border Managed network
+----------+
Figure 1: SNMP ALG in a NAT configurationA similar scenario happens when several subnetworks with private (and possibly conflicting) IP addresses need to be managed by the same management station 🫶. This one is shown in Figure 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 networksSince the devices in the managed network are monitored by the manager device, they must get a fixed IP address 🌸. That's why the NAT used in this case has to be a basic NAT with a static one to one mapping 🎀.
An SNMP ALG is required to scan the whole payload of SNMP packets, detect IP address related data, and translate that data if needed 🦋. This is way more computationally involved than bi-directional NAT, even though both use the same translation tables 🧠. In lots of cases the router may not be able to handle SNMP ALG and still keep acceptable performance 😭. When that happens, it may be better to put the SNMP ALG outside the router, like in Figure 2 ✨.
2. Terminology and Concepts Used 📖
So in general we adapt the terminology defined in [15] 💜. Our main concern is SNMP messages exchanged between SNMP engines 🫶. This document only talks about SNMP messages sent over UDP, which is the preferred transport mapping for SNMP messages [5] 🔥. SNMP messages sent over other transports can be handled in a similar way 🌈. So the term SNMP packet is used throughout this document to mean an SNMP message contained in a UDP packet 🍓.
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 here, so we'll focus on the info in a single SNMP packet 🧚.
There are currently three versions of SNMP 🎀. SNMP version 1 (SNMPv1) 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] 💜. For a more detailed overview of the SNMP standards, check out RFC 2570 [9] 🌸. From here on, unless we say otherwise, we use the term SNMP in statements that apply to all three SNMP versions 💖.
SNMP uses ASN.1 [13] to define the abstract syntax of the messages 🧠. The actual encoding of the messages is done with the Basic Encoding Rules (BER) [14], which provide the transfer syntax 🫶.
We call packets going from a management station to the network elements "outgoing", and packets going from the network elements to the management station "incoming" 🔥.
A basic SNMP ALG is an SNMP ALG implementation where only IP address values encoded in the IpAddress type get translated 🌈. So a basic SNMP ALG doesn't need to be MIB aware 🍓.
An advanced SNMP ALG is an SNMP ALG implementation that can handle and replace IP address values encoded in well known IP address data types, along with instance identifiers derived from those data types 💅. That means an advanced SNMP ALG is MIB aware 🧚.
3. Problem Scope and Requirements 🎯
Like we said before, in lots of cases you need to manage a local addressing realm that uses NAT, from a manager site outside that realm 🎀. A really important example is network management service providers, who run management services from a remote site ✨. These providers may have many customers, and each one might use the same private address space 🦋. When all those addressing realms are managed from a single management station, address collisions happen 😭.
There are two straightforward ways to get around address collisions. You can
- reassign IP addresses to the different addressing realms, or
- use static address NAT to hide the address collisions from the network management application.
The first solution is a problem, because it needs a potentially large set of IP addresses and a reconfiguration of a large chunk of the network 💀. The problem with the second solution is that lots of network management apps aren't NAT aware right now, and because it takes a huge investment to make them NAT aware, they'll probably stay that way for a while 🙈.
So there's a need for a solution that's transparent to the network management application (but not to the user), and that doesn't require a general reconfiguration of a large portion of the network (i.e. the addressing realm) 👑. The SNMP ALG described in this memo is exactly that solution 💖🫶.
3.1 IP Addresses in SNMP Messages
okay so SNMP messages can stash IP addresses in a bunch of different places and formats, and the spec sorted them into four categories 💅
- 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
ipAdEntNetMaskobject defined in the IP-MIB [6]. 🎀 - IP version 4 addresses contained in instance identifiers derived from index objects using the IpAddress data type. An example is the
ipAdEntAddrindex object of the IP-MIB [6]. 🦋 - IP addresses (any version) contained in OCTET STRINGS. Examples include the
addressMapNetworkAddressobject 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]). 🌸 - IP addresses (any version) contained in instance identifiers derived from OCTET STRINGS. This may be derived from well-known textual conventions (e.g. TAddress [5] or Ipv6Address [8] or InetAddress [19]) like the
ipv6AddrAddressindex object of the IPV6-MIB [8]. 🧚
Textual conventions that can contain IP addresses can be further split into NAT friendly and NAT unfriendly ones. ✨ A NAT friendly textual convention makes sure the encoding on the wire has enough info that an advanced SNMP ALG (one that understands the textual convention and has the necessary MIB knowledge) can do a proper translation. The Ipv6Address textual convention is an example of this type. 💜
A NAT unfriendly textual convention needs an SNMP ALG that understands it and has the necessary MIB knowledge, plus access to additional information to do a proper translation. 😭 The TAddress and InetAddress textual conventions are examples of this type, because they require an additional varbind to be present in the SNMP packet so you can tell what type of IP address a given value represents. Such a varbind may or may not be present, depending on the way a management application retrieves data.
3.2 Requirements
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 it must not have a 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 described above, when it's given the specified OIDs and the encoding details.
The SNMP ALG needs bi-directional NAT devices along the way that support static address mapping for all nodes in the respective private realms. 🌈 When a single SNMP ALG supports multiple private realms, the external addresses assumed by each of the NAT devices must not collide with each other. 👑
4. Translating IP Addresses in SNMP Packets ✨
This section walks through several ways to translate IP addresses in SNMP packets. 🍓
A general SNMP ALG must be capable of translating IP addresses in outgoing and incoming SNMP packets. 💅
SNMP messages sent over UDP may get fragmented at the IP layer. 😬 In an extreme case, fragmentation can split an IP address type across two different fragments. To translate IP addresses in SNMP messages, the complete SNMP message has to be available. As described in [18], fragments of UDP packets don't carry the destination/source port number with them, so an SNMP ALG must reassemble IP packets which contain SNMP messages. 🙈 The good news is that SNMP agents are usually aware of the MTU, and SNMP packets are usually pretty small. 🦋 Some SNMP implementations also set the don't fragment (DF) bit in the IP header [1] to avoid fragmentation. 🌸
4.1 Basic SNMP Application Level Gateway
A basic SNMP ALG is an SNMP ALG implementation in which only IP address values encoded in the IpAddress base type get translated. 🎀 It parses an ASN.1/BER encoded SNMP packet looking for elements encoded using the IpAddress base type. Appendix A has a more detailed description of the structure and encoding used by SNMP. 📚
An IpAddress value is easy to spot thanks to 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 it needs translation, the 4 bytes representing the IPv4 address get replaced with the translated IPv4 address, and the UDP checksum is adjusted. Section 4.3 describes an efficient algorithm for adjusting the UDP checksum without recalculating it. 🧮
The basic SNMP ALG doesn't need knowledge of any MIBs, since it relies on the ASN.1/BER encoding of SNMP packets. 💖 That makes it easy to implement. A basic SNMP ALG doesn't change the overall message size, so it can't cause translated messages to get lost due to message size constraints. 🙌
BUT a basic SNMP ALG can only translate IPv4 addresses in objects that use the IpAddress base type. 😤 It also isn't capable of translating IP addresses in objects that are index components of conceptual tables. This is especially a problem for index components that aren't accessible. 💀 So the basic SNMP ALG is restricted to the first of the four possible ways to represent IP addresses in SNMP messages (see Section 3.1).
4.2 Advanced SNMP Application Level Gateway
An advanced SNMP ALG is an SNMP ALG implementation that can handle and replace IP address values encoded in well-known IP address data types, and in instance identifiers derived from those data types. 👑 So an advanced SNMP ALG may be able to transparently map IP addresses in formats 1-4 described in Section 3.1. This means an advanced SNMP ALG must be MIB aware. 🧠
An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID) translation table so it can identify IP addresses that aren't encoded in an IpAddress base type. 🗂️ The OID translation table needs to track the OIDs where translation may be needed. The translation table also needs to keep information about instance identifiers for conceptual tables that contain IP addresses. This OID translation table may be populated offline using a MIB compiler that loads the MIBs used within an addressing realm and searches for types, textual conventions and table indexes that may contain IP addresses. 🌟
The translation function scans the packet for these specific OIDs, checks the translation table, and replaces the data if needed. ⏳ Heads up: since OIDs don't have a fixed size, this search is way more computationally expensive, and the lookup operation may be costly. 💸
Being able 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. If you replace the embedded private IPv4 address with 135.180.140.202, you get the OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. 🤯 This 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. 📏
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 can cause serious side effects for management applications that use lexicographic ordering to retrieve only parts of a conceptual table. Lots of SNMP managers also check lexicographic ordering to detect loops caused by broken agents, so such a manager will incorrectly report agents behind an advanced SNMP ALG as broken SNMP agents. 🙃
4.3 Packet Size and UDP Checksum
Changing an IpAddress value in an SNMP packet doesn't change the size of the SNMP packet. 🌷 So a basic SNMP ALG never changes the size of the underlying UDP packet. 🙌
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 in SNMP packet size needs extra changes in the UDP and IP headers. Increasing packet sizes are especially problematic with SNMPv3. The SNMPv3 message header contains the msgMaxSize field so agents can generate Response PDUs for GetBulkRequest PDUs that are close to the maximum message size the receiver can handle. 📦 If an SNMP ALG increases the size of an SNMP packet, the Response PDU may not be processable anymore, so an advanced SNMP ALG may cause some SNMPv3 interactions to fail. 💔
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, because the modified bytes may start on an odd position. ✨ The C code shown in Figure 3 adjusts the checksum for a replacement of one byte in an odd or even position. 💅
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;
}5. Limitations and Alternate Solutions 🦋
okay so making SNMP ALGs totally transparent to every management app is NOT happening bestie 😭 the basic SNMP ALG from Section 4.1 only translates IP addresses that are encoded in the IpAddress base type. that gives you very limited transparency 💀 because IP addresses show up all the time as part of an index into a conceptual table. so a management app ends up seeing both the translated address AND the original one, and that can cause confusion and erroneous behavior. ngl that's a mess 🙈 BUT certain management apps, like network discovery tools for example, can actually vibe pretty well across NATs with a basic SNMP ALG in place ✨
the advanced SNMP ALG from Section 4.2 gets you better transparency 💅 however, it can only claim to be transparent for the set of data types (textual conventions) that the advanced SNMP ALG implementation understands, and only for a given set of MIB modules. the price of that better transparency is extra complexity, potentially bigger SNMP packets, and mixed up lexicographic ordering 😩 especially with SNMPv3, communication can fail because the packets got too big. and management apps that rely on lexicographic ordering will act up 🥴
both basic AND advanced SNMP ALGs cause problems when you use 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. so the SNMP ALG needs access to all the localized keys in use if it wants to modify SNMPv3 messages without invalidating them. it also has to track any key changes in order to function. more details on the security implications of SNMP ALGs are in Section 6 💜
finally, an SNMP ALG only deals with SNMP traffic and doesn't touch the payload of any other protocol 🧚 but management systems usually use a whole set of protocols to manage a network. the telnet protocol, for instance, is often used to configure or troubleshoot managed devices. so a management system and the human network operator generally need to be aware that a network address translation is happening, EVEN when an SNMP ALG is in place 👀
a possible alternative to SNMP ALGs is SNMP proxies, as defined in RFC 2573 [11] ✨ an SNMP proxy forwarder application forwards SNMP messages to other SNMP engines according to the context, no matter which specific managed object types are being accessed. the proxy forwarder also forwards the response to those previously forwarded messages back to the SNMP engine the original message came from 🎀 a proxy forwarder can be used in a NAT environment to address SNMP engines that have conflicting IP addresses. (just swap the box labeled SNMP ALG for one labeled SNMP PROXY in Figure 2 🦋) deploying SNMP proxies has the advantage that different security levels can be used inside and outside of the conflicting addressing realms 🌈
the proxy solution is structurally preferable 👑 but it does require that the management application is aware of the proxy situation. management applications also have to use internal data structures for network elements that allow for conflicting IP addresses, because the SNMP proxy does NOT translate conflicting IP addresses 😤 and deploying proxies may involve reconfiguring network elements and management stations so they direct their traffic (notifications and requests) to the proxy forwarder 🫶
6. Security Considerations 🔐
⚠️ this section is SERIOUS, so read it carefully bestie, no skimming!! 🚨
SNMPv1 and SNMPv2c have very weak security services, based on community strings 😭 ALL management information is sent in cleartext, with no encryption and/or authentication. in that kind of environment, any intermediate node can modify SNMP messages, and management applications can't verify the integrity of SNMP messages 💀 an SNMP ALG also doesn't need to know the community strings in order to translate embedded IP addresses. so deploying SNMP ALGs in an SNMPv1/SNMPv2c environment introduces no additional security problems 🌸
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 sent in cleartext. in that case, using SNMP ALGs introduces no additional security problems ✨
BUT using an 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 that supports the matching cryptographic algorithms AND has access to the keys in use. also, since keys may be updated, the SNMP ALG has to have a mechanism that tracks key changes (either by analyzing the key change interactions or by propagating key changes through other mechanisms) 🔑 second, the computational complexity of processing SNMP messages may increase dramatically 🥵 the message has to be decrypted before translation happens, and if any translation is done, the hash signature used to authenticate the message and protect its integrity must be recomputed.
in general, key exchange protocols are complicated, and designing an SNMP ALG that 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 that takes a password and generates localized keys for every SNMP engine. the localized keys have the property that a single compromised localized key does not automatically give an attacker access to other SNMP engines, even if the key for those other engines is derived from the same password 🛡️
an SNMP ALG implementation that maintains lists of (localized) keys is a potential target for attacks on all the systems that use those keys 😱 an SNMP ALG implementation that maintains passwords in order to generate localized keys is a potential target for attacks on all systems that use the same password 💀 so an SNMP ALG implementation must be properly secured, so that people who are not authorized to access keys or passwords cannot get to them 🔒
last but definitely not least, SNMP ALGs do not let a network operator 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, like management outsourcing 🌐 deploying 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 🫧
7. Summary and Recommendations 📝
okay recap time bestie 🎀 several approaches to addressing SNMP agents across NAT devices have been discussed in this memo ✨
- 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're fast and efficient and may be sufficient to run simple management applications (like topology discovery applications) in a NAT environment 🏃♀️ however, other management applications are likely to fail because of the limited transparency a basic SNMP ALG provides. basic SNMP ALGs are also problematic in a secure SNMP environment, since they need to maintain lists of keys or passwords in order to function 🔐
- 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. BUT an advanced SNMP ALG is much more complex and less efficient than a basic SNMP ALG 🥴 it may break lexicographic ordering when IP addresses are used to index conceptual tables, and it may change SNMP packet sizes. especially with SNMPv3, communication can fail because of increased message sizes 💀 advanced SNMP ALGs are also problematic in a secure SNMP environment, since they need to maintain lists of keys or passwords in order to function 🔑
- 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. so management applications must be able to deal with network elements that have conflicting IP addresses, and they have to be aware of the proxy situation 🧐 deploying proxies may also involve reconfiguring network elements and management stations to direct their traffic (notifications and requests) to the proxy forwarder. the big perk of SNMP proxies is that they let you use different security levels inside and outside of a given addressing realm 🌈
it is recommended that network operators who need to manage networks in a NAT environment do a careful analysis BEFORE deploying a solution 🔍 specifically, it must be analyzed whether the management applications will work with the transparency and side-effects that SNMP ALGs bring. it should also be researched whether the management applications can deal with conflicting IP addresses on network devices 🧪 and finally, the extra complexity SNMP ALGs add to the overall management system must be compared with the complexity of the structurally preferable SNMP proxy forwarders 💜
8. Current Implementations 🏆
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 the SNMP ALG was combined with the NAT implementation of Lucent's PortMaster3, was deployed successfully in a large network management service organization 🎉
9. Acknowledgments 🫶
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 came from members of the NAT working group 🦋
10. References ✨
okay so the references are basically the reading list 📚 every source this doc leans on, all listed so you can go look stuff up yourself 🧚
- [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
- [3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [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.
- [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.
- [6] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
- [7] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
- [8] Haskin, D. and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group", RFC 2465, December 1998.
- [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.
- [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.
- [11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
- [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.
- [13] ISO, "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.
- [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.
- [15] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997.
- [17] Perkins, D. and E. McGinnis, "Understanding 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.
- [19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000.
11. Authors' Addresses 💌
here's where you can find the three authors, with their mailing addresses and contact details 🫶
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
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
Phone: +1 732 936-1763
EMail: sugla@ispsoft.com
URI: http://www.ispsoft.com/12. Appendix A. Description of the Encoding of SNMP Packets 🔍
okay this appendix is the packet-level tour 🦋 we're going to peek inside a real SNMP message byte by byte
SNMP packets use the ASN.1/BER encoding 🧠 we're not going to unpack every single detail of it here, because the full rules live in the international standards ISO-8824 [13] and ISO-8825 [14]. if you want a friendlier explainer, M. A. Miller's book [16] has a good ASN.1/BER description, and so does Appendix A of D. Perkins and E. McGinnis's book [17] ✨
every variable you can point at in an SNMP packet has its own unique OID (Object Identifier) 🔢, which is usually written as numbers separated by dots, like 1.3.6.1.2.1.1.3.0. each variable also gets an associated base type. ngl this is not 100% accurate, but it's good enough for this level of description 💅 one possible base type is the IpAddress type 🌐. the OID and the base type of each variable both travel inside the ASN.1/BER encoding. extra type info can also be attached to a variable through textual conventions, but those extra semantics are not carried by the ASN.1/BER encoding 🙈
so when a manager wants the value of a variable, it sends a get-request PDU containing that variable's OID plus a NULL value 📨. the managed element answers with a get-response PDU that holds the same OID, the variable's base type, and its current value 💖 Figure 4 shows real data from an SNMPv1 GetResponse PDU 👀
the first 20 bytes are the IPv4 4 header 🧭. the next 8 bytes are the UDP header, and the last two bytes of that UDP header are the UDP checksum (D3 65) 🎀. then the next four bytes, 30 82 00 3E, mark the start of the SNMP message: 30 is SEQUENCE, and 82 00 3E is the length of the data inside that SEQUENCE, which is 62 bytes 📏. the SEQUENCE's data starts with the version (02 01 00) and the community string (04 06 70 75 62 6C 69 63) 🫧. the very last element of the SNMPv1 message's SEQUENCE is the SNMP PDU 💜
here's the whole thing laid out:
+-----------------------------------------+
| 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 tells you it's a GetResponse PDU, and 82 00 2F is the length of that GetResponse data, which is 47 bytes 📐. inside it you find the request-id (02 04 6C F2 0C 5C), the error-status (02 01 00), and the error-index (02 01 00) 🌸. now for the good stuff, the real payload 🎁: a SEQUENCE OF of length 31 (30 82 00 1F) that contains a SEQUENCE of length 27 (30 82 00 1B). the first object in there 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, are an IpAddress: 40 identifies the base type IpAddress, 04 is the length, and the next four bytes are the IP address value (135.180.140.202) 🌈
and this example has something sneaky going on 👀: an IP address is hiding inside an OID. that 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 packet actually contradicts itself because of a basic SNMP ALG 💀: the udpLocalAddress encoded in the OID (192.180.140.202) doesn't match the value of the udpLocalAddress object instance (135.180.140.202). that's the kind of mismatch that makes me say "not the ALG messing with my packets" 🙈
13. Full Copyright Statement 📜
okay legal time, but I'm keeping it complete so nothing gets lost 🫶
the Internet Society owns the copyright on this document (2000), and all rights are reserved 🔒 the document and its translations can be copied and handed out, and derivative works that comment on it, explain it, or help people implement it can be written, copied, published, and distributed, in whole or in part, with no restrictions of any kind 🦋. the one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 📎
the document itself can't be modified in any way, though. you can't remove the copyright notice or the references to the Internet Society or other Internet organizations, with two exceptions: when it's needed to develop Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or when it's being translated into languages other than English 🌍
those limited permissions are perpetual and the Internet Society (or its successors or assigns) will never revoke them 💜
last but not least, the disclaimer ⚠️: this document and the information in it is provided "AS IS", 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 💖
📦 where this page comes from
- ietf: rfc2962 2000-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms