Or are you referring to the issue that some client/server type
interactions are broken when the client is behind NAT? This should
probably be fixable in most cases (I wouldn't call updating huge
installed bases trivial though), but that still leaves the
applications
and protocols that don't conform to the client/server model, such as
VoIP.
VoIP is still a client-server model when you get down to the individual
communications. For that matter so is UDP.
In any communication you have to have a listener waiting for attention
and a party that initiates the message transfer. This happens even
when you look at CSP type mechanisms where there is a symmetric
rendezvous.
What if two boxes want to have the same port open?
Same thing that happens when two processes on the same box ask for
the same port. The latecomer loses. Either that or the port is
assigned on a different IP address, these could be pooled at the
ISP level.
That is not a problem if you know about this restriction when you design
the protocol that is NAT listener friendly.
You could even build into the protocol a feature that would allow
a response of the type, 'the port requested is already in use by
machine at address 10.2.1.1, he is accepting requests to share
via protocol X on port Y'
Believe me, you are
just making the port number part of the address. Internal address
allocation (your RPC w/o RPC mechanism) is only one of the
issues that needs attention in this case.
Needs attention is not the same as 'impossible'.
It is very clear that the negative effects of NAT can be largely
eliminated if there is goodwill and an intention to succeed.
It is equally clear that the whole issue of NAT has been addressed
here with a complete determination to fail.
It's annoying when people complain about a problem when the
solution is right there in their face.
A 'solution' that requires action by parties completely out of
my control does not qualify as such in my opinion.
At present I don't expect much in the way of NAT deployment before
2015, and that is building in expectation of a major shakeup in
the management structure in 2010. If things go on as at present I
don't expect IPv6 deployed before 2025.
The main reason IPv6 is nowhere is the refusal to deal with NAT
except by ideological reactions like the above. NAT is the
way to deploy IPv6.
I don't follow.
NAT performs address translation. it is in effect an Ipv4 to IPv4
translator. Make that transparent and you can make Ipv4 to IPv6
and IPv6 to Ipv4 transparent in the same way.
The idea that "security" is a substance with an independent existance
which underpins a "security industry" is also fatally flawed.
(And one
of the main reasons why I chose to avoid becoming a part of said
industry.) Security is a property of all aspects of life and must be
managed as such.
Which is why the empirical observation that firewalls significantly
reduce the number of successful penetration incidents is important.
The theoretical strength of a firewall against the NSA is irrelevant
when 99% of the attacks are from script kiddies. Filtering out
the 99% of script kiddies allows more time to focus on the remainder.
Right! When the firewall considers IE 9.2 safe it may allow it to
communicate freely, but at a later time, when a vulnerability
is found
and (hopefully) a new version is installed, IE 9.2 isn't allowed to
connect to the rest of the world anymore, or only to trusted
destinations. This mechanism would also be great to catch trojans and
other unauthorized software trying to communicate over the net.
Yes, and sign the messages under a key protected by the trustworthy
computing base.
That is where Palladium gives real value.
Phill