Subject: [midcom] http tunnelling question

From: sva <[email-masked]>
Date: Thu, 24 Jul 2003 21:59:10 +0300

Hi,

(Sorry for the second post, this time with a proper subject :)

The MIPv4 working group has been working on a problem for providing
secure session mobility for enterprise mobile users.  Although we
have adequate (UDP) NAT traversal support through IPsec and MIPv4
NAT traversal documents, we unfortunately have no support for
networks that only allow HTTP access (which are not in the WG scope
right now for several reasons).

Aesthetics aside, several vendors already have some HTTP tunnelling
support in their products.  Being proprietary, the mechanisms do
not interoperate and are probably not really optimal solutions.

So I am looking at two things:  first, is there an interest in doing
something about this in the IETF context, and second, if it were to
be done, what should a solution look like.  Although my interest
is mainly MIPv4 and IPsec, it seems to me that a solution should be
generic, covering both IPv4 and IPv6 in their entirety.

The basic approach I've been considering would consist of the
following three components:

   1. Use one or more HTTP tunnelling mechanisms to create a
      "virtual serial connection" (the hard problem).

   2. Use PPP on top of that connection to provide IPv4, IPv6,
      etc connectivity.

   3. User protocols such as IPv4 (MIPv4, IPsec, etc) or IPv6
      on top of PPP.

The mechanism should also provide something that can be easily
blocked in a HTTP proxy, if the network administrator considers
HTTP tunnelling to be impolite.

The questions I'd like to pose to the WGs (pppext and midcom) are:

   1. The proposed work does not seem to fit neatly into the
      charter of either WG -- which working group would be most
      appropriate?

   2. Has this been discussed before, and if so, what was the
      conclusion?  (I scanned the pppext archive but could
      not find discussion on this or similar topics.)

   3. Is there some existing effort that could be easily
      adapted to solve the same problem?

Although this could be done in the MIPv4 WG for instance
(although we've scoped this out for now), it would make
sense to me to avoid protocol specific solutions when they
are really not needed, and to avoid duplication of work
whenever possible.

Best regards,

-Sami

--
Sami Vaarala
Senior System Architect
Netseal  (http://www.netseal.com/)

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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 25 Jul 2003 08:55:50 -0400

MIDCOM has rejected tunneling solutions because they are designed specifically to 
subvert administrative policies.  Our work product is a protocol to directly control 
NATs and firewalls with administrative blessing.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Jul 2003 11:18:39 -0400

The concept has been repeatedly proposed and rejected because it 
purposefully bypasses firewall security policies. In fact, an April 
fools RFC was written proposing the mechanism you describe:

ftp://ftp.rfc-editor.org/in-notes/rfc3093.txt

-Jonathan R.

Tom Taylor wrote:

> MIDCOM has rejected tunneling solutions because they are designed 
> specifically to subvert administrative policies.  Our work product is a 
> protocol to directly control NATs and firewalls with administrative 
> blessing.
> 
> sva wrote:
> 
>> Hi,
>>

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com