Re: SMUX comments

> From: Matthew_Squire@baynetworks.com (Matthew Squire)
> Date: Fri, 24 Jul 1998 18:47:50 -0400
> To: Henrik Frystyk Nielsen <frystyk@w3.org>, jg@pa.dec.com
> Cc: www-http-ng-comments@w3.org
> Subject: Re: SMUX comments
> -----
> At 04:11 PM 7/24/98 -0400, you wrote:
> >At 14:46 7/24/98 -0400, Matthew Squire wrote:
> >
> >>Its a beautiful goal in an ideal world, but a great many of us spend our
> >>electonic lives behind firewalls.  The possibility of combining multiple
> >>protocols over a single TCP port is perpendicular to the basic premise of
> >>firewall security.
> >
> >I guess that depends on what kind of security you expect from simply a port
> >number. With a protocol like HTTP/1.x you can tunnel almost anything
> >through and it all stays on port 80. This has for example come up with IPP,
> >the HTTP based printing protocol - should IPP be accessible outside the
> >firewall so that an outsider can print jobs?
> >
> >The problem is, of course, that HTTP/1.x doesn't tell what it tunnels
> >through in a very easy to detect manner. So the question is, can you at all
> >achieve security without looking into the stream?
> >
> >On the other hand, I am not a firewall expert so I don't know what people
> >are actually doing - Jim has some real world experience from actually
> >running a firewall. I would expect that firewall would have to look for
> >media types and HTTP methods in the HTTP stream in order to have any idea
> >of what is going on.
> 
> I'm certainly not going to claim firewalls are a god's gift to internet
> security.  But they do pretty good in most cases, they're incredibly
> common, and most people who have them do some kind of per protocol
> filtering. 
> 
> Right now, the only thing using port 80 is my browser, so if I setup a
> connection to some server and it sends me some non-http traffic, that
> traffic gets chucked.  Now throw mux'ing into the mix.  Whoever I connect
> to via a mux'd connection can send me any protocol, maybe they can send me
> a dhcp packet changing my config (probably not the best example, but you
> get the idea).  Right now, this kind of stuff can't get through the wall. 
> 
> Certainly you can tunnel anything over http, but (a) its not common, and
> (b) someone on the inside of firewall has to be running an application that
> expects it.  If mux'ing comes along for http-ng, then this will become
> common and everyone will be running applications that use it.  Its a
> different ballgame at that point. 
> 

To begin with, our major intent is to allow a single connection to
carry both existing HTTP traffic, and HTTP/NG traffic simultaneously; once
you have more than one, you might as well make it possible to do N.  And
there are other Web protocols than HTTP, so we believed we needed more
than 2.  So we did a general design; our intent is Web multiplexing.
If it does that, we're happy.

Secondly:

Significant firewalls are MUCH MORE than just a packet filter; packet
filters are but one piece of them.

A typical, high end firewall, is built using a "DMZ" (demilitarized zone)
network, with filtering routers on (often both sides) the edge. 
(e.g. Digital custom firewalls.).

In some lower end firewalls, the firewall network is a single machine,
with two network interfaces (filtering packets in and out of that system).
(e.g. Raptor, TIS).

Ok, what happens then?

The filtering routers mean that only particular TCP or UDP ports can
even reach the proxies in the firewall.

So, for example, the typical HTTP proxy is a system in this DMZ network,
listening for connections (by convention) on port 8080.

The incoming HTTP request is allowed through the packet filter to the 
system in the DMZ; it goes to an APPLICATION level proxy program. In the 
HTTP case, this program takes a request apart, examines it, enforces policy 
(which might, for example, forbid postscript entities to be transferred 
back through a firewall, or examine the entity for viruses if it is an 
executable, etc. (this is not a ficticious example), or enforce an outbound 
bandwidth limit, as we did in Digital for quite a while). These programs 
examine each HTTP request, and decide on a request by request basis if 
they look sane and are permissable.  If it meets the policy, the request 
is completed.  They are not just a hole in a packet filter allowing HTTP
connections in or out.

The point being that all useful, secure proxies do much more than
just a screening packet filter; dealing with MUX is a tiny perturbation
to what they already do.

Only minimal security can be provided by just a packet filter...

The firewall policy is much more than just allowing port 80 through;
people who feel safe enough just behind a single filtering router
1) haven't yet been burned badly, or 2) are so small that no one has
attacked them or they think they've never been attacked.

OK, what role do packet filters play?  They make it MUCH harder to attack 
the firewall proxy machines; the only protocols (or management) machines 
that can get to the proxy system can be much more easily controlled; I 
can say that most systems can only talk, for example, on port 8080 to 
that system, and the proxy process ensures that the messages are HTTP.
  
