Stewart Stremler wrote:
True. But if we're designing systems that won't work with such a
policy on the firewalls, that sort of policy is essentially *dead*.
No, I disagree. *Every* system fails on "default deny". Even HTTP.
Even FTP. Even ssh.
The fact that every firewall now comes with "HTTP enabled" *by default*
shows that default deny is *not* what most people want.
The choice is taken away from me, while protocols that *do* work with
such firewalls don't impose that sort of constraint on anyone else.
Again, there is no such protocol. Default deny blocks all protocols.
If it does not, then I agree with you, this is a broken firewall.
TCP is hard to replace ... you end up implementing something that looks
an awful lot like TCP.
Absolutely. It looks like TCP but goes through NATs. Good enough.
UDP doesn't go through NATs any better than TCP does. Same issues apply.
I must be missing your point here.
Actually, UDP does go through NATs better. It has to do with the fact
that UDP is connectionless and can reuse the same port multiple times.
Since UDP does not have the notion of a connection, the NAT basically
*must* let any UDP packets through from a port/IP that I have already
transmitted to. Thus, I can use the reverse UDP to set up connections.
Yes, this is an artifact of the UDP implementation of NATs, however, the
basic implementations of UDP tend to map a local IP/port to a single NAT
IP/port. Whereas every TCP connection, even if it maps to the same
local IP/port, often gets a new mapped IP/port.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
