--===============1264837743==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-jhzj4+iamEg5okK41Zcg"


--=-jhzj4+iamEg5okK41Zcg
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2006-06-19 at 19:55 -0400, Paul D. Robertson wrote:
> It's a reasonable first step. If the user has the ability to modify thei=

r=20
> resolver configuration, then that may be a bigger issue than running a=20
> chat client. [...]


> The answer given is enough to enforce the policy from casual abusers,=20
> which is really the goal of most protective policy measures. [...]



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.

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?

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
gets forwarded to a central box where you can split requests (like
dnscache) and either forward requests to upstream resolvers or provide
local responses for the domain in question, and then just return a fake
IP address to the client hoping that the OS trusts the DNS servers
response enough so that our application gets successfully tricked into
not connecting to our servers" ...(/me catching breath after that
sentence).... that answer sounds really like a lame duck.

I can think of a dozen Monty Python type gags that deal with such a
response....

("Here's our server, at IP 127.0.0.1." -- "But that's a loop-back
address!" -- "No, it's not, it's legitimate!" -- "It's not, it's
hookey!" -- "I beg your pardon? It comes straight from the name server!"
-- "But it's not a valid Internet address." -- "Yes, it is! See? It has
four octets!" -- "But it's not routable!" -- "But it could be!" -- "But
it's not, it's a dead address." -- "No, it's not, it's just
resting!" ...)

Cheers,
Frank

--=20
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.


--=-jhzj4+iamEg5okK41Zcg
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQBEl0eOGr6G9pK6fXURAnczAJwKZG26K2tHv6Ej3pRar1 ZJCGlMawCfTVbE
je2zLanPK9dt95Jzpb6D9hM=
=uSP9
-----END PGP SIGNATURE-----

--=-jhzj4+iamEg5okK41Zcg--


--===============1264837743==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
firewall-wizards mailing list
firewall-wizards@listserv.icsalabs.com
https://listserv.icsalabs.com/mailma...rewall-wizards

--===============1264837743==--