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.

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

---

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

> 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

---

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

> 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: 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?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Sep 2005 19:44:44 -0700

>You mean we could invent Bitorrent? :)

BitTorrent (note the spelling) does a lot of very nice things, but 
not those. For those interested, the BitTorrent protocol is described 
at <http://www.bittorrent.com/protocol.html>.

>		 that ietf is completely outside of the

In this case, there is no advantage to the developer of the protocol 
to have it worked on in the IETF, nor even published as an RFC. It 
came out of one person's head, he was able to experiment with it live 
on the net, and he retains the ability to tweak the specs whenever he 
feels like it. It has worked remarkably well, given the variety of 
clients and servers available for the protocol, and the huge amount 
of traffic that is moved daily over it.

--Paul Hoffman, who shares a lot of legal music and OSs with BitTorrent

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Sep 2005 10:36:30 +0200

If you want to discuss this as a generic issue, please do so
with an appropriate subject and without cross posting. Thanks.

BTW I agree that there is a generic architectural issue here
that merits discussion.

    Brian

Michael Thomas wrote:
>>> > at the issues surrounding call home in general, not just in the 
>>> special
>>> > case of
>>> > SNMP.
>>
>>
>>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Sep 2005 13:50:08 -0700

Paul Hoffman wrote:
> BitTorrent (note the spelling) does a lot of very nice things, but not 
> those. For those interested, the BitTorrent protocol is described at 
> <http://www.bittorrent.com/protocol.html>.

Always the risk when one is being flippant, but I only
meant that the world outside of ietf seems to be taking
on a lot of these issues without ietf's advice and consent.

> In this case, there is no advantage to the developer of the protocol to 
> have it worked on in the IETF, nor even published as an RFC. It came out 
> of one person's head, he was able to experiment with it live on the net, 
> and he retains the ability to tweak the specs whenever he feels like it. 
> It has worked remarkably well, given the variety of clients and servers 
> available for the protocol, and the huge amount of traffic that is moved 
> daily over it.

Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?

I'll note that many protocols -- good and bad -- spring from
somebody's head. Some of them become successful too. Very
successful. And ietf has no say about them at all. Is this
the new reality? Sure seems like it to me. Should we be
concerned? Might there be film at 11 at some point because
of it?

		Mike, or is it too soon for another
		 ietf ossification thread?

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 15 Sep 2005 14:09:26 -0700

>on a lot of these issues without ietf's advice and consent.

Fully agree.

>>In this case, there is no advantage to the developer of the 
>>protocol to have it worked on in the IETF, nor even published as an 
>>RFC. It came out of one person's head, he was able to experiment 
>>with it live on the net, and he retains the ability to tweak the 
>>specs whenever he feels like it. It has worked remarkably well, 
>>given the variety of clients and servers available for the 
>>protocol, and the huge amount of traffic that is moved daily over 
>>it.
>

Not sure why this is an elephant; who cares? I have seen numbers that 
show that a huge percentage of traffic is P2P of various flavors, but 
I haven't seen anyone saying that this is having any negative 
effects. BitTorrent in specific spreads out the traffic by making 
many receivers senders as well, so the traffic isn't all concentrated 
on one point. Many music traders (such as myself) leave the torrent 
running after we have gotten all the content because that helps 
reduce the load on the originator so he/she can originate more music, 
and because we have spare bandwidth. The fact that this helps spread 
the load on the Internet is nice, but probably not important to 99% 
of traders.

(Right about now, someone from Japan or Korea should hop in and talk 
about the rampant television show trading that I have heard so much 
about there.)

>the new reality?

It is a new reality, not the new reality. We still create lots of 
important new things here, and lots of folks still come to us to ask 
us to do more. New data formats (or rehashed old data formats) seem 
to be happening more outside the IETF, although Atom 1.0 has 
certainly garnered its share of publicity. But for layer 7 protocols, 
file sharing may be the only major market that has wholly ignored the 
IETF.

>Sure seems like it to me. Should we be
>concerned?

Nope.

>Might there be film at 11 at some point because
>of it?

Yes, if one that has bad congestion control becomes popular. But, 
given the mindshare of BitTorrent these past few years, that seems 
pretty unlikely.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott W Brim <[email-masked]>
Date: Thu, 15 Sep 2005 18:57:34 -0400

On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:
> show that a huge percentage of traffic is P2P of various flavors, but I
> haven't seen anyone saying that this is having any negative effects.

