Re: Thoughts on firewall performance draft

["Michael C. Richardson" <[e-mail]>]

>>>>> "Kevin" == Kevin Dubray <[e-mail]> writes:
    >> This is wonderful as clarifying concept or term on which to build.  As
    >> a stand-alone metric, I'm not so sure .  You referred to measuring
    >> connection concurrency.  This is something that I can and probably
    >> should measure wrt firewalls.  A connection overhead metric may yield
    >> better insight how an IUT "lifts" or handles connection maintainance.

    Kevin> Kevin, I'd like a clarification of what's meant by "connection
    Kevin> overhead." The memory cost of opening a socket is

  Given n current connections, how much time does it take for the n+1'th
connection to be opened.

    Kevin> implementation-specific, and a DUT/SUT that uses 100 kbytes of
    Kevin> memory for each connection may or may not move bits on the wire
    Kevin> more slowly than one requiring only 10 kbytes. That's a firewalls

  The internals issue is more to do with the kind of data structure that
is used to store the connection state. Also, whether or not a new process
needs to be created to handle that connection.

    Kevin> Another option is to make the connection definition(s) very
    Kevin> specific to the workings of TCP, UDP, and ICMP, and count only
    Kevin> those conversations which have successfully navigated the setup
    Kevin> procedures of each protocol.  I'm reluctant to do that; better to
    Kevin> have a more general definition.

  ICMP isn't a protocol in the same way TCP and UDP are. TCP and UDP make use
of IP services. Some of these services are carried by ICMP datagrams.
  A firewall that doesn't consider an ICMP MUST FRAGMENT to be associated
with a TCP connection (i.e. Path MTU discovery) is violating the IP protocol.
[The firewall needn't let it in: it could process it locally, adjusting
its own view of fragment size and perhaps emitting an ICMP out the other
end.]

  The only ICMP that may consistute a protocol *may* be ECHO/ECHO RESPONSE.

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |	SSH IPsec: http://www.ssh.fi/. Secure, strong, international
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[e-mail]</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">[e-mail]</A>.