Historically, attack on these systems from inside is a much bigger problem 
than from outside (which is why high end firewalls are built with TWO 
filtering routers and a machine/network inbetween; one to make it hard 
to attack in each direction.

> >
> >>  In order to do per protocol policy enforcement, I would
> >>have to scan the TCP SMUX stream, jumping from one smux header to the next
> >>while checking the protocol (killing the TCP connection on violation, or
> >>worse, trying to adjust the TCP windows).
> >
> >It is true that if you want to catch MUX SYN packets then you would have to
> >inspect the MUX headers but you do not have to kill the TCP connection -
> >the MUX proxy can reply with a MUX RST header in which case the connection
> >request is simply rejected.
> >
> 
> To me at least, there's a difference between a proxy and a firewall.  A
> proxy can do what you say because it is the terminus of the TCP connection.
>  A firewall is just a intermediate filtering router that doesn't permit
> inbound tcp connections.  It can't remove or insert things from the tcp
> stream because the end guys have their windows sync'd. 
> 

No, any interesting firewall is more than just a filtering router.
Filtering routers are just one component; see above.  It is the piece you
see in your business, but it isn't but one piece of a real firewall gateway
complex.

> >>  If I have more than one firewall
> >>into my site, than I can't do it at all because I might not see the whole
> >>stream.
> >
> >I don't understand what you are saying here...
> 
> 
> I was looking at the following configuration:
> 
>                                  ---------
>    ------------------------------|  FW1  |-----------------
>    |   Internet   |              ---------        | MyNet |
>    --------------------------------------------------------
>                                  |  FW2  |
>                                  ---------
> 
> For redundancy/reliability, etc, I want multiple firewalls.  Each is
> configured the same, to allow http, mail, and a few other protocols, but to
> stop everything else.  Packets from the outside have two ways to get in.
> If some packets come over FW1 and others over FW2, then how can either
> firewall know where the beginning of the smux header is? 
> 

Yup.  Last I knew, Digital (becoming part of Compaq) was running at least 
6 firewalls (Palo Alto, Cambridge, Dascom Road, Littleton, Atlanta, Colorado 
Springs, and I believe there is now at least one in Europe). But they 
are generally application relays.  Absolutely NO packets get in or out 
of Digital without going through an application relay of some sort.  Once 
upon a time we allowed NTP through, but I believe even this is gatewayed 
these days.  NO, absolutely NO, TCP connections (or UDP packets) go through 
the firewall complex directly; this routing issue does NOT arise in these 
systems.

Incoming mail is routed via MX records and appropriate DNS hacks.
HTTP proxies do their normal thing.

> For a different version of a similar problem, assume you have a single
> firewall, but packets arrive out of order.  In order to filter within SMUX,
> the FW has to buffer packets and reform the SMUX stream so that it can go
> from header to header based on the smux packet length. 

Yup.  This is EASY.  Relative to a proxy for ANY of the application protocols
involved.  Just look at the HTTP/1.1 spec, if you want to start to understand
what an HTTP proxy gets to go through.

> 
> No router is going to be doing either of these things (at least not well).
> 

Routers are only one component of a real firewall.  That is the part your 
company builds, so it is not surprising that you see it mostly from that 
perspective.  See above for more details, or go buy one of the books on 
how people build firewalls.

> >
> >>   The only realistic option that I have, as both a builder of
> >>routers and as a site administrator, is to not allow the SMUX protocol
> >>across a firewall.  If SMUX isn't allowed across firewalls, then it won't
> >>reach businesses, and if it can't reach into businesses, what's the point?
> >>
> >>Unless we either restrict the protocols to http/http-ng, or come up with an
> >>easy way to apply per protocol filtering, then I can't see how this idea
> >>will float.  Unfortunately, the latter requirement seems to degenerate into
> >>something along the lines of sharing congestion info across TCP control
> >>blocks (rfc 2xxx). 
> >
> >In my mind, the information in the SYN packet can give you much more
> >precise information about exactly what service you are connecting to than
> >what you can deduce from a port number. I do not fully understand the
> >overhead you are referring to, but to me it seems easier than the
> >heuristics you often are forced to perform with regular HTTP.
> >
> 
> True, but to do so REQUIRES a proxy.  We can kiss protocol filters on
> routers goodbye because there's a way around them.  Proxies are not a
> requirement for security right now, protocol filtering has proved more than
> adequate for many folks.  To me, this is a big paradigm shift. 

Protocol filtering is only one piece of building a firewall; it may
be enough at the very low end (or people are deluded into thinking so);
for these people allowing MUX out isn't typically going to be an issue.

> 
> And instead of being just a http proxy, this new proxy will have to proxy a
> great many more protocols.  

No more than they currently do.  Anything they don't understand, they
just say no to.  Dealing with MUX is simple relative to any application
protocol I'm familiar with.

> Http proxies are busy enough as it is, now
> we're going to throw a bunch of new protocols at them?  Although my company
> might disagree because of the potential new market this creates, it seems
> like we're throwing some pretty useful things out the window.
> 
> I'm stepping down from my soapbox now.
> 
> - Matt

As I said, I've seen this from the other side, where I've been responsible
for a major companies firewall security.  Any major company that tries
to get by strictly with packet filtering is one I sure wouldn't do
business with or give my credit card number to.  And packet filtering
is one important component of a firewall; but it is the easiest
component.

So you happened to run into someone one step short of expert in the area 
(I've been responsible for managing the people who built and extended 
one, but have't built one from scratch myself; if I had to, I could build 
one from scratch though, without having to go figure it or go buy books
on the topic).

And see Bill Janssen's mail; our major goals are elsewhere; I hope
I've convinced you that MUX doesn't make things worse than they already
are.
				- Jim Gettys

Received on Friday, 24 July 1998 22:39:19 UTC