Subject: Re: [midcom] http tunnelling question

From: Sami Vaarala <[email-masked]>
Date: Mon, 28 Jul 2003 13:39:45 -0700 (PDT)

Hi,

I understand and sympathize with the argument that one
is going around firewall policies when doing so.  However,
I find the argument lacking in some respects; some
observations below:

First, there are several protocols already standardized
that bypass firewall security policies, or at least obscure
the actual traffic from the traffic apparent on the wire.
For instance, IP-IP tunnelling makes the actual protocol
(e.g. TCP) inaccessible to a simple firewall.  One can
argue that the firewall can be configured to look inside
the IP-IP tunnel, but the same argument applies to other
forms of encapsulation, such as IP-over-UDP --
or even IP-over-HTTP.

Second, existing NAT traversal standards similarly bypass
firewall policies.  In fact, since UDP has no "next header"
field, a firewall has quite limited means to see inside the
UDP encapsulation, except for specific protocols it is
designed to work with (such as MIPv4 or IPsec NAT traversal).
So using the original argument, UDP-based NAT traversal
should not be considered, as it bypasses firewall policies,
as far as I can see.

Third, not having a well-defined and non-opaque method
of traversal does not prevent vendors from tunnelling
over HTTP!  In fact, the situation will be worse because
a firewall admininistrator has no hope whatsoever to block
the various vendor specific protocols, other than to block
HTTP completely.  The situation would be like having each
vendor do a different variant of UDP NAT traversal using a
different port (or even variable port), with the objective
of maximizing obfuscation and minimizing interoperability
and administrator control.

Given this, a standardized protocol would (in my view)
provide the best hope of (a) interoperability, 
(b) giving the administrator some power of whether to
allow such encapsulation, and (c) minimizing damage to
the proxies or other elements involved.  (This assumes
that vendors go right ahead and tunnel anyway, which I
believe they will.)

Having said that, I can understand the counter-argument;
perhaps doing this would bring more harm than good as
a whole.  I don't have a strong conviction either way,
although I would like to understand the essential
difference to <xxx>-over-UDP encapsulation which is
something that the IETF "sanctions" to some extent.
Since this has been discussed already, I'll check the
archives to see what's been said already.

Thanks for the insights,

-Sami

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

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Jul 2003 09:12:29 -0400

> forms of encapsulation, such as IP-over-UDP --

It's generally the case that IP tunneling is terminated on a
device under the control of the network administrator - that
is to say, a trusted device.  That's not the case with HTTP
tunneling, and it's unfortunately common for network users
to use HTTP tunnel specifically to skirt local network
security policy.

> should not be considered, as it bypasses firewall policies,

The IETF isn't standardizing NAT behaviors (which is another
contentious issue).  What we're working on in midcom and
elsewhere is a protocol for a trusted device or endpoint to
ask a NAT for a NAT table mapping, so that at a minimum the
request is authenticated and authorized.  If a specific NAT
vendor chooses to allow implicit traversal (the arrival of
new UDP traffic from the inside triggers the installation of
a NAT table entry), that's an implementation decision that's
outside the scope of standardization work (in the IETF,
anyway).

Also, note that NAT is not a type of firewall.  This is not
a minor point.

> something that the IETF "sanctions" to some extent.

You may want to check out IPSec NAT traversal work, since
that would be an instance of UDP encapsulation for NAT
traversal purposes.

Melinda

---

From: Sami Vaarala <[email-masked]>
Date: Wed, 30 Jul 2003 07:29:12 -0700 (PDT)

Hi,

>[...]

If two hosts, one inside the firewall and one outside the
firewall use IP-IP tunnelling (or IP-over-UDP tunnelling),
that tunnel is not terminated by a device under the control
of a network administrator?

This is indeed the case when e.g. IPsec is run over UDP:
the UDP tunnel terminates in the IPsec peers, while the
firewall (which may well be under different administration)
takes no part in tunnel termination.  (Are we talking about
the same thing here?)

>[...]

I agree in that this seems to be out of midcom scope.
However, IETF *is* standardizing xxx-over-UDP solutions,
e.g. IPsec & MIPv4 over UDP, for the purpose of traversing
a "clueless" NAT device.

> Also, note that NAT is not a type of firewall.  This is not

A HTTP proxy is also not a firewall.  However, both a HTTP
proxy and a NAT typically incorporate firewall functionality.

> that would be an instance of UDP encapsulation for NAT

The point I was trying to make is that IETF is working on
XXX-over-UDP (IPsec and MIPv4 are specific instances).
It seems to me that there is no fundamental difference in
these efforts to XXX-over-HTTP as such, and I'd like to
understand the reasoning why the latter is usually considered
a bad idea while the former a good idea.

