On Oct 25, 2010, at 2:35 PM, S.P.Zeidler wrote: > Thus wrote Keith Moore ([email protected]): > >> It's understandable that network operators resist change - they're having >> enough trouble coping with the network as it is. But if I were running a >> company and my network operator came to me and said "I want to cripple our >> company's network so that it cannot easily support new applications that >> might be valuable to us", I'd fire him on the spot. Which is pretty much >> what NAT does. > > Question back, very concrete and not at all concerned with networking > ideals: > > Do you want your bank to allow you to attempt opening a connection to any > of their networked devices, trusting that the device itself will not have > any bugs that will allow a hacker to gain access to your bank account data? > Please keep in mind that a sizeable fraction of these machines will > be some variant of Windows.
Do I want a bank that runs lots of Windows boxes? Hell no. :) Here's what I want from a bank, or any other institution whose machines I have to trust: - trusted platforms are kept to a minimum. the system is designed so that most platforms are not trusted. - careful selection of trusted host platform hardware/os, and every application that runs on those platforms. (that pretty much rules out Windows right there) - regular auditing of trusted platforms to see that they're running unmodified apps and appropriate versions of those apps - a centrally-specified policy that says which apps run on which platforms, and what subset of those apps can communicate with untrusted hosts (any host not covered by that policy is inherently untrusted) - all communications between apps which require trust use strong authentication - merely using the source IP address to convey trust is not acceptable - frequent auditing of hosts to make sure that they conform to policy, with alarms when there is a discrepancy - network monitoring to make sure that traffic conforms to policy, with alarms when there is a discrepancy - one or more levels of firewall to make sure that traffic conforms to policy, with alarms when there is a discrepancy - isolation (e.g. firewalls) between hosts that run sensitive apps and ordinary hosts - user authentication into sensitive apps (e.g. those which can access multiple customers' data) requires multiple-factor authentication, at least one of which requires a credential that is incapable of being stored/cached/replayed. - "regression testing" against the policy and implementation to see that the policy permits known valid use cases and forbids known invalid use cases. - all transactions are logged - there's a very good mechanism in place for data recovery - etc. The salient point for this discussion is that the policy is flexible, and all of the mechanisms that exist to implement and reinforce the policy are also flexible. If there's a need to run a new application, the policy can be changed to accommodate it. Also, in a world where most hosts are mobile, it becomes less and less viable to try to divide the world up into trusted vs. untrusted hosts based on their IP addresses. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
