[midcom] Scott Bradner: draft-ietf-midcom-protocol-eval

Scott Brim asked that the comments we received be forwarded.
I've excerpted the meat of the discussion.

Melinda

------- Forwarded Message

The analysis done for SNMP has a large amount of cut-and-paste, with the
same answers given for multiple questions, and little detail about how much
work would be involved, or the nature of the extensions (MIBs) needed. There
are places where obvious aspects of SNMP are overlooked, and other places
where the potential difficulties of using SNMP are not mentioned.

SNMPv1 is obviously a bad choice for configuring MIDCOM elements that
provide network security, yet the bulk of the analysis describes how SNMPv1,
v2c, and v3 might be used. The only version of SNMP that would be suitable
for this purpose is SNMPv3. The analysis should focus on SNMPv3 and not
discuss how to use SNMPv1. I object to the "however" clause in section
1.1.1; the fact that SNMP is not widely used for configuration should not be
a factor unless there are stated reasons why SNMP is not widely used that
impact the evaluation. The fact is SNMP is seldom used for configuration
mainly because SNMPv1 doesn't have security, and as a result most standard
mibs don't contain configuration objects. If MIDCOM creates a mib with
configuration objects and uses SNMPv3 as the protocol, this should be fine
for configuration purposes. The fact that SNMPv3 must be used comes across
as a negative since it is raised in a "however" clause, but the need to
support IPSec isn't raised as a "however" for the other protocols. I think
these comments inadvertently color the analysis; I don't think it's a good
start for an unbiased evaluation.

I greatly appreciate the effort Juergen put into the analysis, and regret
that nobody else in the SNMP community came forward to do this, but the
resulting analysis paints a false picture of SNMP. Note that I am not
complaining that SNMP didn't "win" or anything; I merely want the MIDCOM WG
to have accurate information to use in making their judgements, and the
information presented in this document is sometimes misleading or
inaccurate. 

I am willing to help update the analysis to improve the accuracy of the
information.

Some examples of analysis that I feel are inadequate:

The SNMP Approach

Appendix A is pure boilerplate copied from the O&M Area web site. This
appendix does not discuss the type of work that would need to be done to
make SNMP a suitable candidate. Compare that to the other appendices.
Appendix B discusses the possible need for an ALG, extensions to the control
protocol, and application support, among other things. Appendix C discusses
the need to define a Middlebox Termination type, the possible need to
seperate policies and filters from the Termination type, and behavioral
rules to permit multiple agents to share policy management. Appendix D
discusses an IPFilterRule and the information that would be needed,
evaluation order rules, and so on. Appendix A provides no analysis at this
level of detail. 

At a minimum, Appendix A should describe probable MIB table abstractions and
the objects in the tables, such as the need for a session table, and the
need for attributes of a session including authentication association (maybe
the SNMPv3 securityname), lifetime, and so on. For sending asynchronous
messages, the SNMPv3 target mib and related mibs should be populated, but
this isn't mentioned. For coordinating multiple SNMP managers, advisory
locking can be used, such as the snmpTargetSpinLock in RFC2573, or policies
could be associated with ownerStrings ala RMON, or Snmpconf mechanisms could
be used. None of these are mentioned.

The introductory material on SNMP discusses how the terminology is different
- - including PDPs and PEPs. One approach to using SNMP to configure MIDCOM
would be to use SnmpConf - SNMP for Configuration, which is designed
explicitly to do policy management consistent with the PDP/PEP Policy
architecture and it uses comparable terminology. The Snmpconf approach would
be much closer to the MIDCOM architecture and the architectures of the other
candidate protocols, and explicitly deals with issues such as ruleset
groupings, policy conflicts, capability negotiation/discovery, and so on,
than the typical use of SNMP management for monitoring.

Specific concerns:

