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]
