[PATCH] info file for ROUTE target

[PATCH] info file for ROUTE target

[Cedric de Launois]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Hi,

This little patch is to allow the ROUTE target to be applied by pom-ng
on kernel >= 2.6.0. The patch just removes the "Requires: linux < 2.6.0"
line from the ROUTE/info file.

Please apply ;)

Thanks,

Cedric


[-- Attachment #2: ipt_ROUTE-info.patch --]
[-- Type: text/x-patch, Size: 284 bytes --]

--- patch-o-matic-ng.orig/ROUTE/info	2004-02-20 00:11:50.000000000 +0100
+++ patch-o-matic-ng/ROUTE/info	2004-12-09 15:33:55.000000000 +0100
@@ -1,4 +1,3 @@
 Author: Cédric de Launois <delaunois@info.ucl.ac.be>
 Status: Experimental
 Repository: extra
-Requires: linux < 2.6.0

Re: [PATCH] info file for ROUTE target

[Patrick Schaaf]

Hi Cedric,

> This little patch is to allow the ROUTE target to be applied by pom-ng
> on kernel >= 2.6.0. The patch just removes the "Requires: linux < 2.6.0"
> line from the ROUTE/info file.

Funny, I didn't notice anything strange applying to 2.6.10-rc1,
recently, without that modification. Is runme broken somehow?
Maybe I overlooked something.

A propos overlooked (hi list at large :) - I made two postings on
netfilter-devel recently, which were pure bugfixes for ROUTE,
and nobody seemed to care. Any idea why that was so?

https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017485.html
https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017514.html

I also made a new contribution, my --tee extension to ROUTE, which also
went completely uncommented.

https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017515.html

and finally, unrelated to ROUTE, but equally ignored:

https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017540.html

I DEMAND IMMEDIATE ATTENTION TO THESE IMPORTANT MATTERS!!!111111111111!!!!!

:)
  Patrick

Re: [PATCH] info file for ROUTE target

[Bill Rugolsky Jr.]

On Thu, Dec 09, 2004 at 08:57:07PM +0100, Patrick Schaaf wrote:
> A propos overlooked (hi list at large :) - I made two postings on
> netfilter-devel recently, which were pure bugfixes for ROUTE,
> and nobody seemed to care. Any idea why that was so?
> 
> https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017485.html
> https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017514.html

W.r.t. the latter, ip6t_ROUTE.c doesn't build properly as a module, because it
invokes the inline function ndisc_get_neigh(), which in turn depends on the
symbol (un-exported) symbol nd_tbl:

include/net/ndisc.h:113:
static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, struct in6_addr *addr)
{

        if (dev)
                return __neigh_lookup(&nd_tbl, addr, dev, 1);

        return NULL;
}

Presumably ip6t_ROUTE.c requires an out-of-line version of ndisc_get_neigh()
to be exported.

Regards,

	Bill Rugolsky

Re: [PATCH] info file for ROUTE target

[Patrick McHardy]

Cedric de Launois wrote:

>Hi,
>
>This little patch is to allow the ROUTE target to be applied by pom-ng
>on kernel >= 2.6.0. The patch just removes the "Requires: linux < 2.6.0"
>line from the ROUTE/info file.
>
>Please apply ;)
>  
>
Applied, thanks.

Regards
Patrick

Re: [PATCH] info file for ROUTE target

[Patrick McHardy]

Patrick Schaaf wrote:

>A propos overlooked (hi list at large :) - I made two postings on
>netfilter-devel recently, which were pure bugfixes for ROUTE,
>and nobody seemed to care. Any idea why that was so?
>
>https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017485.html
>https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017514.html
>
Both applied, thanks.

>I also made a new contribution, my --tee extension to ROUTE, which also
>went completely uncommented.
>
>https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017515.html
>
I'll apply this if Cedric is fine with it.

>and finally, unrelated to ROUTE, but equally ignored:
>
>https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017540.html
>
I didn't have time to look at this yet.

>
>I DEMAND IMMEDIATE ATTENTION TO THESE IMPORTANT MATTERS!!!111111111111!!!!!
>
:)

Regards
Patrick

Re: [PATCH] info file for ROUTE target

[Cedric de Launois]

Le jeu 09/12/2004 à 22:24, Bill Rugolsky Jr. a écrit :
> ip6t_ROUTE.c doesn't build properly as a module, because it
> invokes the inline function ndisc_get_neigh(), which in turn depends on the
> symbol (un-exported) symbol nd_tbl:

Indeed, the ipv6 ROUTE target doesn't compile for the reason explained
above.

> Presumably ip6t_ROUTE.c requires an out-of-line version of ndisc_get_neigh()
> to be exported.

Agree.

Regards,

Cedric

Re: [PATCH] info file for ROUTE target

[Patrick Schaaf]

> > Presumably ip6t_ROUTE.c requires an out-of-line version of ndisc_get_neigh()
> > to be exported.
> 
> Agree.

I'm curious - why aren't such functions EXPORT_SYMBOL_GPLled?
Same question applies to the out-of-line ip_finish_output2 in ROUTE.
Methinks that would be much nicer. Is this a policy, or is it just
a communication problem?

best regards
  Patrick

