Subject: Re: Thoughts on firewall performance draft

From: "Michael C. Richardson" <[email-masked]>
Date: Tue, 23 Jun 1998 21:44:48 -0400

>>>>> "Kevin" == Kevin Dubray <[email-masked]> writes:
    Kevin> My point: while citing connection as a concept/metric is helpful,
    Kevin> it is even more helpful if you can help me identify and understand
    Kevin> key relationships with respect to nature of connections and
    Kevin> firewalls, rather than hoping I infer them from a broadbase
    Kevin> definition.

  The tcpsat group has some definitions for different ways of accelerating
TCP over high bandwidth*delay links that might prove useful. 
  I'll try to dig them up.... hmm. no archive listed.

   :!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">[email-masked]</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">[email-masked]</A>.

---

From: [email-masked] (Kevin Dubray)
Date: Tue, 23 Jun 1998 20:24:56 -0400

Even more thoughts. ;-)

> 
> Bit forwarding rate
> The number of bits per second of allowed traffic a firewall can be observed
> to transmit successfully to the correct destination interface in response
> to a specified offered load.
> 
> This definition is firewall-specifc in two ways: First, it specifies
> measurement in bits rather than frames. Second, it specifies measurement of
> allowed traffic--traffic the DUT/SUT is *supposed* to forward as defined by
> a given rule set. Not also that "specified offered load"=!"allowed traffic"
> since it may be desirable to offer a mix of allowed and illegal traffic.
> 
> As an aside, John Dawson remarked after the meeting that buggy
> implementations may forward illegal traffic, and the current definition for
> "rejected traffic" doesn't cover that case (it simply assumes a firewall
> will forward all allowed traffic and drop everything else). To address this
> I plan on adding a definition for "illegal traffic" (traffic not allowed by
> the rule set, regardless of whether it's forwarded or rejected).

Hi David,

Alternatively, you might try:

 The number of bits per second of traffic a firewall can be observed
 to appropriately transmit to the correct destination interface(s) in response
 to a specified offered load.

This wording may help the move the burden from the user identifying classes of
traffic to a firewall discriminating what is to be forwarded - illegal,
blocked, malformed, wonderfully hunky-dory, or whatever.

What constitutes appropriateness for the collection of this metric can be 
defined in the companion methodology document.

I would also consider substituting "device" for "firewall" in the definition.   

> 
> Here's what I would propose:
> 
> Connection
> A state in which nodes agree to exchange data using a known protocol.

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. This is good stuff to help me 
better understand the behavior of my firewall.

My point: while citing connection as a concept/metric is helpful, it is even
more helpful if you can help me identify and understand key relationships with
respect to nature of connections and firewalls, rather than hoping I infer
them from a broadbase definition. 

-Kevin