Re: [Isms] ISMS charter broken- onus should be on WG to fix it

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 14 September 2005 01:15 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLsN-0002sU-Is; Tue, 13 Sep 2005 21:15:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFLsL-0002q6-EA; Tue, 13 Sep 2005 21:15:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14006; Tue, 13 Sep 2005 21:15:47 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFLwq-0000pL-Rd; Tue, 13 Sep 2005 21:20:29 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa08198; 13 Sep 2005 21:14 EDT
Date: Tue, 13 Sep 2005 21:14:11 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Ned Freed <ned.freed@mrochek.com>
Message-ID: <BD0A024BD83DCDA8FD12C65E@sirius.fac.cs.cmu.edu>
In-Reply-To: <01LSZP7AGR0Y000092@mauve.mrochek.com>
References: <200509131506.j8DF664A016810@pacific-carrier-annex.mit.edu> <tslhdcokeed.fsf@cz.mit.edu> <20050913204555.GA14153@boskop.local> <tslbr2wk78f.fsf@cz.mit.edu> <3C03BDBD60783D559EDAE652@sirius.fac.cs.cmu.edu> <01LSZP7AGR0Y000092@mauve.mrochek.com>
Originator-Info: login-token=Mulberry:01PUlmoKex2xSJlN4hcMeWD9S7ncvEfd+qvpQFc8k=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: david.kessens@nokia.com, isms@ietf.org, iesg@ietf.org, 'Eliot Lear' <lear@cisco.com>, Sam Hartman <hartmans-ietf@mit.edu>, ietfdbh@comcast.net, 'IETF Discussion' <ietf@ietf.org>
Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


On Tuesday, September 13, 2005 05:23:26 PM -0700 Ned Freed 
<ned.freed@mrochek.com> wrote:

>> > I suspect that the ssh community would decline to extend ssh in this
>> > direction; I certainly know I would not support it.
>
>> I'm not entirely sure _how_ I'd extend SSH in this direction, or how much
>> utility it would have.  I don't think I would object to it, especially
>> since I suspect it might make some of the ISMS cases easier even if you
>> don't care about the firewall problem.
>
> Well, the ssh client I use has the ability to do port forwarding in both
> directions already. The only thing that has stopped me from using this
> feature
> to do SNMP monitoring of various mobile agents is that it doesn't work
> with
> UDP, and the SNMP stuff I use is UDP only.

Aha!  Another use case for UDP tunnelling in SSH, which is a topic that was 
recently brought up in that WG.

In any event, the problem isn't carrying the SNMP traffic over an ssh 
connedction -- we're fairly confident we know how to do that, though the 
document isn't done yet.  The problems are in determining when to establish 
an SSH connection for the purpose of _receiving_ traffic, and in making 
authentication work in cases where a managed device wants to authenticate 
to something that is essentially a user.  With some authentication 
infrastructures the latter is easy; with others it is not.  The former I 
think is always hard, but has nothing to do with SSH per se.

I think that we can easily avoid making call-home harder than it needs to 
be, and that we should.  I would not object to a change in ISMS's charter 
requiring that it consider the potential effects of any security solution 
it adopts on the ability to add a call-home mechanism, but I also don't 
think such a provision is necessary to achieve the desired result.

I don't think extending the SNMP architecture to add call-home is within 
the scope of ISMS's charter, and I don't think it would be appropriate to 
add it at this time.  I'm not quite as concerned as Margaret is about the 
"wrong area" problem, provided the right people are active in the WG and 
reviewing its output, which I believe is necessary in any event.

However, I do believe the problems are separable, nearly orthogonal, and 
require somewhat different expertise.  Provided that the ISMS work does not 
preclude call-home or some other solution to the problem, I think a 
narrowly-scoped working group is appropriate here.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf