Packet Filtering Hooks integrated into Solaris Nevada

On the 20th of October, during the 1st week of build 52 of Solaris Nevada, the Packet Filtering Hooks project was finally putback into the main Solaris gate. The project took around 16 months to complete and whilst it started out with 5 developers working on it, in the end it finished up with 2: 2 people working on the project changed their careers within Sun from development to management and another was lost to another project. Of the 2 who were with it at the end, only myself was there from the start - the other project member joined the project early this year to cover someone else who left the company to live with his wife in another city.

The aim of this project is to be a first pass at introducing an API for the Solaris kernel that allows us to implement intercepting IP packets in Solaris without the need for a STREAMS module. The reliance on using a STREAMS module brought with it two major problems for Solaris 10:

  • Unable to access packets flowing between zones
  • Disables performance improvements from features such as hardware checksum, etc

In internal testing, the performance improvement with IPFilter using Packet Filtering Hooks vs the STREAMS module is between 20% and 30% in some tests - a very worthwhile gain!

There is one glaringly obvious limitation with the current implementation - it is limited to a single callback being registered for hook events that allow data to be modified. This limitation was brought about in discussion with PSARC where the requirement for making this capability available included solving the problem completely - i.e. in a more complete manner than simply assigning different modules a "priority". Amongst the projects we are currently looking at, layer 2 (or MAC layer) filtering is amongst them and with any luck, solving this problem can be wrapped up in this project!

For people who are fimiliar with Netfilter in Linux today, the table below compares the interception points available with Solaris and Linux today. The hooks that are defined in Solaris today have been defined because that is where we currently have someone interested in using them - we currently have nobody asking to use the interception points below that are unimplemented.

If you are developing a product on Solaris or porting a Linux product to Solaris and would benefit from having a hook that is currently unimplemented (such as Local In/Out), please get in contact with me so we can discuss your needs and what can be done to achieve them. Maybe there's scope for you to become involved in OpenSolaris as a developer and do the initial work to support them.

Solaris Packet Filtering HooksLinux Netfilter
Loopback inbound-
Loopback outbound-
Physical InPre-Routing
Physical OutPost-Routing
ForwardingForwarding
-Local In
-Local Out

Comments:

Hello, Nice project. I am glad to hear it is finished! I want to understand something which I am not sure about: you talk here about packet filtering hooks as the parallel for netfilter in linux. So my question is: linux iptable drivers use netfilter extensively. Will solaris ipfilter make use of packet filtering hooks(as is done in its parallel in linux) ? or does solaris ipfilter already make use of packet filtering hooks? Best, Xu

Posted by xunakaj on November 09, 2006 at 05:47 AM PST #

IPFilter in Solaris was modified to work with this project. The changes to support this are visible through the opensolaris.org website for accessing CVS.

Posted by Darren on November 09, 2006 at 05:57 AM PST #

>>> The hooks that are defined in Solaris today have been defined because that is where we currently have someone interested in using them Then here comes a request for LOCAL_IN and OUT I am implementing Fault-tolerant TCP support though a loadable linux kernel module and wish to do same for Solaris when I am done with Linux. I intercept TCP packets at LOCAL_IN and LOCAL_OUT using NETFILTER framework. So it would be much easier to have same hooks in Solaris and my work is reduced to large extent. I can even use PER_ROUTING and POST_ROUTING but reason i want to avoid is performance. If there is anything other than this filter framework which allows me to intercept TCP packets (inbound + outbound) though loadable kernel module, Please let me know.

Posted by Rohit on November 29, 2006 at 04:51 PM PST #

Hi...I just want wat u guys were discussing....i wanna know the hooks API currently available in solaris....and wanna know if there is any ohter way to take the IP packets from solaris network...

Posted by ArunPrabhu.V on May 23, 2007 at 07:29 PM PDT #

hi...can anyone help me plssssss.... i wanna know how to use the Packet filter hooks..... I'm in great urgency....I need a document or an example program for accessing packets...

Posted by Arunprabhu on June 07, 2007 at 04:43 PM PDT #

Hi.

I have enabled the ip filter by using svcadm enable newtork/ipfilter and add rules using ipf -FA -f ...conf.

It's working fine. But strange thing is if disable the IPF service using svcadm disable network/ipfilter. After disabling i issued the command ipf -E. then i loaded the rules. It is able to work. I checked the status using svcs network/ipfilter. its says disabled but ipfilter is blocking based on the rules i added.

Could please share what is the relation between ipf -E ipf -D and svcadm enable/disable network/ipfilter.

Thanks in advance

Posted by Chandan on May 07, 2009 at 04:59 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

avalon

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today