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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Aug 2005 11:42:58 +0200

All nice Eliot.
But I like you to be a bit more specific.

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.

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.

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.

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.

Sorry to bother you and get you to this (extra) work.
But I prefer that we are all clear on this topic which
seems to be such an important topic to you.

Bert

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Wednesday, August 17, 2005 08:11
> To: Wijnen, Bert (Bert)
> Cc: Nelson, David; [email-masked]
> Subject: Re: [Isms] RE: Call for consensus
> 
> 
> 
> 
> Wijnen, Bert (Bert) wrote:
> > Eliot, can you point out where people should look in
> > the Netconf Documents for the descritpion of the
> > "call home" function?
> 
> The functionality is (admittedly obliquely) described in the 
> BEEP draft
> (draft-ietf-netconf-beep-0?.txt) as well in the base BEEP 
> specification,
> which is RFC 3080.  The term "call home" is not used.  Rather "peer to
> peer" is made use of.
> 
> To be brief, the way this is accomplished in BEEP is via advertised
> profiles.  If a profile is advertised it can be used.
> 
> Another simple way to think about it is through the SMTP "TURN/ETRN"
> commands.  Yes, it goes that far back in our history - even 
> before NATs
> and firewalls, oddly enough.  Just part of the robustness 
> principle back
> then.
> 
> Eliot
> 

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Aug 2005 07:39:27 +0200

Good morning, Bert.

I'm sorry for the delayed response- out sick yesterday.  Please see below.

> definition, so we all know what we're talking about is

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

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

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

> 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: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2005 16:43:50 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

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

    Eliot> "Call home" is the act of the managed element initiating
    Eliot> the transport connection to the manager for the purpose of
    Eliot> being managed in some way.  An example of a "call home"
    Eliot> function would be any of the various update mechanisms in
    Eliot> your Microsoft Windows / Apple / SuSE Linux software update
    Eliot> services.
    >> provides it. That makes it much easier for me to map the
    >> concept onto things I know.

    Eliot> The current SNMP does not provide this function.  

Hi, Eliot.  Based on this discussion I'm going to have to rule call
home functionality out of scope for ISMS.  Please understand that I am
not expressing any opinion on its desirability as an SNMP feature.
I'm making a process decision in the interest of making forward
progress within this working group.  I would also like to suggest a
path to you in order to pursue adding call home functionality to the
scope of this working group without disrupting the process.

I'd like to draw your attention to our charter:

     A solution must not modify the other aspects of SNMPv3 protocol as
        defined in STD 62 (EG, it must not create new PDU types). It should
           also be compliant with the security model architectural block of
              SNMPv3, as outlined in RFC 3411. And if at all possible, it should
                 also not change any other protocols either.

It seems clear to me that adding a new architectural element such as
call home falls outside that charter.

In particular, I believe the following is out of scope:

* Using call home support as an evaluation criteria  for ISMS proposals.

* Including call home  in the ISMS charter  presented to the IESG

* Blocking consensus on issues in ISMS for issues that are exclusively
  about call home. 

* Blocking forward progress on documents until call home issues are
  resolved.

I want to make it clear that I am not making any decisions regarding
some related issues:

* Whether we understand the ssh proposal well enough to have a
  consensus on it.

* Whether we need a proposal in addition to a primary focus.

* Identity mapping for notifications.

* Whether notification and other traffic can be carried over the same
  session.

Also, I encourage you to work with the authors of the ssh draft to
investigate how to perform call home in the ssh draft.  You can feel
free to ask for my technical input if you feel it would be useful;
I'll try to give it on a time available basis.  You should also
continue your investigation of call home in the beep proposal.

So, if I'm ruling this out of scope, how do you get it in scope?  I
think you need to convince the IETF community--the same folks that
placed the restriction on us that we not modify SNMP.  I think you
need to do so in a way that does not disrupt our forward progress if
you fail to convince them.  Here's how I think you should go about it.

When the charter is sent to me for IESG review, ask me to send it out
for external review (IETF wide) rather than just approving it; I will
honor such a request.  You will need a proposal ready to present to
the community when the charter comes out for review.  The proposal
should include proposed modifications to the charter to make call home
in scope.  In addition you probably want to answer the following
concerns:

* People believe that architectural changes to SNMP should happen in
  the management not security area.  Either convince them that this is
  OK in the security area, propose moving the working group, or
  propose splitting the work appropriately.

* Address the concerns about the lack of MIBs and other facilities for
  managing call home.  Have a proposal ready for what is involved in
  doing the work.

* Understand concerns Bert is likely to raise and respond to them.

I believe that this will create a balance between your desire to have
your proposal heard and our desire to make forward progress without
blocking on your proposal.

I'm happy to answer any questions the chairs have in implementing
these decisions.  I'm also happy to answer any questions you have.
Finally, if I've overlooked something and have not managed to provide
you with a fair opportunity for your proposal to be heard and
considered please let me know what I have missed.

Sam Hartman
Security Area Director

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Aug 2005 15:06:13 +0200

Understand, Sam, that what I care about are the following factors:

 - providing a mechanism that is useful to the operations community

 - properly making use of existing standardized components

 - minimizing the number of redundant components

I look at this from a systems perspective.  One protocol is but a piece
of that system.

If in the end it looks as though you, the WG, or the IESG is ignoring
these principles (as it appears now), I will appeal as is appropriate.

> call home falls outside that charter.

I would ask that you please explain to me how you came to this
conclusion.  Further, I ask that you explain what work would have to be
done for "call home" functionality that would NOT have to be done
otherwise such that it is out of scope.

> * Blocking forward progress on documents until call home issues are

I suggest to you that since the working group is not chartered at this
time to write protocol documents (you prohibited that at IETF 62), such
a restriction is not reasonable until a new charter is approved.  If you
agree to drop this restriction, I will in turn agree to (a) not appeal
your decision, (b) continue to work with Dave Harrington on the draft he
is developing, and (c) following the process you've laid down until the
new charter is approved.

If at the time of documents' last call to both the working group and the
IETF we have not resolved these matters, I will raise my concerns again,
as I currently believe we are building a car with two different wheel
sizes.  This includes draft-ietf-netconf-ssh-0[45].txt, which I now
believe to be incompatable with the current direction of the ISMS
working group.  It can and should be corrected.

Again, I stress that I will work with Dave and the NETCONF folks as well
to correct the matter.

Eliot