Re: Transparent vs. Non-transparent AGs/SPFs/whatever

["Ryan Russell" <ryanr () sybase com>]

> You can use the "oh, its you, Bob" approach: poll the users, find out that
> Bob occasionally talks to some.host:2300 using telnet, and then add the
> state to your AG that connections that are identified as coming from Bob
to
> some.host on port 2300 should use the telnet proxy to connect.

Yes, I could set it all up ahead of time, and any conflicts would just be
tough luck for the user.  But that's one of the things I'm calling
unscalable.
But, that's a matter of practicality and not theory.  As usual, I'm mixing
both, but then I'm interest in both for this.

> The reason that transparent proxies can "get away" with using a telnetd
> proxy to intervene in conversations on port 23 is (1) that they have been
> given information that a telnet session is about to take place, and (2)
> they have been given authority to monitor that telnet session and ensure
> that the only information passed complies with the expected protocols of
> telnet.

Been given information meaning that by virtue of the fact that
I've run it on port 23, Im telling it to assume 23 is telnet, or something
else?  By giving authority you mean that I've given it responsibility
for that port because I installed it there?

> It is necessary and sufficient that the AG acquire the information on the
> nature of the traffic the user is trying to invoke, and acquire the
> authority to monitor and moderate that traffic.  If you have a complete
> list of protocols that users are permitted, and can unambiguously assign
> them based upon information available to the AG, and have application
> proxies for each of those protocols, then yes you can do what you want.

So, you argue that given perfect proxies, and enough information flowing
by, they can figure out the protocol (theoretically.)   I question if it's
that simple.
I can imagine protocols that would need some client interaction before the
proxy could determine which protocol it was.  For example, FTP and SMTP
look somewhat similar with the queries and response numbers and all that,
at least at the very beginning of the conversation.  If there were two
other protocols
that looked even close, it would be harder.  And, I can always design some
protocol that intentionally looks like another protocol until some branch
point.

The problem I see here is that you'd have to proxy things in "dumb mode"
until
the protocol was determine or you hit the branch point.  Or, maybe if the
protocols
look that close, you've got a good proxy that handles things until the
branch
point, and then it hands it off to one of two good proxies.

> From a practical standpoint, it sounds highly unscalable, especially if I
want to use a bunch of protocols.

> Note that "information available to the AG" can include table based
> information (i.e. the note that Bob uses telnet to connect to FW1 on 259
at
> partner.firewall.com) or it can include transaction state (i.e. after the
> handshake the remote side sent us a "login:" prompt) or it can include
> anything else you can think of, including a non-transparent butler on the
> client workstation that signals the AG what the user is trying to do.
> Comparing this against the effort of non-transparent proxies is left as an
> exercise for the reader.  :)

The shim idea (what you're calling a butler) could be workable.  The
problem there
comes with client support.  There may not be such a shim for a given OS.

I appreciate the thoughts.

I'll interject at this point in the thread:

Obviously I've ignored the fact(s) that no proxies this good probably
exist, that inside end-users
could always lie to the proxy, and that any protocol can be tunnelled over
any other.

                                   Ryan