Subject: RE: [midcom] Moving SPAN along

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Sep 2002 12:06:05 -0700

We already have a generic solution for crossing firewalls with the help
of a 3rd party: tunneling IP through a VPN service; this allows both TCP
and UDP. There is even an IETF proposed standard: RFC 2661, Layer Two
Tunneling Protocol "L2TP". Sure, there are severe security issues with
allowing a VPN connection to the outside, but any solution that will
allow establishment of arbitrary TCP connection will run into the exact
same issue, and will end up with the same class of solutions: establish
some form of firewall at the tunnel endpoint. I don't think that MIDCOM
should try reinventing another way to do VPN, and I am thus not terribly
interested with any solution that implies relaying the data packets
through a 3rd party.

There are two interesting classes of short term solutions for TCP
traversal: those that require some help from the firewall, and those
that establish an "end-to-end" channel. We already have a proposed
standard for the 1st class of solution: SOCKS, RFC 1928. A tempting
approach for the 2nd class of solution is some form of "symmetric TCP"
establishment, but it seems almost impossible to get a reliable design.
We are thus left with solutions that establish an end-to-end UDP tunnel,
maybe using STUN, and then use that tunnel to carry a TCP-IP exchange.
At this point, we have a problem of allocating IP addresses to the
tunnel end-point, and it is not an easy problem with IPv4. On the other
hand, tunneling IPv6 over UDP end-to-end is exactly what Teredo does.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Sunday, September 01, 2002 7:58 AM
> To: Melinda Shore; [email-masked]
> Subject: RE: [midcom] Moving SPAN along
> 
> 
> I think there are two orthogonal questions.
> 
> The first question is UDP traversal in cases where STUN will not work.
I
> think this is a questions worth solving.
> 
> The second question is TCP traversal. I wish we could solve this but
I'm
> not
> sure it is possible without running into the issue of violating the
policy
> that the firewall administrator is trying to provide. If people think
we
> can
> do a generic solution for peer to peer TCP - I'm very interested in
> figuring
> out how. If people don't think we can then, unfortunately, I think we
may
> be
> stuck with doing traversal of TCP with application specific relays.
H.323
> and IM are some good use cases to think about - though 323 may just
use
> Annex E to avoid this and SIMPLE may use sip like proxies as
application
> level relays. I'd like to solve this problem but before we can figure
out
> if
> a solution is possible, we need to figure out what our constraints are
> from
> the point of view of firewall policy.
> 
> Cullen
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> > Melinda Shore
> > Sent: Wednesday, August 28, 2002 7:54 AM
> > To: Pete Cordell
> > Cc: [email-masked]
> > Subject: Re: [midcom] Moving SPAN along
> >
> >
> > At this point there seems to be very little support for
> > continuing to work on SPAN.  The question is whether or not
> > the problem of traversing symmetric NATs is sufficiently
> > compelling.  If it is we need to continue; if not we can
> > consider dropping the deliverable.  Let's try to resolve
> > this question over the next few days.
> >
> > Melinda
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> >
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 2 Sep 2002 21:20:41 +0100

While L2TP has the benefit of being an off the shelf solution, it also comes
with considerable overhead, e.g.

IP/ (UDP/L2TP/PPP/IP) /UDP/RTP/data

as opposed to:

IP/UDP/RTP/data

The PPP negotiation presumably requires a number of round trips to setup
also.  It's for these reasons that I've dismissed L2TP in the past.  If a
more detailed consideration is required I will need a bit more time to look
into the specifics of L2TP.

The problem with SOCKs is that it requires an OS upgrade.  VoIP has got into
the position it is in because it has a dependency on the firewall and NAT
industry to solve its problems.  Moving that dependency to various OS
providers (including Solaris, HP-UX, etc, etc) is just moving the problem
around rather than solving it.  Thus while architecturally SOCKs may be
appear to be a solution, in practice it does not move the technology
forward.

Your proposed use of STUN to build UDP tunnels does not appear to provide
any benefits over a SPAN type solution.  It has exactly the same security
issues as SPAN (indeed SPAN and Teredo are very similar in this respect) but
has considerably more overhead.  In fact, having an application receive
unspecified IP packets over UDP and then squirting them around a system
seems a powerful thing to do, but also seems much scarier to me than
allowing a client to do a rendezvous TCP connection.

