Re: ISMS working group and a clarification about Call Home

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

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjGV-0006GI-3p; Mon, 12 Sep 2005 04:02:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjGM-0006Cb-6T; Mon, 12 Sep 2005 04:02:06 -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 EAA02572; Mon, 12 Sep 2005 04:01:52 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEjKL-0003U1-G4; Mon, 12 Sep 2005 04:06:12 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2005 01:01:42 -0700
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 j8C81bKC012045; Mon, 12 Sep 2005 01:01:37 -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 j8C8EKna011403; Mon, 12 Sep 2005 01:14:21 -0700
Message-ID: <432535E0.1080709@cisco.com>
Date: Mon, 12 Sep 2005 10:01:36 +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: "Nelson, David" <dnelson@enterasys.com>
References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103258F@MAANDMBX2.ets.enterasys.com>
In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103258F@MAANDMBX2.ets.enterasys.com>
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=2119; t=1126512862; x=1126945062; 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=20and=20a=20clarification=20about=20Call= 20Home| From:Eliot=20Lear=20<lear@cisco.com>| Date:Mon,=2012=20Sep=202005=2010=3A01=3A36=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=NI0xi1j3RLxA8jkrKU/9FIEp0EegXRERaLSZcNO0x8pwbCJBDcnsW/mJUiA7wy/aVimb+wW9 /iSJSRBi2mjr6k2slxiLkfTKuuqsMhfKBgIbv1hZx6ofQ7ddpNbFFaGOoZsxgJ7NrQRkorH2kKv IchjXlm+Gw/ALIEcLRVtal1s=
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: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: ISMS working group and a clarification about Call Home
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

Hi David,

Nelson, David wrote:
> Let's assume, for the sake of discussion, that SNMP must always work
> across Firewalls and NATs.  The original objection to the proposed
> charter was that it did not include support for "Call Home"
> functionality.

First, let's be clear that nobody is suggesting that all connections
should be turned, but that sufficient flexibility must be available to
maneuver through firewalls and NATs.  But let me take this opportunity
to more clearly state why it is the functionality needs to work *both* ways.

A basic tenet of scalable fault management is something known as
trap-based polling.  That is, don't poll excessively (only a periodic
single heartbeat query) until some event event happens and then query as
much as necessary to determine more information.  So for instance, every
five minutes or so a query is made of the device and sysUptime.  But
then at some point an RMON event is triggered indicating that a
particular ifOperStatus has changed to down.  At that point the
management station might query for additional error counts off of the
IF-MIB, perhaps a SONET or ETHERLIKE mib, and perhaps other related
functions, the idea being to isolate the problem (and this probably is
not limited to a single device).

The problem is this: if a non-participating firewall or a NAT is in
place anywhere between the management station and the device, the
management station will either receive the trap but be unable to query
or only be able to query and NOT receive the trap.

The reason CH fixes this problem is that one way or another prior to a
failure, one can be assured that the management station and agent are
able to communicate both because connection direction is the same for
both functions.

> 
> I can see how Call Home would solve the NAT problem, at least on a
> sporadic basis.  The managed entity could initiate an "outgoing" NAT
> session to the management station, and the management station could use
> that connection as needed.  I don't see how this allows the management
> station to later initiate an "incoming" connection to the NAT'ed managed
> entity.  Nor do I see how it would enable firewalls to safely pass
> through only the desired SNMP traffic.

So, as described above, a management station would not initiate an
incoming connection to a managed entity but the other way around.  As to
your other question, this solution addresses the case where the firewall
is not capable of such functions.  This is the case for most commercial
firewalls today.

> Clarification would be helpful.  Thanks.

HTH,

Eliot

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