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

[Harald Welte]

On Thu, Jul 05, 2001 at 02:18:00AM +0300, Sampsa Ranta wrote:
> 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.

Hm, the netfilter mailinglist (the users one, not the devel) has so gained
so much traffic over the last months, that it is hard to keep track. I
usually browse through it once a week, but finding more time for that
just seems impossiblem.  My todo lists still get longer every day...

> 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.

Well, the current 2.4.x code is certainly not the end of development. Plans
for the next step exist, although nothing more than hot air up to now.

> 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.

Yes, certainly there are possibilities like this.  An interesting question,
however, is how would you define the direction of a connection in a 
generalized way?  Of course, we always can define connection relative
(DIR_ORIGINAL, DIR_REPLY), but the connection tracking code does and
will most likely not in the future know the notion of an 'inside' or
'outside' network.  Connection tracking is more general, and not bound 
to firewalls.  But apart from such practical details, yes it would make
sense to export this information in some way.

> 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?

Yup, it is a routing protocol issue.  Currently the kernel routing code
doesn't know anything else than the source where it learned the route from
(like 'zebra' or 'static').  It should not be too dificult to get this
information into a tc classifier, though. 

> 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.

How does this reaml match work? Where is your realm information stored? 
How do you communicate it into the krnel?

> 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.

I don't really understand what you are trying to do. Could you describe
this more in detail? Conditional nat depending on routing?  Well, you can
bind NAT rules to interfaces, so depending to which interface your routing
decision leads, you will have nat or not.  But obviously you are talking
about something more sophisticated, but what ?

> 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.

Well, please give me a detailed overview of a scenario where you would
need DNAT in POSTROUTING, and let us discuss this.  I just can't see the
need right now...

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

wait until the commercial routers run Linux 2.4  ;)

>  Sampsa Ranta

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)