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
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
