Great Circle Associates Firewalls
(June 1996)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Stateful Packet Screens
From: Mike Shaver <shaver @ neon . ingenia . ca>
Date: Sun, 30 Jun 1996 17:41:40 -0400 (EDT)
To: avalon @ coombs . anu . edu . au (Darren Reed)
Cc: chris @ dejong . com, Firewalls @ GreatCircle . COM
In-reply-to: <199606290444 . VAA04439 @ miles . greatcircle . com> from "Darren Reed" at Jun 29, 96 02:41:05 pm

Thus spake Darren Reed:
> In some mail from Chris Tyler, sie said:
> > - Can run with a very small Kernal image (full operating system 
> > functionality is not required).

This is the case for most firewalling applications, I would think.
If you don't need it for firewalling, rip it out.

> > - Can use a very small amount of code to control packets to/from all 
> > services. This small code base is probably easier to audit than a 
> > number of AGs.
> In my experience, it isn't the control code which is hard, but the code
> which does the matching and deciding, "do I want to allow this or not ?"

And that's the crux of the issue, IMHO.
The rules for AGs tend to be more complex than those for SPSs,
because, oddly enough, you want to make more complex decisions.

I find that most of these AG/PS debates can be reduced to a pretty
simple syllogism:
Doing more complex things requires more complex rules.
More complex rules require more complex code.
Therefore, doing more complex things requires more complex code.

As Darren pointed out, it's possible to do everything an AG does with
an SPS, and vice versa.

It's kind of a silly argument, since you're comparing implementations
by enumerating behaviours which are not inherently tied to a given
implementation.

> Writing a proxy is a trivial exercise; writing SPS code is not.

Writing a _trivial_ proxy is trivial.
Writing non-trivial[*] SPS code is non-trivial.

[*] Often pronounced as `korekt'. =)

> You shouldn't be taking any less effort with an AG.  The main difference
> is that you've a greater chance of "failing safe" with an AG than with a
> SPS, if you stuff up the access control rules.

That's implementation dependent, I think.
If your SPS fails closed and has a picky parser (as it should, IMHO --
if DWIM has a place, it's not in security), then you're no worse off
than with an AG with similar characteristics.  (But I repeat myself.)

> * it is hard to achieve the same performance throughput with AG's as SPS's

Given identical functionality (read: external behaviour) and identical
hardware, I think that's false.  The Kernel/user dichotomy costs you
on Unix, but that's not applicable to the general case.

> * it is hard to achieve the same level of security as AG's with SPS's

I disagree, but it's a hard thing to prove.
(`Level of security' is vague enough that you can get nailed either
way, I think.)

> * it is hard to achieve the same flexibility of either with the other

* it is possible to construct one that is indistinguishable from the
other based on externally-visible behaviour.

Mike

-- 
#> Mike Shaver (shaver @
 ingenia .
 com) Ingenia Communications Corporation <#
#>           Resident Linux bigot and kernel hacker. (OOPS!)           <#
#> `If you get bitten by a bug, tough luck...the one thing I won't do  <#
#> is feel sorry for you.  In fact, I might ask you to do it all over  <#
#> again, just to get more information.  I'm a heartless bastard.'     <#
#>                       -- Linus Torvalds (on development kernels)    <#


References:
Indexed By Date Previous: Re: NT Backoffice "Catapult" firewall certified?
From: Mario Bai <mbai @ straticom . com>
Next: Re: NT Backoffice "Catapult" firewall certified?
From: John Betts <johnb @ aztec . co . za>
Indexed By Thread Previous: Re: Stateful Packet Screens
From: Darren Reed <avalon @ coombs . anu . edu . au>
Next: Hardware requirements of Firewall-1
From: Can BAYSAL <baysalc @ boun . edu . tr>

Google
 
Search Internet Search www.greatcircle.com