1.1.3 - I find "replies to requests are signaled by the Middlebox (SNMP
agent) by modifying the managed objects" an odd way to describe the way SNMP
works. For every processed request message, there is an associated response
message that indicates success or failure and the reason for failure. See
also comments below.
2.1.1 - I'm not sure I agree that "associations are established" unless
SNMPv3 users with shared secrets qualifies. I would like to better
understand whether MIDCOM associations have special characteristics that
differ from SNMPv3 users and shared secrets. The analysis doesn't get into
this at all.
2.1.4 - SNMP is silent about the outcome of multiple requests being
presented simultaneously. The SNMP protocol does not explicitly include any
support for this. There are a number of mechanisms used in mibs, such as
advisory locking and ownerstrings, but none are required or enforced by the
protocol.
2.1.5 - SNMP operates on a message-by-message basis, with independent
managers and agents, with no sessions or session associations. There is
little sense of shared state. My impression is that the requirement is
looking for state recovery. SNMP does not support this except that the
manager can poll the agent to determine its state. SysUpTime can help to
identify when a reboot has occurred so the manager knows to reread the
agent's mib.
2.1.6 - Status is mentioned in three different contexts in the other
responses: a response to the status of a particular request (available as a
response message in SNMP), asynchronous notifications (traps/informs), and
queries (polling). The analysis only mentions one type - polling.
2.1.7 - "INFORMS are perhaps more desirable" - there is an assertion here,
but no explanation of why an Inform may be preferred over a trap. SNMPv1 is
not applicable to the desired purpose. 
2.1.8 - "The encryption method is specified in RFC2574" and "can
authenticate themselves with one of two authentication methods" totally
ignores SNMPv3's very deliberate design to support multiple types of
encryption and authentication. The standard configuration defines one
encryption and two authentication mechansisms, but SNMPv3 is capable of
supporting more than those. I would hate to see the WG select another
protocol because it supported more security mechanisms. 
2.1.10 - SNMP contains a Response-PDU that is sent to indicate the success
or failure of a SET-Request PDU; there is no need to poll the device or to
have a device send a trap to communicate the success or failure of a
request.
2.1.11 - in practice, there is little in the way of version interworking
capability discovery as described in the analysis. Any objects that declare
capability support are mib-specific. Generally a manager must poke and prod
an agent to determine which mibs have been implemented and which objects
have been implemented, and whether they have been fully implemented.
Regarding version interworking, SNMP separates the protocol messaging
version and the data schemas. Message version coexistence is explicitly
described in  RFC2576 "coexistence between SNMPv1, v2c, and v3", but most
"updates" to SNMP are updated mib modules. RFC2578-80 define the rules for
updating mib modules. These are not mentioned in the analysis.
2.1.12 - the SNMP protocol and most SNMP mibs do not have any explicit
features to guarantee that two requests do not overlap and conflict. The
only guaranteed atomicity in SNMP is for a SET command, and it asserts only
that the application of the attributes within a single SET request will be
modified "as if simultaneously."  Snmpconf has mechanisms to coordinate
overlap in rules to achieve a deterministic behavior. I do not believe that
either SNMP or Snmpconf preclude the possibility of nondeterministic
behavior.

and so on.

For these reasons, I would like to see the SNMP information in this document
updated prior to publication as an RFC.

- -----Original Message-----

From: Harrington, David [mailto:dbh@enterasys.com]
Sent: donderdag 3 oktober 2002 18:56
To: 'Wijnen, Bert (Bert)'
Subject: RE: draft-ietf-midcom-protocol-eval-05.txt 

Hi Bert,

I will continue to review the document.

I don't know if we would come out any worse in the scoring. I did note that
some places where P+ was assigned to SNMP because a MIB needed to be
developed, was compared to other protocols that got a T, even though
additional message AVTs or whatever needed to be added. Either way, a
content-specific data model (or schema) needed to be developed to get the
support required.

I am less concerned with how we score than that we be properly analyzed. As
you are well aware, an assertion made in an RFC can set precedent that
others will reference in the future. I don't want to see Juergen, or anybody
else, conclude that SNMP is not applicable to a particular problem, and have
that set the precedent that SNMP is inappropriate for a whole class of
related problems. I point out the folklore that TCP is reliable while UDP is
not, so SNMP should use TCP arguments continue to circulate for reason of
reliability.

My feeling is that while it may not be important to this particular contest,
it could be very important to future contests. I would be more willing to
see SNMP simply eliminated from the contest and all mention of SNMP removed
from the documents than to have SNMP inaccurately characterized in the
documents. If they're ging to put SNMP in the documents, then the analysis
should be done accurately.

- -----Original Message-----

I'm about half-way through. 

I believe there are a few points where the analysis is actually wrong. I
point out section 2.1.10 and 2.1.12.

For the most part, my concern is that Juergen may not be identifying places
where SNMP may not be appropriate or could be difficult to apply because of
the difference in architecture. SNMP has a different conceptual architecture
than MIDCOM, Diameter, COPS, and other session-based protocols. The
requirements have been framed in terms of the MIDCOM architecture, so
requirements like "lifetime extension" and "termination of session" don't
quite apply, but can be emulated via mibs. I think that needs to be
explained a bit more than has been done, and where a mib emulation is
required, I think the nature of data required in the mib should be
mentioned, e.g. a session table needs to be created to manage the emulated
sessions; lifetime would need to be specified in the session definition
(row), and could be extended as needed, and so on.

Many of his assertions are only assertions, and don't have any meat to them.
For example, in 2.2.1 compare Juergen's response to that for other
protocols, which discuss how the requirement is met. 

I will offer to help MIDCOM update the SNMP portion of this document if
you'd like, and if Juergen and the chairs have no objection. I obviously
know the SNMP quite well; I just need to understand the MIDCOM architecture,
requirements, and terminology. I have monitored MIDCOM in the past, and have
read many of their docs, so I just need to make sure I understand the
requirements fully. Having monitored Diameter and COPS will also help to
"grok" the requirements.

dbh

- -----Original Message-----

The single largest problem I have with the document is that the whole SNMP
analysis starts out with the assertion that SNMP is used mainly for
monitoring, not configuration. Starting out the "applicability" document
with an assertion like this obviously biases all subsequent analysis. 

I had an interesting comment from somebody recently that related to
something else, but seems applicable here. An engineer needed to know
whether to build a bridge across a river, so he stood at the river where the
bridge would be built. He concluded that no bridge was needed because nobody
crossed the river at that point; they all went 10 miles down the river to
cross at the bridge there instead.

------- End of Forwarded Message
_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom