David, How are you? When you get this email, I hope you had a safe travel back home.
After, Erik Nordmark, Thomas Narten, myself, and Wes Beebee discussed the issue you brought to v6ops @ IETF and we summarized that your issue will not be able to touch the router forwarding tables, why did anyone post a security warning to FeeeBSD with totally erroneous data? We never agreed during discussions in IETF that there was a security problem. All that happens with the issue you raised is creation of a bogus entry in the router or node ND-cache. I don't consider the following data (shown in square brackets) in the BSD security posting as valid: 1. [II. Problem Description IPv6 routers may allow "on-link" IPv6 nodes to create and update the router's neighbor cache and forwarding information. A malicious IPv6 node sharing a common router but on a different physical segment from another node may be able to spoof Neighbor Discovery messages, allowing it to update router information for the victim node.] Router forwarding table will not be updated. 2. Another false analysis is this data: [III. Impact An attacker on a different physical network connected to the same IPv6 router as another node could redirect IPv6 traffic intended for that node. This could lead to denial of service or improper access to private network traffic.] Traffic will not be redirected. So the whole premise behind the BSD warning is baseless. But we still totally appreciate the issue you raised and the five of us did appreciate that bullets 3-4 of on-link determination in RFC4861 did deserve a revisit and that is why Thomas proposed the new text to be added to our draft. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola Sent: Thursday, October 02, 2008 3:08 AM To: ipv6@ietf.org Subject: Neighbor Discovery from non-neighbors FYI, http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc "IPv6 routers may allow "on-link" IPv6 nodes to create and update the router's neighbor cache and forwarding information. A malicious IPv6 node sharing a common router but on a different physical segment from another node may be able to spoof Neighbor Discovery messages, allowing it to update router information for the victim node." ... "NOTE WELL: The solution described below causes IPv6 Neighbor Discovery Neighbor Solicitation messages from non-neighbors to be ignored. This can be re-enabled if required by setting the newly added net.inet6.icmp6.nd6_onlink_ns_rfc4861 sysctl to a non-zero value." + /* + * According to recent IETF discussions, it is not a good idea + * to accept a NS from an address which would not be deemed + * to be a neighbor otherwise. This point is expected to be + * clarified in future revisions of the specification. + */ I wonder if off-list discussion qualifies as "IETF discussion". Or has this been raised on a list somewhere? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/nd6_nbr.c.diff?r1 =1.52;r2=1.53 I guess we have a problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
