Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion

From: "Harrington, David" <[email-masked]>
Date: Sun, 30 Mar 2003 02:51:38 -0500

Hi Dave,
 
I didn't think you stooped to promulgating such FUD. Oh well.
 
I think XMConf may deserve to be considered, but I think it is not sufficiently specified yet to meet the midcom requirements.
Comments inline.

-----Original Message-----
From: Durham, David [mailto:[email-masked]]
Sent: Friday, March 28, 2003 1:11 PM
To: Jonathan Rosenberg; [email-masked]
Cc: Eliot Lear; [email-masked]
Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion

I agree. There is nothing technically preventing XMLConf from doing
small dynamic transactions. In fact, I argue that XMLConf would be
superior over SNMP for such transactions. Do the math:

* snmp's unreliable transport means get followed by set followed by get.
Several round trip latencies incurred by each snmp get set get exchange.
RTT becomes the most significant bottleneck for snmp. Pray there's no
packet loss. 

Can you explain your approach that requires get-set-get? 

I can understand the initial get prior to a set, as simply being good programming practice prior to changing any operational parameter whether remote or local. I assume you would want to do the same before modifying a parameter using XML.

SNMP has responses to requests. If a SET succeeds or fails, you know that in the response; there is no reason to do a get to confirm it was successful or not. If you argue that it would be good practice to check anyway, how would that be different if using XML?

Assuming the logic of examining an attribute, then modifying an attribute, then verifying an attribute is justified for a UDP transaction, isn't the same needed for a TCP transaction? Can you explain how the same transaction would be different for UDP versus TCP? 

Can you explain how a network that causes packet losses for UDP would be more reliable with the same number of packets for TCP? It seems to me the overhead of TCP setup would generate more overhead up front. Since a good SNMP implementation includes timeout/retry logic for SNMP/UDP that would achieve the same effect as TCP retries, I suspect that SNMP/UDP might actually be just as reliable as TCP with less overhead.

* snmp's udp transport has no flow control, fairly easy to perform DoS
attack either on purpose or quite accidentally. 

If you want to argue the virtues of TCP versus UDP, you don't need SNMP in the equation at all. Of course, if you really believe that TCP is superior to UDP for this reason, you can always run SNMP over TCP, as per RFC3430. It has at least as many implementations as XMLConf. It strikes me that you're really stretching to provide FUD for this mailing list.

* snmpv3 has a very complicated user security model. Few people using it
to date. Many operators today typically run snmpv1 over VLANs or VPNs. 

Security is complex. Flexibility can add complexity. When you make the statement that SNMPv3 has a complicated user security model, what are you comparing it against? Does your comparison provide for the same amount of functionality? SNMPv3 is designed to permit operators to apply various levels of security, including rather simple configurations, depending on the environment to be secured.

I suspect there are more using SNMPv3 than are using XMLConf. I certainly agree that there are more SNMPv1 users than SNMPv3 users to date. Does that mean we should use the non-secure SNMPv1 as the MIDCOM protocol? I wouldn't recommend it, and said so in the protocol evaluation. 

XMLConf doesn't actually address security at all. I see nothing the proposal about ow to identify the authenticated user, or how to apply access control to the data, since there isn't even a data addressing capability defined for XMLConf yet.

* A complete Oid is exchanged with every attribute being communicated
making each snmp BER transaction just as big if not bigger than
equivalent XML encoded data. 

Have you actually done the research to put forth this assertion? I don't know how you could have since we havn't yet defined the OIDs for the attributes to be used for MIDCOM, or the naming mechanism for XMLConf attributes yet.

I'd like to see actual comparisons for real data that is relevant to the proposed usage, rather than just an unproven assertion from an obvious supporter of one approach over the other. I would love to have you back this up with real replicable research so people can make an informed decision about the validity of the analysis and a comparison of the results. Which MIBs and corresponding OIDs? Which XML schemas and corresponding XML tags? How about some real data rather than just FUD?

* BER encoding rules sufficiently complex that recently many snmp
deployments have been found susceptible to buffer overflow attacks
allowing attackers to crash systems or launch worms. We can only assume
all the holes have now been plugged. 

Do you want to compare all the CERT vulnerability reports for BER as compared to XML implementations?

A search for XML on www.cert.org showed 78 results; a search for BER showed 31 results; a search for asn.1 showed 27 results. Given how long BER and ASN.1 have been used compared to XML, I'd have a stronger trust of the ASN.1 and BER implementations than the XML implementations. 