I realize this is not in the scope of midcom, though, since
you guys are looking at more fundamental solutions, not
solving practical deployment issues with existing middleboxes.

Best regards,

-Sami

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Jul 2003 10:44:27 -0400

> of a network administrator?

In practice, what we're actually seeing is unfortunately
little use of host/host IPSec and that there's a reasonable
expectation that encapsulated IPSec for NAT traversal
purposes is going to be terminated on one end by a
concentrator or security gateway.  Frankly, given the choice
between not using UDP encapsulation or not using IPSec, the
choice they made was almost certainly reasonable.

I don't find the argument that "they're doing something bad,
so it's okay if we do something worse" very compelling,
particularly given that there are other options available
besides HTTP tunneling.  What we'd like, in the best of all
possible real-world scenarios, is a NAT and firewall
traversal environment that's integrated with and responsive
to local security policy.  Given that we can do that the
arguments for putting everything inside an HTTP tunnel and
blast past security devices are pretty weak.

Also note that firewalls are doing stateful inspection
increasingly higher up the stack, and some high-end
firewalls are now able to block tunneled HTTP traffic,
anyway.  This pushes up the costs and complexity of the
firewalls, but it does reflect the wishes of network
administrators to disallow using HTTP to do an end-run
around site policy.

Melinda

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 11:34:30 -0400

inline.

> takes no part in tunnel termination.  (Are we talking about

In this case, the firewall admin can block the port used for the 
tunnel, since the service provided on that port is JUST tunneling. 
However, a firewall admin cannot block tunnels over HTTP, since port 
80 is used for both sanctioned (web browsing) use and these 
undesirable tunnels. Thats the difference - sneaking in under 
something allowed, vs. making it plain what you are doing.

> proxy and a NAT typically incorporate firewall functionality.

Melinda's point, I think, is that mechanisms designed to bypass the 
ability of a firewall admin to stop them, are very different from 
mechanisms meant to work with NATs (NOT firewalls).

> solving practical deployment issues with existing middleboxes.

That is not true. Plenty of IETF work is going on on practical 
deployment issues, in addition to longer term solutions. See, for 
example, STUN (RFC 3489) and ICE 
(http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt).

-Jonathan R.

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

---

From: Sami Vaarala <[email-masked]>
Date: Wed, 30 Jul 2003 10:16:36 -0700 (PDT)

Hi Melinda,

> blast past security devices are pretty weak.

Well, if one assumes that existing deployed networks can be
changed, then there are surely better choices available;
even UDP NAT traversal is a sub-optimal choice assuming
that the middlebox can be changed.  However, in the case
where you are stuck behind a HTTP proxy and simply want
remote access, you don't have many options.

> administrators to disallow using HTTP to do an end-run

Yes -- and as I said earlier, I agree that the administrator
should have a method for controlling tunnelling.  In fact,
a tunnelling method should indeed announce its presence in
some obvious way (e.g. a header, an URI prefix, a certain
User-Agent attribute, etc) so that even existing proxies could
block the tunnelling if necessary with little overhead and
minimal damage to other network elements.

That's what's good about standardized UDP tunnelling
mechanisms -- they're easy to block if necessary.  If each
vendor went right ahead and used their proprietary UDP tunnelling
instead (which is still the case to some extent, although less
than before) the administrator would have less control.

Best regards,

-Sami

---

From: Sami Vaarala <[email-masked]>
Date: Wed, 30 Jul 2003 10:38:11 -0700 (PDT)

Hi Jonathan,

> tunnel, since the service provided on that port is JUST tunneling. 

Precisely -- but this is only possible because the UDP tunneling
is standardized and therefore the firewall or the administrator knows
that port X equals XXX-over-UDP.  If each vendor uses a different UDP
tunneling scheme, the firewall admin has much less control; ports
vary and might even be dynamically detected.

> something allowed, vs. making it plain what you are doing.

What I was trying to say previously was that a tunnelling mechanism
should certainly announce its presence in some obvious way.  For
instance in the case of HTTP, one could conceivably use a specific
header field (User-Agent, etc), a URI prefix, a content-type, etc,
to announce that one is tunnelling.  Proxies could then simply
block the tunnel, should that be against site policy.  (It might not
always be.)

This is not true with non-standardized approaches which use various
approaches to tunnelling; without a standard the admin is again
much worse off (as in the UDP case).  Granted, a standard doesn't
prevent using vendor specific tunneling, but at least a subset of
hosts would be polite to the network.

> (http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt).

Oops, "looking at more" should have read "looking more at"; these
are interim solutions but the main goal is to communicate with the
middlebox and gain controlled access, which involves changing the
middlebox in some fashion.  I stand corrected.

Best regards,

-Sami