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
- Re: ISMS working group Margaret Wasserman
- ISMS working group Ken Arnold
- Re: ISMS working group and charter problems Jim Thompson
- Re: ISMS working group Ken Arnold
- RE: ISMS working group Fleischman, Eric
- RE: ISMS working group Nelson, David
- RE: ISMS working group Daniel Senie
- Re: ISMS working group Eliot Lear
- Re: ISMS working group and a clarification about … Eliot Lear
- Re: ISMS working group Margaret Wasserman
- Re: ISMS working group Eliot Lear
- Re: ISMS working group Eliot Lear
- Re: ISMS working group Margaret Wasserman
- Re: ISMS working group Daniel Senie
- Re: ISMS working group Eliot Lear
- Re: ISMS working group Eliot Lear
- Re: ISMS working group Wes Hardaker
- Re: ISMS working group Brian E Carpenter