Neil Schneider wrote:
And the fact that developers can't document the network interfaces to
their software so that proxies can be built is a failure to understand
the requirements of network security. It always seems to be the fault
of the security admin because the application is badly behaved and
requires that all inbound ports be open to allow it to function.
Programmers should be denied the ability to write network software if
they can't clearly define which incoming and outgoing ports their
application will require.
I don't think this is the problem at all. The problem is that it is very
nice to be able to use ephemeral ports. But this is directly at odds
with NAT. SIP, for example, is a very well documented and understood
protocol. SIP proxies exist. But how can I get every NAT manufacturer to
put a copy of SER in their NAT device and tell the end users how to
configure their applications to utilize it? And we expect to do this
with every application non-trivial application?
NAT has nothing directly to do with security anyway as far as I am
concerned. The security component of any NAT device is just a packet
filter. Deny all incoming connections. You can do this without NAT.
At this point I wish HTTP would have been better if it were implemented
such that it did not work with NAT. Then we would all have been forced
to move to IPv6 a long time ago and this NAT sillyness would have died
the quick death it so richly deserves instead of making us all suffer
for years on end.
--
Tracy R Reed http://ultraviolet.org
A: Because we read from top to bottom, left to right
Q: Why should I start my reply below the quoted text
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
