Thanks to all who responded to my post about UDP proxying. Here's
some comments and summary:
Most replys were responses to my saying:
> We've based our protocol on both UDP and TCP and have significant
> reasons for wanting to use UDP. I've seen some reluctance from
> folks here to pass anything that smells of UDP.
This last sentence was more in humor than my not understanding the
problems. But thanks to all who tried to educate me on the subject.
My basic question is how to support firewalls if we are developing
a protocol based upon UDP. Should we use an existing mechanism like
SOCKS V5 or build our own. Most replies said "just say no" to UDP.
What I may not have made clear is that we have included strong per
packet authentication to our protocol which hopefully will calm
most sysadmin's fears.
About all I got was a couple people who said they don't use SOCKS
and a couple who want real application proxies. Is a "real application
proxy" just one written for a specific application?
Responses:
---------------------
> From proberts @
clark .
net Sat Jan 27 22:10:47 1996
> I have some specific proxy ideas that I'd like to discuss, to see
> how much their impact on the development process is. I'd say a
> *really* good start would be a fixed port number on both the client and
I don't think I like the idea of fixed port numbers for the client.
This would not allow multiple clients to run concurrently and may
make the client more prone to attack. Any comments on that last
statement?
> > BTW, does anyone use SOCKS? Is it worth supporting now?
>
> I'd like to see real application proxies. Socks isn't in use at any of my
> company's sites (so far as I know), though V5 is starting to look
> interesting.
> > Actually, we are trying to build in a fairly high level of
> > authentication into the protocol.
>
> Authentication of the client, or the packet?
Authentication is on a per packet basis.
---------------------
> From: Ted Stockwell <stockwel @
sctc .
com>
> > BTW, does anyone use SOCKS? Is it worth supporting now?
>
> I can't say. Sidewinder doesn't support socks because it, like other
> firewalls with transparent proxies, doesn't need it.
>
> > What would other firewall maintainers want out of a company
> > developing a new protocol based upon UDP?
>
> That's a tough question. I'd like to understand the networking
> requirements of the application better, and then look at what this
> means for a firewall.
The clients are meant to run continuously while a user is logged in
and will occasionally need to send small messages to the server. The
server may send small messages back to the client at any time. It
would not work well to keep a TCP connection open at all times and
the messages are small enough that TCP overhead is significant to
set up a connection for each message.
---------------------
> From: Darren Reed <avalon @
coombs .
anu .
edu .
au>
>
> > Basically my question boils down to this:
> > If you have to create a new protocol what is the best way to
> > support firewalls?
>
> Make sure it can work with an application level gateway of some
> sort, invisibly, if need be.
>
> > What would other firewall maintainers want out of a company
> > developing a new protocol based upon UDP?
>
> A protocol spec including rationale for using UDP ?
>
> However, if I read your mail right, your new protocol isn't UDP or TCP,
> but a protocol at the IP level. You might wish to submit an RFC to the
> RFC as experimental or even submit it to the right group as a draft for
> movement through the official standards track. Or even do this anyway ?
Actually, we do plan on using UDP as the basis if for no other reason
then UDP seems to be the lowest overhead protocol available above IP.
I suppose we could build directly ontop of IP but I'm not sure what
implications that might have on things like network routing, filtering,
firewalls, cross platform availability, etc.
---------------------
> From: Tim Keanini <blast @
crl .
com>
>
> > > We've based our protocol on both UDP and TCP and have significant
> > > reasons for wanting to use UDP.
>
> I would like to take a few lines to put my spin on this.
> Protocols "work" when they can implement the policy to the letter.
> If the policy is based on who has initiated the connection, that
> sort of policy sticks well to TCP but slides right off of UDP.
> [...]
> Things start to get real interesting when you have a policy like
> "anyone with a blue hat can enter" and all you have is a doorknob
> to work with. Time to call MacGyver.
The idea is that there is a client and a server. The client can
talk to the server and the server can talk to any of the clients.
Every UDP packet has authentication information to validate if
the packet was actually sent by who it supposedly came from.
> The state based packet filters help you "manage the risk" of
> not knowing who really set up the connection of UDP but that
> is something that is all that we can do.
>
> If we are doing anything right, our job is to manage risk.
If I've done my job right, the proper management of those risks
will have been built into the protocol with sufficient assurance
that it cannot easily be hacked.
Thanks, Jamie
|
|
