[no subject]

[John Hall <jhall () F5 COM>]

Mike Lewinski wrote:
...
> Believe it or not someone recently gave me a similiar response as to why
> they were querying us for "version.bind". I think that they must have
> stopped that- I haven't seen it in a while, and I'm sure it generated lots
> of inquiries/complaints.

Mea culpa.  These people probably had an F5 Networks 3DNS box.  One of the
first probe types was a "version.bind" which, as you say, many network admins
found annoying.

The way these global load balancers work is to have the global load balancer
or in our case either the global or local load balancer at each data center
try to connect to the client to determine round trip time from the client
to each data center.  This information is then used to decide which data
center to send that client's requests to.  This method is surprisingly
effective (about 96% correct in our testing).

> If this is what they claim it is, I'd say it's poorly written to be hitting
> us so often, and to be assuming that their packets will make it even
> through...

I agree.  We rate limit these attempts to a few per minute and (I think)
give up after a few attempts.  This could be a new attack type, or
perhaps the reflected part of a DDOS (using random source addresses) on
a site with a global load balancer.

> I notice that one of the features listed at Cisco's web site is
> as follows:
>
> "Enhanced Server Verification with Multiple Port Connect Test
>  Prior to this enhancement, DistributedDirector could evaluate server status
> by performing a TCP connect test to a single port. The Enhanced Server
> Verification with Multiple Port Connect Test feature allows multiple connect
> ports to be specified. If any one of the connect tests fail, the server is
> considered down."

I can't authoritatively speak for Cisco :-), but this looks like *server*
(eg. web server) status checking rather than client status checking.  This
traffic would be between the web server and load balancer, not between the
client and load balancer.

> It's not clear to me if this test is going to the requested web host, or to
> our DNS servers or both.

Each global load balancing product uses its own set of tools to determine
the "distance" to the client from each data center.  Some try to connect
to the client, some to the client's domain name server, others through
other methods.  The goal is to improve the clients experience by giving
them the fastest access possible while also reducing costs by shortening
the path from client to server.

> It does seem dumb that a client who just sent a
> request would be considered "down", but I can also see how many firewalls
> will always be in conflict with a system like this. A good configuration
> will drop virtually anything sent from the remote server that's not a
> response to the original query, and since it's UDP there's nothing for the
> remote "load balancer" to measure latency against. If they ping or send tcp
> packets they'll trigger IDS/firewall rules. And they can't assume that the
> client is really a server, because incoming DNS requests could be similarly
> blackholed.

As I said, I think the feature you were looking at was for checking the
status of the site's servers.  As to your other points, they are somewhat
true.  It is an interesting battle trying to implement ways of measuring
the distance between the client and data centers without annoying the
client's network admin.  And it continues.  We have some new features on
our products that may make such probing unnecessary in the long run, so
maybe you'll see less of it in the future.  Our goal has always been to
provide the capability without triggering your alarms.

> Heh, this thing wants to portscan us, plus check that the webserver it's
> sending the client to is actually up. Probably DNS resolution takes so long
> that the "client" is sitting there repeatedly hitting the refresh button and
> bitching at their ISP (who's servers are being packet flooded by load
> balancers at the moment....)

I don't think port-scanning's the intent and I don't think that such
a product would last too long in the market.  Although I do know that
we are selling a lot of our gear to places that used to use Cisco's
solutions.  :-)

> Mike

--
John Hall <jhall () f5 com>                                      F5 Networks, Inc.
BIG-IP Test Manager                                           206-272-5555

In every non-trivial program there is at least one bug.