RE: the future of SNMP

--- "Harrington, David" <[email protected]> wrote:

> #1 For any solution to work effectively, it will
> need to be supported by both the agent and the
> manager. Fixing it on one side only is not an
> option. 

I agree that the best solution is double-ended.  but I
believe that even just having an snmpv2/v3 agent and a
new mib module _will_ allow a non-upgraded NMS to
perform a bulk file snapshot and transfer.  that's
part 1 of the solution.

part 2 is the data import into something useful.  if
you believe that any serious bulk file application
will operate on a database rather than in-memory
snmp-retrieved data, then import of a CSV file is
pretty trivial and really isn't such a big deal.  I
may be wrong here, but my assumption is that data
chomping _will_ be from a database and that is why I
chose simple ascii CSV files as the 'language' for
sending bulk data across.  it requires little or no
decoding for most databases.


> #2 It isn't enough to deliver a large blob of data
> to an NMS; the NMS needs to be able to break it out
> and process it to display and/or convert the raw
> data into information to make the blob of data
> meaningful to an operator. Without that step it is
> not a useful solution.

again, I believe my CSV solution addresses that
problem.


> #3 using another protocol to transport gathered data
> requires defining some mappings to coordinate that
> usage. It is not as simple as defining a mib and
> then just saying "send it over FTP". 

or scp.  I used ftp only as an example, not to say
that's the only transfer protocol.  in a push model,
the agent would initiate a transfer using the protocol
set by the NMS.  in the pull model, the NMS would
initiate using the protocol of its choice.  perhaps
the agent would place the file in a secret directory
known only by the agent and NMS and the NMS would do a
wget (for example) to pull the data across, using http
or https, etc.


>What are the
> possible error conditions that could occur, and how
> should they be handled? There have been earlier
> attempts to send file of gathered data, such as
> RFC2513, and these have not been widely deployed to
> my knowledge. I would assume that if this design
> brought great beneift to the SNMP community, the
> approach would have been extended for use in other
> scenrios. Do we know why this never gained much
> acceptance?

I don't have the specifics, but our product manager
showed me several vendors that do ship agents (on a
router or switch or dslam or whatever) that _do_ push
bulk mib data across.  and I had an RFP in hand from a
major backone carrier that called for almost exactly
the solution I proposed.  it solves customer problems
today and there _is_ a market need for it.  the issue
is that each vendor did it in a vendor-specific way
and none, to my knowledge, had the level of power that
my proposed mib has.


> #4 As Juergen pointed out, the security mapping
> between FTP and SNMPv3 will be non-trivial. As a
> vendor, it is difficult for me to convince a
> customer they should buy our products because we
> have SNMPv3-strength security and then suggest they
> should use a non-secure protocol like FTP

again, remember there are both a push and a pull
model, and that ftp is only _one_ such protocol that
could be used.


> to ship
> bulk data. Even if the file could be transported
> over SSH or SSL or a VPN or IPSec, no mappings have
> been proposed about how to do that in a standardized
> manner, or what rules need to be followed to balance
> the security between the two.

true, I have not spent a lot of time trying to fine
tune this proposal to meet the needs of the security
community.  I admit that is not my strength and I
welcome input in that area.  but I believe that the
problems of making this secure and making this
efficient are orthogonal, and I would hope the lack of
security design in the current mib rev would not
hamper the proof-of-concept and further development of
this proposal.  I see the security improvements being
folded into the proposal over time, as the mib (and
implementation) are evaluated and matured.


> Which security
> precautions must be follwoed sending bulk responses
> to a noAuthNoPriv request? which are acceptable for
> an authPriv response? Can they be mixed into the
> same buffer?

I don't have answers to those questions.  I would
welcome advice in making the mib more secure by those
who are better qualified in the area of security.


> #5 Even if the file can be transported securely
> using the correct message security level, a
> file-based transfer does not have user-specific
> access control like VACM. I haven't read the mib
> recently; have mechanisms been defined for
> coexistence with VACM? 

there were some patches almost a year back that helped
address this concern, I believe.  while they're not in
the current mib text, they should be in the EOS mail
history.  but I agree that they should be folded back
into the mib and resubmitted for peer review - if the
community agrees (in theory) that there's merit to the
hybrid solution.


> #6 As Juergen pointed out, adding new protocol
> additions may require nothing more than a recompile,

yes, he pointed that out.  and I'm specious about that
assertion.  I guess the proof will be in the pudding,
once an implementation is released and we see if a
simple rebuild of the nms apps is all that's needed.


> because many agents and applications use a toolkit
> and if the toolkit has the extra functionality the
> agent and manager will get it by default. However, I
> will point out that #2 still applies. Even if I can
> add a protocol extension with no work, I still need
> to modify my code to take advantage of the feature.
> For an NMS, this will include probing to determine
> whether the functionality is supported by different
> agents. If the SNMP stack provides the feature if a
> developer calls the appropriate API, then the
> developers need to be educated about the relative
> benefits of the new solution so they will call the
> new API rather than just continuing to call the
> getNext() API for all devices.

so right there, you say that its not going to be a
simple recompile.  I believe that new code will have
to be written.  for example, if a routine exists at
the nms called 'get_me_the_whole_iftable(...)' and
that currently implements to a bunch of ifTable walks
(and error handling, etc), then for the new model that
routine will have to be re-written entirely to detect
and call the new snmp stack routines if the agent
supports it, or switch to the old style if the agent
isn't new-protocol capable.  that doesn't seem to be a
'simple recompile' to me.


> It is easier to just
> call the same API for all tables rather than having
> to test and debug conditional branches of code. I am
> not convinced that GetBulk has seen wide usage by
> major NMS vendors yet, for similar reasons. 

I also believe that getBulk isn't widely used, but
that's mere speculation on my part, as I don't have a
survey of enough NMSs to say that as a fact.  but I
share your belief in that its probable that getBulk
isn't widely used, for various reasons.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/