Re: ISMS working group and charter problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]