Re: ISMS working group and charter problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 08, 2005 at 03:30:28PM -0400, Sam Hartman wrote:

> Note that the mandatory to implement solution for netconf is based on
> ssh and does not support call home.

1) I see lots of people using tools like MIB browsers, snmp command line
   tools called from fancy scripts, monitoring packages such as cacti
   and nagios (these were even used on the IETF network in Paris if I
   recall correctly) and all these packages share the feature that the
   "manager" does not have a fixed transport address but takes the
   initiative to talk to an "agent" when there is need to do so. In
   other words, all these existing and deployed applications simply
   won't work with call home easily since they would require to
   implement some rather magic logic to dispatch SNMP traffic via
   a locally centralized connection manager.

2) It is important to talk about ssh and to not reduce the problem to
   just TCP. As far as I understand ssh, authentication is not
   symmetric because ssh has a clear buildin client/server role
   (servers authenticated via host keys while clients are 
   authenticated via passwords or publickey mechanisms).
   So in the context of ssh, it does have quite some impact who
   establishes the transport connection. (Unless there is a "turn"
   feature in _ssh_. I am not aware of such a mechanism, but I am
   happy to learn.)

3) For those not following ISMS closely, it might be useful to know
   that originally was another proposal (EUSM) which tried to build on
   USM messages and tried to integrate USM with AAA infrastructures.
   This approach did have some rough support but did melt down because 
   of some inappropriate use of EAP. (I can't explain the details since
   I never really understood the _technical_ concern.) Once EUSM was
   off the table, the WG converged to SSH for a very simple reason:
   SSH is already on many routers/bridges/hosts and you find it even
   on power strips these days. Netconf also requires SSH as the
   mandatory to implement transport. Hence, using SSH as a unifying
   mechanism to securely access the various management interfaces
   on a box has some promises wrt. ease of deployment.

I agree with those who said that CH is an architectural change and I
have yet to see a concrete proposal how CH via ssh can be achieved.

/js

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

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]