Re: SMUX comments

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.

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

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

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

>Of course, this is just one opinion...

But appreciated :)

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Friday, 24 July 1998 16:11:18 UTC