Near-term pf plans

[Ermal Luçi]

On Sun, Aug 23, 2015 at 5:09 PM, Kristof Provost <kp at freebsd.org> wrote:

> Hi,
>
> Some of you may have noticed that I fixed a couple of pf issues (or in
> some cases broke things. Sorry Allan.) recently.
>
> Here's a quick list of my current priorities:
>
>  - PR 127042, 202178:
>    This is a panic when an interface an ifgroup have the same name.
>    There's a fix for the immediate problem in
>    https://reviews.freebsd.org/D3435
>
>    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).


>
>  - PR 202351
>    This is a panic after ip6 reassembly in pf. We set the rcvif to NULL
>    when refragmenting. That seems to go OK execpt when we're refragmenting
>    broadcast/multicast packets in the forwarding path. It's not at all
>    clear to me how that could happen.
>
>  - Removal of frag drop / frag crop support in pf.
>    pf has two (or really three, but crop and drop mode are very similar)
>    ways to handle fragmented packets. I've recently extended the
>    'reassemble' mode to also work for ip6.
>    The crop/drop modes really only verify that fragments make sense
>    (i.e. don't claim to deliver data beyond the last fragment, or duplicate
>    data).
>    I'd like to remove support for the crop/drop modes for two reasons:
>     * the code is relatively large and complex. I've already run into a
>       couple of problems related to it.
>     * It doesn't do what users expect. Enabling scrub fragment crop
>       doesn't actually mean pf will filter on the entire fragment. You
>       still end up having to let all fragments pass through the
>       firewall.
>    There's a patch to do just that here:
>    https://reviews.freebsd.org/D3466
>
>
While those provide more security protection they do not always work as
advertised so i agree on their removal.



>  - 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,
otherwise you will have to go into complicated checksum handling which
might not be worth it.
I know Open has done some work on checksum handling altogether which might
be a good reason
to go and look there first.


>  - PR 188511
>    divert-reply implementation for pf
>    I need to review the use case and implementation of the work done by
>    PiBa.NL.dev at gmail.com
>
>
I am aware of the patch just do not think this will be a good candidate for
inclusion.
First divert sockets are slow and should not be advertised for use unless
properly fixed.
Second the better implementation in general, which is on my roadmap, is
convert the route-to/reply-to
keywords to the same implementation as ipfw fwd and that will reduce code
complexity and provide
proper functionality for the scenario the patch is written.


>  - 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.
>
>    With rdr to ::1 we fail the scope check in ip6_input() (right after the
>    pfil hook) because we have a packet to localhost with a
>    m->m_pkthdr.rcvif which is not a loopback interface.
>    That can be fixed by having pf rewrite the rcvif, but that'd
>    special-case rdr to ::1.
>
>    We've got a similar problem for the reply. There we've got a packet from
>    ::1 to something else. This fails the scope lookup too.
>    In essence the problem is that we've already made the routing decision
>    before pf gets the chance to rewrite the destination address.
>
>    I'm not quite sure how to fix this 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.


>
> If anyone has any comments or questions, or disagrees with any of the
> above, please let me know.
>
> If anyone knows of critical problems not on this list please let me
> know, and I'll see what I can do.
>
> Also, pf is currently an (unpaid) side project for me. I'm reasonably
> limited in the amount of time I can invest in it.
>
> Regards,
> Kristof
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>



-- 
Ermal