From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 23:22:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5D3C970 for ; Mon, 28 Jul 2014 23:22:00 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB0823F1 for ; Mon, 28 Jul 2014 23:22:00 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hMcVG4Yn1zB7; Tue, 29 Jul 2014 01:21:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1406589714; x=1409181715; bh=I0I gQemrj96+WcDG2XjxhzqQGsHtKOrmTHCRvj4GKPA=; b=JFHMqCtGBSdRLjRDnhW v7Yj/kJctjQk15uY8uvtU+zlMcceLilEiEiAC6ST6eEuMhZmzO0j16qntkPyNJcw +MMl89edoKoDZ9ndFL6h0BvJkeLKOPS5M7pb/SWd9D0TaedruC5nwy9RarxrXg/p Y3vnM/zv7ZMlS5JXxweoAhOs= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id fzkHIgLwAlpO; Tue, 29 Jul 2014 01:21:54 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Tue, 29 Jul 2014 01:21:53 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hMcV941KVzpf; Tue, 29 Jul 2014 01:21:53 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 29 Jul 2014 01:21:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2014 01:21:53 +0200 From: Mark Martinec To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD =?UTF-8?Q?=3F=20-=20does?= =?UTF-8?Q?=20it=20have=20one=20=3F?= Organization: J. Stefan Institute In-Reply-To: References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> Message-ID: <331930d6178ebbed522e9eddff0196fc@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Kevin Oberman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 23:22:01 -0000 > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed =20 > wrote: >> [...] >> IPFilter 5 does IPv6 NAT. >>=20 >> With the import of 5.1.2, map, rdr and rewrite rules will all work=20 >> with >> IPv6 addresses. >>=20 >> NAT66 is a specific implementation of IPv6 NAT behaviour. 2014-07-29 00:07 Kevin Oberman wrote: > And all IPv6 NAT is evil and should be cast into (demonic residence of=20 > your > choosing) on sight! >=20 > NAT on IPv6 serves no useful purpose at all. It only serves to=20 > complicate > things and make clueless security officers happy. It adds zero=20 > security. It > is a great example of people who assume that NAT is a security feature=20 > in > IPv4 (it's not) so it should also be in IPv6. >=20 > The problem is that this meme is so pervasive that even when people > understand that it is bad, they still insist on it because there will=20 > be an > unchecked box on the security checklist for "All systems not pubic=20 > servers > are in RFC1918 space? -- YES NO". The checklist item should be=20 > (usually) > "All systems behind a stateful firewall with an appropriate rule set?=20 > -- > YES NO" as it is a stateful firewall (which is mandatory for NAT that > provides all of the security. >=20 > I say "usually" because the major research lab where I worked ran=20 > without a > firewall (and probably still does) and little, if any, NAT. It was=20 > tested > regularly by red teams hired by the feds and they never were able to > penetrate anything due to a very aggressive IDS/IPS system, but most=20 > people > and companies should NOT go this route. I have IPv6 at home (Comcast)=20 > and > my router runs a stateful firewall with a rule set functionally the=20 > same as > that used for IPv4 and that provides the protection needed. >=20 > So putting support for NAT66 or any IPv6 NAT into a firewall is just=20 > making > things worse. Please don't do it! > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com You are missing the point, we are talking about NAT64 (IPv6-only=20 datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone=20 had a traditional NAT in mind. Consider a small site with uplinks to two service providers: it can use=20 ULA internally and translate prefix on each uplink. Please see these short blogs: - To ULA or not to ULA, That=E2=80=99s the Question =20 http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html - I Say ULA, You Hear NAT http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html - PA, PI or ULA IPv6 Address Space? It depends =20 http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html - Source IPv6 Address Selection Saves the Day =20 http://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.htm= l Mark