Date: Fri, 06 Mar 2020 10:19:57 +0100 From: Philip Homburg <pch-fbsd-2@u-1.phicoh.com> To: freebsd-net@freebsd.org Cc: =?utf-8?Q?Dennis_K=C3=B6gel?= <dk@neveragain.de> Subject: Re: Revisiting FreeBSD-SA-08:10.nd6 (or: avoiding IPv6 pain) Message-ID: <m1jA99C-0000MvC@stereo.hq.phicoh.net> In-Reply-To: Your message of "Fri, 6 Mar 2020 08:16:01 %2B0100 ." <97992D2A-CE25-44DB-8441-1C2F3A43C1B2@neveragain.de> References: <m1j9pbX-0000F6C@stereo.hq.phicoh.net> <97992D2A-CE25-44DB-8441-1C2F3A43C1B2@neveragain.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Good point, and probably an indication that my provider's setup is > broken. But in terms of RFC-perspective, RAs and ND are not strictly > related, I believe - for example, prefixes might have been configured > manually (?). Hmm, I forgot one case: NBMA (Non-broadcast multiple-access). A prefix may be marked off-link though it is actually onlink. In that case all traffic initially goes through the router. Then the router will send a redirect with the target's MAC address. So the conclusion has to be that a node has accept NS packets with a source address that is off-link. > Exactly, that's where I couldn't understand the Advisory. Though > it seems to focus in router nodes, and not host nodes. Maybe some systems do not properly separate the neighbor cache from the destination cache. Junk in the neighbor cache should not affect the destination cache. So a node may be able to claim an address that is not onlink in the neighbor cache. But the destination cache should always have the right entry so the neighbor cache entry is ignored. I can imagine that if a system confuses the two then attacks are possible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m1jA99C-0000MvC>