From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 04:19:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836A24EF for ; Mon, 20 Oct 2014 04:19:21 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63BA4388 for ; Mon, 20 Oct 2014 04:19:20 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9K4Ir0l088123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 13:19:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9K4IpuJ063541; Mon, 20 Oct 2014 13:18:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 20 Oct 2014 13:18:39 +0900 (JST) Message-Id: <20141020.131839.1886955791866316016.hrs@allbsd.org> To: prabhakar.lakhera@gmail.com Subject: Re: IPv6 stacks responds to all node link local multicast NS From: Hiroki Sato In-Reply-To: References: <20141018.143919.1930138986692891609.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 20 Oct 2014 13:19:14 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 04:19:21 -0000 ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Oct_20_13_18_39_2014_886)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Oct_20_13_18_39_2014_886)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit prabhakar lakhera wrote in : pr> Like I said before, it is not per RFC. It is trivial to derive solicited pr> node multicast address from the target IP, so If someone were to launch a pr> flood attack to poison cache entry for X host by sending Address resolution pr> request for all other local hosts in the network, with NS's source IP=X's pr> IP and with source link layer info=attacker's MAC, computing sol node pr> multicast for each target will make it only slightly costly, so I am not pr> sure if security could be of concern here. pr> pr> The other concern is if it can be a compliance issue given the NS packet pr> format described by the RFC. pr> pr> Also the comment in the code suggests what RFC says but the check is more pr> liberal. Also why it is different for DAD NS vs Neighbor resolution NS. In my understanding, RFC does not allow sending NS messages to all-node multicast address but says nothing about accepting side. An NS message to all-node multicast address is broken, but at least FreeBSD never sends an NS message to all-node multicast address. There is no problem with RFC conformance in this regard. The check itself is easy and I think the attached patch is enough. I am still wondering what kind of trouble we have if we do not do this check. I do not think the security concern is severe because NS flooding from neighbors is still easy even if narrowing down the destination address check upon its acceptance. One possible countermeasure would be rate-limiting of NS/NA. -- Hiroki ----Next_Part(Mon_Oct_20_13_18_39_2014_886)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nd6_nbr_smaddrcheck_20141020-1.diff" Index: sys/netinet6/nd6_nbr.c =================================================================== --- sys/netinet6/nd6_nbr.c (revision 273157) +++ sys/netinet6/nd6_nbr.c (working copy) @@ -116,6 +116,7 @@ int lladdrlen = 0; int anycast = 0, proxy = 0, tentative = 0; int tlladdr; + int dsmaddr; int rflag; union nd_opts ndopts; struct sockaddr_dl proxydl; @@ -147,15 +148,33 @@ goto bad; } - if (IN6_IS_ADDR_UNSPECIFIED(&saddr6)) { - /* dst has to be a solicited node multicast address. */ - if (daddr6.s6_addr16[0] == IPV6_ADDR_INT16_MLL && + /* + * Attaching target link-layer address to the NA? + * (RFC 2461 7.2.4) + * + * NS IP dst is unicast/anycast MUST NOT add + * NS IP dst is solicited-node multicast MUST add + * + * In implementation, we add target link-layer address by default. + * We do not add one in MUST NOT cases. + */ + if (!IN6_IS_ADDR_MULTICAST(&daddr6)) + tlladdr = dsmaddr = 0; + else if (daddr6.s6_addr16[0] == IPV6_ADDR_INT16_MLL && /* don't check ifindex portion */ daddr6.s6_addr32[1] == 0 && daddr6.s6_addr32[2] == IPV6_ADDR_INT32_ONE && - daddr6.s6_addr8[12] == 0xff) { - ; /* good */ - } else { + daddr6.s6_addr8[12] == 0xff) + tlladdr = dsmaddr = 1; + else { + nd6log((LOG_INFO, "nd6_ns_input: multicast NS not to " + "solicited-node multicast address.\n")); + goto bad; + } + + if (IN6_IS_ADDR_UNSPECIFIED(&saddr6)) { + /* dst has to be a solicited node multicast address. */ + if (dsmaddr == 0) { nd6log((LOG_INFO, "nd6_ns_input: bad DAD packet " "(wrong ip6 dst)\n")); goto bad; @@ -206,21 +225,6 @@ } /* - * Attaching target link-layer address to the NA? - * (RFC 2461 7.2.4) - * - * NS IP dst is unicast/anycast MUST NOT add - * NS IP dst is solicited-node multicast MUST add - * - * In implementation, we add target link-layer address by default. - * We do not add one in MUST NOT cases. - */ - if (!IN6_IS_ADDR_MULTICAST(&daddr6)) - tlladdr = 0; - else - tlladdr = 1; - - /* * Target address (taddr6) must be either: * (1) Valid unicast/anycast address for my receiving interface, * (2) Unicast address for which I'm offering proxy service, or ----Next_Part(Mon_Oct_20_13_18_39_2014_886)---- ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlREjR8ACgkQTyzT2CeTzy0ntgCfSOXEMF0lgBP6J9S73ozSELy+ XA0AoKiyoBDnZSC260gCNmFvRFHAO9+u =Ib4O -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)----