On Tue, 6 Sep 2005, Eliot Lear wrote:
All solutions will use a different SSH port as part of the standard just
so that firewall administrators have the ability to block.
FWIW, I'm a bit concerned as well. I don't see clearly which
scenarios you have in mind when you say you want better firewall/NAT
traversal capabilities.
In the scenarios I see, it's a Good Thing that as a network admin I
can block all [incoming] SNMP traffic (whether ISMS or not), and
moreover, that it's blocked by default if I create a typical policy; I
want to do that in the future too. Using a different port is
obviously the first step here.
But if a different port is being used, I don't see what more is
absolutely required.
Are you saying some of the following:
1) ISMS specs should specify that the monitored hosts can/should
certainly keep open a TCP session so the network management (in both
ways) can happen over that session. (This seems pretty trivial..)
2) We should specify how network management hosts could reside behind
a firewalls which block the management ports (I don't think this is
needed or should be done).
3) ISMS specs should specify network management hosts' capability to
poll hosts behind a firewall, which blocks incoming ISMS port by
default -- by using a mechanism where outgoing "I want to be monitored
using ISMS!" messages would open pinholes in the firewalls. (Is there
sufficient benefit in this compared to 1) as you still can't monitor
the hosts when you want to unless they are constantly polling you?)
Something else? Please be a bit more specific about what you think
the "NAT/FW problem" is in this context, and what you'd like to see
done about it.
(Personally, I'm not sure if I buy the whole ISMS thing at the moment,
because the operators AFAICT are sufficiently happy with the SNMPv1/2
security model -- so whatever you build, it has to be at least that
simple otherwise it won't be used.)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf