All of lore.kernel.org
 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 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.