Stewart Stremler wrote:
'Lazy programmers' in that they don't provide a way for me to spcify
the IP address to be broadcast and the port number to use. Calling
me wrong doesn't make 'em any less lazy.
If we are arguing that the NAT programmers are lazy, we might have some
agreement. I don't have any good way of interrogating a NAT to ask
"what is your policy?".
You're so caught up in doing it your own way, you're determining
the choices the owners and the users get to make without consulting
them. You're implying that the network belongs to the developers,
not to the local policy-makers.
I don't want to do it *my* way. I want to do it the way that *the
majority of users want it*. I am willing to bend whichever direction is
necessary to make that happen. The problem is that current NATs give me
no direction I can take.
I'm not saying everyone _should_ use NAT. I'm saying that all the
developers should offer the appropriate level of control to the
users and the owners so that they CAN use NAT.
And, if you notice, most P2P programmers do offer that control. Take a
look at connection options in any piece of P2P software. They're
generally a huge mess. All to cope with NATs.
Most P2P software would work beautifully in a world without NATs.
The problem ain't with the application programmers.
In fact, I *could* use fixed ports if the blasted NATs would just tell
me what port they dumped me on.
The developer provides software. The developer has TWO masters: the
owner, and the user.
If the developer provides software that violates policy, it's a security
flaw. If they provide software that fails if policy is enforced (but
the owner has no objection to the software per se), it's a usability
flaw. Either way, it's not a problem with the owner or the user.
And what happens when the owner is the user and has said: "No fixed
ports, I'm not clueful enough to touch my router configuration, so I
want autoconfiguration of P2P". The flaw is that the owner/user wants
two conflicting goals. And, when that happens, the user identity wins
out over the owner identity.
When usability and security conflict, security loses. Period.
When the security people finally get that, we might finally get more
secure systems. But that's a different discussion.
What we have with the anti-NAT sentiment is the developers are
determining policy. They've taken sides with the user and against the
owner, and are trying to usurp the role of "owner". They're designing
systems to subvert the controls put in place to enforce policy.
Absolutely, because the "owner" doesn't exist for 99.9% of these boxes.
The "owner" only appears when he gets in the way of the "user". There
is no "owner" to please; there is only the "user". And the "user" has
said "Own my NAT, please!"
(And yes, I know that NAT isn't a firewall, but the same controls that
one uses to get through a default-deny-for-incoming-connections firewall
are exactly the same as one uses for NAT. Get around NAT, you also
get around those (few) people who use the default-deny policies; even
if you don't, they do, and who are you to tell 'em that they're wrong?)
There are plenty of ways for an active owner to stop traversal. Even
with hole punching, there are still plenty of ways to stop this (RST any
incoming connection without a rule stops all TCP hole punching cold).
However, the inverse is not true. There are no good ways for a passive
owner to enable traversal. Nor is there a good way for NAT companies to
enable some mechanism that isn't complete ownage.
Anyhow, the longer I am at this, the less convinced I am about the
benefit of "default deny" in an end-user system. Even behind all these
"secure NATs", botnets thrive anyhow. But that's a different discussion.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