The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.  What you're describing is not a
bug, it's feature.  It means the IETF have done their job.  If there
were interoperability problems in the fundamental and/or widespread
technologies being used in the Internet, then there would be a problem
(we're working on those).  Congratulations.

swb

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Sep 2005 16:00:48 -0700

Paul Hoffman wrote:
> Not sure why this is an elephant; who cares? 

   I'm not sure; maybe it's really a mutual non-admiration
   society, and everybody's happy? But it's an elephant
   insofar as it's pretty darn big trafficwise, and the
   fact that ietf doesn't seem concerned?

> I have seen numbers that 

   I don't think this is _entirely_ true: p2p stuff definitely
   has, um, interesting effects on, say, voip at home, and some
   of the p2p apps -- especially the earlier ones if I recall
   correctly -- had some pretty nasty effects on various networks.

   Are we to believe that they are largely self-healing problems
   as bad p2p apps will eventually correct themselves since it's
   in their interest? Is it reasonable to believe that there is
   enough general clue that they could be expected to do that?
   And the collective clue of the ietf is not really needed to
   help this along?

> But for layer 7 protocols, file sharing 
> may be the only major market that has wholly ignored the IETF.

   This isn't that unusual really, but what facinates me
   is that the reverse seems true as well.

> Yes, if one that has bad congestion control becomes popular. But, given 
> the mindshare of BitTorrent these past few years, that seems pretty 
> unlikely.

   But surely BitTorrent isn't the last one that will come
   along. I guess the base question is this: is the net robust
   enough to really allow experimentation with flash crowds of
   millions of alpha testers? So far it has, but we're layering
   more and more stuff onto the net too -- like voip -- that
   are pretty sensitive to average expectations (I'm thinking
   about things like Vonage, not managed services). Is that
   a danger for the overall internet architecture? That is, is
   there a price for this benign neglect that has yet to surface?

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 15 Sep 2005 16:04:50 -0700

> (we're working on those).  Congratulations.

Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?

I know that we aren't the net.cops, but are we not
net.stewards either?

		Mike, asking.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Sep 2005 01:51:21 +0200

>   fact that ietf doesn't seem concerned?

Why should the IETF be concerned about traffic?

Now of course that doesn't mean our amateur protocol designers get it  
right every time... For instance, when you become a Gnutella  
"ultrapeer" you'll very likely create some nasty congestion in the  
outgoing direction of your ADSL or cable connection because when you  
receive one request, the program wakes up and sends out copies of  
that request over several dozen TCP sessions at the same time, which  
will invariably overload the buffers at some point between the host  
and the DSL/cable connection.

> we're layering
>   a danger for the overall internet architecture?

Anyone who thinks he or she is going to meet real time constraints  
over a random path across the internet that spans multiple ASes has  
more problems than the IETF can possibly fix.

And no, I don't think it's reasonable to restrict p2p bulk data  
transfer to accommodate voice over the public internet.

(Maybe at some point people from Apple would like to share the  
results of them setting a DSCP code point / type of service in the IP  
header of voice packets.)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Sep 2005 11:39:13 +0200

> plant Kudzu. We have nothing to say about that?

I just read today that kudzu extract may reduce the desire
for alcohol (Scientific American, 8/2005, p 17). What seems
evil may not always be evil.
> I know that we aren't the net.cops, but are we not

Up to a point, but there are limits to what we can do.

We can request that the RFC Editor not publish things we think
are damaging. The IESG does this a few times a year. Similarly,
we can request that IANA not register things we think are
damaging, or at least to label them as potentially dangerous.

We can publish screeds about damaging practices. The IAB does this
a few times a year.

We can try to develop non-damaging solutions for requirements where
the easy solutions are damaging, and we can try to repair our own
damage (as HTTP 1.1 repairs HTTP 1.0).

We can try to ensure that the Internet can 'route around damage' -
that's one of the main reasons for defending the e2e principle,
for example.

But we can't prevent people from deploying solutions that we
didn't develop, and we shouldn't even try to IMHO.

    Brian

---

From: Thomas Narten <[email-masked]>
Date: Fri, 16 Sep 2005 09:24:04 -0400

Scott W Brim <[email-masked]> writes:

> wild and create excellent gardens.

Exactly. The beauty of TCP/IP (and indeed many protocols when done
well) is that they are generic enablers for additional higher-level
uses.

TCP/IP creates opportunity for innovation, and does so in a way that
is generally safe for the network.

In the case of BitTorrent, it runs on top of TCP. It is silly to
assume/expect all application protocols to be developed in the IETF.

It is true that BitTorrent (or more precisely its heavy use) creates
interesting dynamics that have implications for the net and maybe even
the IETF.

For example, BitTorrent creates an environment in which end users
start running "background" jobs that run for hours and suck up idle
background network capacity. I've heard ISPs use figures of 30% or
more of their capacity.... This is Just Fine at one level, but also
upsets some business models.  Wouldn't it be nice if BitTorrent
traffic (at least in some cases) could be labeled as "background"
traffic so that ISPs had the ability to better prioritize or
figure out when it is critical to add more bandwidth vs. "just nice to
have"? Maybe more work here for diffserv?

Thomas

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 16 Sep 2005 09:29:30 -0400

>evil may not always be evil.

Have you ever lived in the southern U.S.?  It's amazing driving through 
some areas, where you see kudzu covering trees, barns, telephone polls, 
and some slow-moving cows...

>didn't develop, and we shouldn't even try to IMHO.

Agreed.  Sometimes the IETF does the initial engineering, sometimes it 
has to do garbage collection and repair, and hope that the operators 
can cope in the meantime.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Marc Manthey <[email-masked]>
Date: Fri, 16 Sep 2005 17:12:59 +0200

> and some slow-moving cows...

wow, i never heard of it but it looks very nice

http://www.jjanthony.com/kudzu/

greetings

-- 
" Sic transit gloria mundi"
Les Enfants Terribles
www.let.de

---

From: Michael Thomas <[email-masked]>
Date: Fri, 16 Sep 2005 10:28:09 -0700

Brian E Carpenter wrote:
> damage (as HTTP 1.1 repairs HTTP 1.0)

This is more or less what I had in mind. Correct me if
I'm wrong, but http 1.0 wasn't the invention of the ietf,
but sprang forth outside of its purview. Http 1.1 was a
response to the many difficulties placed on the net because
of http 1.0, and there was an active feedback loop between
the http world and the net (ietf) world to adapt both at
layer 7 as well as below. Http, after all, was The Big
Thing for all parties, so it's not surprising that there
was active cross interest.

What facinates me about p2p is that it was clearly the
next Big Thing, but there seems to be no feedback loop
operating whatsoever. I guess that surprises me. Thomas
brought up qos/diffserv and operator business models which
is certainly something ietf clue level could assist on, but
it seems that we neither know them, nor do they know us and
that both sets of people seem satisfied with that. I'm not
saying that it's bad -- it's just a very surprising outcome.
Ought both sides be that confident that the net as engineered
today is what it needs to be for this Big Thing and the
Big Thing after that? Or that our fertilization is really
the correct mix to prepare the ground for the next Big Thing?

> didn't develop, and we shouldn't even try to IMHO.

I wasn't suggesting control, but much more that the cross
pollination of clue isn't happening and whether we should be
alarmed about that. In particular, what does that say about
ietf? Some have suggested that it means that we've done our
job, but that strikes me as a wee bit too self-satisifed
for my taste.

		Mike

---

From: "Nicholas Staff" <[email-masked]>
Date: Sun, 18 Sep 2005 10:12:03 -0700

> What fascinates me about p2p is that it was clearly the
> operating whatsoever.

At the risk of birthing a much unwanted tangent, I think it would have been
somewhat egocentric for the IETF to do anything that lent legitimacy to the
p2p movement.  At least until some of the bigger issues surrounding it start
to find resolutions.

> job, but that strikes me as a wee bit too self-satisifed

While it may be self-satisfied I still very much agree with Brian (though
having had nothing to do with the design of IP or the Internet I can't
possibly be self-satisfied, so let's just say I'm very satisfied with all of
you ;)).  I'd even go so far as to say it's none of our business (please
don't bikeshed this).  In a properly architected alphabet the letters have
no fear of the words because the words never lack for a letter.

While there are people who don't like corporate involvement in the IETF
(again no intention of spawning a tangent), I think it's that involvement
that insures a long-lasting future,  whether or not we are omnipresent on
the bleeding edge.  Truth is this is a dream come true for entrenched
corporations a. because they are somewhat assured they won't come out with
an 8-track while someone else comes out with a CD-ROM and b. once you have
your huge customer base you don't really need exclusivity to a technology,
you just need to make sure you're not excluded from it (i.e. we're a Cisco
shop and so long as Cisco can do what the others can we'll probably stay a
Cisco shop).  Anyway I guess what I'm saying is so long as 95% of the market
share continues to participate in the IETF, our opinions will continue to
matter.  I would however be alarmed if Cisco, IBM, Sun, and Microsoft
unsubscribed from this list in favor of the BitTorrent Engineering Task
Force.

Nick