Subject: RE: ISMS working group

From: "Nelson, David" <[email-masked]>
Date: Thu, 8 Sep 2005 14:41:19 -0400

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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Daniel Senie <[email-masked]>
Date: Thu, 08 Sep 2005 16:38:23 -0400

>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.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 10:01:36 +0200

Hi David,

> charter was that it did not include support for "Call Home"

First, let's be clear that nobody is suggesting that all connections
should be turned, but that sufficient flexibility must be available to
maneuver through firewalls and NATs.  But let me take this opportunity
to more clearly state why it is the functionality needs to work *both* ways.

A basic tenet of scalable fault management is something known as
trap-based polling.  That is, don't poll excessively (only a periodic
single heartbeat query) until some event event happens and then query as
much as necessary to determine more information.  So for instance, every
five minutes or so a query is made of the device and sysUptime.  But
then at some point an RMON event is triggered indicating that a
particular ifOperStatus has changed to down.  At that point the
management station might query for additional error counts off of the
IF-MIB, perhaps a SONET or ETHERLIKE mib, and perhaps other related
functions, the idea being to isolate the problem (and this probably is
not limited to a single device).

The problem is this: if a non-participating firewall or a NAT is in
place anywhere between the management station and the device, the
management station will either receive the trap but be unable to query
or only be able to query and NOT receive the trap.

The reason CH fixes this problem is that one way or another prior to a
failure, one can be assured that the management station and agent are
able to communicate both because connection direction is the same for
both functions.

> through only the desired SNMP traffic.

So, as described above, a management station would not initiate an
incoming connection to a managed entity but the other way around.  As to
your other question, this solution addresses the case where the firewall
is not capable of such functions.  This is the case for most commercial
firewalls today.

> Clarification would be helpful.  Thanks.

HTH,

Eliot