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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 18 Aug 2005 16:08:32 +0200

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2005 16:05:49 -0400

>>>>> "Wijnen," == Wijnen, Bert (Bert) <[email-masked]> writes:

    Wijnen,> Thanks for your input Keith.  For the example you cite, I
    Wijnen,> wonder - SNMPv3 over UDP stays as a mandatory transport I
    Wijnen,> would think (We say so in the SNMP specs) - The coldStart
    Wijnen,> to me seems not sensitive from a security point of view
    Wijnen,> (or so I think, others may think different), so I do not
    Wijnen,> see why it could not be sent unauthenticated
    Wijnen,> (i.e. noAuthNoPriv) via a TRAPv2 on UDP.  - 

You probably want notifications to be integrity protected, for example
so you know that the box has actually rebooted.  Similarly you want
the delivery confirmation to be integrity protected.

--Sam