Re: ISMS working group and charter problems

[Margaret Wasserman <[e-mail]>]

Hi Eliot,

[I am writing as a participant in ISMS and other SNMP-related WGs. 
This note is not intended to represent the reasoning that I would use 
ot make a decision about the ISMS charter in an IESG context.]

As you know, I disagree with your opinion that call-home 
functionality should be added to the ISMS charter for three reasons:

(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.

IMO, the ISMS group has one very important purpose:  Many people are 
using SNMPv1/v2 today and have not upgraded to SNMPv3 because of the 
(perceived) cost and complexity of deploying SNMPv3 security.  ISMS 
will integrate SNMP security with existing, widely-deployed security 
infrastructure such as SSH and RADIUS, so hopefully people will start 
using SNMP security.

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.

(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.

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?

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.

(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.

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?

If you do believe that this is a common need, I think that you will 
need to better define/explain your use cases.

Margaret


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf