RE: Firewall performance

[David LeBlanc <dleblanc () mindspring com>]

At 09:59 PM 6/23/99 -0700, Ryan Russell wrote:

> > Depends on whether or not it's a proxy firewall or a filter. A
> > lot of the vendors that make NT-based firewalls access data just
> > above NDIS, then make a go/no-go decision at that point. Doing
> > that eliminates NT's IP stack entirely.

> Still has to use NT routing code, no?  Just not the socket calls.

No.  NT's stack looks like:

        NDIS
         |
ARP <-> IP <-> routing
         |
  TCP/UDP/ICMP
  |           |
  -------------
       |
     winsock
       |
     apps

Problem is that it is non-trivial under NT 4.0 to get to anything between
NDIS and winsock.  There isn't even a published interface to ARP (changed
in Win2k (5.0)).  Intercepting things at the Winsock layer is way too high
to do useful firewalling.  So what you do is bind to the NDIS layer (a set
of functions that are a direct interface to the NIC - no stack of any kind
involved), and then implement your own routing code.  That way, you're way
below anything having to do with NT's stack.  In fact, if I were writing a
firewall for NT, I'd completely unbind TCP/IP from the external interface,
and make that all my own code.

> This could still be significant, couldn't it?  I've read that the
> *BSDs can router IP with 1 memcpy of the packet, while Linux
> takes 3.  Not being terribly impressed with NT networking,
> I assume something equally bad or worse with NT.

A properly written firewall running on NT would copy the packet from the
buffer of one NIC directly to the other, and never even copy into main
memory.  Worst case scenario is you'd copy it out of one NIC into main RAM,
and then down into the other NIC, for a total of 2 copies.  That's if the
person writing the code knows how NT drivers work, and is writing efficient
code.  If you really want to do it right, get network cards with a bunch of
RAM on the cards, and then the OS serves only as a loader and an
administration interface - everything else is happening in the kernel.

Having ported a huge amount of UNIX-based networking code to NT, and having
ended up with a much faster app, I believe that the skill of the
programmers are often much more important than the OS.  Considering that
most firewalls started out on UNIX, and that the people who wrote the code
probably regard NT as foreign and strange, then it is no surprise at all
that the UNIX->NT ports are less than optimal.  So if there are performance
differences, it is far more likely to be a reflection on the people doing
the port than on the OS.  People who have a really good understanding of NT
driver development are pretty rare.

Personally, I question why we should have a general-purpose OS on top of
our firewalls at all - I think eventually firewalls ought to be appliances.
 Less stuff to go wrong that way.


David LeBlanc
dleblanc () mindspring com