Re: How is party proliferation problem solved in SMP?

["James R. (Chuck) Davin" <[e-mail]>]

Although I don't disagree with any particular solution being proposed,
I think it is important to be accurate about what the problem might be
and the corresponding range of solutions.

It is not, in fact, any aspect of the SNMP administrative model that
poses a problem (perceived or otherwise) in this case, but, depending
on your perspective, either a particular mechanism of a particular
authentication protocol or the software architecture of particular
management platforms.

It is not entirely clear to my foggy brain that all possible
implementation strategies have been enumerated or that their relative
costs have been accurately assessed. For example, an implementor might
want to explore the use of the Unix filesystem as a way of sharing
information among Unix processes. If that seems too complex, an
implementor might want to explore the simpler strategy of using SNMP
proxy as a way of "fanning out" protocol interactions.

I don't particularly disagree with any of the conclusions (for which,
I suspect, there may be very sound arguments), but, for me, Carl
Sagan's reckoning of the number of parties in the universe is not a
good substitute for careful analysis.

> X-Folder-Dispatch: Mon, 28 Sep 92 09:57:15 -0400
> X-Folder-Dispatch: +dst-snmpev
> Return-Path: bcruucp
> Received: by thumper.bellcore.com (4.1/4.7)
> 	id <AA08324> for davin; Sat, 26 Sep 92 01:53:50 EDT
> Received: from andrew.cmu.edu by thumper.bellcore.com (4.1/4.7)
> 	id <AA08320> for  /usr/lib/sendmail -oi -fsnmp2-request X-snmp2; Sat, 26 Sep 92 01:53:49 EDT
> Received: by andrew.cmu.edu (5.54/3.15) id <AA28454> for [e-mail]; Sat, 26 Sep 92 01:53:46 EDT
> Received: via switchmail; Sat, 26 Sep 1992 01:53:43 -0400 (EDT)
> Received: from zeus.andrew.cmu.edu via qmail
>           ID </afs/andrew.cmu.edu/service/mailqs/q002/QF.oekzf2e00WArE0UmV5>;
>           Sat, 26 Sep 1992 01:53:06 -0400 (EDT)
> Received: from zeus.andrew.cmu.edu via qmail
>           ID </afs/andrew.cmu.edu/usr5/sw0l/.Outgoing/QF.Yekzf0S00WAr5YE4sZ>;
>           Sat, 26 Sep 1992 01:53:05 -0400 (EDT)
> Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.zeus.andrew.cmu.edu.sun4c.411
>           via MS.5.6.zeus.andrew.cmu.edu.sun4c_411;
>           Sat, 26 Sep 1992 01:53:03 -0400 (EDT)
> Message-Id: <[e-mail]>
> Date: Sat, 26 Sep 1992 01:53:03 -0400 (EDT)
> From: "Steven L. Waldbusser" <[e-mail]>
> To: [e-mail], [e-mail]
> Subject: Re: How is party proliferation problem solved in SMP?
> In-Reply-To: <[e-mail]>
> References: <[e-mail]>
> 
> 
> 
> Excerpts from mail: 22-Sep-92 How is party proliferation .. Michael L.
> Kornegay@math (255)
> 
> > How is party proliferation problem solved in SMP?
> 
> > One of the slides in the SMP BOF of July 15, 1992 indicated this problem
> > with the SNMP Administrative Model was solved with SMP.
> 
> A management station is typically made up of many different functional
> units (graphers, pollers, maps, browsers, ...).  Often several instances
> of each may be running on a single management station.
> 
> The protection from message reordering provided by the SNMP
> Administrative Model demands that all PDU's to and from a particular
> party be issued with clock/nonce values in sequence, or else the packets
> out of sequence get dropped as unauthentic.  With this constraint, two
> pollers on management station A polling agent B have three available
> strategies for cooperation:
> 
> 1.  Each poller uses a separate party at the agent and a separate party
> at the MS.
> 2.  The pollers share parties, but use some locking scheme to ensure
> that between them, they build and send PDU's in sequence.
> 3.  The pollers use some protocol to speak to a central protocol engine
> that will issue SNMP PDU's on their behalf - this central protocol
> engine has no difficulty meeting the constraint of sending PDU's in
> sequence.
> 
> Solutions 2 and 3 are difficult due to added complexity (and therefore
> decreased reliability) due to their distributed nature.  They also have
> significant performance limitations.  In addition, they lack a standard
> mechanism for communication of locking info (solution 2) or PDU requests
> (solution 3).  This is especially important when the level of
> application integration is at the menu level.  In other words, two
> application from different vendors called from the menu of a platform
> from yet a third vendor are unlikely to agree on either (1) a database
> protocol to retrieve and lock the next clock/nonce values, or (2) an API
> to send requests to an SNMP protocol engine to generate SNMP PDU's.
> 
> This leaves us with solution #1.  This solution does not require the
> definition and implementation of a standard protocol among applications.
>  Unfortunately, if N parties are needed to perform management between MS
> A and agent B, and there are M instances of applications running on MS
> A, M*N parties must be configured per MS/Agent pair.  The grand total
> for a network is M*N*(#MSs)*(#agents).  This can grow to unmanageable
> levels on a campus network.  Because the number of applications on a
> platform, M, can easily be more than ten, it is a major contributing
> factor to the large number of parties needed.  
> 
> SMP drops the protection from message reordering (retaining protection
> from replay and adding reordering protection for SETs on an as-needed
> basis).  This allows all of the applications on a platform to share the
> same set of parties without sending PDU's out of sequence and thus
> reduces the number of parties needed by an order of magnitude.
> 
> 
> 
> Steve