> > From: itojun@xxxxxxxxxx [mailto:itojun@xxxxxxxxxx]=20 > > >=20 > > >Its not exactly a surprise, folk seem to place a higher premium on=20 > > >shooting NAT than anything else. Meanwhile the vast majority of=20 > > >residential broadband access is behind NAT. > > > > > >And from a security point I want to see as much NAT as possible.=20 > > >Without NAT we would be in a much worse situation security=20 > > wise than we=20 > > >are today. NAT is a blunt instrument but it shuts down=20 > > inbound server=20 > > >connects. And that is such a good thing from the point of view of=20 > > >stopping propagation of network worms. > > (snip) > >=20 > > a few points. IPv6 technology really needs to be demystified. > >=20 > > you do not have to rewrite IP address to ensure that there's no > > inbound connections. you just have to have a packet=20 > > filter which > > watches/drops TCP SYN or whatever alike. if you do not=20 > > have enough > > address space to serve your enterprise, it is a good=20 > > reason to use > > IPv6 :-) > > My point here is that the principal objection being raised to NAT, the = > limitation on network connectivity is precisely the reason why it is = > beneficial. > > There is no other device that can provide me with a lightweight firewall = > for $50. We ask for one. Don't say "I want NAT" say "I want a stateful firewall". That's what you are really asking for and getting a lot of other @#$%%n in the process. Every $50 PNAT vendor could deliver you a stateful firewall at the same price point. It's only a matter of removing the address translation. > > if=20 > > you have RFC3041 > > and other tricky systems, your system will have higher=20 > > likelyhood of > > having implementation bugs (violation of KISS principle). > > Same can be said of IPv6. > > We have a lot of really good ways of avoiding issues we don't like: = > complexity, accessibility, limited access in third world countries.=20 > > Unless the arguments are applied consistently they should not be made at = > all. Otherwise they just become special pleading. > > > > even if you stop all inbound connections, malicious=20 > > parties which > > controls HTTP/whatever servers can inject your end node=20 > > any kind of > > crufted TCP options, which might cause buffer overflow=20 > > (DoS/privilege > > user hijacking).=20 > > As I told Bruce Schneier after his silly IPSEC and Certification = > Authority papers, security is risk control, not risk elimination.=20 > > It is not helpful to criticise a security measure that empirically = > offers a high degree of security for failing to address cases it is not = > designed to deal with. An HTTP server behind a NAT box is no HTTP server = > and thus no threat. > > In a full default deny infrastructure I can allow the HTTP server = > external access and deal with issues such as HTTP server corruption by = > requiring the HTTP server to run in an isolated O/S partition so that = > compromise of the server cannot lead to compromise of the host. > > > > spam, phishing and botnet are independent from=20 > > presense/absense of NAT. > > I can shut down 95% of existing botnets using reverse firewalls. I have = > yet to find a legitimate network use with an access pattern that = > remotely resembles the access patern of a production botnet. > > The approach I propose in the dotCrime Manifesto is that by default the = > newtork access point throttles outgoing SYN and DNS requests to some = > large number that is well short of the needs of spammers, DDoS SYN = > flooding etc. > > > OSes have to be secured by default, that's all. > > Linux is ten million odd lines of code. When you have more than a = > million lines of code you can be certain that at least 50% of the people = > working on it were below average in talent. Vista is ten times bigger. > > We simply don't know how to build a secure operating system today. > > > > heavy use of firewall/ > > NAT have propagated "false sense of security" inside enterprise > > The 'security through obscurity' argument is bogus.=20 > > Back in the early 1990s people were arguing AGAINST the use of shaddow = > passwords in UNIX on the grounds that they give a 'false sense of = > security'. > > I agree that most enterprises have an exagerated idea of what perimeter = > security can do for them, but that does not mean that the solution is to = > drop all the firewalls. That is not what is being discussed when people = > are talking about deperimeterization. > > > > network, and therefore, many of end systems within=20 > > enterprise are very > > vulnerable to attacks. the most common attack vector=20 > > these days are > > laptops owned by people like IETFers (goes in and out=20 > > of enterprise) > > or VPN-connected laptops, which carry worms. so, many=20 > > people purchase > > end node firewall systems ("fire suit" in the old=20 > > terminology), but, > > if your end node operating systems are secure by=20 > > default, you do not > > need those end node firewall systems and/or keep=20 > > upgrading signature > > files. > > There is no individual security control that cannot be trumped. Host = > based security can be disabled if the host is compromised. We don't yet = > have the trustworthy systems we need to prevent that attack. > > There is no individual security control that cannot be trumped, but we = > can deploy combinations of security controls that make it very much = > harder for an attacker to succeed. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf