[AG-TECH] Access Grid 3.0 beta1 available !

[Frank Sweetser]

On Tue, Jan 31, 2006 at 10:28:15AM -0600, Ivan R. Judson wrote:
> 
> I think the interesting question from a user perspective is:
> 
> Would you rather open one port and we tunnel all traffic through it (and
> you'll never know about all the types or kinds of traffic) or make it easy
> to have one tunnel per type of data/connection that's easier to open/close
> and audit based on actual use?

I'd say this is more from a developer perspective (as I find users want it to
"Just Work"), but yes, there is that issue too.  A frightening example of this
is the Windows RPC over HTTP feature that was introduced awhile back as a way
to do Windows RPC past firewall admins that wouldn't let you.  It basically
takes a whole collection of APIs that were known to have security problems in
the past, and muxes them in with tons of legitimate web browsing HTTP traffic.

> I *think* the future is in the latter, because you can easily see a
> manageable system being built that allows programmatic (with authentication
> obviously) access for dynamically opening and closing tunnels based on
> specific "contracts" about usage, data, src/destination, duration, etc.

At least for low to medium security situations, sure.  The Linux NAT/firewall
code actually already does things along those general lines.  For example, the
FTP module snoops the FTP control session, and dynamically creates firewall
openings and NAT state table entries to accomodate the otherwise filtered data
sessions.  This becomes a bit trickier when dealing with firewalls outside of
your administrative domain, though.  

In the meantime, though, it just has to be balanced against how much
administrative work it takes to manage the firewall.  The smaller and more
static the port list used, the easier it is for the firewall admin to open
them, and the easier time you'll probably have convinving him to do so.  It's
pretty rare you can make everyone completely happy here, so you end up aiming
for what I like to call a "minimally unacceptable" solution ;)

> I can't see any good way to justify "opaque aggregate tunnels" that hide the
> fact a break-in occurred in a mess of other data.

True, though I find that when a break-in occurs, they usually bring enough
other garbage along that they're easy enough to find.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Network Engineer          |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC