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

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