Re: ISMS working group and charter problems
Eliot Lear <lear@cisco.com> Mon, 12 September 2005 06:43 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEi2J-00010n-9X; Mon, 12 Sep 2005 02:43:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEi29-0000zS-Sq; Mon, 12 Sep 2005 02:43:25 -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 CAA29206; Mon, 12 Sep 2005 02:43:08 -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 1EEi6A-0001HV-Ie; Mon, 12 Sep 2005 02:47:27 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2005 23:43:00 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j8C6gvuk016376; Sun, 11 Sep 2005 23:42:57 -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 j8C6tcCA011061; Sun, 11 Sep 2005 23:55:38 -0700
Message-ID: <4325236D.7070007@cisco.com>
Date: Mon, 12 Sep 2005 08:42:53 +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: <20050906231355.7FBD73BFD6F@berkshire.machshav.com> <431E7EA7.3030005@cisco.com> <p0620073abf4489a3eaca@[192.168.2.7]>
In-Reply-To: <p0620073abf4489a3eaca@[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=4440; t=1126508140; x=1126940340; 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=20charter=20problems| From:Eliot=20Lear=20<lear@cisco.com>| Date:Mon,=2012=20Sep=202005=2008=3A42=3A53=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=ZFpoGhRGfHo/jYaHV0pZ4ezsADYASARU7O2UFGOjhNiyFvoQ0qQJuvvdrMGsCPDywUMTp0TC GrmGMh+g3XfNqLOA/YTCHvuNp49IRq6H01sJeMJRJZl0EOfmu33nkqXirZfS8j5gX4DB2Y5DqNu fGh4CNwN5wEA4ylC8OD26mb4=
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: 7fa173a723009a6ca8ce575a65a5d813
Content-Transfer-Encoding: 7bit
Cc: nanog@merit.edu, IETF Discussion <ietf@ietf.org>, iesg@ietf.org
Subject: Re: ISMS working group and charter problems
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, My apologies for my delayed response. I've been away. The timing of this charter review was unfortunate. > (1) I don't think that call home fits within the scope of the ISMS > group. I am not necessarily saying that we shouldn't do this somewhere > in the IETF, just not in this WG. > > This is a security area WG. It is not charged with producing a > next-generation of SNMP, just with the (important) task of integrating > the current generation of SNMP with more widely-deployed security > mechanisms. I personally think that tightly-scoped WGs are good. I > also think that it would be inappropriate to add new architectural > features to SNMP in a security area WG. How many times shall we change SNMP? ISMS will represent a substantial change, no matter how it is done. There will be a new packet format, and there will be a new authentication architecture for SNMP. Whether or not somebody's idea of an architecture for SNMP is changed at this point is irrelevant. All tools that use this solution will change. Doing yet another round of changes to accomplish CH will cause a continuously unstable network management standard for some period to come. It is at best an overly bureaucratic reasoning that says that X work has to be done in X area when Y group has already opened the protocol in Y's area. As I've previously written, all the interest parties from the O&M area have been in the room. As others have written, CH requires security review. What, then, is the problem? > > (2) I do think that call home represents a significant architectural > change to SNMP, for the same reasons that Randy Presuhn has offered. I'd > also like to emphasize one of his points -- we have already defined how > SNMP runs over TCP (in RFC 3430), so ISMS is not the first group to > consider this. Running SNMP over TCP did not require the types of > operational changes that you are discussing. Beyond what I wrote above, as others have written, a substantial architectural change is moving from packet based to session based security. Furthermore, had I been paying attention to the SNMP over TCP discussions at the time I would have raised this concern at that time. > IMO, the idea of an SNMP command responder (agent) initiating the > communication is not as simple as you have portrayed it. There are many > open questions, like: How would the command responder know what > manager(s) to contact? When should the command responder try to initiate > the communication? How often should it re-try if the initial contact > fails? What should it do if the connection drops? These are valid questions, and worthy of discussion. They are not insurmountable questions, however. I could right now give you my own proposed answers for each of these, but I propose that they are best answered in a working group! > > SNMP command responders are stateless entities that simply respond to > the queries they receive in the order that they receive them. Changing > them so that they can initiate and effectively manage a communication > connection to the manager is a pretty big change, IMO. No it is not. All that is required is an understanding that responses to a manager will travel via a pre-established SSH connection. For example (and only example), we have an SNMP-TARGET-MIB that already identifies in the case of a notification the method to communicate. Conveniently the aforementioned TCP communication has great examples of precisely how to populate this MIB in its appendix. > > (3) I am not certain that there are a large number of people who want to > initiative SNMP management communication through a NAT/Firewall who do > not have the ability to allow/tunnel an SSH connection through that same > NAT/Firewall. I believe you are conflating two issues here. The first is that one can use SSH tunneling over which to route SNMP queries or responses. The second is the ability to cause the remote command generator to use that tunnel. > > In my experience, NATs and Firewalls are usually placed at the > boundaries of an administrative area. In many cases, they are > intentionally used to prevent access to internal systems from the > outside. I have not run into many cases where a network administrator > has wanted to allow management access to systems from outside of the > local network, but perhaps you have? I have, as has Eric, as have the many others who have written to you to say this at this point. Any overlay network or service provider that wishes to offer a managed service to his or her customer will have run into this problem. Any enterprise with mobile devices will run into this problem, particularly with phones. Now you can say that enterprises should simply bring up VPNs to solve the problem, and while that's likely to sell more Cisco hardware, it may not be the right solution for everyone, particularly if the phones are managed by a vendor. > > If you do believe that this is a common need, I think that you will need > to better define/explain your use cases. Margaret, I'm surprised that the one use case I mentioned in my original note did not resonate with you. If you run Windows or MacOS or most commercial variants of Linux your own computer already calls home to have certain functions managed. Why is it so difficult to believe that a device within a network would want to accomplish the same objective with the existing SNMP framework? Eliot _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Daniel Senie
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Pekka Savola
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- RE: ISMS working group and charter problems Thomas Gal
- RE: ISMS working group and charter problems Daniel Senie
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- RE: ISMS working group and charter problems Thomas Gal
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Randy Presuhn
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Harald Tveit Alvestrand
- Re: ISMS working group and charter problems Dave Singer
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Brian E Carpenter
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Jari Arkko
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Jari Arkko
- Firewall considerations (Re: ISMS working group a… Harald Tveit Alvestrand
- Re: ISMS working group and charter problems Melinda Shore
- Re: ISMS working group and charter problems Margaret Wasserman
- Re: ISMS working group and charter problems Margaret Wasserman
- Re: ISMS working group and charter problems Michael Thomas
- Re: ISMS working group and charter problems Margaret Wasserman
- Confusion about ISMS rechartering Sam Hartman
- Re: Confusion about ISMS rechartering Dave Crocker
- RE: ISMS working group and charter problems Fleischman, Eric
- RE: ISMS working group and charter problems Fleischman, Eric
- RE: ISMS working group and charter problems Margaret Wasserman
- RE: ISMS working group and charter problems Fleischman, Eric
- Re: ISMS working group and charter problems Spencer Dawkins
- Re: ISMS working group and charter problems Michael Thomas
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Daniel Senie
- RE: ISMS working group and charter problems Nelson, David
- Re: ISMS working group and charter problems Tom Petch
- Fwd: ISMS working group and charter problems Rich Morin
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Wes Hardaker
- ISMS working group and charter problems Brent Chapman