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

Sam Hartman <> Tue, 13 September 2005 21:06 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EFHzI-0006p6-9F; Tue, 13 Sep 2005 17:06:44 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EFHzF-0006oS-JP; Tue, 13 Sep 2005 17:06:41 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id RAA27074; Tue, 13 Sep 2005 17:06:38 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.43) id 1EFI3h-0001Li-Rx; Tue, 13 Sep 2005 17:11:19 -0400
Received: by (Postfix, from userid 8042) id 3F667E0049; Tue, 13 Sep 2005 17:06:40 -0400 (EDT)
References: <> <> <20050913204555.GA14153@boskop.local>
From: Sam Hartman <>
Date: Tue, 13 Sep 2005 17:06:40 -0400
In-Reply-To: <20050913204555.GA14153@boskop.local> (Juergen Schoenwaelder's message of "Tue, 13 Sep 2005 22:45:55 +0200")
Message-ID: <>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc:, 'IETF Discussion' <>,, 'Eliot Lear' <>,
Subject: Re: [Isms] ISMS charter broken- onus should be on WG to fix it
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>>>>> "Juergen" == Juergen Schoenwaelder <> writes:

    Juergen> Sam,

    Juergen> this is not about blocking port 22 as far as I understand
    Juergen> things. I think the issue here is that TCP connection
    Juergen> establishment determines ssh client/server roles.  If
    Juergen> there would be a way to initiate the connection but
    Juergen> subsequently taking over the server role, protocols like
    Juergen> netconf and presumably isms would find it much easier to
    Juergen> provide CH functionality.

Right.  But for the ssh-connect application I don't think you would
want that unless you were trying to get around firewall policy.

I suspect that the ssh community would decline to extend ssh in this
direction; I certainly know I would not support it.

I would support setting up port forwarding as a way to get a back
channel; I would also support a facility to run an ssh protocol over
ssh channel.

One advantage of both port forwarding and ssh over ssh is that they
provide a much more consistent model for authentication and
authorization of the request to "turn" than an explicit turn facility.


Ietf mailing list