I do agree that most deployed implementations have already been fixed, given the most commonly used toolkits posted CERT statements identifying which code releases fix the toolkits' vulnerabilities.

 * Rowstatus is the best transactional mechanism snmp has. Need I say
more? Okay, I will: get rowstatus, set rowstatus, check rowstatus, get
first attribute, set first attribute, get first attribute, get second
<time passes>, unset rowstatus, check row status... Phew. Again, pray
there is no packet loss. 

Wow, I'm glad I don't use the tools you use. 

Don't your manager and agent know how to handle messages with multiple varbinds? Don't your tools understand that requests have responses? With tools like the ones you use, no wonder you have to worry about things like packet loss; obviously if they don't handle such basic things a multi-varbinds and response messages, then timeouts and retries would comparatively be rocket science. Phew!

* With snmp you'll have to force fit your data into pdu's sized for MTU.
Certain kinds of certs and keys make this a difficult proposition. 

There are protocols like IKE and Kerberos designed to do key distribution. I don't think we're planning to use a MIDCOM mib to do key distribution to punch a pinhole through a firewall or configure NAT address ranges.

* MIB data model requires MIB specialists to read & write. Meanwhile
there is a large number of people familiar with either XML or its
supporting tools. 

You might be making your claim a bit too early. I suspect there are many who have written HTML web pages, but I would estimate that the number of people who have developed or read mibs may still exceed the number who have developed XML schemas. Do you have an real data to back your assertion?

* XML self-documenting.  

As long as you own a book on XML ;-) I've heard the claim often; I don't quite accept it as being true. While I am an experienced mib writer, I still find it easier to quickly find relevant data in a mib document than extracting useful information without tools from an XML document, especially if an XML schema document is involved.

 Schema & data are communicated with same
transport. 

And this benefits a customer how? I'm much more interested in understanding how this helps a user than in seeing assertions that a property of the proposal somehow makes it better without demonstrating any derived benefit. 

* snmp lacks several critical base data types such as Integer64 readily
supported by XMLSchema. 

How many mibs have not been able to be designed due to the lack of these "critical" data types? The SNMP community agrees that these types would be nice to have, and should have been included in SMIv2 for correctness, but to my knowledge it hasn't stopped anybody from developing mibs. So I question your definition of critical.

I will accept that XML can have lots of additional types supported by XMLSchema. How does that affect interoperability? There are tradeoffs involved with extensibility.

* lex-next ordering makes implementations complex or requires copy of
intermediate snmp data structures that are independently ordered. 

Lex-next does make implementations complex; it also provides a powerful functionality in return. Again, tradeoffs. XMLConf doesn't define how to find the first data element, never mind the next one.

Copying intermediate data structures sounds like an implementation-specific design decision. I don't think there is anyplace in the standard that requires this.

* No transactional model, either for small and dynamic transactions or
large and static ones. 

I think your assertion is broad and ambiguous. I do agree that SNMP does not have strong support for transactions. But then neither does XMLConf have much in the way of transaction support other than to claim support for rollback and commit, which are also required for SNMPv3 SETs. Can you point out in the XMLConf proposal the transactional model for small and dynamic transactions and for large and static ones?

* snmp has multi-manager transactional complexities that must be handled
at the data model level. 

XMLConf has no data model at all, yet allows multiple edit sessions to exist simultaneously for difrent subsets of data, with locks (assuming the optional lock feature is supported). Please explain how the multi-manager transactional complexities are addressed in XMLConf, given the lack of a data model level.

* snmp midcom implementations need to handle attributes arriving in any
order, possibly across multiple packets. 

We haven't selected or defined the mibs to be used for MIDCOM yet. While SNMP typically does require handling attributes arriving in any order, I don't know how you can make such sweeping statements about multiple packets without even knowing the design of the mibs.

I can go on an on the con's of snmp here. One con on XMLConf is that
it's just starting. However, XML is not new. This wg can get started
immediately writing XMLSchema models for middle boxes. 

I think it is arguable whether XML is new or not, depending on your definition of new. But you are suggesting using XML Schema which is at revision 1.0. That strikes me a being pretty new.

 I do think it would be hard to name as many cons for XMLConf, because there is so little specified for XMLConf so far, it isn't very possible to do a viable technical analysis, either pro or con.

