Netfilter / Conntrack future integration with the rest of the network layer

[Sampsa Ranta]

Hello,

I've been working with Netfilter for a quite a time now. I recently posted
a message concerning the future of Netfilter to netfilter mailing list
but it seems that it did not reach any developers with it.

I was a bit worried on people short-seeing the possibilities and
integration of conntrack and netfilter code with other parts of networking
layer in kernel than the netfilter itself. Parts I actually mean are
routing  and queuing.

Introducing the connection tracking is a big step also for routing issues.
With a marking system like Nordstrom introduced we can match the
connections further, even by direction.

But I agree that the direction information is not very usable itself in
the netfilter space. But if I had an match & target to copy this into for
example realm (or class, which word you prefer) mark, I would even be able
to route connections originating from my local network differently than
connections originated from other network by something like policy
routing.  Or maybe adjust queue QoS parameters differently by this.

On the other hand I was succesting that some tokens from routing might be
usable back in the netfilter. For example, let's look at internet
networks, I have over 100 000 routes in my routing table when I run BGP.
Okay, routing on internet goes by AS paths. The as paths tell me via via
which AS networks the packet is about to travel. Okay, this is routing
protocol issue. But why did I bring this up?

Let's say I in routing protocol I marked everything going through AS11854
for example with realm tag 10. Well, this something like 34 routes
currently in my BGP table. Even if they got a new I block this match
would work. Then again by using the conntrack match, I could say which
direction this is going and give the QoS values. This would of course
require that connections go through same router, but it is anyway easier
to even use conntrack on edge not in the core.

I've already written this realm match for Netfilter, I wonder if it would
be any good in patch-o-matic.

Second application I was thinking with routing was the conditional NAT
depending on the routing. However this would need DNAT "mark" to be set
after routing.

In this case the first packet of connection would be routed by the unNATed
destination. But I think it is not the right way to think like "DNAT
belongs to PREROUTING", than rather like this

- DNAT target affects
   routing if done before routing
   conntrack entry

- DNAT target depends on
   nothing (?)

- nat tables are only looked up once

- next packet of conntracked connection with DNAT is modified in
   PREROUTING

What I mean is that you've generated a check to the target that is not
fully neccessary if you understood the code correctly. Okay, this prevents
newbies from doing silly things but also prevents experienced people
taking all out of it. Teaching newbies should be handled by documentation.

Anyway, you're doing superb job anyway. Netfilter already beats
commercial routers trying fill same shoes anytime.

Thanks,

 Sampsa Ranta
 sampsa@netsonic.fi