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

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Sep 2005 14:31:54 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi, Personally, I'd rather see the issue of working through
    David> NATs and firewalls solved at the SSH level, and then SNMP
    David> and other SSH-using applications, such as Netconf and CLI,
    David> could use the solution in a consistent manner.

I think that the ssh connection application already has a fairly
reasonable story for NATs and firewalls, so I don't see much of a need
for ssh itself to advance in this area.  

For the most part people who block port 22 really do intend to block
ssh and so having standard facilities to get around that would not be
appropriate.  The port forwarding support in ssh seems to be an
adequate solution for NATs.

SNMP can use these facilities certainly.  However you may want/need a
more automated solution.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2005 22:45:55 +0200

> adequate solution for NATs.

Sam, 

this is not about blocking port 22 as far as I understand things. I
think the issue here is that TCP connection establishment determines
ssh client/server roles.  If there would be a way to initiate the
connection but subsequently taking over the server role, protocols
like netconf and presumably isms would find it much easier to provide
CH functionality.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Sep 2005 17:06:40 -0400

>>>>> "Juergen" == Juergen Schoenwaelder <[email-masked]> 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 suspect that the ssh community would decline to extend ssh in this
direction; I certainly know I would not support it.

I would support setting up port forwarding as a way to get a back
channel; I would also support a facility to run an ssh protocol over
ssh channel.

One advantage of both port forwarding and ssh over ssh is that they
provide a much more consistent model for authentication and
authorization of the request to "turn" than an explicit turn facility.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Sep 2005 17:37:49 -0400

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

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

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Sep 2005 23:44:07 +0200

> authorization of the request to "turn" than an explicit turn facility.

Can you please elaborate a bit? I am not sure I understand the idea
you seem to have in your mind...

/js

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Sep 2005 21:14:11 -0400

On Tuesday, September 13, 2005 05:23:26 PM -0700 Ned Freed 
<[email-masked]> wrote:

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

Aha!  Another use case for UDP tunnelling in SSH, which is a topic that was 
recently brought up in that WG.

In any event, the problem isn't carrying the SNMP traffic over an ssh 
connedction -- we're fairly confident we know how to do that, though the 
document isn't done yet.  The problems are in determining when to establish 
an SSH connection for the purpose of _receiving_ traffic, and in making 
authentication work in cases where a managed device wants to authenticate 
to something that is essentially a user.  With some authentication 
infrastructures the latter is easy; with others it is not.  The former I 
think is always hard, but has nothing to do with SSH per se.

I think that we can easily avoid making call-home harder than it needs to 
be, and that we should.  I would not object to a change in ISMS's charter 
requiring that it consider the potential effects of any security solution 
it adopts on the ability to add a call-home mechanism, but I also don't 
think such a provision is necessary to achieve the desired result.

I don't think extending the SNMP architecture to add call-home is within 
the scope of ISMS's charter, and I don't think it would be appropriate to 
add it at this time.  I'm not quite as concerned as Margaret is about the 
"wrong area" problem, provided the right people are active in the WG and 
reviewing its output, which I believe is necessary in any event.

However, I do believe the problems are separable, nearly orthogonal, and 
require somewhat different expertise.  Provided that the ISMS work does not 
preclude call-home or some other solution to the problem, I think a 
narrowly-scoped working group is appropriate here.

-- Jeff

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Sep 2005 17:23:26 -0700 (PDT)

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

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Sep 2005 13:23:32 -0700

> at the issues surrounding call home in general, not just in the special 

I'll bite: what could the IETF do if it looked
long and hard?

		Mike

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Sep 2005 15:47:16 -0700 (PDT)

> I'll bite: what could the IETF do if it looked

Well, the one approach that immediately comes to mind is that the introduction
of a third party might provide a means of getting timely information about
software updates without sacrificing user privacy.

Such a third party would act as a repository for update information provided by
vendors. Applications would then "call home" to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
employed to minimize information leakage even if the third party was
compromised.

Mind you, thiis all off the top of my head. This may not work for some reason
I haven't considered, or there may be other, better approaches.

				Ned

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Sep 2005 17:32:02 -0700

> employed to minimize information leakage even if the third party was

You mean we could invent Bitorrent? :)

		Mike, doesn't it strike others as odd
		 that ietf is completely outside of the
		 p2p bizness?