From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E41F921F32E for ; Tue, 9 Dec 2014 13:02:38 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id gq1so1153543obb.23 for ; Tue, 09 Dec 2014 13:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZfpSeNKPqV27BOWbeIEy+gh0vgdhdyzoQWdlegZEGds=; b=AgWEzDeOZ9lOVNc9eUQOJf6iVFvDy1bzHcY0MfNb85c6c73YSLOI1lyNS474lBGwnl OhdDwRISYo8+j7LS0nDpkPfGzZQk7Fq2NQWpxfLyyxf5eBVkRlX7jbE+WlvORCgl6xTD 6W6kWR3VA0AtDhVdDmz5tmcwdNmZ6uESJAI3ITfvr+e+Dg3qd7yWfOl6vI3NUDSM8+xn Q/hNdr5MNs8htLBZhYqq44Gsp+wMgFSw6LkwE+Kvi4AgiFO/L3SggQ6RHPF8z3YXthsd 4RGPtDik7jRbuRnL9ADbYD1fO/2rXZ8F6Nwhi2vUzVHJues6dhSu7rYf7cCj2/dEz3gC wrOw== MIME-Version: 1.0 X-Received: by 10.202.209.200 with SMTP id i191mr256055oig.134.1418158957903; Tue, 09 Dec 2014 13:02:37 -0800 (PST) Received: by 10.202.227.77 with HTTP; Tue, 9 Dec 2014 13:02:37 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 13:02:37 -0800 Message-ID: From: Dave Taht To: Eric Schultz , openwrt@lists.prplfoundation.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] New FCC requirements and CeroWrt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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: Tue, 09 Dec 2014 21:03:07 -0000 On Tue, Dec 9, 2014 at 12:34 PM, Eric Schultz wrote: > David, > > Thanks for the response. We're getting advice from the EFF right now, > and hopefully other groups, on what the requirement is. It's > admittedly vague and hard to separate what the FCC means versus what > developers might think. The argument that myself, jim gettys, dan geer and bruce schneir have been making ( https://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/= ) Is that there is no guarantee that any device will not be hacked, with or without signing, with or without some lawyers approval, with or without some arbitrary strings of tests for compliance with existing regulations. And, as there is a near certainty of bugs in the default firmware, there a HUGE need to be able to update firmware in the field, lest we be spammed to death by our lightbulbs. I can point to multiple devices that achieved FCC certification that were very damaging to the airspace, and remain so, with their default firmware. Take this bug for example... http://www.bufferbloat.net/issues/216 which cost much hair. It wouldn't have shown up in any testing regime I know of. a year later, broadcom found and fixed essentially the same bug. There are millions of devices in the field that have not been updated, and will never be updated. (there are many nuances to these arguments - see geer's talk in particular, but also jim's comments) Being "born free", with source code provided to all and the FCC, and future updates having a *clear* and signed and *public* commit history is the only means of certainty for ensuring devices actually meet the spectrum and other requirements, and to continue to do so during the lifetime of the device. There is no safety inherent in signed binaries. Buggy code can be signed al= so. Any look at a bug database (take cerowrt's closed bugs) will show that nothing is perfect the first time (remove the open checkbox here) http://www.bufferbloat.net/projects/cerowrt/issues There is some safety in signing code that has already been throroughly vetted at the source and compiler level, and even then, that is hard. http://cm.bell-labs.com/who/ken/trust.html > > You bring up a lot of good points that I need to add to the page to > clarify. I'm not sure in this case you can separate the radio > frequency parameters from the kernel in the case of OpenWrt. I'm not a > kernel engineer but I've tried to general understanding of how the > frequency authorization works in OpenWrt and Linux. The process is well documented, and the best that it is possible to do, IMH= O. http://wireless.kernel.org/en/developers/Regulatory Given evolving regulatory requirements I think this is FAR better than closed source firmware can do. > As I understand it, the system for deciding which frequencies to use > is included as part of the kernel in OpenWrt. The kernel uses the > frequency database to decide on what commands to send to the wifi > driver (which include changing frequency, using DFS, etc). The driver > is clearly part of the device at this point. But how should the driver > verify that the commands coming in comply with requirements? It's not The verification step is in the signed database and in a minimal amount of code that is easily verified. Assurance to the FCC that this code is in there, and enabled, would be way better than signed binaries or any other scheme currently on the wiki. Again, in my case, I am tired of the argument that - in addition to the firmware on the routers - the onchip firmware must be closed, because (in addition to many other faults), there is no garuntee that it will comply either now, or later. There are zillions of IoT devices that have closed firmware (take wemo, please), and radios, that have been hacked already. > entirely clear. And how does the manufacturer guarantee that only > authorized updates are made to the device? How does anyone? Given all the exploits published this year, starting with heartbleed, there *can* be no guarantees. No lawyer has yet come up with a system of law that can trump natural law, though they seem to insist on trying. > I want to make clear, the wiki page does not include recommendations. > These were ideas that one of our members were throwing around > internally with their development and legal team. They've asked me to > try to come up with better solutions since they don't really like any > of the ones they've come up with internally. I'm contacting folks to > try to come up with recommendations for companies so they don't go for > the more extreme routes that unnecessarily lock down devices and hurt > the community. With the exception of the ath9k, they already have. It is not just bad for the linux community, but for everyone that shares ALL spectrum, that radios have all their firmware be locked down. The genie here is increasingly out of the bottle with software defined radio also. > > Eric > > > > On Tue, Dec 9, 2014 at 2:14 PM, David Lang wrote: >> We really need to find out what the new FCC requirements are. >> >> People have been claiming that the FCC requires all sorts of lockdowns t= hat >> they don't actually require for decades (when I first got into Ham Radio= , we >> were hearing that any radio able to operate on the business bands had to= be >> locked down to prevent the owner from changing it's frequency. It wasn't >> true) >> >> If they are saying that the RF portion can't be modified in a Software >> Defined Radio, that would be somewhat reasonable, saying that the softwa= re >> implementing the 802.11(whatever) protocol on that RF portion must be lo= cked >> down is less so, and saying that the main OS on the router must be locke= d >> down is completely unreasonable. >> >> I would be surprised if they required that the OS can't be changed. >> >> As for the implementation of the 802.11(whatever) protocol, I would be >> surprised if they required this to be locked down, but not dumbfounded >> >> >> now that I've finished the rant, reading the statement quoted on that wi= ki >> page: >> >>> Applications for certification of U-NII devices in the 5.15-5.35 GHz an= d >>> the 5.47-5.85 GHz bands must include a high level operational descripti= on of >>> the security procedures that control the radio frequency operating >>> parameters and ensure that unauthorized modifications cannot be made. >> >> >> All that it is talking about is the radio frequency parameters. >> >> The followup/clarification is again talking about the RF parameters. >> >> >> Remember, when the FCC is talking about a 'device', they are talking abo= ut >> the radio, not the entire computer that has a radio as part of it. >> >> According to the background, they are worried about interference with ra= dar, >> so this could mean that the firmware needs to have a mechansim to detect= the >> radar and not transmit on that frequency, but this is only a few channel= s. >> You could still have an opensource, non locked down firmware that just >> didn't give you the option of using those channels, and a signed firmwar= e >> that did. >> >> This does not require secure boot or any of the other lockdown methods t= hat >> are being talked about on that page. I hope these are not the "official" >> openwrt recommendations (and if they are, why are they not on an openwrt >> page?) >> >> David Lang >> >> >> On Tue, 9 Dec 2014, Eric Schultz wrote: >> >>> Dave, >>> >>> Thanks for the quick response and I appreciate your passion. >>> >>> No one here wants Secure Boot or DRM at all. I personally find the >>> idea abhorrent and no one at prpl wants it. The difficulty is figuring >>> out how companies can comply with the regulation in a way that doesn't >>> require hardware be locked down. I wish I could avoid ever thinking of >>> this topic but unfortunately, if companies don't find a solution that >>> fulfills the FCC's requirements, they're going to go with DRM. I want >>> to see if we can give manufacturers a solution that avoids DRM >>> entirely. >>> >>> I'd be happy to learn more about the make-wifi-fast effort and to see >>> how we can facilitate it's success. >>> >>> Thanks a ton, >>> >>> Eric >>> >>> On Tue, Dec 9, 2014 at 11:49 AM, Dave Taht wrote: >>>> >>>> On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz >>>> wrote: >>>>> >>>>> All, >>>>> >>>>> I work for the prpl Foundation, an open source foundation organized b= y >>>>> a number of companies, most related to MIPS. One project we work with >>>>> externally is the OpenWrt project. Recently one of our members >>>>> mentioned a new FCC requirement (described at >>>>> >>>>> http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_5ghz_= wifi) >>>>> which requires wifi hardware devices to restrict modifications in way= s >>>>> that were not previously required. Some of the suggestions the compan= y >>>>> had internally for complying would be to use features like Secure Boo= t >>>>> and other types of DRM-like mechanisms to prevent routers from being >>>>> modified. This obviously would be quite bad for the OpenWrt ecosystem >>>> >>>> >>>> It would be bad for everyone. Worse, since the research contingent >>>> making progress on keeping wifi working in the first place in the face >>>> of enormous growth, is centered around the ath9k chipset, additional >>>> rules and regulations centered around DRM are likely to choke off >>>> further development of then new ideas and techniques needed to keep it >>>> working. >>>> >>>>> so we agreed as a group >>>>> to try to provide hardware companies with a way of complying without >>>>> harming the community. >>>> >>>> >>>> My view is mildly more extreme - the 2.4 and 5.8 ghz spectrum currentl= y >>>> allocated to wifi is the *public's* spectrum. >>>> >>>> I am deeply concerned about further intrusions on it by things like >>>> this: >>>> >>>> https://www.qualcomm.com/products/lte/unlicensed >>>> >>>> and we need more spectrum, not less, in order to keep wifi for >>>> everyone, working. >>>> >>>>> I'm looking to find individuals (and other companies!) interested in >>>>> working with myself and the foundation, companies, the OpenWrt >>>>> community >>>> >>>> >>>> >>>>> and eventually regulators to provide guidance to hardware >>>>> companies on how to best comply with these rules. >>>> >>>> >>>> I intend to continue ignoring them to what extent I can. Regrettably >>>> this situation is contributing to community members being unable to >>>> apply new queue management techniques to new standards like 802.11ac, >>>> and seems to be the source of all the proprietary ac firmware. >>>> >>>> I think a first step would merely to be for a big maker to publicly >>>> release their 802.11ac firmware and let the chips fall where they may. >>>> >>>>> If you're interested >>>>> in getting involved or just would like to know more, please get in >>>>> touch with me. We want to make sure that routers are hackable >>>>> and we could use all the help we can get. >>>> >>>> >>>> +10. I would like to see prpl participating in the make-wifi-fast effo= rt, >>>> also. >>>> >>>> >>>> http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-126= 5-00-0wng-More-on-Bufferbloat.pdf >>>> >>>> >>>> >>>>> Thanks and I look forward to working with you, >>>>> >>>>> Eric >>>>> >>>>> -- >>>>> Eric Schultz, Community Manager, prpl Foundation >>>>> http://www.prplfoundation.org >>>>> eschultz@prplfoundation.org >>>>> cell: 920-539-0404 >>>>> skype: ericschultzwi >>>>> @EricPrpl >>>>> _______________________________________________ >>>>> Cerowrt-devel mailing list >>>>> Cerowrt-devel@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>> >>>> >>>> >>>> >>>> -- >>>> Dave T=C3=A4ht >>>> >>>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks >>> >>> >>> >>> >>> -- >>> Eric Schultz, Community Manager, prpl Foundation >>> http://www.prplfoundation.org >>> eschultz@prplfoundation.org >>> cell: 920-539-0404 >>> skype: ericschultzwi >>> @EricPrpl >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschultz@prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks