Re: merging forwarding & packet filtering?

[David Young <dyoung%pobox.com@localhost>]

On Fri, Feb 18, 2011 at 08:20:27PM -0300, Dennis Ferguson wrote:
> To keep both types of users well served the structures which implement
> standard routing (which must be there) and "policy routing" are generally
> kept separate, preserving the scalability of the former while avoiding
> implementation constraints that might exist in the latter if it needs
> to serve users which want to do frequent, incremental updates.  If you
> think you have a structure which can serve both without penalizing
> one or the other that is great, but in my experience there is no way
> to make one thing do both really well.

Thanks for your thoughtful and informative response!

I don't think that it's necessary to create a new data structure
that meets every need.  Some policies just refine forwarding rules,
and we can apply those policies after a super-fast forwarding-table
lookup.  For example, a policy that uses PF state to pin a flow to the
current default nexthop is just a refinement of the default route, so
let us write it as such.  Let pin_flow_to_nexthop be the name of a
packet-filter rule that creates a state for each flow and copies the
nexthop to it, and let -policy attach a policy to a forwarding-table
entry.  First let's set the default nexthop to 10.0.0.1 (happens to be
connected to wm0):

# route add -net default 10.0.0.1 -policy pin_flow_to_nexthop

Wait a while for flows to start:

# sleep 10
# route -n get default
   route to: default
destination: default
       mask: default
    gateway: 10.0.0.1
 local addr: 10.0.0.10
  interface: wm0
     policy: pin_flow_to_nexthop
      flows: tcp 10.0.0.5:38237  <-> 10.25.43.7:22 nexthop wm0:10.0.0.1
             tcp 10.0.0.29:38783 <-> 10.19.0.7:34543 nexthop wm0:10.0.0.1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0         0         0 

Now, let's change the default nexthop to 10.1.1.254 (happens to be
connected to tlp0).  Old flows stay with the previous nexthop.  New
flows take the new nexthop:

# route change -net default 10.1.1.254 -policy pin_flow_to_nexthop
# sleep 10
# route -n get default
   route to: default
destination: default
       mask: default
    gateway: 10.0.0.1
 local addr: 10.0.0.10
  interface: tlp0
      flags: <UP,GATEWAY,DONE,STATIC>
     policy: pin_flow_to_nexthop
      flows: tcp 10.0.0.5:38237  <-> 10.25.43.7:22 nexthop wm0:10.0.0.1
             tcp 10.0.0.29:38783 <-> 10.19.0.7:34543 nexthop wm0:10.0.0.1
             tcp 10.0.0.29:21012 <-> 10.19.25.8:4001 nexthop tlp0:10.1.1.254
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0         0         0 

We can think of these as fancy cloning routes, where the clones are
indexed by 4-tuple instead of by destination.

The advantage of hanging the rule off of a forwarding-table entry in
this way is that I have one place to start if I want to read or set the
policy of the system, and I can tell by reading the forwarding table if
it the entries therein are potentially contravened.

This not the only way, and it may not be the best way to make the
forwarding policy more transparent, but I hope that it gives you an idea
of what I mean by and what benefits I desire from merging forwarding &
packet filtering.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24