Re: encapsulated protocols?

[Adam Shostack <adam () homeport org>]

Mark Horn [ Net Ops ] wrote:
| Adam Shostack says:
| >       No, I conclude that *for the mass market* packet filters will
| >win because
| >1. They're faster

| That really depends on the proxy and the application, doesn't it?  In the
| particular case that started this whole issue, we were talking about
| HTTP.  There are several caching HTTP proxies available.  For HTTP
| performance to the Internet, it's hard to beat a cache.

        I can make the argument that the appearance of faster is not
the same as being faster.  If the proxy runs short on ram, and can not
maintain its index of looked at pages, it suddenly becomes much
slower.  In getting a page it has never seen before, it is slower.  By
adding a TCP/IP hop, its slower.   But you're correct, it can be
faster.

| Now as soon as you start talking about stateful packet filters, you're
| also talking about something that, in addition to parsing the headers,
| also parses some of data stream.  In both cases, proxies vs. stateful
| packet filtering, you have to parse the headers and the data.  You've just
| lost the inherent speed benefit that is supposed to come with packet
| filters.  If you decide that you only want a packet filter that only
| inspects the headers, you've compromised more of your security because the
| data stream is what really counts.

A nit: stateful packet filtering doesn't need to parse the data.
(Except for FTP).  A stateful packet filter could be one that looks at
ACK bits.  I'll assume that by SPF, you mean Checkpoint style SMLI.
SMLI looses some of the benefits of speed, but does not have to
rebuild the packet with its own IP address, which buys it something.

| The long and short of this boils down to that last sentance.  How do you
| prevent encapsulating entirely new communications streams inside the data
| portion of a packet?  That's the question.  It is the same question for
| stateful packet filtering as for proxies.

        Ok, I'll grant you that, and suggest that its a Hard fight to
win.  IPsec is only going to make it harder, unless we get to the
point of an encryption standard that seperates authentication from
confidentiality, and the keying of the two to allow an authorized
third party to participate.  As a cryptanalyst, I believe those goals
are amazingly hard to meet.  I haven't look closely enough at IPsec
and Oakley/ISAKMP to understand what they do to firewalls in the
context of your question.  I'm afraid I might have to write RFCs, and
argue that the standard needs more work. But my desire to see IPsec
deployed outwieghs my desire to see proxy firewalls deployed.

| >This, in practice, leads
| >companies to fail to properly secure the machines behind it.  
| 
| Isn't that entirely the point?  You said that you "follow Bellovin", well,
| don't forget about the fundamental theorem of firewalls (please reference
| "Firewalls and Internet Security" by Cheswick & Bellovin, p.7).
| 
| The fact that companies want to run large, and inherently buggy programs
| is a failure to properly secure any machine that's running that large and
| inherently buggy program.  I agree that it is very easy to get complacent,
| and think that you don't need to do anything to the machines behind the
| firewall.  But those machines, as long as they're running any program of
| any reasonable complexity can never be completely secured.
|
| Thus, while having a firewall is only a piece of the puzzle, you can never
| have complete internal security, so you'll always need a firewall.

        I agree completely.

Adam


-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume