Date: Tue, 10 Feb 2015 08:48:18 +0000 From: "kristof (Kristof Provost)" <phabric-noreply@FreeBSD.org> To: freebsd-net@freebsd.org Subject: [Differential] [Commented On] D1815: Evaluate packet size after the firewall had its chance Message-ID: <c0a413b13bf8d1701b7989233cf495c5@localhost.localdomain> In-Reply-To: <differential-rev-PHID-DREV-xlnbupssscjsdzdcfhsp-req@FreeBSD.org> References: <differential-rev-PHID-DREV-xlnbupssscjsdzdcfhsp-req@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
kristof added a comment. >>! In D1815#3, @ae wrote: > Since you are in ip6_forward(), this means ip6_input() has already checked this packet and PFIL had a chance to handle this packet. > IPv6 router should not do reassembling fragmented packets and do new fragmentation of them, but if you want, I think your packet filter should track these fragments on input. The defragmentation is done on the input side. When fragmented packets arrive we queue them up inside pf (telling the network stack we dropped them) on the input side. Once we've got a complete packet we can perform the actual filtering (which has to be done on the full packet or the firewall could be bypassed by fragmenting packets). At that point we have an oversized packet which somehow has to be sent out again. As netpfil doesn't have a way to tell the network stack 'Here are a bunch of packets' the only way I can see is to call ip6_forward(). > How do you tested this patch? The actual defragmentation was tested by generating packets with scapy. The forwarding path mostly by having a VM forward packets. The patch set is also running on my (dual stack, VIMAGE enabled) gateway. REVISION DETAIL https://reviews.freebsd.org/D1815 To: kristof Cc: ae, freebsd-net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c0a413b13bf8d1701b7989233cf495c5>