Date: Mon, 16 Mar 2015 09:51:55 -0400 From: Eric van Gyzen <vangyzen@FreeBSD.org> To: Kristof Provost <kristof@sigsegv.be>, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Cc: ae@FreeBSD.org, bz@FreeBSD.org Subject: Re: PF IPv6 fragments handling Message-ID: <5506DFFB.7050302@FreeBSD.org> In-Reply-To: <20150314020500.GW1975@vega.codepro.be> References: <20150203202519.GD2167@vega.codepro.be> <20150209232416.GB37777@vega.codepro.be> <20150314020500.GW1975@vega.codepro.be>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 (whic= h > it does in pf_test6() -> pf_refragment6() because the packet has the > PF_REASSEMBLED tag). > That's also what the OpenBSD stack does. >=20 > In the D1815 review Gleb Smirnoff proposed a different solution. Instea= d > 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 th= e > same on the output side. >=20 >=20 > 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 --qr4U7lrVe1SHhDRsKSca87alQaau6r17R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVBt/7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzRTcwNEY0QTBEMTM0MUU4QkNFNEQ3M0RB RkMxMkExM0VDMjBEQUI4AAoJEK/BKhPsINq4sOsIAIpD3poy5Q9T1lePn0ZO7zMN eXV/hBau+eQ8WygRmMqeGLKhAWVvffqp/fJn29T9zeICXC+/wvUYlCEQkZITtIFC pyKg9grzblufzkYCkGdXihZNqN48BlyubTfsU8xNeCsRwGtu8PpHHBtCbO6YVFA/ tg3WbRdFpwMI9wse5RIA/uE10p3/OGAxCWTkz/SUm9xBUa00uVt09lq0s8kEfApF idruQOPv6VrY2GCkRYlYgK5GVfdHWYzjRcNkxaa89xLuxqROJ8cIlLlL4LINSOQQ HY8J8uUtezuoguS7qoYnKkdTkqgx7OEG/VBRAAZvbdiCHG/jAvrkk6Ov0RIm1IQ= =v9U3 -----END PGP SIGNATURE----- --qr4U7lrVe1SHhDRsKSca87alQaau6r17R--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5506DFFB.7050302>