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

["Stephen P. Gibbons" <steve () aztech net>]

I'll yammer some more.  Feed-back is still appreciated.  :-)

Ryan Russell wrote:

> > 1) AG is the sole path to the "big bad Internet"
> > 2) Primary DNS resolvers are located on the same subnet as client
> machines.
>
> Why same subnet?  Do you mean just "inside" ?

I imagine that the pool of IP addresses available to the AG is limited,and
exhaustable. Enabling the AG to re-use the same IP address for
multiple client/server connections seems like a win and the easiest way
to do that is if the DNS query and client connection request are
correlatable.  This constraint could be lifted, with trade-offs.

> > 3) Primary DNS resolvers forward DNS resolution to AG, when they're
> confused.
>
> The only contain a table of "inside" hosts, yes?

Yes.

> > 4) AG has X number of IP addresses/virtual interfaces assigned to it and
> > configured.
> > 5) I've mostly been thinking in terms of outbound access, inbound
> shouldn't be that much different, though.
>
> > Straw-man:
> > 1) Client.local.goodguy.com requests an http connection to
> www.somesite.com
> > 1A) resolve www.somesite.com via dns.local.goodguy.com
> > 1B) dns.local.goodguy.com can't resolve it, so it gets forwarded to
> > dns.ag.goodguy.com
> > 1C) dns.ag.goodguy.com realizes that the request came from an internal
> address and:
> > 1C1) reconfigures an available virtual interface
> > 1C2) responds with this newly configured address instead of the A RR for
> > www.somesite.com
> > 1C3) keeps a state table of requests and responses
> > 2) client.local.goodguy.com connects to the A RR that it got back via
> recursive DNS.
> > 2A) ag.goodguy.com looks at the IP address/subnet that the request came
> from, and:
> > 2B) checks it's state table
> > 2C) then figures out which external host it should act as a proxy to and
> > proxies the connection.
>
> This sounds like a really clever hack.  It could rather neatly solve the
> problem of the AG not being transparent from it's point-of-view.

"It's point of view" meaning the client's point of view, yes?

> If you're hadning out a unique inside IP address per DNS name, so it

> can keep track of the real destination IP address, it think this is workable.

It's still a back-of-the napkin idea, but I think so too.

> Unfortunatly, it doesn't help my question.  There are two side-effects of
> an AG
> being not transparent, and I didn't break these out very well in my
> original note.
> One is that your client has to do something special in terms of delivering
> the packet
> to the AG (i.e. that will be the destination IP address of the packet.)
> You've got a potentially
> nice solution for that.
>
> The second is that the client program has the option to inform the AG what
> proxy it's
> speaking, and to what port on the final machine.  You browser could talk to
> the AG
> and say "I want HTTP at www.sun.com at port 80."  I don't imagine all proxy
> clients do
> this, some also probably just work off of port number.  But, the advantage
> here is
> that the client can pick a protocol independent of port number, i.e. it
> could ask for
> HTTP on port 23.

Ah.  The approach that I've outlined presumes the stance of "anything
notspecifically enableded, is prohibited."  The AG proxies should be
configuarable
so that it would be easy enough to allow HTTP traffic from a given client to
a given server on a given port.

I'm thinking that it wouldn't be horrendously difficult to write an AG proxy or

proxy "shim" that understood most of the standard initial protocol exhanges,
and could determine the protocol being used, even if it was running on a
non-standard port.  This should be relatively easy to do for most of the
useful TCP protocols, and would fit into the category of plug-GW on
steroids.  (The biggest concern here would be about keeping things simple
and straight-forward.)

There's still the option of running proxies that require client configuration,
so that if you need to be able to talk HTTP to www.sun.com on port 23
you can.

The ideas that I've presented were initially aimed at how to solve
the problem of using standard clients talking to standard servers on standard
ports with little or no user training, and getting the benefits of an AG vs.
relying on an SPF.  I think that some of the harder problems are also
solvable, but increase the complexity beyond the level of what one person
can write (and feel comfortable) with in a month or two (my original estimate,
for the basic functionality of what I outlined.)

--
Steve