All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Schaaf <bof@bof.de>
To: Cedric de Launois <delaunois@info.ucl.ac.be>
Cc: "netfilter-devel@lists.netfilter.org"
	<netfilter-devel@lists.netfilter.org>,
	Patrick McHardy <kaber@trash.net>, Patrick Schaaf <bof@bof.de>
Subject: Re: [PATCH] info file for ROUTE target
Date: Fri, 10 Dec 2004 10:14:45 +0100	[thread overview]
Message-ID: <20041210091445.GC4121@oknodo.bof.de> (raw)
In-Reply-To: <1102669404.11255.29.camel@descartes.info.ucl.ac.be>

> 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

  reply	other threads:[~2004-12-10  9:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-09 14:43 [PATCH] info file for ROUTE target Cedric de Launois
2004-12-09 19:57 ` Patrick Schaaf
2004-12-09 21:24   ` Bill Rugolsky Jr.
2004-12-10  8:37     ` Cedric de Launois
2004-12-10  8:43       ` Patrick Schaaf
2004-12-16 12:25         ` Harald Welte
2004-12-10  0:18   ` Patrick McHardy
2004-12-10  9:03     ` Cedric de Launois
2004-12-10  9:14       ` Patrick Schaaf [this message]
2004-12-14  2:47         ` Patrick McHardy
2004-12-10  0:16 ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041210091445.GC4121@oknodo.bof.de \
    --to=bof@bof.de \
    --cc=delaunois@info.ucl.ac.be \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.