From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from complete.lackof.org (complete.lackof.org [198.49.126.79]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7DEDF3B2A4 for ; Mon, 17 Apr 2017 19:41:00 -0400 (EDT) Received: from taggart.lackof.org (c-24-22-132-166.hsd1.wa.comcast.net [24.22.132.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "taggart.lackof.org", Issuer "CAcert Class 3 Root" (verified OK)) by complete.lackof.org (Postfix) with ESMTPS id 4FD8133E004A; Mon, 17 Apr 2017 17:40:59 -0600 (MDT) Received: by taggart.lackof.org (Postfix, from userid 1000) id A01E5265; Mon, 17 Apr 2017 16:40:58 -0700 (PDT) X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0-4) with nmh-1.6 From: Matt Taggart To: Dave Taht cc: cerowrt-devel@lists.bufferbloat.net In-reply-to: <87tw5nt2rd.fsf@nemesis.taht.net> References: <87tw5nt2rd.fsf@nemesis.taht.net> Comments: In-reply-to Dave Taht message dated "Mon, 17 Apr 2017 09:31:02 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Apr 2017 16:40:58 -0700 Message-Id: <20170417234058.A01E5265@taggart.lackof.org> X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on complete.lackof.org Subject: Re: [Cerowrt-devel] bcp38 and the caida "spoofer" tool X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 23:41:00 -0000 Dave Taht writes: > I am curious as to how many here are using the lede/openwrt bcp38 package? I always install it everywhere since I consider it part of being a good netizen, even if I think the odds of it getting used are low. So far it's always just worked, with one exception where I was doing something weird with rfc1918 ranges, and then I just had to use the luci interface to adjust. I've had similar ideas for ways to use openwrt/lede to help protect against IoT devices participating in botnets. Ideally each time you added an IoT device to your network, you'd have to go in to luci and approve the device and what types of things it was allowed to do. Possibly separate ESSIDs for them? Maybe dedicate one wired port to be sort of an IoT DMZ? -- Matt Taggart matt@lackof.org