Internet Draft Comments on SNMP Proxy October 1990 Comments on SNMP Proxy via Use of the @ sign in an SNMP Community Contributors/Constituents (in alphabetical order) Jeffrey D. Case, SNMP Research & UTK John Cook, CHIPCOM Chuck Davin, MIT Eric Decker, cisco Systems Mark S. Fedor, PSI Frank Kastenholz, RACAL Interlan Keith McCloghrie, HLS Dave Perkins, 3COM Marshall Rose, PSI Greg Satz, cisco Systems Martin L. Schoffstall, PSI Bob Stewart, Xyplex Steve L. Waldbusser, CMU 1. Introduction This memo outlines technical reasons why introducing programmatically-interpreted structure into the SNMP community string, as proposed in [1], is a bad idea. Interested Parties [Page 1] Internet Draft Comments on SNMP Proxy October 1990 2. Specific Comments In the following comments, references to section numbers are to sections in [1]. 2.1. The first point to note is that use of programmatically-interpreted structure in the SNMP community string is, (as pointed out in section 5.3.4) forbidden by the SNMP specification [2]. 2.2. One of the goals of SNMP is to shift the burden of network management away from devices (e.g. a router or bridge) having a major function other than management, and onto devices which do have management as a major function. By definition, a proxy agent is a device for which (one of) its major function(s) is management. Thus, in the case of proxy, a goal of SNMP is to reduce the impact of network management on a managed device at the expense of making the proxy agent more complicated. In contrast, the goal of [1] is to make the proxy agent simpler, rather than reduce the impact on the managed device. For example, a proxy agent could reduce the impact of successive queries on a managed device by caching some of the device's (relatively) static MIB information (e.g. sysDescr) and responding to queries for those MIB objects without bothering the device; this behavior, however, is expressly forbidden by section 4. 2.3. In section 5.1, it is stated that the "memo suggests an administrative policy by which addressing information can be expressed for the purposes of proxy", but the memo then goes on to propose a programmatic policy. 2.4. In section 5.2, it is suggested that the use of an @ sign for Mail addressing is analogous to the proposal to use an @ sign in the community string. This is false. The @ sign in a mail address does separate a user-name from an address; however, in mail, when intermediate relays are known by the sender, the address specified by the sender is the address of the relay, not the address of the system where the user's mailbox resides (e.g. for the mail address "kzm@hls.com", the "hls.com" identifies a mail-relay, not the host where kzm's Interested Parties [Page 2] Internet Draft Comments on SNMP Proxy October 1990 mailbox resides). Thus, to follow the mail analogy, the proposed scheme should put the proxy's address after the @ sign instead of the managed device's. Also, omitting the @ sign and the following address in a mail-address implies a mailbox on the local system, in contrast to the proposal in [1]. 2.5. The proposal describes how addressing information is exchanged, but does not support exchange of other parameters that may be necessary for remote management, e.g., authentication information. For example, if the proxy communicates with the managed device using SNMP, the value to be used in the community string for this communication is not specified. Similarly, the IEEE 802.1 management protocol makes use of a password and access control information, which is not specified in the proposal. 2.6. The proposal often confuses the terms agent, proxy, and station. In particular, section 5.3.1 claims that the tag field simplifies the amount of processing on the "agent". Presumably, it is the proxy agent for which the simplification is claimed. Whether this simplifies or complicates the managed device is unclear due to the lack of information about how the proxy agent and the managed device communicate. 2.7. There is no need to define (as is done in section 6) additional tag values for different media types which use the same format of MAC address. In particular, this requires a management station to know the network topology (and possibly its current state) in order to communicate with a managed device. (For example, if a proxy can reach the managed device by both 802.5 and FDDI, but the 802.5 is presently down and the management station chooses the address on the 802.5 media, the management request cannot be sent, even though the path via FDDI may be available). Indeed, a canonical bit ordering solves the problem for the difference between 802.5 and other 802.x addresses. Removing the media-specific nature of tags would simplify the protocol and allow for future extensions without the overhead/delay of needing new types defined for new types of media which have the same address type. Interested Parties [Page 3] Internet Draft Comments on SNMP Proxy October 1990 2.8. Section 5.3.3 claims that use of the @ sign "allows a management station to send proxys to stations without any a priori knowledge". Presumably, the reference is intended to refer to a management station communicating with a managed device via a proxy agent, when the management station has no a priori knowledge. This is nonsensical. How can a management station send a request when it knows nothing about a device? Even if the management station has just learned that the managed device exists (presumably via the proxy agent), then it must discover both parts of the proposed format of the community string; in general, for security reasons, few real- world administrations use the "public" community, and few would want the same community to be in use on all managed devices at the same time. In the event that an authentication scheme better than the present "trivial" authentication is introduced, the management station will not know the secrets of that community without a priori knowledge. Similarly, how could a management station choose the media type to use for the tag value, if it has no a priori knowledge? Even if the above information were able to be learned dynamically, it is easier for the proxy agent to learn this information than for a distant management station, since the proxy agent is closer to the dynamic environment where the changes are occurring. Having learned the information, it would be simpler for the proxy to store (dynamically) its knowledge in a table and for the management station to reference that table via the SNMP. Such an alternate approach would be fully compliant with the SNMP specification and still achieve the same functionality as the proposal in [1]. 2.9. One of the tags in section 6, specifies the use of two addresses to be placed after the @ sign. It is not so far- fetched to extrapolate this to suggest another tag be defined as meaning that a whole SMT frame is placed after the @ sign. This would in fact make more sense, since then all the difficulties of protocol conversion between SNMP and SMT would be overcome. On the other hand, it would then be using SNMP as a network-layer protocol !! 2.10. The procedure outlined in section 7.2 for "multi-level proxys" underlines that the whole proposal is in fact an application of source routing. The difficulties stated in that section are symptomatic of the problems of using source Interested Parties [Page 4] Internet Draft Comments on SNMP Proxy October 1990 routing in this type of environment, whether it is for one or multiple levels of proxy. 2.11. Section 7.2 (multi-layer proxy) is completely at odds with the statement that claims that use of the @ sign "allows a management station to send proxys to stations without any a priori knowledge". The management station must have complete knowledge of the "route" that the management transaction must "follow". 2.12. This section is also deficient in that it does not specify the format of the addresses for the intermediate proxies. Are these addresses Domain Names? IP Addresses? Multi-level proxies could lead to community strings more complex than the worst mail addresses seen on the Internet. 2.13. Section 4 of the proposal, starting at the bottom of page 6, states "There are numerous issues regarding proxy network management. 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". What are these issues? They ought to be presented, discussed, and resolved in order to accept the proposal. Interested Parties [Page 5] Internet Draft Comments on SNMP Proxy October 1990 3. General Comments The above comments are directly related to the text in the proposal. The following are more general comments concerning the proposal as a whole. 3.1. One of the strengths of IP is that Host-A does not have to know the subnet technology of Host-B in order for them to interoperate. This way, a new network with a new subnet technology can be added and can interoperate with all existing hosts without the existing Hosts having to know the addressing scheme/etc. of the new technology. In the context of the @ sign proposal, putting an address in the community string requires the addressing scheme to be known by every manager which wants to query the managed device (even a distant one, i.e. not the one which configures the proxy agent). So, putting an address in the community string runs counter to the strengths of TCP/IP. 3.2. Even within a subnet, there are advantages to hiding the addressing structure - how would you like it if ARP were not a dynamic protocol, but instead you had to add static entries to your ARP table for each host on your network, and to their ARP tables before you could communicate with them; and to your routers' ARP tables before you could communicate with any off-net Host. In this same vein, one of the major deficiencies recognised by the IETF's Host-Requirements work, was the need for configuring things dynamically (e.g. addresses in workstations); this resulted in the formation of the Dynamic Host Configuration working group to address the problem. The IETF has also been interested in figuring out how to do dynamic IP address assignments. So, putting an address in the community string runs counter to IETF efforts to make address assignments more dynamic. 3.3. Consider the scenario where one managed device is being accessed via a single proxy agent from multiple managers. In this scenario, the @ sign proposal implies (since it is stated that there are no table look-ups involved) that the same community string is used for the proxy agent to send to the managed device as is used for the managers to communicate with the proxy agent. Now, the community string must be used for Interested Parties [Page 6] Internet Draft Comments on SNMP Proxy October 1990 authentication. By using the same one, there is an inherent security weakness in the proposal. 3.4. One of the benefits claimed for proxy is that it off- loads from a managed device onto a proxy agent, a number of administrative burdens associated with handling multiple communities and multiple managers. This benefit can not be realised when the same community string is used between the manager and the proxy, as between the proxy and the managed device. 3.5. The SNMP RFC [2] introduces the concept of a MIB view as the means for access-control. The @ sign in the community string proposal implicitly utilizes views but does not address access-control. 3.6. By including addresses, community strings would undoubtedly be longer. If the address in the community string is propogated in the request to the managed device, then there is a (small) increase in the memory space requirement of the managed devices, and a (small) increase in the processing time to look-up community strings in the device's data structures. The length of increase for the "public" community would be from 6 bytes to 15 bytes for MAC addresses, and from 6 bytes to 29 bytes (!!) for OSI addresses. This runs counter to the SNMP goal of reducing the burden on managed devices. 3.7. Currently fielded implementations of SNMP would not be able to properly handle structured community strings as described in the proposal. Current implementations would treat the @ sign just as they treat any other octet in the community string. 3.8. Which @ sign encoding is to be used? In ASCII, the @ sign is 0x40, in EBCDIC it is 0x7c. Interested Parties [Page 7] Internet Draft Comments on SNMP Proxy October 1990 3.9. Section 4 of the proposal states "Defining that a station run both protocols would be redundant and CPU expensive" (Presumably this means that a managed object run both SNMP and some other network management protocol). Just having additional protocols does not require more CPU power (especially when the second protocol is SNMP). The expense of having SNMP as an additional protocol is determined by how many SNMP requests must be processed, not the existance of the SNMP protocol module. There are managed objects that support multuiple management protocols with no significant CPU expense. 3.10. The proposal may present a significant security breach. The SNMP community identifies what security mechanisms are to be used, along with any keys needed. In order to determine what security is in use with a given PDU, the PDU's community must be identified. Hence, the community string in the PDU must be sent in clear text. Since it is in the clear, the amount of information in the community string must be minimzied. An intruder should not be able to determine the nature of the algorithms in use or their keys, the structure of the network being managed, or the nature of the administrative relationships among managers, proxies and agents. These last two points can be directly determined by reading the community string if it is structured as described in the proposal. Security is not required by all sites. However, the SNMP protocols and its supporting algorithms, policies and procedures should not explicitly prevent, as a matter of their architectural design goals, the use of security. It is true that, as it stands now, SNMP as a whole is not secure. However, alternate approaches to proxy can be envisioned which do not have this security weakness. Interested Parties [Page 8] Internet Draft Comments on SNMP Proxy October 1990 4. References [1] R. Fox, Use of the Community String for SNMP Proxys, Internet Draft, Internet Engineering Task Force, (July, 1990). [2] 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). Interested Parties [Page 9]