deschall gateways, standard ports, and firewalls

C Matthew Curtin (cmcurtin@research.megasoft.com)
Wed, 21 May 1997 22:34:28 -0400 (EDT)


>>>>> "Chris" == C Mason <lmason@istar.ca> writes:

Chris> This sounds similar to my problem. I mentioned a few days ago
Chris> that our firewall (BorderWare) allows transparent access to the
Chris> internet (with no changes in the client software), but only on
Chris> standard ports. Obviously, with such a setup, no proxy server
Chris> is required, so we're basically out of luck connecting to the
Chris> key server. If the server could accept connections on any
Chris> standard port (ftp, telnet, ssh, http, mail, pop, etc.), this
Chris> would allow people in such a situation to participate.

Keep in mind that even in proxiless gateway configurations, it is
probably going to still be necessary to run the u2t gateway.

The reason is because the data being passed between clients and
keyservers is done through UDP datagrams. It is common practice for
Internet gateways to not allow any UDP packets back in through the
gateway, and often times, no UDP traffic is allowed out. (This is
typically because UDP does not have a concept of a "virtual circuit."
Even though TCP has extremely weak (i.e., nonexistant) authentication
mechanisms, there are some tricks that we can play in order to
determine if an inbound packet is an answer to one that originated in
our network (i.e., looking for the ACK bit to be set.) Other times,
it's simply because folks are usin application layer gateways that
won't support anything by default, which means that additional effort
will have to be spent in order to allow UDP to flow through the
gateway, which is typically something that an organization doesn't
want to have to do.)

With UDP, this is not an option, since there are no ACKs. Stateful
packet filtering and such things really can't be done. There are some
other tricks that can be played on the gateway to allow UDP to work
through in a theoretically more secure manner than just allowing it
all through, but these get kind of nasty, and lots of folks don't know
how to do these kinds of things anyway. Seems like many firewall
types are becoming increasingly dependant on their vendors for
providing their solutions, and dictating their possibilities.

(As a long time firewalls guy, I'll just note that this is a sad and
annoying trend, and leave it at that.)

Chris> (In fact, if it could allow tcp connections to a standard port,
Chris> we wouldn't even need the u-t script.)

Justin and I have been talking about running more gateways on port
8080, so that people with a configuration like yours would be able to
run the u2t gateway behind your firewall, point your clients at that,
and then have IT talk to our t2u gateway that will run on the existing
gateways, except on port tcp/8080.

Is there anyone who would like to participate, but won't be able to
get to tcp/8080, either? It would be optimal to address all of the
folks stuck with this problem all at once.

-- 
Matt Curtin  Chief Scientist Megasoft Online  cmcurtin@research.megasoft.com
http://www.research.megasoft.com/people/cmcurtin/    I speak only for myself
Death to small keys.  Crack DES NOW!   http://www.frii.com/~rcv/deschall.htm