From: Patrick McHardy <kaber@trash.net>
To: Marek Szuba <Marek.Szuba@if.pw.edu.pl>
Cc: netfilter-devel@vger.kernel.org,
Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Subject: Re: IPv6 conntrack support for neighbour discovery
Date: Tue, 04 Nov 2008 15:06:55 +0100 [thread overview]
Message-ID: <491056FF.8030801@trash.net> (raw)
In-Reply-To: <20081030145218.5395c3fe@hiperon.ws.hirg>
Marek Szuba wrote:
> Hello everyone,
>
> Following a suggestion I was given at the kernel Bugzilla I am
> forwarding this here.
>
> It has come to my attention lately that the only two ICMPv6 packet
> types which IPv6 conntrack allows at present to initiate new
> connections are "echo request" and "node information query"; all other
> types appearing in this context are considered invalid. In particular,
> this includes two neighbour-discovery types specified in RFC 2461:
> "router solicitation" and "neighbour solicitation" - meaning that if a
> server drops all INVALID packets early in its INPUT or OUTPUT chain of
> IPv6 netfilter's filter table, neither of the two can be received from
> clients. Given that router solicitation is used for stateless network
> autoconfiguration and neighbour solicitation is an IPv6 equivalent of
> ARP requests, having these two dropped can be quite bad - especially
> the latter, as it pretty much kills IPv6 over Ethernet.
>
> Steps to reproduce:
>
> 1. Obtain an IPv6 address assigned to an Ethernet interface of host A
> (link-local will do);
> 2. If necesssary, flush all ip6tables filter chains on host A and set
> their policies to ACCEPT;
> 3. From host B on the same Ethernet network, ping6 the aforementioned IP
> address to verify that everything works;
> 4. On host A, run something like "ip6tables -I INPUT 1 -m state --state
> INVALID -j DROP";
> 5. Try to repeat step 3. This time the ping should fail and counters
> associated with the aforementioned rule should increment;
> 6. Repeat all the above using OUTPUT instead of INPUT, with the same
> final result.
>
> BTW. This problem was discovered and (hopefully) fixed collaboratively
> by Łukasz Stelmach <steelman@post.pl> and myself, please attribute both
> of us should the patch make it into code repositories.
>
> Attaching a proposed solution to the problem - the enclosed patch adds
> "router solicitation" and "neighbour solicitation" to the list of
> ICMPv6 types IPv6 conntrack considers allowed to initiate new
> connections. Note that in principle "router advertisement" ICMPv6
> packets could also be considered valid-new, as e.g. radvd periodically
> advertises its presence to the local network - as however it is not
> necessary to let this through as new to have things work (plus we
> aren't that big on broadcasting, even on supposedly-secure networks),
> the patch only adds solicitations to the list.
This patch seems fine to me. Yasuyuki, what do you think?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-04 14:07 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 [this message]
2008-11-05 4:44 ` Yasuyuki KOZAKAI
[not found] ` <200811050444.mA54i7F8028119@toshiba.co.jp>
2008-11-05 9:50 ` Patrick McHardy
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=491056FF.8030801@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).