I don't want to stop you suggesting alternative solutions for the SPAN type
space, but I'm afraid that so far I don't think what has been proposed are
viable ways to move ahead.

Pete.

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>; "Melinda Shore"
<[email-masked]>; <[email-masked]>
Sent: 02 September 2002 20:06
Subject: RE: [midcom] Moving SPAN along

> hand, tunneling IPv6 over UDP end-to-end is exactly what Teredo does.
.... cut ....

---

From: "Shai Mohaban" <[email-masked]>
Date: Mon, 2 Sep 2002 20:40:07 -0700

I am not sure I follow the OS upgrade argument. Wouldn't the same be
true for SPAN? Either you upgrade the endpoint to support SPAN, or you
put some kind of a proxy to do SPAN for it. You can do the same with
SOCKS or whatever other mechanism you argue against with the "OS
upgrade" argument...

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pete Cordell
> Sent: Monday, September 02, 2002 1:21 PM
> To: Christian Huitema; Cullen Jennings; Melinda Shore; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Sep 2002 03:40:52 -0400

> interested with any solution that implies relaying the data packets

I think its worth investigating in what ways our problem here is the 
same as VPN, and in what ways its not. I think the biggest difference is 
that the protocol is targeted by use for applications instead of the 
underlying host. Practically speaking, this means that what you want to 
allocate is an IP address and port, as opposed to just an IP address, 
which is what you typically get through a VPN. I wonder if any existing 
VPN protocol can do that, or be extended to do that...

We also want low overhead, as Pete has pointed out, since the target 
applications are multimedia, although this is a general goal that any 
VPN protocol would probably also have.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 3 Sep 2002 09:51:46 +0100

Oooppps, I was still in tunnelling mode when I was talking about SOCKS and I
was actually thinking about RSIP!!!  My apologies.

SOCKS (as mentioned in the original e-mail) obviously requires firewall
support and so can not be compared directly with things in the SPAN space.
SOCKS is in the Midcom protocol space.

Pete.

----- Original Message -----
From: "Shai Mohaban" <[email-masked]>
To: "'Pete Cordell'" <[email-masked]>; "'Christian Huitema'"
<[email-masked]>; "'Cullen Jennings'" <[email-masked]>;
"'Melinda Shore'" <[email-masked]>; <[email-masked]>
Sent: 03 September 2002 04:40
Subject: RE: [midcom] Moving SPAN along

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 3 Sep 2002 15:39:18 +0100

Maybe it's worth doing some sort of quick SPAN evaluation document covering
VPN techniques and other such things.

I'm away on holiday for a week after today, but I can produce a rough
outline when I get back and then we can all pile in a build some consensus
around it.  (The document needn't become an RFC.  We would just need to keep
it alive long enough to either produce a SPAN protocol or decide there were
other ways to do it.  If another way was selected we'ed presumably produce
an informational draft, but that's a little way off for the time being.)

For the time being, what other IETF standard VPN techniques are there (other
than L2TP)?
IP over UDP (a la Teredo)?
PPP over IP or UDP?
We should mention RSIP in the document.
What other things?

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Christian Huitema" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "Melinda Shore"
<[email-masked]>; <[email-masked]>
Sent: 03 September 2002 08:40
Subject: Re: [midcom] Moving SPAN along

---

From: "Cullen Jennings" <[email-masked]>
Date: Wed, 4 Sep 2002 11:29:11 -0700

> From: Jonathan Rosenberg [mailto:[email-masked]]
...
> VPN protocol would probably also have.

To take this a step further - I think zero overhead would be desirable
unless it was not possible.

Cullen

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 16 Sep 2002 10:52:00 +0100

Cullen,

[Catching up after holiday...]

Just to let you know, I agree with the objective you stated below.  However
I'm also aware that you don't (usually) get something for nothing.

If there is stuff that is superfluous, then it should be cut out.  There's
no point in carrying bits around just for the sake of it (unless it's XML
:-)

Pete.