> I look at this as water under the bridge. Yep, it was complicated code > and now it works. I can run bittorrent just fine beyond an Apple > wireless router and I did nothing to make that work. Micro-torrent > just communicates with the router to make the port available.
So, the security model here is that arbitrary untrusted applications, running on an arbitrary untrusted OS, selected by people who have no understanding of computer or network security are allowed to update the security policy on the perimeter device. I can see why those secure NAT boxes have *totally* stopped the Windows botnet problem in its tracks... > Of course, no disagreement there. The real challenge is going to be > education of customers so that they can actually configure a firewall > policy to protect their now-suddenly-addressable-on-the-Internet home > network. I would love to see how SOHO vendors are going to address this. Permit any outbound Permit any inbound established Deny any inbound Achieves essentially the same functionality as a NAT device without the annoying mangling of addresses. Vendors could then continue to offer the UPnP "request a hole" functionality that they do today, or tweak the labels on their "forward this port" web GUI to say "permit the port" instead. For end-users who want to carry on doing exactly what they do today, the changes required for both them and their CPE vendor are trivial. For end-users who are currently frustrated by NAT, they have their real, honest-to-goodness end-to-end Internet restored. Everybody wins, apart those with a vested interest in "upselling" to "business" connectivity plans, or those who would prefer that the Internet is TV on new technology, and that end-users remain good little eyeballs, dutifully paying for their Big Business Content. Regards, Tim.
