RE: ISMS working group

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf