From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 03:42:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B408CB11; Fri, 25 Jul 2014 03:42:04 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D1E82B00; Fri, 25 Jul 2014 03:42:04 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 1471365D; Thu, 24 Jul 2014 20:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1406259724; bh=RFXkQFhwYGC630bSR4OUCowUxREFPMuNLY35uLH6GsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SDLNisqdmHd3/2vp5BzDirAqv53BvrTZg6VW9rD90b1eEPXikyAAUHDUK7JWlGO9Y Tzu4w32R1/AzHhnxWQ7Jgayr2OxPXh4WMd52U/Mxd0TWhUumYcPCAh93HUlI9LIqou VWy/zRD9TCTlUWRCA3vzETKkU9aJ2AUsKVw1y+fI= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Date: Thu, 24 Jul 2014 20:41:59 -0700 Message-ID: <13225341.zrHnT6Xi7E@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <201407231542.s6NFgX4M025370@slippy.cwsent.com> <53D01DDD.8000806@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1803975.B8PWlyEuu6"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: "Bjoern A. Zeeb" , Allan Jude 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: Fri, 25 Jul 2014 03:42:04 -0000 --nextPart1803975.B8PWlyEuu6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Wednesday 23 July 2014 20:59:19 Bjoern A. Zeeb wrote: > On 23 Jul 2014, at 20:41 , Allan Jude wrote: > > On 2014-07-23 16:38, Bjoern A. Zeeb wrote: > >> On 23 Jul 2014, at 15:42 , Cy Schubert = wrote: > >>> Taking this discussion slightly sideways but touching on this thr= ead a > >>> little, each of our packet filters will need nat66 support too. P= f > >>> doesn't > >>> support it for sure. I've been told that ipfw may and I suspect i= pfilter > >>> doesn't as it was on Darren's todo list from 2009. > >>=20 > >> our pf does support IPv6 prefix rewriting quite nicely and has for= years. > >=20 > > Bjoern: What IPv6 stuff does our pf not do well? >=20 > I think the most pressing, as Peter said, is fragment handling, thoug= h a > good fraction of major content providers seems to do mss clamping to = a min > IPv6 mtu on IPv6 and drop fragments at the edge (not much different t= o > IPv4, which makes you wonder?). Whoever is clever will think of ho= w many > different queueing and fragment handling implementations we need in t= he > kernel, and how often we have to do it on an end node that might also= run a > firewall, pick one we have, turn it into a library thing, apply it t= o all > places, and then add the latest IETF suggestions on top of it. Correct. There is code in the openbsd cvs history where they added it while the=20= internal APIs looked similar enough to ours. It's simpler than ipv4=20= reassembly - taking advantage of things like overlapping fragments not = being=20 allowed. I'm almost desperate enough to take a shot at it myself, but mbufs and = I do=20 not get along. Nobody wants code I've touched to be in the tree if mbu= fs are=20 involved. The initial commits.. first the supporting changes: (refactor code for reuse) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff= ?r1=3D1.128&r2=3D1.129 (add ipv6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf_norm.c.diff= ?r1=3D1.129&r2=3D1.130 Then they added the code to defragment/refragment: (pf_test6 defrag/refrag) http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=3D= 1.729&r2=3D1.730 The catch is that they fixed a lot of edge cases so one needs to follow= the=20 history forward a bit to make sure it it's covered. The other problem = is our=20 codebase is even older than when this was added so some looking at olde= r=20 commits is required. In the time since the feature was added, they have refactored it a few = times=20 and merged the two code paths for ipv4 and ipv6. It bears no resemblan= ce to=20 what we have in our tree. The killer reason why this is a problem that needs to be solved.. IPv6 = +=20 DNSSEC exercises this code a lot. Performance isn't a factor - it's basic functionality that's at stake. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart1803975.B8PWlyEuu6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT0dILAAoJEDXWlwnsgJ4EAHQH/iMghRDgsUtmVXFbDXbq7hK/ U2DMMFOp61HYHNgDLDfPpXnTfF8iC6T0yqndLk0n9V8Lxxf+Vwfb2Q8sEBeoIWRb t7fy6Au9DXB/4zCvm+Ux2m7f2p0pfSkUVVps2J55y8tcxXeYFjT5ngHdGIlHFd7s vSOsLfRpwYiMat17S/9GJCNxjYMQvrFSRo+2PNye3MYTTcqnICun92RshTGHWXvr oGhEdBp0h9FHTj2lB0x5jHhoBzZxZM0GzYZPno/FjBfSG/s70+cOxvvzWTmB6W4j swDMSthmxzq1Rc0Bp6N0HQb3In0K/UAprvho99rn4d1ow9DfEw8rfn5xjUKq8KM= =+cIU -----END PGP SIGNATURE----- --nextPart1803975.B8PWlyEuu6--