Re: Gauntlet adaptive proxies

[David Bonn <David.Bonn () watchguard com>]

> > > > > "Fred" == Frederick M Avolio <fred () avolio com> writes:

Fred> In my experience, people want a dial or lever, with high security at one
Fred> end, and usability or speed on the other. I don't think the NAI adaptive
Fred> proxy exactly gives that. But it does give *some* granularity in setting.
Fred> For example, as Darren pointed out, it would be nice to have the
Fred> granularity of a proxy for FTP setup and command processing, but to have
Fred> the speed of a packet filter for the file transfer. Or let's look at
Fred> HTTP. I could, perhaps (I've only read the paper, not played with it)
Fred> select any of the following:

...

Those two examples are really two separate problems.  FTP (and a bunch 
of other services like RealAudio) are well-served by a proxy control
channel and packet filtering the data stream.  WG has been doing
*that* for FTP since 1996.  The presence of network address
translation greatly complicates this, and getting all of the cases
right and testing them is ugly.

"Filterizing" HTTP and other protocols after studying the first part
of the data stream is (to my mind) a lot harder.  We've discussed it
for a long time, but once again it got way ugly.  You'll need to deal
with all of the NAT issues, but also rewriting all of the TCP sequence
numbers.  I gave up when we came to incompatible TCP options and
window sizes that could easily be way, way out of sync.

It seems easier to pass the pair of sockets representing the proxy to
kernel mode and deal with them there.

David Bonn
CTO & VP Engineering
WatchGuard Technologies, Inc.