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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 18 Aug 2005 12:14:13 +0200

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Aug 2005 13:26:24 +0200

Bert,

Forgive me but I'm frustrated.  I won't just complain, however.  I have
a proposal (I've been chewing on it for a bit).  See below.

How could call home functionality possibly have ended up in the charter?
 Nobody knew we would come close to using a TCP-based approach until
March when an WG-shaking event occurred.  Every approach submitted and
envisioned prior to that was a new security model using the existing UDP
transport.

But we are here now, and we are positioned to either take advantage of
or miss a huge opportunity or create a mess.  Anyone who thinks that
firewalls or NATs routinely implement the proxy function of RFC 3413
hasn't taken a good look at the market lately.  Let's at least make the
best of the position we find ourselves and take corrective action.  I
hate to say it, but take a look at Windows.  Most of the time management
connections are issued by clients.  Really this is no different.

Let me refresh your and Dave's memory on the matter of NETCONF.  The
initial authors of the base spec ALWAYS envisioned a call home function.
 We got it for free with BEEP, which was part of the core specification
until the working group forced us to separate out protocol mappings.  We
even had it in an early draft of the SSH specification, but cut it out
[too much channel cruft as you may recall].  What's more, I claim it's
easier than ever to do now.

In the netconf ssh draft, what I propose is that we add some text around
the following idea:

 - when the manager contacts the agent, it will request the "netconf"
   SSH service.
 - when the agent contacts the manager, it will request the
   "netconf-turn" service (or "netconf-callhome" if you prefer - I
   would like to reuse the SMTP term since they invented the concept,
   so far as I can recall).
 - Add text in security considerations about how to handle identity
   for the call home approach.  I claim it's No Big Deal.  It just
   says that the client process for callhome should probably tie to
   an appropriately authorized user for the function being managed.

This mechanism has the added benefit of not requiring pre-existing
implementations to change their code.  The reason I want it in round one
of netconf is that I would if I could nuke all other transport options
including BEEP.  Options are a necessary evil.  Transport options are an
UNnecessary evil.

Rinse and repeat.  The same process can be applied to SNMP.  There is no
difference.  Presto.  Yes, it took me a few days to come up with this in
a simple way.  And yes, there are a few issues surrounding the mapping
for traps, but I claim we can solve those as well to peoples'
satisfaction.  What do people think?

The result is a single mandatory transport for both NETCONF AND BEEP.
Similar call home functionality for both.

This is NOT Eliot's "would be nice" for a protocol.  It's really
important for our customers.  We've always envisioned having call home
functionality in our products.  In fact we've had proprietary solutions
for years (which is how we know it's important to our customers).  The
other option - and they're already talking about it - is SNMP over SIP.
 I kid you not.  Sort of makes me think of running IP over a DHCP
option, but heck anything's possible.

In summary, please let's be elegant.  Let's kill two birds with one
stone.  Let's make it easier on all of our customers in the future.  And
let's codify something that everyone else has been doing for years.

My connectivity will be sketchy for the next few days, but will continue
as best I can (although I don't want to beat a dead horse).

Eliot
ps: yes, I've offered to put this into real draft words for Dave.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Aug 2005 15:51:28 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "Wijnen, Bert (Bert)" <[email-masked]>; <[email-masked]>; "Margaret Wasserman" <[email-masked]>; "Andy Bierman"
<[email-masked]>
> Sent: Thursday, August 18, 2005 4:26 AM
> Subject: Re: [Isms] RE: Call for consensus and a proposal
...
> envisioned prior to that was a new security model using the existing UDP
...

Not so.  The TLSM proposal the evaluation team looked at in
http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt
explicitly provided for TLS/TCP as a transport.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2005 09:19:15 -0700

Hi Eliot,

I cc:ed the NETCONF WG because you are proposing changes to NETCONF over SSH
to the ISMS WG.

In theory, I agree with your goal of a single transport for both NETCONF 
and ISMS,
and I like your proposal.  If it had been on the table at the interim 
meeting where this
was all worked out,  I think it would have been selected the one and 
only NETCONF transport.

However, the NETCONF WG took a long time to decide on 3 different 
transports.
I don't really know how useful NETCONF over SOAP is going to be, but I 
bet a few
people would complain if we told them (at the last minute) that NETCONF 
over BEEP
is being removed. (It's not!)

Any new NETCONF features need to be done as proprietary extensions first,
shown to be useful in real operator environments, and then gain wide 
acceptance
from the WG.  I would support new NETCONF work today that met this criteria.

Andy