Internet Draft Proxy Via Community July 1990 Use of the Community String for SNMP Proxys July 1990 Richard Fox SynOptics Communications, Inc. rfox@synoptics.com 1. Status of this Memo This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community. Distribution of this memo is unlimited. Richard Fox [Page 1] Internet Draft Proxy Via Community July 1990 2. Historical Perspective As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion. As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II. In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet- standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects. Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined in the Internet-standard MIB was derived by taking only those Richard Fox [Page 2] Internet Draft Proxy Via Community July 1990 elements which are considered essential. However, the SMI defined three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non- standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. This memo defines extensions to the MIB using the second method. It contains definitions of managed objects used for experimentation. Richard Fox [Page 3] Internet Draft Proxy Via Community July 1990 3. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP. 3.1. Format of Definitions The section 5.4.3.1 contains the specification of all object types contained in the MIB. Following the conventions of the SMI, the object types are defined using the following fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type, presented using Richard Fox [Page 4] Internet Draft Proxy Via Community July 1990 ASN.1. This must resolve to an instance of the ASN.1 type ObjectSyntax defined in the SMI. Definition: A textual description of the semantics of the object type. Implementations should ensure that their interpretation of the object type fulfills this definition since this MIB is intended for use in multi- vendor environments. As such it is vital that object types have consistent meaning across all machines. Access: A keyword, one of read-only, read-write, write-only, or not-accessible. Note that this designation specifies the minimum level of support required. As a local matter, implementations may support other access types (e.g., an implementation may elect to permitting writing a variable marked herein as read-only). Further, protocol-specific "views" (e.g., those implied by an SNMP community) may make further restrictions on access to a variable. Status: A keyword, one of mandatory, optional, obsolete, or deprecated. Use of deprecated implies mandatory status. Richard Fox [Page 5] Internet Draft Proxy Via Community July 1990 4. The Need for Proxy The standard model used by SNMP to manage a network is by exchanging SNMP messages over UDP between a management station and a network device (such as a router, bridge, or host computer): the management station sends a SNMP message to an end devices SNMP agent and the SNMP agent processes the SNMP message against its local Management Information Base (MIB)[3] and sends back to the management station the appropriate response. There are instances where this management paradigm is not sufficient to meet the demands of the network configuration. Examples of this are: - Device may implement SNMP but not UDP/IP[9,10], the preferred method of accessing SNMP. However, it can communicate SNMP messages over other network protocols or transport protocols. It is common to find SNMP mapped directly in an LLC frame on IEEE 802 networks. - Device communicates over a link layer protocol such as 802.5 or FDDI where the network management protocol is defined as part of the link layer protocol and SNMP does not exist on the device. Defining that a station run both protocols would be redundant, and CPU expensive. 802.5 has a set of ring and station commands that are part of the protocol[11] and FDDI has defined a complete network management protocol that allows any station to completely manage both the network and the stations on the network[12]. - Device does not implement SNMP but implements a proprietary management protocol. What is needed is a configuration where the SNMP management station relies on an intermediary device, termed a proxy agent, to take SNMP requests and convert them to a form that the end device can understand. This proxy agent would also take the responses from the end device and map them into SNMP messages to be sent back to the requesting SNMP management station. There are numerous issues regarding proxy network management. Richard Fox [Page 6] Internet Draft Proxy Via Community July 1990 For example, how should a device handle traps from a proxyed device. Some of these issues are discussed in section 7. Issues not mentioned in this document are beyond the scope of this document. If a PDU is proxyed to a station that doesn't respond, the agent doing the proxying should make no assumption of the state of the device. This requirement forces agents proxying to only send response PDU's to the management station based on the response from the proxyed station. If the station gets no response from the end device, then it should not attempt to send a response PDU to the SNMP management station, but let the SNMP management station time the request out and act accordingly. Section 5 will propose a proxy mechanism based on structuring the community string in a SNMP message. Section 6 will define constants needed in the structure of the community string and section 7 will discuss issues pertaining to possible future extensions of this document. 5. Community String Approach for doing Proxys 5.1. Use of the Community String for Proxys The key design issue in choice of a proxy method is how addressing information is shared between the network management station, the proxy agent, and the managed device. This memo proposes a solution, in which the address information is explicitly placed in the community string of each SNMP message that is to be proxyed. The goal of the solution proposed in this document is to be light weight (very little resources required), require minimal CPU resources and to be as dynamic and flexible as possible. In the SNMP, a community name denotes an administrative relationship between a managed device and one or more management stations. Thus, this memo suggests an administrative policy by which addressing information can be expressed for the purposes of proxy. Richard Fox [Page 7] Internet Draft Proxy Via Community July 1990 5.2. Choice of Proxy Indicator In deciding how to structure the community string it is desirable to try and use concepts that are currently used and are widely accepted. Mail as defined in RFC822[13] uses the @ sign to distinguish between the user that receives the mail and the address or machine that the mail is to be delivered to. This concept is similar to the problem of how to share addressing information between the network management station and the proxy agent. Based on the widespread use of mail and other protocols that use the @ sign for addressing information, this document proposes to use the @ sign as a proxy indicator to be located in the community string of an SNMP message. 5.3. Structure of the Community Name If a network management station and proxy agent are configured in accordance with this document, then community strings indicating the presence of proxy information take on the form: name@tag.address Tag is 2 octets and can equal either 0 or one of the defined values in section 6. The tag field and address field are represented as binary numbers not ascii, thus a tag field of 0 is the word [0] and not the ascii value 48. IP address 64.32.16.8 evaluates to bytes [0100000] [0010000] [00010000] [00001000]. If the tag is 0, then no proxy addressing information is present (i.e., the address portion is empty). This special tag value has the same meaning as if no @ appeared at all. If the tag is defined in the table in section 6, then the octets that follow the @ sign contains the address of actual managed device (device that is being proxyed to). The length of the address is determined by the tag value. See section 6 for details of the tag field. If the tag is not 0 and is not recognized by the receiving station, the PDU is to be dropped and no further processing required ( It may desirable to report this condition back to the management station. Perhaps in the future a trap will be Richard Fox [Page 8] Internet Draft Proxy Via Community July 1990 defined to report this condition if the need ever arises. ). The @ does not have to appear in the community string in this proposal. Having no @ provides complete transparent backward compatibility with non-proxy SNMP agents. Example Uses of the @: - want to proxy with community name public: community field = public@0 or community field = public. There is no address associated with this community name. - want station to proxy for IP address 128.64.32.16 with community name of public: community field = public@1.128.64.32.16. The actual octets that are sent are: ['p']['u]['b']['l']['i']['c']['@'][0][1][128][64][32][16]. - want station to proxy for an FDDI SMT address of 16.8.4.2.1.0 with community name of public: community field = public@4.16.8.4.2.1.0. The actual octets that are sent are: ['p']['u]['b']['l']['i']['c']['@'][0][4][16][8][4][2][1][0]. 5.3.1. Motivation for Including the Tag Field Simplifies the amount of parsing that the agent software must do since there are different size addresses. As the number of new protocols that might be proxyed to increases, so does the possibility that different address types will have the same length or format. It might be very important to know which type of address the proxy is for. An example that currently exists is: ethernet sends data on the network in the reversed bit order of FDDI and Token Ring. By tagging the address field there is no confusion on how the address has been represented. (see table in section 6). Until some convention is standardized on how to represent addresses this tag field will solve the problem. Another example is a station proxys to the same station using two different protocols. The tag field will inform the proxy agent which address the PDU is for and which protocol the agent should use to communicate with the end device. Richard Fox [Page 9] Internet Draft Proxy Via Community July 1990 5.3.2. Motivation for Using the @ in the Community String for Proxys It allows backwards compatibility to management stations that are not aware that the station has the ability to proxy. It provides a dynamic approach to doing proxys since there are no predefined tables associated with the proxy. This allows a management station to send proxys to stations without any a priori knowledge. A PDU supplies 1 address for the entire PDU. This saves complexity by not requiring the address to appear with each var bind, but only requiring the address to appear once in the community string. Provides a means to manage devices that do not implement the SNMP protocol or are unaccessible by the management station but are accessible by another station that can be managed by the management station. Allows LANs such as FDDI to be viewed as a system at higher levels above the link layer management level. Simple in concept, easy to implement and powerful in functionality. Causes no new ASN.1[7] constructs to be defined or changed. Does not prevent agent implementations from building firewalls to hide or protect devices that are not desired to be managed via proxys. This approach (see section 5.3.4.1) allows the proxy mechanism to be turned on or off by an administrator. 5.3.3. Considerations Limits var binds in a single PDU to all be directed at the same address. Demands that structure be applied to the community string (only for proxys) in the interpretation of the community field, but requires no change in ASN.1 definitions. (see Richard Fox [Page 10] Internet Draft Proxy Via Community July 1990 section 5.3.4). Makes it illegal to use @ as part of the user name in the community name when using proxys(see section 5.3.4). 5.3.4. SNMP Compliancy SNMP forbids any device to place restrictions on the uses and format of the community string. In order to be complaint with the SNMP standard a method of allowing community names with @ in them must be allowed. This has been achieved by the MIB object defined in sections 5.3.4.1 and 5.3.4.2. This MIB object provides a mechanism which can turn on or off the use of the @ sign for use as a proxy indicator. This added feature will allow an administrator to decide if the @ sign is to be used for proxys or for community names. Richard Fox [Page 11] Internet Draft Proxy Via Community July 1990 5.3.4.1. Object Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, OBJECT-TYPE FROM RFC1155-SMI; atsign-proxy OBJECT IDENTIFIER ::= { experimental xx } END OBJECT: ------- community-proxy { atsign-proxy 1 } Syntax: INTEGER { no-atsign-proxy(1), -- the @ is not used as -- a proxy atsign-proxy(2) -- @ to be used as proxy -- indicator } Definition: Determines if the device is to interpret the @ sign in the community field as a proxy designator or as part of the community name. Access: read-write. Status: mandatory. Richard Fox [Page 12] Internet Draft Proxy Via Community July 1990 5.3.4.2. Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, OBJECT-TYPE FROM RFC1155-SMI; atsign-proxy OBJECT IDENTIFIER ::= { experimental xx } community-proxy OBJECT-TYPE SYNTAX INTEGER { no-atsign-proxy(1), atsign-proxy(2) } ACCESS read-write STATUS mandatory ::= { atsign-proxy 1 } END 6. Constants The tag field portion of the community name is used to determine if the proxy function is being used and if so, which type of protocol address is to be used by the proxy. The tag field also implies the length of the address ( This assumes fixed length addresses. In the future if variable length addresses are required (ISO) then the address field can be used to encode the length of the address. This is similar to the way a SNAP frame is encoded in the data portion of an LLC frame[15]. ). At the time of this writing the following tag types have been defined: ------------------------------------------------------------------- tag value | address type | address length ------------------------------------------------------------------- 0 | null | 0 bytes ------------------------------------------------------------------- 1 | IP address | 4 bytes ------------------------------------------------------------------- Richard Fox [Page 13] Internet Draft Proxy Via Community July 1990 2 | MAC address in LSB | 6 bytes ------------------------------------------------------------------- 3 | MAC address in MSB | 6 bytes ------------------------------------------------------------------- 4 | SMT MAC address | 6 bytes ------------------------------------------------------------------- 5 | Token Ring MAC address | 6 bytes ------------------------------------------------------------------- 6 | SMT w/Source MAC address & | 12 bytes | destination MAC address | ------------------------------------------------------------------- Tag value 6 supplies 2 MAC addresses to be used in a proxy to a SMT station. The first address is the MAC address that the proxy agent should use to send the proxy to the end station which is the second address. This tag is useful if the management station knows which ring the end station is on by helping the proxy agent determine how to reach the station. If the management cannot provide this information then tag value 4 should be used. 7. Issues for Future Considerations 7.1. Traps Currently the management station only finds out who sent an SNMP trap PDU, but not who originated it. In the case that a proxy station forwarded the PDU to the SNMP network management station a method is required to relay the origination address. This document considers using the @ convention in the community field. The station that is forwarding the trap to the management station will put in the proper tag and address, of the origination device, in the community field. This is the proxy approach defined in section 5.3 in reverse. This concept is still under consideration and further study is required. Richard Fox [Page 14] Internet Draft Proxy Via Community July 1990 7.2. Multi-Level Proxys This document has explicitly defined a method to do a 1 level proxy; where a management station sends an SNMP message to a proxy station who then sends a message to the end device. There may be a desire to have the proxy station send a message to another proxy station which then forwards a message to the end device. A proposal under consideration is the use of source routing within the community name using the @ convention. Consider the configuration: SNMP Manager -- Proxy A -- Proxy B -- ... ... -- Proxy Z -- end device If the SNMP manager needs to manage the end device an SNMP message could contain the following community field: name@Proxy B@......@Proxy Z@end device The parsing mechanism used in section 5.3 needs to be updated to handle this multi-level proxy. The parsing becomes: - If there is no @ sign present, then the PDU is not to be proxyed and the station acts on the PDU itself. - If there is an @ sign then the agent looks for its address in the string of @s. -- if its address is not found then it looks to see if at least 2 @s are present. --- if only 1 @ is present then this is a single level proxy and the address present is that of the end station. In this case, the proxy works as in section 5.3. --- if there is at least 2 @, then this is the first station to receive the proxy and the PDU is forwarded to the first address listed. -- if its address is found then looks to see what follows its address. Richard Fox [Page 15] Internet Draft Proxy Via Community July 1990 --- if only 1 @ follows its address, then the address that follows is that of the end station and it sends a message as in Section 5.3. --- if there are more than 1 @, then the PDU is forwarded to the next address following its own in the list. The main problem with this approach is that the assumption, that all proxy agents are SNMP proxy agents, is required. If this is not the case, then it can not be guaranteed that the source routed community name will stay intact long enough for the end station to ever receive the message. Defining a multi level proxy mechanism is both complex and does not fit into the SNMP philosophy of "keeping it simple". For these reasons, this document suggests that only single level proxys be supported at this time and leaves the multi level proxy as an issue for further study. Richard Fox [Page 16] Internet Draft Proxy Via Community July 1990 8. Identification of OBJECT instances for use with the SNMP The names for all object types in the MIB are defined explicitly either in the Internet-standard MIB or in other documents which conform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element. Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way specific to the named object type, identifies the desired instance. This naming strategy admits the fullest exploitation of the semantics of the powerful SNMP get-next operator, because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB. The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type defined in this memo to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition. For example, suppose one wanted to identify an instance of the variable sysDescr in the Internet-standard MIB. The object class for sysDescr is: iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 2 1 1 Hence, the object type, x, would be 1.3.6.1.2.2.1.1 to which is appended an instance sub-identifier of 0. That is, 1.3.6.1.2.2.1.1.0 identifies the one and only instance of sysDescr. Richard Fox [Page 17] Internet Draft Proxy Via Community July 1990 9. Acknowledgements I would like to thank all of the people that have helped in putting this document together. I would really like to thank Amatzia Ben-Artzi for his ideas and suggestions. I would also like to thank Phil Gross for his inputs and suggestions. Richard Fox [Page 18] Internet Draft Proxy Via Community July 1990 10. References [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). [2] V. Cerf, Report of the Second Ad Hoc Network Management Review Group, Internet Working Group Request for Comments 1109. Network Information Center, SRI International, Menlo Park, California, (August, 1989). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [6] M.T. Rose (editor), Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1158. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules Richard Fox [Page 19] Internet Draft Proxy Via Community July 1990 for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [9] J.B. Postel, Internet Protocol, Request for Comments 791. Network Information Center, SRI International, Menlo Park, California, (September 1981). [10] J.B. Postel, User Datagram Protocol, Request for Comments 768. Network Information Center, SRI International, Menlo Park, California, (August, 1980). [11] Token Ring Access Method and Physical Layer Specifications, Institute of Electrical and Electronic Engineers, IEEE Standard 802.5-1989, (1989). [12] FDDI Station Management (SMT) Rev 6.2, American National Standard, X3T9.5/84-49, (May 1990). [13] D. Crocker, Standard for the format of ARPA Internet text messages, Request for Comments 822, Network Information Center, SRI International, Menlo Park, California. (August 1982). [14] J.K. Reynolds, and J.B. Postel, Assigned numbers, Internet Working Group Request for Comments 1060. Network Information Center, SRI International, Menlo Park, California. (March 1990). [15] J.B Postel and J.K Reynolds, Standard for the transmission of IP datagrams over IEEE 802 networks, Request for Comments 1042, Network Information Center, SRI International, Menlo Park, California. (February 1988). Richard Fox [Page 20] Internet Draft Proxy Via Community July 1990 Table of Contents 1 Status of this Memo ................................... 1 2 Historical Perspective ................................ 2 3 Objects ............................................... 4 3.1 Format of Definitions ............................... 4 4 The Need for Proxy .................................... 6 5 Community String Approach for doing Proxys ............ 7 5.1 Use of the Community String for Proxys .............. 7 5.2 Choice of Proxy Indicator ........................... 8 5.3 Structure of the Community Name ..................... 8 5.3.1 Motivation for Including the Tag Field ............ 9 5.3.2 Motivation for Using the @ in the Community String for Proxys .................................. 10 5.3.3 Considerations .................................... 10 5.3.4 SNMP Compliancy ................................... 11 5.3.4.1 Object Definitions .............................. 12 5.3.4.2 Definitions ..................................... 13 6 Constants ............................................. 13 7 Issues for Future Considerations ...................... 14 7.1 Traps ............................................... 14 7.2 Multi-Level Proxys .................................. 15 8 Identification of OBJECT instances for use with the SNMP ............................................... 17 9 Acknowledgements ...................................... 18 10 References ........................................... 19 Richard Fox [Page 21]