From owner-freebsd-pf@FreeBSD.ORG Tue Sep 26 13:39:23 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F52B16A403 for ; Tue, 26 Sep 2006 13:39:23 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611C143D64 for ; Tue, 26 Sep 2006 13:39:22 +0000 (GMT) (envelope-from rajkumars@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so810642wri for ; Tue, 26 Sep 2006 06:39:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ncbJUy62UupMnBo+bwfRcb5iH6debSx2muuSIDjeKnC6FJEtQJjDasVcX8XhYbu5IOjQiese04HNIDTwpQ6rk4MhzAnoHHvw/a6uGTye8O717/k7CVXR6WladOont1JysSKSk2lHA3ICLbg23xMzunVBAZr7498Dwb5OPNq/NBg= Received: by 10.90.100.6 with SMTP id x6mr176715agb; Tue, 26 Sep 2006 06:39:21 -0700 (PDT) Received: by 10.90.35.3 with HTTP; Tue, 26 Sep 2006 06:39:21 -0700 (PDT) Message-ID: <64de5c8b0609260639v173f513ckb65a018d4b2774f@mail.gmail.com> Date: Tue, 26 Sep 2006 19:09:21 +0530 From: "Rajkumar S" To: "Max Laier" , freebsd-pf@freebsd.org In-Reply-To: <200609251900.50657.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a542da30609250749i52f966a3x7a9402872d33b976@mail.gmail.com> <200609251900.50657.max@love2party.net> Cc: Subject: Re: netgraph related question X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 13:39:23 -0000 On 9/25/06, Max Laier wrote: > I'd like to work on both of these problems, provided there is enough > interest and we can come up with a proper sollution for the hook-point > problem. > > Any ideas? I posted about this couple of days ago, posting it here again for discussion. Here instead of a rule extension, I am suggesting adding a new rule action. I am suggesting a new rule action because a pf netgraph node also can deny/allow a packet, just like pass/block. This also goes well with general pf syntax, such as keep state, log and state full tracking options. The netgraph link is established via a rule like: queue in on dc0 from 192.168.0.0/24 to 192.168.0.1 Where the packet will be passed to a netgraph node with full state information about the TCP stream. If the packet is dropped in netgraph then it's as good as a block, other wise it's a pass. The packet should be passed to the netgrpah node with a tag identifying the session to which this packet belongs, ie all packets belonging to a single TCP session should have the same tag. This session tracking is important because that can help in identifying patterns that span multiple packets in userspace easily. The pf netgraph node can then set tags as well as assign the packet to a particular queue, for example slow down kazaa. I guess there is tremendous interest in having L7 capabilities in pf, as normal port based access control is in adequate to deal with problems like skype and other p2p. I have no idea about the implementation of what I have just said, so I hope this makes some sense :) raj