From: Patrick McHardy <kaber@trash.net>
To: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Cc: Marek.Szuba@if.pw.edu.pl, netfilter-devel@vger.kernel.org
Subject: Re: IPv6 conntrack support for neighbour discovery
Date: Wed, 05 Nov 2008 10:50:29 +0100 [thread overview]
Message-ID: <49116C65.7030405@trash.net> (raw)
In-Reply-To: <200811050444.mA54i7F8028119@toshiba.co.jp>
Yasuyuki KOZAKAI wrote:
>> This patch seems fine to me. Yasuyuki, what do you think?
>
> In short: nf_conntrack_proto_icmpv6.c does not help for protocols using
> their messages. conntrack helper is better.
>
>
> In detail:
>
> A solicitation and advertisement does not construct 'connection'
> in most cases. Because the destination of solicitation is typically
> multicast address, and the source address of advertisement for replying is
> typically unicast address.
>
> In the first place, static configuration is better for their messages.
>
> Even if you add their ICMPv6 types to nf_coonntrack_proto_icmpv6.c,
> you will need to configure rules to allow IPv6 stack to receive
> Router/Neighbor Solicitation/Advertisement with all-node or solicited
> multicast address.
>
> For example, IPv6 node sends neighbor solicitation to
> solicited multicast address to resolve L2 address. If you block it
> on your node, then other nodes (including routers) cannot resolve
> L2 address of your node. Also Duplicated Address Detection (DAD) does not
> work.
>
> What threat you want to avoid ? If it is spoofed router advertisement
> to all-nodes multicast address, conntrack helper is better.
> It would expect advertisement with the specific destination address
> (all-node multicast address or the link-local/global unicast address on your
> node), only when your node sends router solicitation (with the all-node
> multicast address or the unicast address of router as destination address).
>
> But I don't recommend to block unsolicited router advertisement.
> If many hosts block it on a link, that results in increasing traffic
> on the link by solicitation. And hosts would not be able to know
> the change of configuration on router in short time.
>
> FYI: IIRC SEcure Neighbor Discovery (SEND) is the current solution from
> IETF guys, but I don't know the implementation for Linux.
Thanks for the detailed explanation.
Marek, could you close the bugzilla report with a link to
Yasuyuki's explanation please? Thanks!
next prev parent reply other threads:[~2008-11-05 9:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 13:52 IPv6 conntrack support for neighbour discovery Marek Szuba
2008-11-04 14:06 ` Patrick McHardy
2008-11-05 4:44 ` Yasuyuki KOZAKAI
[not found] ` <200811050444.mA54i7F8028119@toshiba.co.jp>
2008-11-05 9:50 ` Patrick McHardy [this message]
2008-11-05 12:40 ` Marek Szuba
2008-11-05 12:48 ` Patrick McHardy
2008-11-05 13:01 ` Yasuyuki KOZAKAI
[not found] ` <200811050444.mA54i7XU020102@toshiba.co.jp>
2008-11-05 12:35 ` Marek Szuba
2009-01-21 23:41 ` [PATCH 0/2] " Eric Leblond
2009-01-21 23:43 ` [PATCH 1/2] netfilter: use sysctl to choose icmpv6 autoconf behaviour Eric Leblond
2009-01-21 23:43 ` [PATCH 2/2] netfilter: don't track ICMPv6 negotiation message Eric Leblond
2009-01-21 23:49 ` Eric Leblond
2009-01-21 23:51 ` [Resend PATCH " Eric Leblond
2009-01-23 10:21 ` [PATCH 0/2] IPv6 conntrack support for neighbour discovery Yasuyuki KOZAKAI
2009-01-23 7:40 ` Yasuyuki KOZAKAI
2009-01-23 9:02 ` Eric Leblond
2009-01-23 9:42 ` Jozsef Kadlecsik
2009-01-23 9:50 ` Jozsef Kadlecsik
2009-01-23 10:42 ` Yasuyuki KOZAKAI
[not found] ` <200901231021.n0NALINO007201@toshiba.co.jp>
2009-01-23 10:51 ` Eric Leblond
2009-01-23 11:10 ` Yasuyuki KOZAKAI
2009-01-24 10:32 ` [PATCH] netfilter: don't track ICMPv6 negotiation message Eric Leblond
2009-01-27 10:07 ` Yasuyuki KOZAKAI
[not found] ` <200901231110.n0NBAR7Z000645@toshiba.co.jp>
2009-01-26 13:11 ` [PATCH 0/2] IPv6 conntrack support for neighbour discovery Patrick McHardy
2009-01-27 10:09 ` Yasuyuki KOZAKAI
[not found] ` <200901271009.n0RA9d4I025010@toshiba.co.jp>
2009-01-27 10:14 ` 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=49116C65.7030405@trash.net \
--to=kaber@trash.net \
--cc=Marek.Szuba@if.pw.edu.pl \
--cc=netfilter-devel@vger.kernel.org \
--cc=yasuyuki.kozakai@toshiba.co.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).