Re: [PATCH] info file for ROUTE target

[Cedric de Launois]

Le ven 10/12/2004 à 01:18, Patrick McHardy a écrit :
> >I also made a new contribution, my --tee extension to ROUTE, which also
> >went completely uncommented.
> >
> >https://lists.netfilter.org/pipermail/netfilter-devel/2004-November/017515.html
> >
> I'll apply this if Cedric is fine with it.

In fact, I advised Patrick (Schaaf) to collect reactions related to its
tee extension from this list. This is because --tee duplicates a packet,
which could cause DoS security problems if not used carefully.
Thanks to conntrack, we can avoid flooding ourself with duplicated
packets. My fear is that you could still have something like this :

          PC1                                    PC2

      orig packet     
           |
           v                  dup pkt 1
   [ROUTE --tee --gw PC2] -------------------------.
         | |   ^                                   |
         | |   |                                   v
         | |   '-----dup pkt 2 ---------- [ROUTE --tee --gw PC1]
         | |                                      | |
         v v                                      v v
 Flood of duplicated packets            Flood of duplicated packets

So we cannot make sure that people don't shoot themself. But anyway,
people using the ROUTE target are warned enough by pom...
Maybe I'm too paranoid ?

However, I think the --tee extension can really be useful. For example
to inspect pkt on other machine(s) and detect problems at line rate.

Since the ROUTE target is still an experimental target, my position is
to promote innovative (though sometimes risky) extensions. If the
extension introduces too many problems, I reserve the right to remove
it.

Thus, let's apply the patch ;)

Regards,

Cedric

Re: [PATCH] info file for ROUTE target

[Patrick Schaaf]

> Thanks to conntrack, we can avoid flooding ourself with duplicated
> packets.

NOTE: due to no IPv6 conntrack, the (completely untested :) IPv6 --tee
patch does _not_ contain the recursion detection I made for v4.

I'd love to do this in a different way, but don't know how.
What is needed, is simply an efficient function that, given
a (gateway) IP address, or even the already resolved route,
tells us whether it will reenter the local IP stack.

> My fear is that you could still have something like this :
> 
>           PC1                                    PC2
> 
>       orig packet     
>            |
>            v                  dup pkt 1
>    [ROUTE --tee --gw PC2] -------------------------.
>          | |   ^                                   |
>          | |   |                                   v
>          | |   '-----dup pkt 2 ---------- [ROUTE --tee --gw PC1]
>          | |                                      | |
>          v v                                      v v
>  Flood of duplicated packets            Flood of duplicated packets

This is easily possible. There are lots of other failure scenarios.

For example, when the chosen --gw resolves through our defaul route,
chances are good all duplicate packets will come back to us almost
immediately. We saw this in our testing, already. TTL should always
be properly decremented, so this is a bit self-limiting, but
nevertheless it's certainly a dangerous thing.

> So we cannot make sure that people don't shoot themself. But anyway,
> people using the ROUTE target are warned enough by pom...
> Maybe I'm too paranoid ?

If ROUTE were in the base kernel (which it isn't going to be, according
to the last workshop results I've seen), I would be against including
the --tee functionality, and would have made a separate target TEE for
our needs.

I'm certainly open to doing that, anyway, if this helps alleviate
some paranoia.

all the best
  Patrick

Re: [PATCH] info file for ROUTE target

[Patrick McHardy]

Patrick Schaaf wrote:

>>My fear is that you could still have something like this :
>>
>>          PC1                                    PC2
>>
>>      orig packet     
>>           |
>>           v                  dup pkt 1
>>   [ROUTE --tee --gw PC2] -------------------------.
>>         | |   ^                                   |
>>         | |   |                                   v
>>         | |   '-----dup pkt 2 ---------- [ROUTE --tee --gw PC1]
>>         | |                                      | |
>>         v v                                      v v
>> Flood of duplicated packets            Flood of duplicated packets
>>
>
>This is easily possible. There are lots of other failure scenarios.
>
>For example, when the chosen --gw resolves through our defaul route,
>chances are good all duplicate packets will come back to us almost
>immediately. We saw this in our testing, already. TTL should always
>be properly decremented, so this is a bit self-limiting, but
>nevertheless it's certainly a dangerous thing.
>
Seems ok to me, you can also add a route via loopback, it will loop until
the ttl expires. Fact is you can shoot yourself in the foot with some
setups. I've added your patch except the file iptables/extensions/xxx :)

Regards
Patrick

Re: [PATCH] info file for ROUTE target

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Fri, Dec 10, 2004 at 09:43:50AM +0100, Patrick Schaaf wrote:
> > > Presumably ip6t_ROUTE.c requires an out-of-line version of ndisc_get_neigh()
> > > to be exported.
> > 
> > Agree.
> 
> I'm curious - why aren't such functions EXPORT_SYMBOL_GPLled?
> Same question applies to the out-of-line ip_finish_output2 in ROUTE.
> Methinks that would be much nicer. Is this a policy, or is it just
> a communication problem?

well you could make the ROUTE patch export those symbols.  However,
we're not going to export symbols of the core network stack for some
iptables target that only exists in patch-o-matic.

> best regards
>   Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]