Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

From: "Harrington, David" <[email-masked]>
Date: Tue, 10 Dec 2002 19:51:42 -0500

Hi,

Comments inline (then I really need to do some $$$ work).

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 3:04 PM
To: Harrington, David; [email-masked]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
 
You are right. There is no minimum requirement on min. no. of transactions per se. 
However, it is clear that the protocol should have no inherent issues with scaling.
 
Couple of questions. 
 
1.       I believe, security is the main distinction between v2 and v3 of SNMP.
SNMPv3 is being suggested as the MIDCOM protocol because of it security suit.
 
I believe, the trust level and the ensuing rev of SNMP should be the left to the 
choice of the customers/enterprises that house the middlebox, even as IETF
recommends SNMPv3 as the preferred protocol choice.

dbh> The MIDCOM requirements call for security. SNMPv1 and SNMPv2c do not have security, therefore they would not meet the requirements.  

dbh> Could SNMP be secured in other ways? Possibly, but I wouldn't recommend it because the security would not be integrated with the data model, and could not provide access control for specific portions of the MIB. In MIDCOM, I beleive it is important that one agent be able to manage, say, the firewall functionality in the middlebox, while another agent is responsible for, say, the IDS functionality. You can do this division of labor using SNMPv3's VACM functionality. In SNMPv1 and SNMPv2c, you could implement the VACM MIB modules, but you lose the binding between the robustly-authenticated "user" and which types of functionality they have access to.

2.       Let us say, SNMP is chosen as the MIDCOM protocol of choice. 
Several host stations acting as MIDCOM agents could simultaneously be 
running as SNMP server applications, right. 
 
Are there any scaling issues with the middlebox interfacing with multiple 
SNMP servers simultaneously?

dbh> At some point, an implementation may encounter scaling problems. It depends primarily on the implementation. 

dbh> for background to my next point, let me explain SNMP typical functioning. SNMPv3 defines both ends as being entities, with basically the same types of potential functionality - processing requests or processing responses or processing traps. In SNMP, the request and the response typically carry the same PDU. In a GET request, an SNMP agent (the middlebox) would need to take the list, look up the attributes in its (virtual) database, and plug the data into the response message. Typically the managemetn application (the agent) will take the data from the response message, look up the attribute in its (virtual) database, and record the values it received. Roughly comparable work to process the data.

dbh> I have worked with management applications that could regularly poll 10's of 1000's of devices. It was designed using a multi-tasking design, and some work went into ensuring it could meet scalability requirements. I have also worked with SNMP agents (what would here be the middlebox) that would lock up if it had more than 20 requests to process. Scalability has to do with implementation decisions. SNMPv3 was explicitly designed to support full-function management applications and minimal footprint small appliances. Implementations must be designed to match the environment in which they will operate.

dbh> I do not believe that SNMPv3 has any scalability issues inherent in the protocol design. Given implementations that are deployed in their target environments, I believe that well-designed implementations will perform well, and poorly designed implementations will perform poorly. To answer the question any better than this will require that we define minimum requirements, apply them to all the candidate protocols, and test them so we have real data to compare. Personally, I have real job and my bosses want me to earn my pay, and doing this type of development so we can experiment is more than I wish to commit to.

How will the traps work in the multi-server scenario? 

dbh> SNMPv3 trap management can support multiple manager applications, and you can configure the system to deliver certain types of traps to one manager, and another type to a different manager.
 
Thanks.
 
Cheers,
suresh

 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Harrington, David
Sent: Tuesday, December 10, 2002 12:40 PM
To: [email-masked]
Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
 
Hi Cedric,
 
I agree that the numbers don't say much without knowing what you're measuring and what you're comparing to.
 
Are there specific requirements about the number of transactions per minute that must be met to qualify? I didn't see any in the requirements documents. Eric raised the issue the other day, saying that the requireent was for a number of transactions per minute. Even if it took multiple request/reply pairs to perform a transaction, at ~500 SET messages per second I don't see that SNMPv3 would have a problem.
 
I fear that this is an unnecessary rathole. There are no identified minimum requirements. There are no comparative numbers for the other protocols available. The numbers by themselves are meaningless, except to show that SNMPv3 throughput has not been found to be a problem in other environments.
 
dbh
  
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 11 Dec 2002 09:54:25 +0100

David,

Does SNMP allow to dynamically direct traps based on table
indices or values of managed objects?

Or more concretely, would the following be a valid MIB design?

One kind of transactions used in the semantics doc is an asynchronous
notification from middlebox to midcom agent. Particularly, the
notification (for example on expiration of a policy rule) is sent
to one or more agents that configured it and not to midcom agents
unrelated to the policy rule.

I assume that a policy rule is modeled by a row of a table,
indexed by the owner (or creator) of the row (and some further
index components). Is there a way to have a notification on
policy rule timeout sent to (just) the owner of the row?

Certainly, you can just specify this in the SMI description of the
notification, but would existing standard compliant SNMP agent
toolkits support this (with some extra code provided by the MIB
implementor)?

The address and other required information on the owner might be
stored in a separate table.

    Juergen

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Thu, 12 Dec 2002 23:37:11 -0800

My concern, the same.
How effective is SNMP protocol for asynchronous notifications?
Will the PUSH model work effectively?
Refer section 8.2 of RFC 3303.

regards,
suresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Juergen Quittek
Sent: Wednesday, December 11, 2002 12:54 AM
To: Harrington, David; [email-masked]
Subject: direction of SNMP traps (was: RE: [midcom] SNMPv3 as MIDCOM
protocol: Opinions?)

David,

    Juergen

-- Harrington, David wrote on 10 December 2002 19:51 -0500:

> dbh> SNMPv3 trap management can support multiple manager applications, and
you can configure the system to deliver certain types of traps to one
manager, and another type to a different manager.