At 02:41 PM 9/8/2005, Nelson, David wrote:
Let's assume, for the sake of discussion, that SNMP must always work across Firewalls and NATs. The original objection to the proposed charter was that it did not include support for "Call Home" functionality. I can see how Call Home would solve the NAT problem, at least on a sporadic basis. The managed entity could initiate an "outgoing" NAT session to the management station, and the management station could use that connection as needed. I don't see how this allows the management station to later initiate an "incoming" connection to the NAT'ed managed entity. Nor do I see how it would enable firewalls to safely pass through only the desired SNMP traffic. Clarification would be helpful. Thanks.
Especially in the case of UDP traffic, there is no clear distinction between packets leaving a NAT-protected environment and packets coming in, for a particular association. So if the device that "calls home" sends a heartbeat packet once a minute or every 15 seconds or whatever, the NAT device will keep an association ("connection" doesn't really cut it for describing a UDP conversation) open. The management station would then be able to initiate a request to the managed entity, provided the managed entity accepted new requests on the same port it was using for heartbeats. Note that EVERYTHING in this paragraph applies equally to firewalls doing stateful packet inspection using publicly routable IP addresses.
Implementing call home functionality over SSH would provide a connection that is likely to be nailed up, and re-established automatically whenever it drops for any reason. Otherwise, the expense of setup and tear-down of TCP sessions and SSH keying on the management platform would probably become a concern in large deployments. If a channel exists for sending information over SSH to the management platform, then a channel exists for information in the other direction too. Even if the connection is NOT nailed up, but only comes up for status information and heartbeats, there's still an opportunity to have a command queue of waiting messages destined for the managed device.
Such functionality is potentially useful. It certainly has the ability to bypass NAT and/or firewall functionality, which is a serious concern. Equipment vendors certainly like the concept of hardware that calls home. Stratus Computer did this starting in the early 1980s (using 2400 baud modems, as that was the technology that was reliable in that era). Others have done it as well. There are some ethical and perhaps even liability issues involved too, however. If you use a "call home" function to set up a communication path into a a customer's network (e.g. a router vendor trying to track licensing on products they sell to a company), and the server(s) at the vendor get infected resulting in a breakin at the customer's site, the vendor may be in trouble. If the customer didn't know and approve the product calling home, the customer might not be aware of the potential for that security breach. That too could be a significant problem.
I'm not taking sides over whether call home should be in ISMS or not, but it's certainly something that should be thought through carefully before implementing systems that do these things.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf