idnits 2.17.1 draft-ietf-nat-snmp-alg-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([15]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2000) is 8691 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 430, but not defined ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '3') ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '5') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2011 (ref. '6') (Obsoleted by RFC 4293) ** Obsolete normative reference: RFC 2021 (ref. '7') (Obsoleted by RFC 4502) ** Obsolete normative reference: RFC 2465 (ref. '8') (Obsoleted by RFC 4293, RFC 8096) ** Obsolete normative reference: RFC 2570 (ref. '9') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2572 (ref. '10') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (ref. '11') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (ref. '12') (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. '15') -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Downref: Normative reference to an Informational draft: draft-ietf-nat-traditional (ref. '18') ** Obsolete normative reference: RFC 2851 (ref. '19') (Obsoleted by RFC 3291) Summary: 20 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Raz 2 Internet-Draft Lucent Technologies 3 Expires: January 5, 2001 J. Schoenwaelder 4 TU Braunschweig 5 B. Sugla 6 ISPSoft Inc. 7 July 7, 2000 9 An SNMP Application Level Gateway for Payload Address Translation 10 draft-ietf-nat-snmp-alg-05.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To view the entire list of Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/iid-abstracts.txt 33 This Internet-Draft will expire on January 5, 2001. 35 Copyright Notice 37 Copyright (C) The Internet Society (2000). All Rights Reserved. 39 Abstract 41 This document describes the Application Level Gateway (ALG) for the 42 Simple Network Management Protocol (SNMP) by which IP addresses in 43 the payload of SNMP packets are statically mapped from one group to 44 another. The SNMP ALG is a specific case of an Application Level 45 Gateway as described in [15]. 47 An SNMP ALG allows network management stations to manage multiple 48 networks that use conflicting IP addresses. This can be important in 49 environments where there is a need to use SNMP with NAT in order to 50 manage several potentially overlapping addressing realms. 52 This document includes a detailed description of the requirements 53 and limitations for an implementation of an SNMP Application Level 54 Gateway. It also discusses other approaches to exchange SNMP packets 55 across conflicting addressing realms. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology and Concepts Used . . . . . . . . . . . . . . . . 5 61 3. Problem Scope and Requirements . . . . . . . . . . . . . . . . 5 62 3.1 IP Addresses in SNMP Messages . . . . . . . . . . . . . . . . 6 63 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Translating IP Addresses in SNMP Packets . . . . . . . . . . . 7 65 4.1 Basic SNMP Application Level Gateway . . . . . . . . . . . . . 7 66 4.2 Advanced SNMP Application Level Gateway . . . . . . . . . . . 8 67 4.3 Packet Size and UDP Checksum . . . . . . . . . . . . . . . . . 9 68 5. Limitations and Alternate Solutions . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. Summary and Recommendations . . . . . . . . . . . . . . . . . 13 71 8. Current Implementations . . . . . . . . . . . . . . . . . . . 14 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 75 A. Description of the Encoding of SNMP Packets . . . . . . . . . 16 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 The need for IP address translation arises when a network's internal 81 IP addresses cannot be used outside the network. Using basic network 82 address translation allows local hosts on such private networks 83 (addressing realms) to transparently access the external global 84 Internet and enables access to selective local hosts from the 85 outside. In particular it is not unlikely to have several addressing 86 realms that are using the same private IPv4 address space within the 87 same organization. 89 In many of these cases, there is a need to manage the local 90 addressing realm from a manager site outside the domain. However, 91 managing such a network presents unique problems and challenges. 92 Most available management applications use SNMP (Simple Network 93 Management Protocol) to retrieve information from the network 94 elements. For example, a router may be queried by the management 95 application about the addresses of its neighboring elements. This 96 information is then sent by the router back to the management 97 station as part of the payload of an SNMP packet. In order to retain 98 consistency in the view as seen by the management station we need to 99 be able to locate and translate IP address related information in 100 the payload of such packets. 102 The SNMP Application Level Gateway for Payload Address Translation, 103 or SNMP ALG, is a technique in which the payload of SNMP packets 104 (PDUs) is scanned and IP address related information is translated 105 if needed. In this context, an SNMP ALG can be an additional 106 component in a NAT implementation, or it can be a separate entity, 107 that may reside in the same gateway or even on a separate node. Note 108 that in our context of management application all devices in the 109 network are assumed to have a fixed IP address. Thus, SNMP ALG 110 should only be combined with NAT that uses static address assignment 111 for all the devices in the network. 113 A typical scenario where SNMP ALG is deployed as part of NAT is 114 presented in figure Figure 1. A manager device is managing a remote 115 stub, with translated IP addresses. 117 \ | / . 118 +---------------+ WAN . +------------------------------+ 119 |Regional Router|-----------------|Stub Router w/NAT and SNMP ALG| 120 +---------------+ . +------------------------------+ 121 | . | 122 | . | LAN 123 +----------+ . --------------- 124 | Manager | Stub border Managed network 125 +----------+ 127 Figure 1: SNMP ALG in a NAT configuration 129 A similar scenario occurs when several subnetworks with private (and 130 possibly conflicting) IP addresses are to be managed by the same 131 management station. This scenario is presented in Figure 2. 133 +---------------+ +-----------------+ 134 | SNMP ALG |-----|Management device| 135 +---------------+ +-----------------+ 136 T1 | | T1 137 | | 138 Stub A .............|.... ....|............ Stub B 139 | | 140 +---------------+ +----------------+ 141 |Bi-directional | |Bi-directional | 142 |NAT Router w/ | |NAT Router w/ | 143 |static address | |static address | 144 |mapping | |mapping | 145 +---------------+ +---------------+ 146 | | 147 | LAN LAN | 148 ------------- ------------- 149 192.10.x.y | | 192.10.x.y 150 /____\ /____\ 152 Figure 2: Using external SNMP ALG to manage two private networks 154 Since the devices in the managed network are monitored by the 155 manager device they must obtain a fixed IP address. Therefore, the 156 NAT used in this case must be a basic NAT with a static one to one 157 mapping. 159 An SNMP ALG is required to scan all the payload of SNMP packets, to 160 detect IP address related data, and to translate this data if 161 needed. This is a much more computationally involved process than 162 the bi-directional NAT, however they both use the same translation 163 tables. In many cases the router may be unable to handle SNMP ALG 164 and retain acceptable performance. In these cases it may be better 165 to locate the SNMP ALG outside the router, as described in Figure 2. 167 2. Terminology and Concepts Used 169 In general we adapt the terminology defined in [15]. Our main 170 concern are SNMP messages exchanged between SNMP engines. This 171 document only discusses SNMP messages that are send over UDP, which 172 is the preferred transport mapping for SNMP messages [5]. SNMP 173 messages send over other transports can be handled in a similar way. 174 Thus, the term SNMP packet is used throughout this document to refer 175 to an SNMP message contained in an UDP packet. 177 SNMP messages contain SNMP PDUs (Protocol Data Units). An SNMP PDU 178 defines the parameters for a specific SNMP protocol operation. The 179 notion of flow is less relevant in this case, and hence we will 180 focus on the information contained in a single SNMP packet. 182 There are currently three versions of SNMP. SNMP version 1 (SNMPv1) 183 protocol is defined in STD 15, RFC 1157 [2]. The SNMP version 2c 184 (SNMPv2c) protocol is defined in RFC 1901 [3], RFC 1905 [4] and RFC 185 1906 [5]. Finally, the SNMP version 3 (SNMPv3) protocol is defined 186 in RFC 1905 [4], 1906 [5], RFC 2572 [10] and RFC 2574 [12]. See RFC 187 2570 [9] for a more detailed overview over the SNMP standards. In 188 the following, unless otherwise mentioned, we use the term SNMP in 189 statements that are applicable to all three SNMP versions. 191 SNMP uses ASN.1 [13] to define the abstract syntax of the messages. 192 The actual encoding of the messages is done by using the Basic 193 Encoding Rules (BER) [14], which provide the transfer syntax . 195 We refer to packets that go from a management station to the network 196 elements as "outgoing", and packets that go from the network 197 elements to the management station as "incoming". 199 A basic SNMP ALG is an SNMP ALG implementation in which only IP 200 address values encoded in the IpAddress type are translated. A basic 201 SNMP ALG therefore does not need to be MIB aware. 203 An advanced SNMP ALG is an SNMP ALG implementation which is capable 204 of handling and replacing IP address values encoded in well known IP 205 address data types and instance identifiers derived from those data 206 types. This implies that an advanced SNMP ALG is MIB aware. 208 3. Problem Scope and Requirements 210 As mentioned before, in many cases, there is a need to manage a 211 local addressing realm that is using NAT, from a manager site 212 outside the realm. A particular important example is the case of 213 network management service providers who provide network management 214 services from a remote site. Such providers may have many customers, 215 each using the same private address space. When all these addressing 216 realms are to be managed from a single management station address 217 collision occurs. There are two straight forward ways to overcome 218 the address collision. One can 219 1. reassign IP addresses to the different addressing realms, or 220 2. use static address NAT to hide the address collisions from the 221 network management application. 223 The first solution is problematic as it requires both a potentially 224 large set of IP addresses, and the reconfiguration of a large 225 portion of the network. The problem with the second solution is that 226 many network management applications are currently unaware of NAT, 227 and because of the large investment needed in order to make them NAT 228 aware are likely to remain so in the near future. 230 Hence, there is a need for a solution that is transparent to the 231 network management application (but not to the user), and that does 232 not require a general reconfiguration of a large portion of the 233 network (i.e. the addressing realm). The SNMP ALG described in this 234 memo is such a solution. 236 3.1 IP Addresses in SNMP Messages 238 SNMP messages can contain IP addresses in various places and 239 formats. The following four categories have been identified: 240 1. IP version 4 addresses and masks stored in the IpAddress tagged 241 ASN.1 data type which are not part of an instance identifier. An 242 example is the ipAdEntNetMask object defined in the IP-MIB [6]. 243 2. IP version 4 addresses contained in instance identifiers derived 244 from index objects using the IpAddress data type. An example is 245 the ipAdEntAddr index object of the IP-MIB [6]. 246 3. IP addresses (any version) contained in OCTET STRINGS. Examples 247 include addressMapNetworkAddress object of the RMON2-MIB [7], 248 and IP addresses contained in OCTET STRINGS derived from 249 well-known textual conventions (e.g. TAddress [5] or Ipv6Address 250 [8] or InetAddress [19]). 251 4. IP addresses (any version) contained in instance identifiers 252 derived from OCTET STRINGS. This may derived from well-known 253 textual conventions (e.g. TAddress [5] or Ipv6Address [8] or 254 InetAddress [19]) like the ipv6AddrAddress index object of the 255 IPV6-MIB [8]. 257 Textual conventions that can contain IP addresses can be further 258 divided in NAT friendly and NAT unfriendly ones. A NAT friendly 259 textual convention ensures that the encoding on the wire contains 260 sufficient information that an advanced SNMP ALG which understands 261 the textual convention and which has the necessary MIB knowledge can 262 do a proper translation. An example of this type is the Ipv6Address 263 textual convention. 265 A NAT unfriendly textual convention requires that an SNMP ALG, which 266 understands the textual convention and which has the necessary MIB 267 knowledge, has access to additional information in order to do a 268 proper translation. Examples of this type are the TAddress and the 269 InetAddress textual conventions which require that an additional 270 varbind is present in an SNMP packet to determine what type of IP 271 address a given value represents. Such a varbind may or may not be 272 present depending on the way a management applications retrieves 273 data. 275 3.2 Requirements 277 An SNMP ALG should provide transparent IP address translation to 278 management applications. An SNMP ALG must be compatible with the 279 behavior of the SNMP protocol operations as defined by RFC 1157 [2] 280 and RFC 1905 [4] and must not have negative impact on the security 281 provided by the SNMP protocol. A fully transparent SNMP ALG must be 282 able to translate all categories of IP addresses as described above, 283 when provided with the specified OID's and the encoding details. 285 The SNMP ALG requires bi-directional NAT devices enroute, that 286 support static address mapping for all nodes in the respective 287 private realms. When there are multiple private realms supported by 288 a single SNMP ALG, the external addresses assumed by each of the NAT 289 devices must not collide with each other. 291 4. Translating IP Addresses in SNMP Packets 293 This section describes several ways to translate IP addresses in 294 SNMP packets. 296 A general SNMP ALG must be capable to translate IP addresses in 297 outgoing and incoming SNMP packets. 299 SNMP messages send over UDP may experience fragmentation at the IP 300 layer. In an extreme case, fragmentation may cause an IP address 301 type to be partitioned into two different fragments. In order to 302 translate IP addresses in SNMP messages, the complete SNMP message 303 must be available. As described in [18], fragments of UDP packets do 304 not carry the destination/source port number with them. Hence, an 305 SNMP ALG must reassemble IP packets which contain SNMP messages. The 306 good news is, however, that usually SNMP agents are aware of the 307 MTU, and that SNMP packets are usually relatively small. Some SNMP 308 implementations also set the don't fragment (DF) bit in the IP 309 header [1] to avoid fragmentation. 311 4.1 Basic SNMP Application Level Gateway 313 A basic SNMP ALG is an SNMP ALG implementation in which only IP 314 address values encoded in the IpAddress base type are translated. A 315 basic SNMP ALG implementation parses an ASN.1/BER encoded SNMP 316 packet looking for elements that are encoded using the IpAddress 317 base type. Appendix A contains a more detailed description of the 318 structure and encoding used by SNMP. 320 An IpAddress value can be identified easily by its tag value (0x40). 321 Once an IpAddress has been detected, the SNMP ALG checks the 322 translation table and decides whether the address should be 323 translated. If the address needs translation, the 4 bytes 324 representing the IPv4 address are replaced with the translated IPv4 325 address and the UDP checksum is adjusted. Section 4.3 describes an 326 efficient algorithm to adjust the UDP checksum without recalculating 327 it. 329 The basic SNMP ALG does not require knowledge of any MIBs since it 330 relies on the ASN.1/BER encoding of SNMP packets. It is therefore 331 easy to implement. A basic SNMP ALG does not change the overall 332 messages size and hence it does not cause translated messages to be 333 lost due to message size constraints. 335 However, a basic SNMP ALG is only able to translate IPv4 addresses 336 in objects that use the IpAddress base type. Furthermore, a basic 337 SNMP ALG is not capable to translate IP addresses in objects that 338 are index components of conceptual tables. This is especially 339 problematic on index components that are not accessible. Hence, the 340 basic SNMP ALG is restricted to the first out of the four possible 341 ways to represent IP addresses in SNMP messages (see Section 3.1). 343 4.2 Advanced SNMP Application Level Gateway 345 An advanced SNMP ALG is an SNMP ALG implementation which is capable 346 of handling and replacing IP address values encoded in well known IP 347 address data types and instance identifiers derived from those data 348 types. Hence, an advanced SNMP ALG may be able to transparently map 349 IP addresses that are in the format 1-4 as described in Section 3.1. 350 This implies that an advanced SNMP ALG must be MIB aware. 352 An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID) 353 translation table in order to identify IP addresses that are not 354 encoded in an IpAddress base type. The OID translation table needs 355 to maintain information about the OIDs where translation may be 356 needed. Furthermore, the translation table needs to keep information 357 about instance identifiers for conceptual tables that contain IP 358 addresses. Such an OID translation table may be populated offline by 359 using a MIB compiler which loads the MIBs used within an addressing 360 realm and searches for types, textual conventions and table indexes 361 that may contain IP addresses. 363 The translation function scans the packet for these specific OIDs, 364 checks the translation table and replaces the data if needed. Note 365 that since OIDs do not have a fixed size this search is much more 366 computationally consuming, and the lookup operation may be 367 expensive. 369 The ability to translate IP addresses that are part of the index of 370 a conceptual table is a required feature of an advanced SNMP ALG. IP 371 addresses embedded in an instance identifier are ASN.1/BER encoded 372 according to the OID encoding rules. For example, the OID for the 373 10.1.2.3 instance of the ipAdEntIfIndex object of the IP-MIB [6] is 374 encoded as 06 0D 2B 06 01 02 01 04 14 01 02 0A 01 02 03. Replacing 375 the embedded private IPv4 address with 135.180.140.202 leads to the 376 OID 06 11 2B 06 01 02 01 04 14 01 02 81 07 81 34 81 0C 81 4A. This 377 example shows that an advanced SNMP ALG may change the overall 378 packet size since IP addresses embedded in an OID can change the 379 size of the ASN.1/BER encoded OID. 381 Another effect of an advanced SNMP ALG is that it changes the 382 lexicographic ordering of rows in conceptual tables as seen by the 383 SNMP manager. This may have severe side-effects for management 384 applications that use lexicographic ordering to retrieve only parts 385 of a conceptual table. Many SNMP managers check lexicographic 386 ordering to detect loops caused by broken agents. Such a manager 387 will incorrectly report agents behind an advanced SNMP ALG as broken 388 SNMP agents. 390 4.3 Packet Size and UDP Checksum 392 Changing an IpAddress value in an SNMP packet does not change the 393 size of the SNMP packet. A basic SNMP ALG does therefore never 394 change the size of the underlying UDP packet. 396 An advanced SNMP ALG may change the size of an SNMP packet since a 397 different number of bytes may be needed to encode a different IP 398 address. This is highly undesirable but unavoidable in the general 399 case. A change of the SNMP packet size requires additional changes 400 in the UDP and IP headers. Increasing packet sizes are especially 401 problematic with SNMPv3. The SNMPv3 message header contains the 402 msgMaxSize field so that agents can generate Response PDUs for 403 GetBulkRequest PDUs that are close to the maximum message size the 404 receiver can handle. An SNMP ALG which increases the size of an SNMP 405 packet may have the effect that the Response PDU can not be 406 processed anymore. Thus, an advanced SNMP ALG may cause some SNMPv3 407 interactions to fail. 409 In both cases, the UDP checksum must be adjusted when making an IP 410 address translation. We can use the algorithm from [18], but a small 411 modification must be introduced as the modified bytes may start on 412 an odd position. The C code shown in Figure 3 adjusts the checksum 413 to a replacement of one byte in an odd or even position. 415 void checksumbyte(unsigned char *chksum, unsigned char *optr, 416 unsigned char *nptr, int odd) 417 /* assuming: unsigned char is 8 bits, long is 32 bits, 418 we replace one byte by one byte in an odd position. 419 - chksum points to the chksum in the packet 420 - optr points to the old byte in the packet 421 - nptr points to the new byte in the packet 422 - odd is 1 if the byte is in an odd position 0 otherwise 423 */ 424 { long x, old, new; 425 x=chksum[0]*256+chksum[1]; 426 x=~x & 0xFFFF; 427 if (odd) old=optr[0]*256; else old=optr[0]; 428 x-=old & 0xFFFF; 429 if (x<=0) { x--; x&=0xFFFF; } 430 if (odd) new=nptr[0]*256; else new=nptr[0]; 431 x+=new & 0xFFFF; 432 if (x & 0x10000) { x++; x&=0xFFFF; } 433 x=~x & 0xFFFF; 434 chksum[0]=x/256; chksum[1]=x & 0xFF; 435 } 437 5. Limitations and Alternate Solutions 439 Making SNMP ALGs completely transparent to all management 440 applications is not an achievable task. The basic SNMP ALG described 441 in Section 4.1 only translates IP addresses encoded in the IpAddress 442 base type. Such an SNMP ALG achieves only very limited transparency 443 since IP addresses are frequently used as part of an index into a 444 conceptual table. A management application will therefore see both 445 the translated as well as the original address, which can lead to 446 confusion and erroneous behavior of management applications. 447 However, a certain class of management applications like e.g. 448 network discovery tools may work pretty well across NATs with a 449 basic SNMP ALG in place. 451 An advanced SNMP ALG described in Section 4.2 achieves better 452 transparency. However, an advanced SNMP ALG can only claim to be 453 transparent for the set of data types (textual conventions) 454 understood by the advanced SNMP ALG implementation and for a given 455 set of MIB modules. The price paid for better transparency is 456 additional complexity, potentially increased SNMP packet sizes and 457 mixed up lexicographic ordering. Especially with SNMPv3, there is 458 an opportunity that communication fails due to increased packet 459 sizes. Management applications that rely on lexicographic ordering 460 will show erroneous behaviour. 462 Both, basic and advanced SNMP ALGs, introduce problems when using 463 SNMPv3 security features. The SNMPv3 authentication mechanism 464 protects the whole SNMP message against modifications while the 465 SNMPv3 privacy mechanism protects the payload of SNMPv3 messages 466 against unauthorized access. Thus, an SNMP ALG must have access to 467 all localized keys in use in order to modify SNMPv3 messages without 468 invalidating them. Futhermore, the SNMP ALG must track any key 469 changes in order to function. More details on the security 470 implications of using SNMP ALGs can be found in Section 6. 472 Finally, an SNMP ALG only deals with SNMP traffic and does not 473 modify the payload of any other protocol. However, management 474 systems usually use a set of protocols to manage a network. In 475 particular the telnet protocol is often used to configure or 476 troubleshoot managed devices. Hence, a management system and the 477 human network operator must generally be aware that a network 478 address translation is occurring, even in the presence of an SNMP 479 ALG. 481 A possible alternative to SNMP ALGs are SNMP proxies, as defined in 482 RFC 2573 [11]. An SNMP proxy forwarder application forwards SNMP 483 messages to other SNMP engines according to the context, and 484 irrespective of the specific managed object types being accessed. 485 The proxy forwarder also forwards the response to such previously 486 forwarded messages back to the SNMP engine from which the original 487 message was received. Such a proxy forwarder can be used in a NAT 488 environment to address SNMP engines with conflicting IP addresses. 489 (Just replace the box SNMP ALG with a box labelled SNMP PROXY in 490 Figure 2.) The deployment of SNMP proxys has the advantage that 491 different security levels can be used inside and outside of the 492 conflicting addressing realms. 494 The proxy solution, which is structurally preferable, requires that 495 the management application is aware of the proxy situation. 496 Furthermore, management applications have to use internal data 497 structures for network elements that allow for conflicting IP 498 addresses since conflicting IP addresses are not translated by the 499 SNMP proxy. Deployment of proxies may also involve the need to 500 reconfigure network elements and management stations to direct their 501 traffic (notifications and requests) to the proxy forwarder. 503 6. Security Considerations 505 SNMPv1 and SNMPv2c have very week security services based on 506 community strings. All management information is sent in cleartext 507 without encryption and/or authentication. In such an environment, 508 SNMP messages can be modified by any intermediate node and 509 management application are not able to verify the integrity of SNMP 510 messages. Furthermore, an SNMP ALG does not need to have knowledge 511 of the community strings in order to translate embedded IP 512 addresses. Thus, deployment of SNMP ALGs in an SNMPv1/SNMPv2c 513 environment introduces no additional security problems. 515 SNMPv3 supports three security levels: no authentication and no 516 encryption (noAuth/noPriv), authentication and no encryption 517 (auth/noPriv), and authentication and encryption (auth/priv). SNMPv3 518 messages without authentication and encryption (noAuth/noPriv) are 519 send in cleartext. In such a case the usage of SNMP ALGs introduces 520 no additional security problems. 522 However, the usage of SNMP ALG introduces new problems when SNMPv3 523 authentication and optionally encryption is used. First, SNMPv3 524 messages with authentication and optionally encryption (auth/noPriv 525 and auth/priv) can only be processed by an SNMP ALG which supports 526 the corresponding cryptographic algorithms and which has access to 527 the keys in use. Furthermore, as keys may be updated, the SNMP ALG 528 must have a mechanism that tracks key changes (either by analyzing 529 the key change interactions or by propagating key changes by other 530 mechanisms). Second, the computational complexity of processing SNMP 531 messages may increase dramatically. The message has to be decrypted 532 before the translation takes place. If any translation is done the 533 hash signature used to authenticate the message and to protect its 534 integrity must be recomputed. 536 In general, key exchange protocols are complicated and designing an 537 SNMP ALG which maintains the keys for a set of SNMP engines is a 538 non-trivial task. The User-based Security Model for SNMPv3 [12] 539 defines a mechanism which takes a password and generates localized 540 keys for every SNMP engine. The localized keys have the property 541 that a compromised single localized key does not automatically give 542 an attacker access to other SNMP engines, even if the key for other 543 SNMP engines is derived from the same password. 545 An SNMP ALG implementation which maintains lists of (localized) keys 546 is a potential target to attack the security of all the systems 547 which use these keys. An SNMP ALG implementation which maintains 548 passwords in order to generate localized keys is a potential target 549 to attack the security of all systems that use the same password. 550 Hence, an SNMP ALG implementation must be properly secured so that 551 people who are not authorized to access keys or passwords can not 552 access them. 554 Finally, SNMP ALGs do not allow a network operator to use different 555 security levels on both sides of the NAT. Using a secure SNMP 556 version outside of a private addressing realm while the private 557 addressing realm runs an unsecured version of SNMP may be highly 558 desirable in many scenarios, e.g. management outsourcing scenarios. 559 The deployment of SNMPv3 proxies instead of SNMP ALGs should be 560 considered in these cases since SNMP proxies can be configured to 561 use different security levels and parameters on both sides of the 562 proxies. 564 7. Summary and Recommendations 566 Several approaches to address SNMP agents across NAT devices have 567 been discussed in this memo. 568 1. Basic SNMP ALGs as described in Section 4.1 provide very limited 569 transparency since they only translate IPv4 addresses encoded in 570 the IpAddress base type. They are fast and efficient and may be 571 sufficient to execute simple management applications (e.g. 572 topology discovery applications) in a NAT environment. However, 573 other management applications are likely to fail due to the 574 limited transparency provided by a basic SNMP ALG. Basic SNMP 575 ALGs are problematic in a secure SNMP environment since they 576 need to maintain lists of of keys or passwords in order to 577 function. 578 2. Advanced SNMP ALGs as described in Section 4.2 provide better 579 transparency. They can be transparent for the set of data types 580 they understand and for a given set of MIB modules. However, an 581 advanced SNMP ALG is much more complex and less efficiency than 582 a basic SNMP ALG. An advanced SNMP ALG may break the 583 lexicographic ordering when IP addresses are used to index 584 conceptual tables and it may change the SNMP packet sizes. 585 Especially with SNMPv3, there is an opportunity that 586 communication fails due to increased message sizes. Advanced 587 SNMP ALGs are problematic in a secure SNMP environment, since 588 they need to maintain lists of of keys or passwords in order to 589 function. 590 3. SNMP proxies as described in RFC 2573 [11] allow management 591 applications to access SNMP agents with conflicting IP 592 addresses. No address translation is performed on the SNMP 593 payload by an SNMP proxy forwarder. Hence, management 594 applications must be able to deal with network elements that 595 have conflicting IP addresses. This solution requires that 596 management applications are aware of the proxy situation. 597 Deployment of proxies may also involve the need to reconfigure 598 network elements and management stations to direct their traffic 599 (notifications and requests) to the proxy forwarder. SNMP 600 proxies have the advantage that they allow to use different 601 security levels inside and outside of a given addressing realm. 603 It is recommended that network operators who need to manage networks 604 in a NAT environment make a careful analysis before deploying a 605 solution. In particular, it must be analyzed whether the management 606 applications will work with the transparency and the side-effects 607 provided by SNMP ALGs. Furthermore, it should be researched whether 608 the management applications are able to deal with conflicting IP 609 addresses for network devices. Finally, the additional complexity 610 introduced to the over all management system by using SNMP ALGs must 611 be compared to the complexity introduced by the structurally 612 preferable SNMP proxy forwarders. 614 8. Current Implementations 616 A basic SNMP ALG as described in Section 4.1 was implemented for 617 SNMPv1 at Bell-Labs, running on a Solaris Machine. The solution 618 described in Figure 2, where SNMP ALG was combined with the NAT 619 implementation of Lucent's PortMaster3, was deployed successfully in 620 a large network management service organization. 622 9. Acknowledgments 624 We thank Pyda Srisuresh, for the support, encouragement, and advice 625 throughout the work on this document. We also thank Brett A. Denison 626 for his contribution to the work that led to this document. 627 Additional useful comments have been made by members of the NAT 628 working group. 630 References 632 [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 634 [2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 635 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 637 [3] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 638 "Introduction to Community-based SNMPv2", RFC 1901, January 639 1996. 641 [4] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 642 Operations for Version 2 of the Simple Network Management 643 Protocol (SNMPv2)", RFC 1905, January 1996. 645 [5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 646 "Transport Mappings for Version 2 of the Simple Network 647 Management Protocol (SNMPv2)", RFC 1906, January 1996. 649 [6] McCloghrie, K., "SNMPv2 Management Information Base for the 650 Internet Protocol using SMIv2", RFC 2011, November 1996. 652 [7] Waldbusser, S., "Remote Network Monitoring Management 653 Information Base Version 2 using SMIv2", RFC 2021, January 1997. 655 [8] Haskin, D. and S. Onishi, "Management Information Base for IP 656 Version 6: Textual Conventions and General Group", RFC 2465, 657 December 1998. 659 [9] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 660 to Version 3 of the Internet-standard Network Management 661 Framework", RFC 2570, April 1999. 663 [10] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 664 Processing and Dispatching for the Simple Network Management 665 Protocol (SNMP)", RFC 2572, April 1999. 667 [11] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 668 2573, April 1999. 670 [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 671 for version 3 of the Simple Network Management Protocol 672 (SNMPv3)", RFC 2574, April 1999. 674 [13] ISO, , "Information processing systems - Open Systems 675 Interconnection - Specification of Abstract Syntax Notation 676 One (ASN.1)", International Standard 8824, December 1987. 678 [14] ISO, , "Information processing systems - Open Systems 679 Interconnection - Specification of Basic Encoding Rules for 680 Abstract Syntax Notation One (ASN.1)", International Standard 681 8825, December 1987. 683 [15] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 684 (NAT) Terminology and Considerations", RFC 2663, August 1999. 686 [16] Miller, M., "Managing Internetworks with SNMP", MT Books, 1997. 688 [17] Perkins, D. and E. McGinnis, "Understanding SNMP MIBs", 689 Prentice Hall, ISBN 0-13-437708-7, 1997. 691 [18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 692 Translator (Traditional NAT)", ID 693 draft-ietf-nat-traditional-04.txt, April 2000. 695 [19] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, 696 "Textual Conventions for Internet Network Addresses", RFC 697 2851, June 2000. 699 Authors' Addresses 701 Danny Raz 702 Lucent Technologies 703 101 Crawfords Corner Rd 704 Holmdel, NJ 07733-3030 705 USA 707 Phone: +1 732 949-6712 708 Fax: +1 732 949-0399 709 EMail: raz@lucent.com 710 URI: http://www.bell-labs.com/ 712 Juergen Schoenwaelder 713 TU Braunschweig 714 Bueltenweg 74/75 715 38106 Braunschweig 716 Germany 718 Phone: +49 531 391-3266 719 Fax: +49 531 391-5936 720 EMail: schoenw@ibr.cs.tu-bs.de 721 URI: http://www.ibr.cs.tu-bs.de/ 723 Binay Sugla 724 ISPSoft Inc. 725 106 Apple Street 726 Tinton Falls, NJ 07724 727 USA 729 Phone: +1 732 936-1763 730 EMail: sugla@ispsoft.com 731 URI: http://www.ispsoft.com/ 733 Appendix A. Description of the Encoding of SNMP Packets 735 SNMP packets use the ASN.1/BER encoding. We will not cover the full 736 details of this encoding in this document. These details can be 737 found in the International Standards ISO-8824 [13] and ISO-8825 738 [14]. A good description of ASN.1/BER can be found in the book 739 "Managing Internetworks with SNMP", by M. A. Miller [16], or in 740 Appendix A of the book "Understanding SNMP MIBs", by D. Perkins, and 741 E. McGinnis [17]. 743 Each variable that is referred to in an SNMP packet is uniquely 744 identified by an OID (Object Identifier), usually written as a 745 sequence of numbers separated by dots (e.g. 1.3.6.1.2.1.1.3.0). Each 746 variable also has an associated base type (this is not very accurate 747 but good enough for this level of description). One possible base 748 type is the IpAddress type. The base type of each variable and its 749 OID are conveyed by the ASN.1/BER encoding. Note that it is possible 750 to associate additional type information with a variable by using 751 textual conventions. The additional type semantics provided by 752 textual conventions are not conveyed by the ASN.1/BER encoding. 754 When a value of a variable is needed by a manager it sends a 755 get-request PDU with the OID of that variable, and a NULL value. The 756 managed element then responds by sending a get-response PDU that 757 contains the same OID, the base type of the variable, and the 758 current value. Figure 4 shows an example of real data contained in 759 an SNMPv1 GetResponse PDU. 761 The first 20 bytes contain the IPv4 4 header. The next 8 bytes 762 contain the UDP header. The last two bytes of the UDP header contain 763 the UDP checksum (D3 65). The next four bytes 30 82 00 3E are the 764 beginning of the SNMP message: 30 is SEQUENCE, and 82 00 3E is the 765 length of the data in the SEQUENCE in bytes (62). The data in the 766 SEQUENCE is the version (02 01 00) and the community string (04 06 767 70 75 62 6C 69 63). The last element in the SEQUENCE of the SNMPv1 768 message is the SNMP PDU. 770 +-----------------------------------------+ 771 | IP Header | 45 00 00 5E 772 | | 47 40 00 00 773 | | 3F 11 39 00 774 | | 87 B4 8C CA 775 | | 87 B4 8C 16 776 +-----------------------------------------+ 777 | UDP Header | 00 A1 05 F5 778 | | 00 4A D3 65 779 +-----------------------------------------+ 780 | SNMP Message | 30 82 00 3E 781 | Version | | 02 01 00 04 782 | Community | 06 70 75 62 783 | | | 6C 69 63 A2 784 | PDU Type | | 82 00 2F 02 785 | Request ID | 04 6C F2 0C 786 | | Error Status | 5C 02 01 00 787 | Error Index | SEQUENCE | 02 01 00 30 788 | OF | SEQUENCE | 82 00 1F 30 789 | | OID | 82 00 1B 06 790 | | | 13 2B 06 01 791 | | 02 01 07 05 792 | | 01 01 81 40 793 | | 81 34 81 0C 794 | | 81 4A 84 08 795 | IpAddress | 135 | 180 | 40 04 87 B4 796 | 140 | 202 +-------------------+ 8C CA 797 +---------------------+ 799 The SNMP PDU itself is a tagged SEQUENCE: A2 indicates a GetResponse 800 PDU and 82 00 2F is the length of the data in the GetResponse PDU in 801 bytes (47). The data in the GetResponse PDU is the request-id (02 04 802 6C F2 0C 5C), the error-status (02 01 00), and the error-index (02 803 01 00). Now follow the variables which contain the real payload: A 804 SEQUENCE OF of length 31 (30 82 00 1F) containing a SEQUENCE of 805 length 27 (30 82 00 1B). In it, the first object is an OID of length 806 19 (06 13) with the value 1.3.6.1.2.1.7.5.1.1.192.180.140.202.520. 807 The last 6 bytes 40 04 87 B4 8C CA represent an IpAddress: 40 is the 808 identification of the base type IpAddress, 04 is the length, and the 809 next four bytes are the IP address value (135.180.140.202). 811 The example also shows an IP address embedded in an OID. The OID 812 prefix resolves to the udpLocalAddress of the UDP-MIB, which is 813 indexed by the udpLocalAddress 192.180.140.202 (81 40 81 34 81 0C 81 814 4A) and the udpLocalPort 520 (84 08). The SNMP packet actually shows 815 an internal contradiction caused by a basic SNMP ALG since the 816 udpLocalAddress encoded in the OID (192.180.140.202) is not equal to 817 the value of the udpLocalAddress object instance (135.180.140.202). 819 Full Copyright Statement 821 Copyright (C) The Internet Society (2000). All Rights Reserved. 823 This document and translations of it may be copied and furnished to 824 others, and derivative works that comment on or otherwise explain it 825 or assist in its implementation may be prepared, copied, published 826 and distributed, in whole or in part, without restriction of any 827 kind, provided that the above copyright notice and this paragraph 828 are included on all such copies and derivative works. However, this 829 document itself may not be modified in any way, such as by removing 830 the copyright notice or references to the Internet Society or other 831 Internet organizations, except as needed for the purpose of 832 developing Internet standards in which case the procedures for 833 copyrights defined in the Internet Standards process must be 834 followed, or as required to translate it into languages other than 835 English. 837 The limited permissions granted above are perpetual and will not be 838 revoked by the Internet Society or its successors or assigns. 840 This document and the information contained herein is provided on an 841 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 842 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 843 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 844 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 845 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 847 Acknowledgement 849 Funding for the RFC editor function is currently provided by the 850 Internet Society.