RE: Additional TPC/IP stack

[Scott Wiegel <slwiegel () cisco com>]

Warning: This may be construed as one person's support of a particular
product.  I am a primary contributor (technically at least) to the
Centri Firewall product.

As one of the primary architects of the Centri Firewall, let me add a
little bit to this discussion.

> > An NT based firewall I've been reading about is marketted as using an
> > additional TCP/IP stack, which performs additional checking before
> > transerring the packets to the native NT TCP/IP stack. (The firewall
> in
> > question is Cisco's Centri)  My questions are:
> >     Do you feel that such additional checking in an ad hoc IP stack
> is
> > valuable?
>
> The stack implemented in the Centri product is NOT an ad hoc IP
> implementation.  It is an IP implementation that was developed with
> security being the first and foremost thought on everyone's mind.  If
> you simply implement a protocol stack in accordance with available
> specifications and not much security knowledge, then all advantages of
> a dual stack architecture are truly lost.
>
> In general, I believe that error checking can never be a bad
> thing. One of the reasons that software has so many security
> problems is because there is an insufficiency of "sanity check"
> interlocks between layers of software. There's too much trust.
> So, it's probably not a bad idea to have different implementations
> that effectively check eachother over for bugs or loose
> interpretations
> of specifications.
>
> The TCP, IP, and UPD modules that have been implemented for the Centri
> firewall were written with one primary goal: To ensure that any and
> all known problems with these specifications were handled in some
> fashion.  When you have your own stack (instead of blindly relying on
> someone elses), the information that you can gather and the additional
> security checks that can be implemented allows a level of confidence
> that will never be gained from utilizing some one elses
> implementation.
>
> Most security experts also agree upon a minimalist approach.  This
> approach basically states that the software in question does what it
> is supposed to do and nothing else (my loose interpretation).  Many
> vendor provided stacks are also responsible for performing additional
> non-security related processing.  As such, they tend to grow well
> beyond their original purpose.  This slow growth over time can make
> performing any type of security analysis very, very difficult.  And
> when a new release arrives every other month...
>
> >     What kind of additional checks would make sense?
>
> Mostly, in an IP stack, I'd expect you'd be looking for large
> or corrupt or fragmented or tiny or otherwise weird packets.
> I suppose you might also look at sequencing issues, and
> so forth -- that's about all that you have available to you at
> the IP level, unless you start reassembling all the traffic
> and looking into the data streams (that's a hard problem!).
>
> This is a very accurate list of things that you would look for.  Many
> of the problems in modern day TCP/IP stacks can be attributed to poor
> handling (or sometimes correct/accepted handling) of bizarre cases.
>
> For modern firewalls, the information present at the IP, TCP, and UDP
> layers is not sufficient, IMO, to enforce desirable security policies
> for a large number of end-users.  In addition, many end-users want
> firewalls that can run on smaller hardware footprints.  This was one
> of the driving forces behind the original architectural decision of
> the Centri design team to re-assemble packets (IP and TCP reassembly)
> and allowing the Centri security kernel module the ability to scan all
> application data that passes through the system (without a requirement
> to traverse the Kernel/User Space boundary).
>
> In other words it makes sense but I'm not sure there's a huge
> "bang for the buck" in doing it -- the bulk of the interesting
> holes that are going to let someone punch through a firewall
> are in application software BEHIND the firewall -- which means
> that looking through the stack is less interesting than looking
> at the application stream.
>
> But there is a huge "bang for the buck" if, in addition to these
> checks, you also check the most common application flaws and security
> weaknesses with knowledge (or state, or whatever the term du jour is)
> gained from the protocol stack implementation (and not just the data
> available via the BSD ioctl or Winsock interface).
>
> >     Is this a valid/reasonable approach or is it just hype?
>
> I don't know if I'd dismiss it entirely as hype. But I don't know if
> I'd say it adds dramatically to the security of the system in
> question.
> It's also quite possible that the vendor in question chose to go
> that route because of problems (performance/quality/interface)
> with the existing IP stack. I'm cheating here because I already
> know the poster was referring to a particular NT based product
> and I know the guys who wrote it -- a lot of the decision to
> replace the stack was based on early experience with NT's
> IP stack.
>
> Correct as usual.  Although two of the other primary driving forces
> were performance and security.  We wanted the higher levels of
> security that only an application layer gateway can offer with
> performance metrics similar to a packet filter.
>
> It would be very difficult to state definitively that any of these
> three criteria was the primary driving force behind the architectural
> and design decisions that were made with the Centri Product.  It was
> really the combination of all these factors that lead to most of the
> arcitectural/design decisions.
>
> Scott L. Wiegel
> Director, Software Engineering
> Cisco Systems, Inc.
> 107 S. State Street
> Monticello, IL 61856
> 217-762-2375