Towards Rough Concensus and Running Code

[Keith McCloghrie <[e-mail]>, Marshall Rose <[e-mail]>, Glenn Waters <[e-mail]>]

     We have reviewed the various proposals which were submitted for
     consideration to the working group.

     We feel that many of the proposals are complementary to the
     user-based security model for SNMPv2.  As such, we offer the
     following analysis of the proposals, in which we suggest ways in
     which they can be accomodated by (modifications to) the user-based
     security model.  In doing this, we hope that the working group can
     reach concensus on a workable specification for SNMPv2.

     We invite your comments!

Keith, Marshall, and Glenn


ps:  there's one point of confusion to be cleared up -- the
     internet-drafts are has two files named:

	draft-kzm-snmpv2-proto-alt-00.txt
	draft-kzm-snmpv2-proto-alt-01.txt

     the first one of these is legitimate, the second one is bogus!  it
     turns out that someone else submitted modifications to the protocol
     operations document and this was assumed to be from the same
     author.  so, ignore

	draft-kzm-snmpv2-proto-alt-01.txt

     and look at

	draft-mahoney-snmpv2-proto-alt-00.txt

     instead!  They're the same file, but 

	draft-kzm-snmpv2-proto-alt-01.txt

     is going away.

				#######

Proposal:	Security Encapsulation of SNMP
Author:		Alten
Draft:		[1] draft-alten-snmp-sec-encap-00.txt

First, we observe that in the history of the Internet there has been
very limited success in deploying a public-key infrastructure.  Key
management is, of course, the problematic aspect of any technology based
on public key cryptography.

Further, in the US, PKC is a patented technology.  We observe that, in
the history of the IETF, that standardization of technology involving
claims of intellectual property has proven problematic (No part of the SNMP
standard is encumbered with intellectual property considerations.)

Therefore, we claim the following: it unwise to base any aspect of SNMP
on PKC.

As such, we feel that the working group should reject this proposal.


				   #######


Proposal:	SNMPv2a Simple Authentication/Integrity for
		Community-based SNMP messages
Authors:	Blumenthal, Hein, Natale, Wijnen
Draft:		[2] draft-blumenthal-snmpv2a-community-00.txt

First, we observe that this approach is unworkable for SNMPv1
implementations as it mandates interpretation of the community string.

Second, we observe that this approach provides less functionality, but
no less cost, than the SNMPv2+USEC proposal when used for
community-based traffic.

Therefore, we feel that the working group should reject this proposal.

				   #######


Proposal:	SNMPv2t Simple Network Management Protocol Version 2 with
		Transitional Authentication
Authors:	Blumenthal, Hein, Natale, Wijnen
Draft:		[3] draft-wijnen-snmpv2-snmpv2t-00.txt

First, we observe that the SNMPv2t proposal relies on the following
documents from the SNMPv2+USEC proposal:

    draft-kzm-snmpv2-intro-alt-00.txt
    draft-kzm-snmpv2-smi-alt-00.txt
    draft-kzm-snmpv2-tm-ds-03.txt
    draft-kzm-snmpv2-conf-alt-00.txt
    draft-kzm-snmpv2-proto-alt-00.txt
    draft-kzm-snmpv2-mib-alt-00.txt
    draft-kzm-snmpv2-coex-alt-00.txt
    
which de-couple the administrative framework from other parts of SNMPv2.
    
Second, the remainder of the SNMPv2t proposal deals with community-based
traffic. In the SNMPv2+USEC proposal, Appendix B of

    draft-kzm-snmpv2-sec-alt-00.txt

describes community-based traffic.  The encodings used by the two
proposals for community-based is different; however, both encodings are
different than the SNMPv1 encoding (e.g., a change in the version
field).  The encoding in Appendix B of the SNMPv2+USEC proposal allows
for a manager to transparently interact with a community-based SNMPv2
agent, at a cost of an encoding which is marginally more complicated
than the SNMPv2t encoding.  The configuration cost for an agent under
either approach is identical, i.e., an agent which is community-based
requires no modifications to its configuration database to support
either the SNMPv2+USEC proposal or the SNMPv2t proposal.

As such, the question is whether transparency for the manager is better
than encoding efficiency for the agent.  In the traditional SNMP spirit,
we favor the agent, and therefore will change the SNMPv2+USEC proposal
to adopt a much simpler encoding.  If the <model> field of the
parameters component is 1, then the octets following specify a community
string.  While is not exactly the SNMPv2t encoding, we claim it is just
as simple.

