netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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!

  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).