PF IPv6 fragments handling

[Eric van Gyzen]

On 03/13/2015 22:05, Kristof Provost wrote:
> At that point we run into the packet size check, which in ip6_forward()
> is done before the pfil(PFIL_OUT) hook. That means that we'll send an
> ICMP6_PACKET_TOO_BIG error rather than forwarding the packet.
> 
> The proposed fix in D1815 is to simply move the size check after the
> pfil(PFIL_OUT) hook so pf has the chance to refragment the packet (which
> it does in pf_test6() -> pf_refragment6() because the packet has the
> PF_REASSEMBLED tag).
> That's also what the OpenBSD stack does.
> 
> In the D1815 review Gleb Smirnoff proposed a different solution. Instead
> of returning a reassembled packet from pfil(PFIL_IN) in ip6_input() we
> could change netpfil so we could return multiple packets. That means
> we'd reassemble and immediately refragment on the input, and then do the
> same on the output side.
> 
> 
> I have a preference for the solution in D1815 for two reasons:
>  - it's less work for me. It's a relatively small change in ip6_output()
>    and nothing else. Changing netpfil so it can return multiple packets
>    is a more invasive change and will impact other firewalls too.
>  - it's less work for the kernel when forwarding. Not only do we only
>    reassemble and refragment once, but we also only need to do
>    ip6_forward() processing on a single packet, rather than for each
>    fragment.

Here is a brainstorm that might give the best of both:  Return the
reassembled packet from PFIL_IN, but with the original fragment chain
stashed in metadata.  Most of the stack operates on the single,
reassembled packet.  ip6_output() sends the original fragment chain.
Sure, it uses more memory, but reduced CPU time might be worth it.

I am sure there are numerous challenges.  When the stack modifies the
packet, it will need to modify the fragment chain to match.  Size checks
would probably need to look at the fragment chain instead of the
reassembled packet.  This could be a maintenance problem when people
forget to handle the rare case of the fragment chain.

Like I said, it is a brainstorm.  Treat it accordingly.

Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20150316/25e96e68/attachment.sig>