Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Aug 2015 13:43:48 +0200
From:      Kristof Provost <kristof@sigsegv.be>
To:        Ermal =?utf-8?B?THXDp2k=?= <ermal.luci@gmail.com>
Cc:        freebsd-net <freebsd-net@freebsd.org>, "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org>
Subject:   Re: Near-term pf plans
Message-ID:  <20150826114348.GA3433@vega.codepro.be>
In-Reply-To: <CAPBZQG2ERdcn-rqvKvtTm0%2B5fyk0_vjxMYdWd1YbgS02zAZ=bA@mail.gmail.com>
References:  <20150823150957.GK48727@vega.codepro.be> <CAPBZQG2ERdcn-rqvKvtTm0%2B5fyk0_vjxMYdWd1YbgS02zAZ=bA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2015-08-25 19:56:59 (+0200), Ermal Luçi <ermal.luci@gmail.com> wrote:
> On Sun, Aug 23, 2015 at 5:09 PM, Kristof Provost <kp@freebsd.org> 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 same
> >    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 should
> 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.

> >
> >  - 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 do
> >    updates on checksums assuming there's a full checksum. (Which is the
> >    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.

> 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.

> >  - PR 172648
> >    This bug started out with an issue with TCP reassembly, but I've not
> >    been able to reproduce that. There is a problem with rdr targets for
> >    ipv6 though.
> 
...
> I will try to look back at this but as a general rule look first at Open if
> they have already fixed this.
> IPv4 code has some security belts on such packets in pf(4) code to avoid
> doing the wrong thing.
> 
I think their checks in ip6_output() are less strict than ours. 

Regards,
Kristof



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150826114348.GA3433>