Date: Sat, 18 Oct 2014 09:30:32 -0700 From: prabhakar lakhera <prabhakar.lakhera@gmail.com> To: Hiroki Sato <hrs@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: IPv6 stacks responds to all node link local multicast NS Message-ID: <CALg%2BrhX6L8HARzuWR=V429vO%2BtV7N=nX0B20vHrWAACRMpPwkQ@mail.gmail.com> In-Reply-To: <20141018.143919.1930138986692891609.hrs@allbsd.org> References: <CALg%2BrhVZFc=vE%2BnZS-hsm%2BUc54kZwzO6N8qThG9uv%2Be-e2uh5w@mail.gmail.com> <20141018.143919.1930138986692891609.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Like I said before, it is not per RFC. It is trivial to derive solicited node multicast address from the target IP, so If someone were to launch a flood attack to poison cache entry for X host by sending Address resolution request for all other local hosts in the network, with NS's source IP=X's IP and with source link layer info=attacker's MAC, computing sol node multicast for each target will make it only slightly costly, so I am not sure if security could be of concern here. The other concern is if it can be a compliance issue given the NS packet format described by the RFC. Also the comment in the code suggests what RFC says but the check is more liberal. Also why it is different for DAD NS vs Neighbor resolution NS. On Friday, October 17, 2014, Hiroki Sato <hrs@freebsd.org> wrote: > prabhakar lakhera <prabhakar.lakhera@gmail.com <javascript:;>> wrote > in <CALg+rhVZFc=vE+nZS-hsm+Uc54kZwzO6N8qThG9uv+e-e2uh5w@mail.gmail.com > <javascript:;>>: > > pr> This probably is more of a compliance issue (or may be not as the NS > pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 > does > pr> not talk about it). > pr> > pr> The neighbor solicitation message format says this: > pr> > pr> http://tools.ietf.org/html/rfc4861#page-22 > pr> > pr> > pr> Destination Address > pr> Either the solicited-node multicast address > pr> corresponding to the target address, or the target > pr> address. > pr> > pr> > pr> Is it safe to assume that this is a MUST? > pr> If yes, nd6_ns_input right now only checks if the destination is a > pr> multicast or not (the check is more strict for DAD NS packets) and > pr> therefore allows all node link local multicast address resolution NS > pr> packets and process them completely (creates neighbor cache, responds > pr> with NA etc). > > What is the problem when accepting NS messages to ff02::1? > > -- Hiroki >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALg%2BrhX6L8HARzuWR=V429vO%2BtV7N=nX0B20vHrWAACRMpPwkQ>