-Dave

> -----Original Message-----
> From: Jonathan Rosenberg [  <mailto:[email-masked]> mailto:[email-masked]]
> Sent: Friday, March 28, 2003 9:02 AM
> To: [email-masked]
> Cc: Eliot Lear; [email-masked]
> Subject: Re: [midcom] On SNMPv3, clarification, invitation for
discussion
>
> Pyda,
>
> This is a pretty substantial claim. Can you provide details on why
this
> is true?
>
> -Jonathan R.
>
> Pyda Srisuresh wrote:
> > I agree. I believe, XMLCONF is useful for one-time
> configuration/retrieval.
> > SNMP is still desirable for
> > dynamic transactions.
> >
> > cheers,
> > suresh
> >
> >
> >>-----Original Message-----
> >>From: [email-masked] [  <mailto:[email-masked]> mailto:[email-masked]]On Behalf
Of
> >>Eliot Lear
> >>Sent: Monday, March 24, 2003 3:57 PM
> >>To: Melinda Shore
> >>Cc: [email-masked]
> >>Subject: Re: [midcom] On SNMPv3, clarification, invitation for
> >>discussion
> >>
> >>
> >>Melinda,
> >>
> >>Two more additions to your valid comments.
> >>
> >>XMLCONF has an intended audience: configuration and retrieval of
static
> >>information within devices.  This may be slightly imprecise, but let
me
> >>tell you what we *don't* think XMLCONF is good for: exchange of
protocol
> >>state information.  We wouldn't want to replace BGP with XMLCONF,
for
> >>example.
> >>
> >>I believe midcom comes a lot closer to a state exchange protocol,
such
> >>as BGP, then it does to the screen scraping that we are attempting
to
> >>address with NET-CONF.  Certainly this holds true for STUN, and
that's a
> >>good hint, IMHO.
> >>
> >>ALSO.  To repeat what Bert, Andy, and others have said, while the
> >>requirement has been relaxed, there is nothing stopping anyone from
> >>writing a MIB or specification with writable objects.  You simply
aren't
> >>REQUIRED to do so.
> >>
> >>If this group believes that SNMP with writable objects is the right
way
> >>to go, I say go for it.
> >>
> >>Eliot
> >>
> >>_______________________________________________
> >>midcom mailing list
> >>[email-masked]
> >>  <https://www1.ietf.org/mailman/listinfo/midcom> https://www1.ietf.org/mailman/listinfo/midcom
> >
> >
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> >  <https://www1.ietf.org/mailman/listinfo/midcom> https://www1.ietf.org/mailman/listinfo/midcom
> >
>
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
>  <http://www.jdrosen.net> http://www.jdrosen.net                      PHONE: (973) 952-5000
>  <http://www.dynamicsoft.com> http://www.dynamicsoft.com
>
> _______________________________________________
> midcom mailing list
> [email-masked]
>  <https://www1.ietf.org/mailman/listinfo/midcom> https://www1.ietf.org/mailman/listinfo/midcom
_______________________________________________
midcom mailing list
[email-masked]
 <https://www1.ietf.org/mailman/listinfo/midcom> https://www1.ietf.org/mailman/listinfo/midcom

---

From: Eliot Lear <[email-masked]>
Date: Sun, 30 Mar 2003 09:12:22 -0800

I recognize that this is not the place to debate XMLCONF, but I do want 
to disagree with one statement Dave made.

> XMLConf doesn't actually address security at all. I see nothing the
> proposal about ow to identify the authenticated user, or how to apply
> access control to the data, since there isn't even a data addressing
 > capability defined for XMLConf yet.

Wrong, wrong, right, and right.  We do address certain components of 
security.  One identifies an authenticated user through a choice of 
either SASL or TLS in BEEP, and appropriate analogs should one use 
multi-channel HTTP.

We do not specify an authorization model  in the draft as it stands.  As 
we see it, one would need to address the meta-data model in order to 
address authorization in the protocol.  This is not to say that an 
implementor shouldn't provide an authorization model.  We just don't 
standardize it in the current document.

Let me suggest that the debate between SNMP and XMLCONF is sort of wrong 
in the first place, as it wasn't really meant to replace SNMP, and that 
if one really feels the need to debate the matter, it is better done on 
the xmlconf mailing list, which hangs off ops.ietf.org.

Eliot

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom