> 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. -- Yasuyuki Kozakai From: Patrick McHardy <kaber@xxxxxxxxx> Date: Tue, 04 Nov 2008 15:06:55 +0100 > 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@xxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
