Re: ISMS working group and charter problems

At 12:26 AM +0200 9/7/05, Harald Tveit Alvestrand wrote:
>I believe that the ISMS WG's proposal is about ADDING the 
>possibility of SNMP over TCP, not about CHANGING SNMP to use TCP.
>UDP will still work.

That is correct.  UDP and the current SNMPv3 USM security mechanisms 
will still work.  They will also remain mandatory parts of SNMPv3.

>And I believe Eliot's concern is about letting the TCP session that 
>carries the SNMP PDUs be opened from the agent to the manager, 
>rather than from the manager to the agent (yes I know - this is 
>SNMPv1 terminology, but I've forgotten the SNMPv3 terminology); that 
>is another feature that comes in addition to what the group is 
>apparently currently working on.
>And just BTW: I find "call home" reasonable to specify too, once 
>you've done TCP. It's obvious enough that I think it will be added 
>to implementations whether or not we specify it, so we should have 
>very strong reasons not to do so.
>I don't even believe you need to "turn" the session, since SNMPv3 
>doesn't recognize the concept of a "direction" for a session.... 
>just let the PDUs flow....

Unless I am seriously misunderstanding something, this is a bit more 
complicated than you and Eliot seem to think that it is...  The 
command responder (agent) is a stateless piece of software that 
simply responds to queries as they are received.  It has no way to 
anticipate when queries will be received, and no concept of what 
other systems it would like to receive queries from.  So, where would 
it get the information necessary to open a connection to the manager? 
How would it know what to do if the manager could not be reached? 
How would it know when he connection should be taken down?

Now, I am not saying that I couldn't come up with an answer to these 
questions -- it seems likely that we'd have to grow another SNMP MIB 
that would control how/when/if the command responder would attempt to 
establish a communication connection with the command generator, etc. 
I agree that SNMP over TCP might be an important element of this 
solution, but it is already defined in RFC 3430.  So, if there really 
is sufficient interest in adding call home capability to SNMP, I 
don't see why the IETF couldn't do this work.

But, why does anyone think that we should do this work in the 
Security area in a WG that is tasked with integrating the SNMP 
security model with SSH and RADIUS?

Margaret

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf