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

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 17 Aug 2005 13:26:37 -0400

>> It cannot.  However you could set things up so that no matter
    >> which side invokes the snmp subsystem, packets are allowed to
    >> flow in both directions.

    Margaret> SNMP communication is bi-directional, but it is not
    Margaret> symmetrical, and I'm not sure that we can or should
    Margaret> change that under the auspices of defining a new, better
    Margaret> integrated security mechanism for SNMP.

> Is it asymmetric at the level that we're talking about
> though--at the PDU transport level?
>
> I do think the simplest level to do call home is to make the channel
> bidirectional. 

The channel is bidirectional no matter what - in the sense that both
ends occasionally send something over it. But the only true symmetry is
in the session/channel establishment cost - which is evenly shared
between the two peers.

Asymmetric here (as Margaret pointed out) means - who must know what
about who (such as but not limited to locations and identities of
potential managers). 

If asymmetricity of the higher layers didn't impact PDU transport - this
WG could be concluded with two one-statement RFCs: (1) "just use SSH",
and (2) "just use TLS". Devil is in the details, such as who to
establish a channel to, when, how, with what parameters, etc. Managers
are at much better position to answer those questions.

Currently SNMP agents (as Margaret pointed out) just sit there and wait
for incoming requests. If and when one comes - send a message back if
ncessary. Vey simple. Note that Web-based management doesn't change this
basic assumption - it simply replaces SNMP server with httpd.

Introducing Notifications ("confirmed traps") was a divergence from this
puerille line of thinking. Now the agent must figure out who to send
notification to, and more important - what to do if it appears that
notification hasn't reached its destination. But the main SNMP concept
wasn't altered: agent in its routine functioning stays small and dumb.

Perhaps we do want to change all this? And as we're at it - perhaps we
do want to get rid of ASN.1? It's only half-joke.

> I do agree with you though that it is unclear what
> call home would mean in an SNMP context and that we should
> convince ourselves that we want call home and know what it
> means before specifying it.

Can't agree more. Am not convinced that "call home" is needed and/or can
solve any of SNMP problems.

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 18 Aug 2005 16:46:34 -0400

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. 

(Speaking of traps and not notifications - as notification is a
different beast. Reboot event usually generates a trap, not a
notification.)

Not necessarily!  

Recall, that SNMP uses "Trap-guided Polling" approach. Received trap
basically means "something probably has happened on that device, so I
better go look now, rather than when my schedule suggests to check on
it."  Trap information merely guides as to what to look first.

It would be better if traps could be trusted (i.e. integrity- and
source-identity-protected), but the cost of establishing that security
association may well outweight the cost of just polling when you get the
trap - especially since after receiving the trap you'd probably need to
poll anyway (regardless of whether you trusted the trap or not). It's
not like having secure traps saves you from the need to go and poll the
device.

> Similarly you want
> the delivery confirmation to be integrity protected.

Yes, IF I'm sending a secure notification - I'd like the confirmation to
be secure too. But as it was said before - support of notifications
effectively turns agent into a manager wrt. the burden of figuring who
to talk to and establishing the connection/session/whatever. SNMPv3/USM
allowed to take it easy by using static configuration.

---

From: "Glenn Waters" <[email-masked]>
Date: Thu, 18 Aug 2005 18:17:34 -0400

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
> > > >
> > >

---

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

And I think we explicitly did putthose examples in the
RFC so that people could (reasonably easy) configure those.

I guess I am biased, having done various implementations
and so it may seem more "reasonably easy" to me than
to others. I also think if you look at the text of
the parameters in Appendix A in RFC3413, that it does
not look as awfull as it looks in the unformatted text
provided by Randy below.

Bert

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Randy Presuhn
> Sent: Friday, August 19, 2005 01:36
> To: [email-masked]
> 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
> > 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.
> ...
> 
> 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
> 
> 
> 
>