Re: ISMS working group

Eliot Lear <lear@cisco.com> Mon, 12 September 2005 07:45 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEizx-0003Kq-3D; Mon, 12 Sep 2005 03:45:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEizj-0003Cr-5t; Mon, 12 Sep 2005 03:44:59 -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 DAA01764; Mon, 12 Sep 2005 03:44:41 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEj3j-0002on-Od; Mon, 12 Sep 2005 03:49:01 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2005 00:44:19 -0700
X-IronPort-AV: i="3.97,98,1125903600"; d="scan'208"; a="340764635:sNHT39258956480"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8C7iDKC005887; Mon, 12 Sep 2005 00:44:13 -0700 (PDT)
Received: from [212.254.247.4] (ams-clip-vpn-dhcp4556.cisco.com [10.61.81.203]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8C7utRC011315; Mon, 12 Sep 2005 00:56:56 -0700
Message-ID: <432531CB.3070109@cisco.com>
Date: Mon, 12 Sep 2005 09:44:11 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Margaret Wasserman <margaret@thingmagic.com>
References: <431DD59A.4000400@ofcourseimright.com> <AE6514F0-4714-4A48-9F56-A155823489F2@moonhill.org> <p0620074bbf44d3d23a6d@[192.168.2.7]>
In-Reply-To: <p0620074bbf44d3d23a6d@[192.168.2.7]>
X-Enigmail-Version: 0.92.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1379; t=1126511818; x=1126944018; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20ISMS=20working=20group| From:Eliot=20Lear=20<lear@cisco.com>| Date:Mon,=2012=20Sep=202005=2009=3A44=3A11=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=O1nCeZU/6v4qnG25aKP2N1iwhMsP9ad/55XrzjAaeiOS7Ou1ccXOXD3AAuT6yMuXVoW4kaAd YZoyCUaAfsvX9iVRQvFgVYivswofrvnjVuT3F9xJ+au/HGMiah6ue3Q+baPUSy5iKxQwN+XDE2R SLVkUzw/e+8zLAS0GQ9XoqGI=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: Ken Arnold <arnold@moonhill.org>, ietf@ietf.org, iesg@ietf.org, Eliot Lear <lear@ofcourseimright.com>
Subject: Re: ISMS working group
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

Margaret,
> The call home solution doesn't help with the problem of the _manager_
> being behind a NAT.  It only applies to situations where the manager is
> at a fixed location on a globally-addressable network and the managed
> device is behind a NAT or firewall.

Actually, depending on how the solution is developed it certainly CAN
help the problem with the manager being outside a NAT.  But we are now
being somewhat loose with terms, so let me be more specific.

Consider the case where a manager is behind a firewall or NAT and the
device sits out in the open.  This could easily be an enterprise where
the network management station itself sits behind a firewall in order to
prevent/detect/respond to control attacks.

Now consider notifications.  The device will have no means to get a
notification to a manager unless a hole is specifically poked for the
purpose and the management station is in the same address space as the
managed device.

If the management station has initiated an SSH connection to the agent,
the agent can then initiate notifications over the SSH connection,
either by using the "snmp" application as a simple two way stream as
Harald suggests, or as a "turned" connection as I had suggested in the
first message on this thread (I think both approaches should be debated).

> BTW, the solution where you configure the NAT/firewall to admit the
> appropriate traffic could also be set-up to work properly when the
> manager is mobile and/or when the manager is gaining Internet access
> through a NAT.  "Call home" would not work in these situations.

And so your premise above not holding, the remainder of your argument
also does not hold.

Eliot

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