Internet Draft Proxy Via Community December 1990 Use of the Community String for SNMP Proxys December 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 December 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 December 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 December 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. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [16]. Richard Fox [Page 4] Internet Draft Proxy Via Community December 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 possibly 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. If a PDU is proxyed to a station that doesn't respond, the Richard Fox [Page 5] Internet Draft Proxy Via Community December 1990 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 and section 6 will define constants needed in the structure of the community string. Richard Fox [Page 6] Internet Draft Proxy Via Community December 1990 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. 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: Richard Fox [Page 7] Internet Draft Proxy Via Community December 1990 name@tag.address The tag is made up of the following two fields: protocol_type.address_type Both fields of the tag are 2 octets wide. The fields may take on the values defined in the two tables of section 6. The tag field and address fields are represented as binary numbers. Thus, if the value 3 is to be used in a protocol_type field, the representation of this field evaluates to the two octets in network byte order of [00000000] [00000011]. An IP address of 64.32.16.8 would be represented in the address field in the following octets in network byte order: [0100000] [0010000] [00010000] [00001000]. If either field of the tag is 0, then no proxy addressing information is present (i.e., the address portion is empty). This is equivalent to a PDU in which no proxy information, including the @ sign, is specified. The protocol_type value specifies the management protocol that is to be used by the proxy agent to the managed device. The address_type value specifies what type of address to use when sending to the managed device (and in the case of MAC addresses it specifies how the supplied address is represented, either in MSB or LSB). Following the tag field is the actual address (addresses in some cases) to use to communicate with the proxyed device. The length of the address is determined by the address_type value. See section 6 for details of the tag fields. On reception of an SNMP PDU with proxy information contained in the community string, the proxy agent may drop the PDU with no further processing if either the protocol_type or address_type values of the tag are not recognized or supported ( It may desirable to report this condition back to the management station. Perhaps in the future a trap will be defined to report this condition if the need ever arises. ). The @ does not have to appear in the community string of an SNMP PDU if the proxy functionality is not being requested. This provides backwards compatibility with non-proxyable SNMP agents. Richard Fox [Page 8] Internet Draft Proxy Via Community December 1990 Example Uses of the @: - want to proxy with community name public: community field = public@0.0 or community field = public. There is no address associated with this community name. The actual octets that are sent could either be: ['p']['u]['b']['l']['i']['c']['@'][0][0][0][0] or ['p']['u]['b']['l']['i']['c']. - want proxy agent to proxy for IP address 128.64.32.16 using SNMP in the conventional way with community name of public: community field = public@.1.1.128.64.32.16. The actual octets that are sent are: ['p']['u]['b']['l']['i']['c']['@'][0][1][0][1][128][64][32][16]. - want station to proxy for an FDDI SMT address of 16.8.4.2.1.0 (represented MSB first) with community name of public: community field = public@3.3.16.8.4.2.1.0. The actual octets that are sent are: ['p']['u]['b']['l']['i']['c']['@'][0][3][0][3][16][8][4][2][1][0]. If instead, the management station was representing the MAC address in canonical form (LSB first) then the community field = public@3.2.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 by having the sub fields of the tag field being a fixed size and the address_type field explicitly specifying the size of the address field. Allows the management station to specify what protocol the proxy agent should use to communicate with the end device. This allows a management station to send proxys to the same station using different protocols in a straight forward manner. Allows the addition of new protocols transparently to environments that do not use those protocols. Allows the management station to specify the address that should be used to reach the end device. As new protocols are defined, new address types are sure to Richard Fox [Page 9] Internet Draft Proxy Via Community December 1990 follow. The tag field allows for the definition of new address types transparently to environments that do not use these protocols/address types. By allowing the management station to specify the address type, there is no confusion by the proxy agent as to the exact representation or type of the address contained in the address portion of the community string. Thus, since some networks send MAC addresses in LSB and others in MSB, without the tag field a proxy agent may not know exactly what form the address is currently represented in. Also, addresses of different protocols can be easily distinguish even if they are the same size. 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. Richard Fox [Page 10] Internet Draft Proxy Via Community December 1990 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 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 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 section 5.3.4.1. 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 December 1990 5.3.4.1. Object Definitions RFCxxxx-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, OBJECT-TYPE FROM RFC1155-SMI; atsign-proxy OBJECT IDENTIFIER ::= 22 community-proxy OBJECT-TYPE SYNTAX INTEGER { no-atsign-proxy(1), -- the @ is not used as -- a proxy atsign-proxy(2) -- @ to be used as proxy -- indicator } ACCESS read-write STATUS mandatory DEFINITION "Determines if the device is to interpret the ascii @ sign in the community field as a proxy designator based on the algorithms defined in this document or as part of the community name." ::= { atsign-proxy 1 } END Richard Fox [Page 12] Internet Draft Proxy Via Community December 1990 6. Constants The tag field is composed of two components. The first component is a two octet quantity used to specify the protocol that the proxy agent is to use when communicating with the device to be managed via proxys. The second component is a two octet quantity used to determine the length of the address which follows the tag field and how the address is represented ( This assumes fixed length addresses. In the future if variable length addresses are required (ISO) then this component of the tag 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]. ). This section defines two tables which contain valid specification values for each of the two components of the tag field. The values defined in these two tables are current as of the time of the publication of this document. Richard Fox [Page 13] Internet Draft Proxy Via Community December 1990 6.1. Protocol_type Table This table defines the currently defined values for the protocol_type portion of the tag field: ------------------------------------------------------------------- protocol_type | protocol being used by the proxy agent ------------------------------------------------------------------- 0 | NULL: No proxy is to be done ------------------------------------------------------------------- 1 | SNMP over UDP/IP ------------------------------------------------------------------- 2 | SNMP over LLC ------------------------------------------------------------------- 3 | FDDI SMT management protocol ------------------------------------------------------------------- 4 | IEEE 802.5 MAC layer management protocol ------------------------------------------------------------------- Richard Fox [Page 14] Internet Draft Proxy Via Community December 1990 6.2. Address_type Table This table defines the currently defined values for the address_type portion of the tag field. The table defines the representation of the address portion of the proxy community string as well as the length in octets that the address following the tag field will be: ------------------------------------------------------------------- tag value | address type | address length ------------------------------------------------------------------- 0 | null | 0 octets ------------------------------------------------------------------- 1 | IP address | 4 octets ------------------------------------------------------------------- 2 | MAC address in LSB | 6 octets ------------------------------------------------------------------- 3 | MAC address in MSB | 6 octets ------------------------------------------------------------------- 4 | FDDI SMT w/Source MAC address | 12 octets | & destination MAC address | | both in MSB | ------------------------------------------------------------------- 5 | FDDI SMT w/Source MAC address | 12 octets | & destination MAC address | | both in MSB | ------------------------------------------------------------------- Address_type values 4 & 5 require two MAC addresses to be used in a proxy to an SMT station on a FDDI dual counter rotating network. The first address specifies the MAC that the proxy agent should use to send out the proxyed SMT frame and the second address specifies to which destination MAC the SMT frame is destined for. This specification is used when the management station can provide the proxy agent this information (for management dependent reasons). Richard Fox [Page 15] Internet Draft Proxy Via Community December 1990 7. 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 16] Internet Draft Proxy Via Community December 1990 8. 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 Phill Gross for his inputs and suggestions. Richard Fox [Page 17] Internet Draft Proxy Via Community December 1990 9. 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 18] Internet Draft Proxy Via Community December 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). [16] M.T Rose and K McCloghrie (editors), Towards Concise MIB Definitions, Internet Draft, Internet Engineering Task Force, (September 1990). Richard Fox [Page 19] Internet Draft Proxy Via Community December 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 .................................... 5 5 Community String Approach for doing Proxys ............ 7 5.1 Use of the Community String for Proxys .............. 7 5.2 Choice of Proxy Indicator ........................... 7 5.3 Structure of the Community Name ..................... 7 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 .................................... 11 5.3.4 SNMP Compliancy ................................... 11 5.3.4.1 Object Definitions .............................. 12 6 Constants ............................................. 13 6.1 Protocol_type Table ................................. 14 6.2 Address_type Table .................................. 15 7 Identification of OBJECT instances for use with the SNMP ............................................... 16 8 Acknowledgements ...................................... 17 9 References ............................................ 18 Richard Fox [Page 20]