[PATCH] info file for ROUTE target

Patrick Schaaf bof at bof.de
Fri Dec 10 10:14:45 CET 2004


> 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



More information about the netfilter-devel mailing list