Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-histori

> > From: itojun(_at_)itojun(_dot_)org [mailto:itojun(_at_)itojun(_dot_)org]=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(_at_)ietf(_dot_)org
> 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(_at_)isc(_dot_)org

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf