Subject: Underspecified CallHome

From: Balazs Lengyel <[email-masked]>
Date: Fri, 02 Jun 2006 17:08:56 +0200

Hello,
It was stated a number of times that call-home is underspecified. I would like to work on 
  that a bit.
Please could you make a short list of things you believe should be specified for call home!
Balazs

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 08:42:11 -0700

Balazs Lengyel wrote:
> Hello,
> It was stated a number of times that call-home is underspecified. I 
> would like to work on  that a bit.

   - data model to NV-configure an agent to call home
   - capability for callhome (fully specified capability template
     defined in prot-12, Appendix C)
   - agent needs to convey reason for connect when calling home
     (operations or notifications or ?)
   - NV-configure multiple (ordered) managers to call
   - callhome agent protocol procedures
   - callhome manager protocol procedures
   - manager fail-over procedure (agent reconnects to new manager)

> Balazs

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Jun 2006 22:42:01 +0200

On Fri, Jun 02, 2006 at 04:29:48PM -0400, Phil Shafer wrote:
 
> BEEP handles the device-initiated connection easily, and one can
> use 'sshd -i' on the device side to pass a device-initiated connection
> into the ssh daemon code, allowing us to preserve the existing
> client/server relationship in netconf.  I'm clueless about how soap
> would handle this.

While I love the simplicity of this approach (agent establishes the
TCP connection and once established it takes over the SSH server
role), I had the feeling that security folks seriously disliked it
during the ISMS discussions. Instead, they seemed to prefer something
where you have to use host-key authentication and you end up with
different notions of access control rules since you have different
authenticated identities to deal with.

I like to see a common approach to deal with "agent" initiated
connections between netconf and ISMS and as I said I love the
simplicity of what you propose for netconf...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Phil Shafer <[email-masked]>
Date: Fri, 02 Jun 2006 16:29:48 -0400

>   - data model to NV-configure an agent to call home

The config needed to get a device to call home is might
well be device specific.

>   - callhome manager protocol procedures

The big job here is getting the protocol mappings for reverse
direction connections, and having a mechanism to uniquely identify
the device to the app.

As far as device identification, the device's ssh host-key (or its
fingerprint?) should suffice.

>     (operations or notifications or ?)

For this, I was imagining a specific log, where the newly connected
manager could do a simple RPC saying "Who dares to disturb the great
and powerful Oz?"  The reply would be a list of recent reasons the
device has called home, which the manager can inspect to find both
the current reason (the last one on the list) and the past reasons
(to see if any were lost).

Thanks,
 Phil

---

From: Steve Berl <[email-masked]>
Date: Fri, 02 Jun 2006 13:13:30 -0700

> client/server relationship in netconf.  I'm clueless about how soap

DSL Forum TR-069 has this already. It be valuable to steal from there.

> (to see if any were lost).

Again, TR-069 specifies that the first message that the device sends is an
Inform, which includes the reason for the call.

-steve

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Jun 2006 22:32:42 -0700

> simplicity of what you propose for netconf...

Yes.  Ditto for endless-RPC.
One more and I guess you win a prize :-)

Since I'm an embedded C programmer, I have a permanent bias
towards simplicity.  The art of engineering is keeping the
inherent complexity as low as possible (which is like entropy;
once introduced, it can never be removed from the system ;-)

(I will refrain from ranting on IETF security protocol usage
and documentation requirements.  Not simple.)

Andy

---

From: "Kent Watsen" <[email-masked]>
Date: Tue, 6 Jun 2006 11:44:38 -0700

>The config needed to get a device to call home is might

At first I was hopeful that a standard agent-configuration model could
be imposed on all devices, but than realized that devices have wildly
different approaches towards how they enable services on interfaces.
However, it might make sense to standardize a "virtual
agent-configuration" - that is, a top-level node using the
netconf-namespace that if read-from or written-to would trigger the
device to adapt to/from its internal model.  My assumption is
<get-config> would not return this virtual-configuration without a
filter, but it would return the device-specific configuration for the
same. 

> fingerprint?) should suffice.

This only works if there is a chance to float the host-key beforehand,
which isn't possible when the customer receives the equipment directly
from manufacturing and uses an NMS-supplied script to bootstrap its call
home.  A resolution to this is to also configure the agent with
NMS-supplied ID/OTP (one-time password).  Thus, immediately after the
agent-initiated TCP session is established and before passing the
connection to `sshd -i`, the device can send a TCP message containing
its ID, host-key, and the HMAC of its host-key using the OTP.  The NMS
can use the ID to do a database lookup for the device's record, which
should contain the same OTP, which it can use to authenticate the
host-key.  Then the NMS can initiate an SSH-client on top of the
already-established TCP session and authenticate itself to the device
(i.e. login) at which time the device can clear the OTP from its
configuration.

Kent