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!
--
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
