Subject: RE: [Isms] RE: Call for consensus

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 19 Aug 2005 01:08:28 +0200

A simple noAuthNoPriv trap for a coldstart (or similar 
initial call home) only needs the default config
parameters as described in RFC3411-3415. It does not
require extensive SNMP configuration or config
of SNMP security parameters. Those will be needed
when you start to do serious SNMP work.

Or so is my view.

Bert

> -----Original Message-----
> From: Glenn Waters [mailto:[email-masked]]
> Sent: Friday, August 19, 2005 00:18
> To: Wijnen, Bert (Bert); Keith McCloghrie
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Isms] RE: Call for consensus
> 
> 
> Now I am confused.
> 
> We started the ISMS group in part because people were not
> implementing/deploying SNMPv3 due to the complexity of the security
> administration. Now I see the suggestion that a notification 
> (coldStart
> in the example below) would go over UDP which implies that 
> the existing
> SNMPv3 security model must be implemented/deployed. If we consider the
> existing security model to be fine enough for notifications then why
> even bother with ISMS?
> 
> Regards, /gww 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]
> On
> > Behalf Of Wijnen, Bert (Bert)
> > Sent: Thursday, August 18, 2005 10:09
> > To: Keith McCloghrie
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Isms] RE: Call for consensus
> > 
> > Thanks for your input Keith.
> > 
> > For the example you cite, I wonder
> > - SNMPv3 over UDP stays as a mandatory transport I would think
> >   (We say so in the SNMP specs)
> > - The coldStart to me seems not sensitive from a security point
> >   of view (or so I think, others may think different),
> >   so I do not see why it could not be sent unauthenticated
> >   (i.e. noAuthNoPriv) via a TRAPv2 on UDP.
> > - And then after that, the manager can setup a connection to the
> >   agent, no?
> > 
> > I am not saying that a call-home (as I now better understand what
> > it means) is not a usefull feature, I am saying that it seems
> > to add extra requirements or an extra problem that this WG was
> > not intended to solve. And we have (had at least) trouble enough
> > to focus on the things we ARE supposed to work on.
> > 
> > Bert
> > 
> > > -----Original Message-----
> > > From: Keith McCloghrie [mailto:[email-masked]]
> > > Sent: Thursday, August 18, 2005 15:49
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: [Isms] RE: Call for consensus
> > >
> > >
> > > Bert,
> > >
> > > After a (cold) reboot, an agent will typically send a coldStart
> > > notification.  If that notification is to be sent via a TCP-based
> > > transport mapping, then the agent has to setup the TCP connection.
> > > The notion of "trap-based polling" has been part of SNMP since the
> > > beginning, wherein an agent sends a notification to a manager and
> the
> > > manager decides to send requests to the agent based on the
> information
> > > contained in the notification.  What Eliot describes is
> > > equivalent to a
> > > "trap-based polling" scenario for a notification such as 
> coldStart.
> > >
> > > Keith.
> > >
> > >
> > > > Thanks Eliot. Your explanantions are very useful
> > > > (at least to me).
> > > >
> > > > So based on what you say, then I see:
> > > > - Call-Home is a new function that we do not have
> > > >   in current SNMPv3.
> > > > - Call-Home is not a specific issue w.r.t. the
> > > >   WG charter, which is (in my view) to develop
> > > >   a securityModel that provides better integration
> > > >   with existing operational security infrastructure.
> > > > - Call-Home is also not available (in the mandatory
> > > >   to implement) NetConf over SSH. So it cannot be
> > > >   assumed to be available in that environment.
> > > > - You may have uncovered/presented a feature that
> > > >   operators may need or want, but I do not think
> > > >   that that feature falls in this WG's charter, the
> > > >   more since you explain that it is not well enough
> > > >   defined/available in NetConf (mandatory parts) and
> > > >   also not in current SNMPv3.
> > > > - So if such a feature is indeed needed/wanted, then
> > > >   it seems something that may need separate attention.
> > > >   Possibly in a separate WG, possibly as individual
> > > >   submission, Possibly in Netconf as a follow on
> > > >   work item, and maybe later (or at lower priority)
> > > >   in ISMS. But I claim it is not the primary task of
> > > >   this WG to focus on it.
> > > >
> > > > Just my individual opinion.
> > > > Bert
> > > > p.s. Hope you feel much better today!
> > > >
> > > > > -----Original Message-----
> > > > > From: Eliot Lear [mailto:[email-masked]]
> > > > > Sent: Thursday, August 18, 2005 07:39
> > > > > To: Wijnen, Bert (Bert)
> > > > > Cc: [email-masked]; Margaret Wasserman; Andy Bierman
> > > > > Subject: Re: [Isms] RE: Call for consensus
> > > > >
> > > > >
> > > > > Good morning, Bert.
> > > > >
> > > > > I'm sorry for the delayed response- out sick yesterday.
> > > > > Please see below.
> > > > >
> > > > > > Pls write a short paragraph or two that explains exactly
> > > > > > what you mean with "call home". I think it is a term
> > > > > > that means something in your mind, and possibly something
> > > > > > else in my (or other peoples) mind(s). So having a good
> > > > > > definition, so we all know what we're talking about is
> > > > > > (I think) a good thing.
> > > > >
> > > > > "Call home" is the act of the managed element initiating
> > > the transport
> > > > > connection to the manager for the purpose of being managed in
> > > > > some way.
> > > > >  An example of a "call home" function would be any of the
> > > > > various update
> > > > > mechanisms in your Microsoft Windows / Apple / SuSE Linux
> software
> > > > > update services.
> > > > >
> > > > > This function is used explicitly for several reasons.  First,
> many
> > > > > elements are unavailable through firewalls or NATs
> > > largely because the
> > > > > firewall does not support transport of other than specific
> > > > > UDP functions
> > > > > such as DNS and/or NTP and/or certain gaming applications.
> > > > >
> > > > > Second, there is an inherent security benefit for devices
> > > that do not
> > > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP
> > > requests as
> > > > > SNMP does since the lower levels filter out
> > > communications that the
> > > > > device didn't establish.  The level of benefit is of
> > > course tied to
> > > > > whether or not TLS is run atop the connection or IPSEC is run
> > > > > below it,
> > > > > but from a configuration perspective the latter isn't all
> > > that easy.
> > > > >
> > > > > >
> > > > > > Then, I'd like to know where/how you think current SNMPv3
> > > > > > provides it. That makes it much easier for me to map
> > > > > > the concept onto things I know.
> > > > >
> > > > > The current SNMP does not provide this function.  Were we to
> > > > > add it the
> > > > > identities mapped must be explictly mentioned in the draft.
> > > > > TCP offers
> > > > > us important opportunity, however, that would not have
> > > come up had UDP
> > > > > remained the transport of choice in ISMS.
> > > > >
> > > > > >
> > > > > > Then I'd like you to uncover some more of the "obliqueness"
> > > > > > of where how it is done in NetConf (over BEEP). You seem to
> > > > > > claim (implicit) that NetConf "consciously decided to have
> > > > > > a call-home" functionality, but I am not so sure they did.
> > > > >
> > > > > As you can read from the BEEP draft either side may 
> initiate the
> > > > > connection.  We didn't use the term "call home", that's all.
> The
> > > > > design-team had a discussion on this point and Margaret
> > > claimed that
> > > > > since the function was available to BEEP it needn't be
> > > present in all
> > > > > mappings.  While I didn't think much of the answer at the time
> (I
> > > > > prefered all mappings to offer all functions), since I
> > > could do what I
> > > > > wanted to do in BEEP I was happy enough.  I've CC'd Margaret
> > > > > and Andy as
> > > > > they can check my memory and notes (much of this occurred on
> > > > > the phone).
> > > > >
> > > > > > In any event, if they have it via the NetConf over BEEP
> > > > > > mechanism, then they cannot assume it will be present,
> > > > > > because only NetConf over SSH is mandatory to implement.
> > > > >
> > > > > When we offer the same service we should use the same 
> method to
> > > > > accomplish the task.  As I've written, I'm not wedded to
> > > BEEP but I do
> > > > > think we need this capability in either and we should
> > > implement it in
> > > > > the same way.  At the very least it has the potential to
> simplify
> > > > > administration while the other method has more than the
> > > potential to
> > > > > complicate it.  You're also re-using the same code paths
> > > which is good
> > > > > for security, not to mention efficiency.
> > > > >
> > > > > Does this answer your questions sufficiently?
> > > > >
> > > > > Eliot
> > > > >
> > > >
> > > > _______________________________________________
> > > > Isms mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/isms
> > > >
> > >
> > 
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> 

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Aug 2005 16:35:52 -0700

