On Wed, 7 Sep 2005, The IESG wrote:
A modified charter has been submitted for the Integrated
Security Model for SNMP (isms) working group in the Security
Area of the IETF.
...
In order to leverage the authentication information already
accessible at managed devices, the new security model will
use the SSH protocol for message protection, and RADIUS for
AAA-provisioned user authentication and authorization.
However, the integration of a transport mapping security model
into the SNMPv3 architecture should be defined such that it is
open to support potential alternative transport mappings to
protocols such as BEEP and TLS.
The new security model must not modify any other aspects of
SNMPv3 protocol as defined in STD 62 (e.g., it must not create
new PDU types).
If (as I have gathered from the discussion over the past few days)
the last sentence quoted above means that it is out of scope for the
working group to even consider solutions that allow agents and
managers to work on either side of firewalls or NATs, then I think
that the charter is drawn too narrowly and should be revised.
Indeed, I think that it should be an explicit goal (if not a
requirement) for the solution to work even when one of the parties
(agent or manager) is unable to accept incoming TCP connections.
That issue will have to be addressed eventually, and it is better
for implementors to go through the churn once rather than twice.
Mike Heard
P.S. Note that I am using the words "agent" and "manager" in the
traditional sense, i.e., to mean "notification originator + command
responder" and "notification receiver + command generator"
respectively.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf