From owner-freebsd-pf@freebsd.org Wed Aug 26 12:50:34 2015 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCB0B99AF84; Wed, 26 Aug 2015 12:50:34 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 90AB961; Wed, 26 Aug 2015 12:50:34 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by ykbi184 with SMTP id i184so185328299ykb.2; Wed, 26 Aug 2015 05:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IoOHX2RFm6A9u1Mg2d+ncn0hSoMLEMF7L8ZY+JBSTlk=; b=pfneAVQa+owfoM+AgSORBji2cQ4g2yXDI4T3HzVsEmmLvhm2i5ftyYicJS3e4CRIrR I8IUdobP8+FnGjve8bAELIQKAT9+LmblzA1R2+IQtNfRCWxJen/kJPrkD5OQ89KEg60S XWfdS9sqQr6sVLVSZxDAYITUj0lP+ldi0Xno8FDR5tR3rKH0k2A0Vfz9ltBiS2LuYVjm vO/EVD9BzDU/4J0MqAY850l2UqC3M9bhUZMTCKtGQlQWaUcJIVZ3lk8CxF0bD4rQNUmE taxwVXqJgiGr63rycApoa42xT3LuWT1iOAK9SX0F2YY+k+lK4Z4dlXpu9CsvDfMTVEX6 DHkg== MIME-Version: 1.0 X-Received: by 10.129.78.85 with SMTP id c82mr41079083ywb.162.1440593433587; Wed, 26 Aug 2015 05:50:33 -0700 (PDT) Received: by 10.129.73.205 with HTTP; Wed, 26 Aug 2015 05:50:33 -0700 (PDT) In-Reply-To: <20150826114348.GA3433@vega.codepro.be> References: <20150823150957.GK48727@vega.codepro.be> <20150826114348.GA3433@vega.codepro.be> Date: Wed, 26 Aug 2015 14:50:33 +0200 Message-ID: Subject: Re: Near-term pf plans From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Kristof Provost Cc: freebsd-net , "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:50:34 -0000 On Wed, Aug 26, 2015 at 1:43 PM, Kristof Provost wrote= : > On 2015-08-25 19:56:59 (+0200), Ermal Lu=C3=A7i wr= ote: > > On Sun, Aug 23, 2015 at 5:09 PM, Kristof Provost wrote= : > > > > > I'm inclined to say that ifgroups and interfaces should share a > > > namespace. That would certainly help pf, because it uses both > > > interchangeably, which just doesn't work unless they're in the sam= e > > > namespace. That affects more in the network stack though, so I'd > like > > > opinions for people with more experience with ifgroups. > > > > > > > > > The solution is easy the scenario of interface name and group name shou= ld > > not be allowed. > > I do not see the use case for this to be allowed at all its just > confusion > > in general in pf(4). > > > Agreed. I'll see about putting together a patch to do that. > Ok, keep me in the loop for the review. > > > > > > > - Removal of frag drop / frag crop support in pf. > ... > > While those provide more security protection they do not always work as > > advertised so i agree on their removal. > > > Okay, I'll get the patch committed soon. > > > > - PR 198868, 193579 (TSO issues) > > > pf has issues on certain network interfaces with TSO enabled. The > > > most important of these are amazon VMs. > > > I believe the problem is that pf tries to work with packets with > full > > > checksums. Usually output packets have pseudo-header checksums in > the IP > > > and TCP headers. pf doesn't know about those. It always tries to d= o > > > updates on checksums assuming there's a full checksum. (Which is t= he > > > case, pf always calculates a full checksum in pf_check_out()) > > > > > > I believe the fix for this issue is to have pf be aware of the > > > pseudo-header checksums. The type of checksum can be determined > from the > > > CSUM_TCP and CSUM_TCP_IPV6 flags. Whenever pf changes a packet > header it > > > will have to check for those flags to figure out if the checksum > should > > > be updated or not. > > > > > > > > I would be inclined to say that the real solution is not check packets > > generated from the host, > This also applies to forwarded packets. Think of things like NAT or port > rewriting. We have to change IP addresses for nat, and thus also update > checksums. Normally you would expect those with correct checksum AFAIK since the input path validates those as well! > > > otherwise you will have to go into complicated checksum handling which > > might not be worth it. > We should end up with slightly more complicated checksum code (because > sometimes we'll update and sometimes we won't), but I expect it to > actually be faster. Right now we always calculate a full checksum on > outbound packets. In the new case we'll either not touch the checksum, > or only calculate updates (depending on scenario). > > > I know Open has done some work on checksum handling altogether which > might > > be a good reason > > to go and look there first. > > > Right, I'll check. > > After looking at Open code, their solution is to not check anymore checksums on pf(4) code but only mark them to be recalculated if pf(NAT/RDR/BINAT) touches the packet and let the OS mechanics deal with them. Certainly they went to length on doing this allover but it seems a better choice, also same effort as making the checksum handling right, rather than duplicating whole portions of code which are difficult to get right and keep in sync. How do you say that we try to do the same in FreeBSD and seems a better path in maintainability rather than a complex code that can get out-of-date soon. Relying on the protocol routines deal with checksum handling, since they have already the code, is the better path and with so many offloading features on the NICs nowadays it does not make much sense to have it on pf(4), taking also in consideration the input path verifies them and output path handles them properly even during forwarding and even during host packet transmission. This also has the benefit to increase the performance! > > > - PR 172648 > > > This bug started out with an issue with TCP reassembly, but I've n= ot > > > been able to reproduce that. There is a problem with rdr targets f= or > > > ipv6 though. > > > ... > > I will try to look back at this but as a general rule look first at Ope= n > if > > they have already fixed this. > > IPv4 code has some security belts on such packets in pf(4) code to avoi= d > > doing the wrong thing. > > > I think their checks in ip6_output() are less strict than ours. > Regards, > Kristof > --=20 Ermal