Hi -

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Glenn Waters" <[email-masked]>; "Keith McCloghrie" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, August 18, 2005 4:08 PM
...

In order for that notification to be delivered, *something*
will have had to have created the following non-default entries:

1) an entry in snmpTargetAddrTable, indexed by snmpTargetAddrName, consisting of
   snmpTargetAddrTDomain,    snmpTargetAddrTAddress, snmpTargetAddrTimeout,
   snmpTargetAddrRetryCount (these last two items have usable DEFVALs),
   snmpTargetAddrTagList, snmpTargetAddrParams, snmpTargetAddrStorageType
   (this item also has a usable DEFVAL) and snmpTargetAddrRowStatus

2) an entry in snmpTargetParamsTable (to be indexed by snmpTargetAddrParams),
   consisting of snmpTargetParamsMPModel, snmpTargetParamsSecurityModel,
   snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel,
   snmpTargetParamsStorageType (this last one having a usable DEFVAL), and
   snmpTargetParamsRowStatus

3) an entry in snmpNotifyTable (indexed by snmpNotifyName)
   consisting of snmpNotifyTag, snmpNotifyType, snmpNotifyStorageType
   (has a usable DEFVAL) and snmpNotifyRowStatus

4) an entry in snmpNotifyFilterProfileTable (indexed by snmpTargetParamsName)
   consisting of snmpNotifyFilterProfileName, snmpNotifyFilterProfileStorType
   (has a usable DEFVAL) and snmpNotifyFilterProfileRowStatus

5) an entry in snmpNotifyFilterTable (indexed by snmpNotifyFilterProfileName
   and snmpNotifyFilterSubtree) consisting of snmpNotifyFilterMask,
   snmpNotifyFilterType, snmpNotifyFilterStorageType (these three have potential
   usable DEFVALs), and snmpNotifyFilterRowStatus

Appendix A of RFC 3413 gives a worked-out example.
Whether this is "extensive" configuration or not is left to the reader.

Randy