Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Ned Freed <[e-mail]>]

> On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman
> <[e-mail]> wrote:

> >>>>>> "Juergen" == Juergen Schoenwaelder <[e-mail]>
> >>>>>> writes:
> >
> >     Juergen> Sam,
> >
> >     Juergen> this is not about blocking port 22 as far as I understand
> >     Juergen> things. I think the issue here is that TCP connection
> >     Juergen> establishment determines ssh client/server roles.  If
> >     Juergen> there would be a way to initiate the connection but
> >     Juergen> subsequently taking over the server role, protocols like
> >     Juergen> netconf and presumably isms would find it much easier to
> >     Juergen> provide CH functionality.
> >
> > Right.  But for the ssh-connect application I don't think you would
> > want that unless you were trying to get around firewall policy.

> I don't think that's necessarily the case. Sure, you might be trying to do
> that, but you also might be trying to get around the fact that the machines
> at your house are behind a NAT and thus lack routable addresses.

Or consider the case of a firewall whose policy is simply one where incoming
connections are not allowed for fear of worms infecting vulnerable systems. The
only way to monitor systems behind such a firewall is to have them establish
outgoing connections. Such behavior is in no way, shape or form a violation of
that firewall's policy, yet it is necessary to work properly in such a (very
common) firewalled environment.

More generally, every protocol we define, every enhancement to a protocol we
specify, and every operational policy we advocate has the potential of being
used to "get around firewall policy" in some situation or other.  And this is
especially true when we're defining protocols that provide some form of
confidentiality, which of course we do more and more frequently. This is the
nature of the beast, like it or not. Were we to use this as a criteria not to
proceed with our work we might as well all go home.

Furthermore, the fact of the matter is that specifying how something is
supposed to be done tends to aid in establishing useful firewall policies far
more than it hurts. People are going to use the "call home" approach for
monitoring whether we like it or not - it is just too useful for them not to.
And absent a specification it will be done in a zillion incompatible ways and
without any real understanding of the security issues. And unless firewall
operators are prepared to block absolutely everything (which of course they
cannot) they don't stand a chance in hell of controlling such services. A
timely specification, on the other hand, could simultaneously raise awareness
of the security issues as well as provide some measure of consistency in such
traffic, in turn allowing some measure of control.

And make no mistake about it: When it comes to call home services, the
situation is already dire. Only yesterday I observed a popup from a piece of
video processing software I use informing me that a new version is now
available. Obviously this application had just "called home" and found out
about the new version. Hopefully that's all it did - nowhere in the product
documentation does it mention it would do this, nor is there any preferences
setting I can find to tell it not to. 

If I were to object to Eliot's proposal (I don't - in fact I strongly support
it), it would be on the grounds that the IETF should be taking a long hard look
at the issues surrounding call home in general, not just in the special case of
SNMP.

> > I suspect that the ssh community would decline to extend ssh in this
> > direction; I certainly know I would not support it.

> I'm not entirely sure _how_ I'd extend SSH in this direction, or how much
> utility it would have.  I don't think I would object to it, especially
> since I suspect it might make some of the ISMS cases easier even if you
> don't care about the firewall problem.

Well, the ssh client I use has the ability to do port forwarding in both
directions already. The only thing that has stopped me from using this feature
to do SNMP monitoring of various mobile agents is that it doesn't work with
UDP, and the SNMP stuff I use is UDP only.

				Ned

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