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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf