Well, the article is out, including the small sidebar on what state seems 
to mean to each of the five contenders.  The article only looked at 
stateful failover capable firewalls.

TCP state blurb and chart: 

Full article by Brian and Greg: 

Not in the article or sidebar, How We Did TCP Shenanigans:

We wanted to evaluate the firewalls' ability to discern one client
connection from another, and to stamp on spoofed packets. So, on the same
testbed as the stateful failover tests, we set up a Linux (2.2.19 kernel)
client in place of the Caw client emulator, and sniffed on each side of
the firewall.  Using netcat, we then created a simple connection from the
client, through the firewall, to the test server's http service:

	nc -n 192.168.2.11 80

...thus creating and leaving the TCP connection established.

Next, we used "sendip," by Mike Ricketts, (sendip home),
to generate our test packets.  "Sendip" ensures correct checksums for
the packet, and allowed us to arbitrarily manipulate most header
fields.  We then performed the following tests, using a fresh client
netcat connection for each test:

 1. spoof an ACK with IPs, ports and sequence numbers correct for the next
packet (a perfect spoof), which required we also spoof an RST to stop the
ACK storm
 2. spoof an ACK with IPs and ports correct for the next packet, but
sequence numbers way out of window (+/- 3,000,000+)
 3. spoof an ACK with IPs and ports correct for the next packet, and
sequence numbers out of series, but within window, which required we
also spoof an RST to stop the ACK storm
 4. spoof a RST with IPs and ports correct for the next packet, but
sequence numbers way out of window (+/- 3,000,000+)
 5. spoof a RST with IPs and ports correct for the next packet, and
sequence numbers out of series, but within window
 6. spoof an ACK with IPs correct, but client port incorrect, sequence
numbers way out of window (+/- 3,000,000+) (a "Rogue ACK").


(a variation on the below is in the article)

Packet 1 is a control that tests whether we are generating good,
believable packets.  Packet 2 tests whether the firewall cares about
sequence numbers for ACK pakets. Packet 3 is a semi-perfect spoof, and
tests whether the firewall is being TOO strict with ACK packets, which
should be able to arrive out of order, within the acceptable window.  
Packets 4 and 5 test whether the firewall handles RST packets any
differently -- whether looser because they can abort problem sessions, or
stricter because they present high denial of service risks in some
environments.  Finally, packet 6 tests whether the firewall is really
looking at "state" for connections to a server it is guarding, or whether
it is functioning as a basic packet filter for such services.

Results (for those not going to the graphic pretty chart in the article):


FW		Block good port nums but BAD Seq ACK?	Permit in-win ACK?
-------		-------------------------------------	------------------
PIX 535		yes					yes		
Netscr 1000	yes					yes		
Nokia 530	no					yes		
FW1-NG (sparc)	no					yes		
Stonesoft	no					yes		
Lucent Brick	no					yes	



FW		Block good port nums but bad seq RST?	Permit in-win RST?
-------		-------------------------------------	------------------
PIX 535		yes					yes 	
Netscr 1000	yes					yes 
Nokia 530	no					yes	
FW1-NG (sparc)	no					yes	
Stonesoft	no					yes	
Lucent Brick	no					yes	


FW		Block rogue ACK?
-------		----------------
PIX 535		yes
Netscr 1000	yes
Nokia 530	yes
FW1-NG (sparc)	yes
Stonesoft	yes
Lucent Brick	no

"rogue ACK" == ACK sent with client-side port number wrong, and both
sequence numbers well out of window (+/- > 3,000,000)