Therefore, we claim the following: if the Appendix B of 

    draft-kzm-snmpv2-sec-alt-00.txt

is changed so that a parameters component starting with '1' indicates
community-based traffic, then all technical aspects of the SNMPv2t
proposal are now provided for in the SNMPv2+USEC proposal.  Accordingly,
we are changing Appendix B.

As such, if the authors of the SNMPv2t proposal agree with this claim,
then as we have modified Appendix B, we ask them to consider the SNMPv2t
proposal completely assimilated by ours.


				#######

Proposal:	Extensible Message Framework for the Simple Network
		Management Protocol (SNMPemf)
Authors:	Kornegay, Hanson
Draft:		[5] draft-kornegay-snmpv2-emf-00.txt

First, we observe that experience from at least four entirely
independent implementations (cmu/waters, snmptcl/rose&kzm,
scotty/schoenwaelder, and snmpv2t/romanov) has shown that it is vastly
preferable to use the same packet format for all flavors of SNMP (V1,
V1t, V2) rather than using the ASN.1 CHOICE construct.

Second, we observe that the extensibility suggested by this proposal is
provided by the <model> field of the parameters component specified in the

    draft-kzm-snmpv2-sec-alt-00.txt

document from the SNMPv2+USEC proposal.

Therefore, we claim the following: all of the functionality provided by
the SNMPemf proposal is already provided by the SNMPv2+USEC proposal.

As such, if the authors of this proposal agree with this claim, then we
ask them to consider the SNMPemf proposal completely assimilated by
ours.


				#######


Proposal:	A Decoupled Approach to SNMPv2 and Its Features
		(sans the Report-PDU)
Authors:	Arneson, Asija, Mahoney, Harrington
Drafts:		[6] draft-mahoney-snmpv2-features-00.txt
		[7] draft-harrington-data-filter-mib-00.txt
		[8] draft-harrington-control-mib-00.txt

First, we observe that this proposal seeks to decouple SNMPv2 into four
feature sets: the SNMPv2 message, "privacy without authentication",
noAuth/noPriv communications, and a full set of security features.
All of these feature sets are intended to be independent of the security model.
We feel that this approach leads to unnecessary combinations of feature
sets and models.  It is likely that agents and managers will implement
only a subset of these combinations -- if they implement different
subsets, the result will be non-interoperability.  

Second, this proposal also introduces a new concept, a "data filter", which
consists of a triple <context, readView, writeView>.  We see only two
capabilities which this adds, e.g.,
     1) allowing a manager to specify the views to be used for processing
	a message (c.f., allowing a fox to specify which hens it can chase);
     2) allowing a manager to be configured to access several individual
	views for the same context, as opposed to combining the individual
	views into a composite.
These introduce extra complexity without any apparent usefulness.

Third, this proposal makes access control independent of the security
model, which leads to more indirection, making the inter-relationships
harder  to understand, and requiring the MIB objects to be more
general/opaque and thus, more complicated.  We claim this indepedence is
unnecessary.  Configuring v1 community-based authentication is outside
the scope of this WG.  Thus, the only immediate need is to support
configuration of a single model.  Adding complexity at this time to
allow for the future support of other models is not warranted.

Further, this proposal has a major flaw in that its access control
mechanism, when applied to user-based security, does not specify the
level of security required for that user to access a "datafilter".
So, if user "root" has write-access to 'internet', any attacker can
send a noAuth/noPriv message for user "root" and write any MIB variable
in the agent!

Finally, the security properties of this proposal worry us: since the
early days of the work on SNMP security, "privacy without
authentication" has always been explicitly precluded, for the (obvious)
security reasons.  In addition, this proposal also makes reference to the
Alton proposal on using PKC, which is clearly unusable.


				#######


Proposal:	The Report-PDU
Authors:	Mahoney, Harrington, Arneson
Drafts:		[9] draft-mahoney-snmpv2-proto-alt-00.txt

First, we observe that this proposal adds the Report-PDU to the SNMPv2
protocol operations document (and also accidently introduces a typo,
i.e., "(6)" is missing near the top of page 24).

