Date: Wed, 27 Jul 2016 00:23:06 +0800 From: Julian Elischer <julian@freebsd.org> To: "Dr. Rolf Jansen" <rj@obsigna.com>, freebsd-ipfw@freebsd.org Cc: Michael Sierchio <kudzu@tenebras.com>, Jan Bramkamp <crest@rlwinm.de> Subject: Re: ipfw divert filter for IPv4 geo-blocking Message-ID: <c2cd797d-66db-8673-af4e-552dfa916a76@freebsd.org> In-Reply-To: <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com> References: <61DFB3E2-6E34-4EEA-8AC6-70094CEACA72@cyclaero.com> <CAHu1Y739PvFqqEKE74BjzgLa7NNG6Kh55NPnU5MaA-8HsrjkFw@mail.gmail.com> <4D047727-F7D0-4BEE-BD42-2501F44C9550@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote: >> Am 25.07.2016 um 12:47 schrieb Michael Sierchio <kudzu@tenebras.com>: >> >> Writing a divert daemon is a praiseworthy project, but I think you could do >> this without sending packets to user land. >> >> You could use tables - … > >> Am 25.07.2016 um 14:01 schrieb Jan Bramkamp <crest@rlwinm.de>: >> >> I would use a set of IPFW tables with skipto/call tablearg rules instead … > Michael and Jan, many thanks for your suggestions. > > As everybody knows, 'Many roads lead to Rome.', and I am already there. I don't feel alike going all the way back only for the sake of trying out other routes. and I personally am responsible for at least parts of several of them ;-) (parts of ipdivert, netgraph, and various ipfw bits). > > Once a week, the IP ranges are compiled from original sources into a binary sorted table, containing as of today 83162 consolidated range/cc pairs. On starting-up, the divert daemon reads the binary file in one block and stores the ranges into a totally balanced binary search tree. Looking-up a country code for a given IPv4 address in the BST takes on average 20 nanoseconds on an AWS-EC2 micro instance. I don't know the overhead of diverting, though. I guess this may be one or two orders of magnitudes higher. Even though, I won't see any performance issues. yes the diversion to user space is not a fast operation. When we wrote it, fast was 10Mbits/sec. The firewall tables use a radix tree (*) and might be slower than what you have, but possibly it might be made up for by not having to do the divert logic. it's not entorely clear from your description why you look up a country rather than just a pass/block result, but maybe different sources can access different countries?. I did similar once using ipfw tables but couldn't find a reliable source of data. > > Independent from the actual usage case (geo-blocking), let's talk about divert filtering in general. The original question which is still unanswered can be generalized to, whether "dropping/denying" a package simply means 'forget about it' or whether the divert filter is required to do something more involved, e.g. communicate the situation somehow to ipfw. there is no residual information about the packet in the kernel once it has been passed to the user process. so just "forgetting to hand it back" is sufficient to drop it. > > Best regards > > Rolf > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c2cd797d-66db-8673-af4e-552dfa916a76>