Re: ISMS working group
Margaret Wasserman <margaret@thingmagic.com> Wed, 07 September 2005 17:45 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3zg-00057L-7e; Wed, 07 Sep 2005 13:45:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED3ze-00055f-BZ; Wed, 07 Sep 2005 13:45:54 -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 NAA05414; Wed, 7 Sep 2005 13:45:53 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED42s-0005CG-1O; Wed, 07 Sep 2005 13:49:14 -0400
Received: from [66.30.121.250] (account margaret HELO [192.168.2.7]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 512387; Wed, 07 Sep 2005 13:47:48 -0400
Mime-Version: 1.0
Message-Id: <p0620074bbf44d3d23a6d@[192.168.2.7]>
In-Reply-To: <AE6514F0-4714-4A48-9F56-A155823489F2@moonhill.org>
References: <431DD59A.4000400@ofcourseimright.com> <AE6514F0-4714-4A48-9F56-A155823489F2@moonhill.org>
Date: Wed, 07 Sep 2005 13:44:17 -0400
To: Ken Arnold <arnold@moonhill.org>, Eliot Lear <lear@ofcourseimright.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: iesg@ietf.org, ietf@ietf.org
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
Hi Ken, 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. In those cases, the choices would be for the administrator to configure the NAT/firewall to admit his management traffic so that the manager can establish a connection to the device, or for the device to perform a "call home" function so that the device can establish a connection to the manager. 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. The only cases that I can see where "call home" is a better solution are when: (1) The NAT/firewall is not configurable to admit specific traffic, do static port mapping and/or to handle SSH tunneling. (2) The NAT/firewall (nearest to the agent) is not under the administrative control of the people who want to do the management. I'm not sure how often either of these cases really occurs on SNMP-managed networks in practice, but I think that is an interesting question. Margaret At 4:46 PM -0400 9/6/05, Ken Arnold wrote: >Firewalls are a ubiquitous feature of my everyday life, as is NAT. >My home is behind a NAT-ing firewall; my laptop has its own >firewall; every time I travel I rely on that firewall in hot spots >(such as starbucks); I run VirtualPC on my Mac, which has a firewall >and NAT translation; my parent's system is similar to mine: NAT-ing >firewall and on-system firewall for double protection (as are my >in-laws' and brothers' systems); my previous company had a NAT-ing >firewall for each ISP connection, and their product (a linux >cluster) had a firewall to protect itself from the customer's own >internal network. >Many small network appliances have firewalls (sometimes NAT-ing >ones) that protect themselves the same way. I could go on and on. > >Which means that any network solution -- let alone something as >potentially central as SNMP -- that ignores either NAT or firewall >-- is dead on arrival as far as I'm concerned, and as far as any IT >group I've ever seen is concerned. If there are non-firewalled >networks of consequence anymore I am unaware of them. Ignoring >these relegates any solution to theoretical situations or very small >in-home or in-group solutions. Then someone else will have to >figure out some way to manage anything larger scale, which will be >able to also handle small scale and so will overwhelm the >non-firewalling, non-NAT-ing designs. But only after such a >relatively impotent design confuses the world by adding yet one more >standard to chose from. > >Please get this right this time by including firewalls and NAT in >the solution space so it really *is* a solution. > > Ken > >P.S. Please also note that a non-firewalled SNMP creates some >pressure to bring down firewalls, to trade off SNMP for security. >Things that pressure networks to be less secure are pretty >antisocial in our current security environment of zombie spam farms, >etc. _______________________________________________ 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