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
next prev parent 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.