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.  

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

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

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.  

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

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

And instead of being just a http proxy, this new proxy will have to proxy a
great many more protocols.  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

Received on Friday, 24 July 1998 18:41:26 UTC