> No, the point is that the answer is a "band-aid" approach that requires
> a certain setup (the ability to intercept name requests and return fixed
> IPs). It is not a general solution that anyone can employ, and it
> requires a more invasive modification of someones network instead of
> just filtering (or allowing) a port on a firewall.

That's an over-dramatization. If you can't serve authoritative DNS to
your clients, then Google Talk is the *least* of your problems.

> It is a "band-aid" approach rather than a mature solution. If Google
> can't provide a mature way of preventing traffic *1 what does that tell
> you about the design of the program/protocol?

I've yet to meet a protocol designer who thought "Oh, people won't want to
run my thing, I should make it easy to stop it." I've said for a large
number of years that we, as an industry missed our chance to deal with
this when we let things tunnel over HTTP without just blocking HTTP to 90%
of the Internet and holding the line until protocol designers did the
right thing.

> With all the stunts modern IM solution perform in order to maintain
> network connectivity (tunneling even over telnet...sigh), the obvious
> answer is that these protocols are *designed* not to be circumvented or
> denied. The answer "oh, just modify your network so that name resolution

That's been true of every new protocol in the last 6 or 7 years, if not
longer. If you're going to let users install things, you're going to have
to deal with it. Software restriction policies, ACLs, etc. You can't
give up control of the end platform, then expect to get decent security
by blocking arbitrary ports.

Paul D. Robertson "My statements in this message are personal opinions
paul@compuwar.net which may have no basis whatsoever in fact."
http://fora.compuwar.net Infosec discussion boards

firewall-wizards mailing list