Reknamorken wrote:

] Hrm... Why would the firewall mess with the sequence numbers?
] I guess it depends on the firewall. A PIX would, but a
] Checkpoint wouldn't, would it? I mean, the Layer 3+ stuff is
] all handled by the endpoints isn't it??

You are correct that it depends. If anything, the checkpoint is going to be more trouble then the pix. Things like fragment reassembly and certain kinds of syn defender gateways may cause a little bit of trouble. Eitherway, you are definately going to have to sniff the outbound traffic from the online firewall because you are not going to make the same port number decisions when NATing unless you have a very tight algorithm for this and you can ensure (HA!) that both firewalls are getting all the packets in the SAME ORDER.

] Although, now that you bring it up, the spying idea is really
] good. I bet you $$ this fixes the problems with state updates
] happening every 100ms (like Checkpoint).

I thought that most of the Checkpoints state sync slowness was related to VPN tunnels. If that is the case, this won't help.

] The secondary could
] stay completely up to date. It's not the like the CPU is
] doing anything important while it's offline anyway. I guess
] there is a chance of synchronization problems, but it seems
] unlikely. Also, it doesn't seem like they can get too far out
] of sync.

Far out of sync? One skipped packet will screw up a TCP connnection.
Additional out of syncness has no effect. The question is "How more difficult is this then what people are already doing? How great is the advantage? Does the advantage outweight the cost."

So far I'm not convinced, but I AM playing devils advocate.

] This Dan Kaminsky fellow is quite bright.

Indeed.

RE: Slashdot | Black Ops of TCP/IP: Paketto Keiretsu 1.0 Release