We feel that the Report-PDU is not a protocol operation between SNMPv2
managers and agents, but rather is an aspect of maintenance between
SNMPv2 entities.

However, we also see value in having all of the PDU definitions in one
document.

Therefore, we claim the following: if we modify

    draft-kzm-snmpv2-proto-alt-00.txt

to include the definition of the Report-PDU, but indicating that it is a
part of the interaction between two protocol engines rather than a part
of the interaction between an agent and a manager, and we remove the
Report-PDU definition from

    draft-kzm-snmpv2-sec-alt-00.txt

then everyone should be happy.

As such, if the authors of this proposal agree with this claim,
then we ask them to consider this proposal completely assimilated by
ours.


				   #######


Proposal:	Simple Authentication Mechanism for SNMP
Author:		Romanov
Draft:		[13] draft-romanov-simple-snmp-00.txt

First, we observe that with the exception of the "nonce", all security
properties "solved" by this proposal are solved using similar mechanisms
and at similar cost by the document

    draft-kzm-snmpv2-sec-alt-00.txt

in the SNMPv2+USEC proposal.

Second, according to this proposal, the nonce is

    a random value, that accompanies a timestamp.  Nonces
    are generated by a managing entity, on per-request basis, and
    are copied to the corresponding field in the response. They are
    used to prevent a replay within the lifetimeWindow, and to prevent
    replaying a response addressed to one manager, to another.

We observe that Sections 1.5 and 5.1 in

	draft-kzm-snmpv2-sec-alt-00.txt

already discuss replay, and the request-id fulfills the same function
as the "nonce".  Values of request-id can be chosen unpredictably just as
easily as nonce values.

While this provides protection for managers, protection for mis-routing
to agents is achieved by the agentID field.  This leaves only
protecting the agent against replayed retrieval attacks within the
lifetime window.  We observe that if the replay occurred because of a
network mishap, there is no harm done; if the replay occurred because
of a third-party, then that third-party is able to have received the
response to the original request.  Therefore the only protection
afforded by the nonce is preventing disclosure of additional
information during, at most, the lifetime window.  In environments
which "care that much", they should be using encryption to prevent the
first disclosure.

Therefore, we claim that thrust/payload ratio of having a nonce is too low.

As such, if the author of this proposal agrees with this claim, then we
ask him to consider his proposal completely assimilated by ours.


				#######


Proposal:	SNMPv2+USEC
Auathors:	Galvin, McCloghrie, Rose, Waters
Drafts:		draft-kzm-snmpv2-intro-alt-00.txt
		draft-kzm-snmpv2-smi-alt-00.txt
		draft-snmpv2-tc-ds-03.txt (not changed)
		draft-kzm-snmpv2-tm-ds-03.txt
		draft-kzm-snmpv2-conf-alt-00.txt
		[10] draft-kzm-snmpv2-adminv2-alt-00.txt
		[11] draft-kzm-snmpv2-sec-alt-00.txt
		draft-kzm-snmpv2-proto-alt-00.txt
		draft-kzm-snmpv2-mib-alt-00.txt
		draft-kzm-snmpv2-coex-alt-00.txt

First, we observe that we have identified two changes above, i.e., a
simpler encoding for community-based traffic, and moving the definition
of the Report-PDU.

Second, in an earlier exchange Romanov suggested that a manager should
accelerate its notion of agentBoots, as appropriate, when receiving
authenticated traffic from an agent.  We agree with this change.

Third, two other implementors have privately commented to us on their
implementation experience, and we expect that a few additional messages
will be posted to the mailing list regarding these experiences within
the next few days.


				#######


Proposal:	SNMPv2+USEC Remote Configuration MIB
Authors:	McCloghrie, O'Keefe, Rose, Waters
Drafts:		[12] draft-kzm-snmpv2-usec-conf-alt-00.txt

We confess that we have spent more time focusing on the SNMPv2+USEC
proposal, it's specification and implementation, and on examining the
other proposals, looking for synthesis, and so on, than on implementing
the SNMPv2+USEC Remote Configuration MIB.

As such, we readily admit that we will not have an implementation of
this MIB module ready by August 25th.  However, we remind the working
group that our position has been that the MIB, while important, was not
urgent, and that it did not be completed in the same time-frame as the
base USEC proposal.  We prefer that the working group spend its time
working on the security model, rather than on the specification of the
instrumentation to support the security model.


				#######