[Cerowrt-devel] some comments from elsewhere on the lockdown

[David P. Reed]

Sounds great to me

On Sep 25, 2015, Dave Taht <dave.taht at gmail.com> wrote:
>The core of the FCC letter is currently this. comments?
>
>snip snip
>
>In place of last year’s and the new proposed regulations, we propose a
>system of rules that would foster innovation, improve security, make
>Wi-Fi better, and overall improve usage of the Wi-Fi spectrum for
>everybody.
>
>1) Mandate that: for a SDR, wireless, or Wi-Fi radio of any sort - in
>order to achieve FCC compliance - full and maintained source code for
>at least the device driver and radio firmware be made publicly
>available in a source code repository on the internet, available for
>review and improvement by all.
>
>2) Mandate that: the vendor supply a continuous update stream, one
>that must respond to regulatory transgressions and CVEs within 45 days
>of disclosure, for the warranted lifetime of the product + 5 years
>after last customer ship.
>
>3) Mandate that: secure update of firmware be working at shipment, and
>that update streams be under ultimate control of the owner of the
>equipment. Problems with compliance can then be fixed going forward.
>
>4)  Failure to comply with these regulations will result in FCC
>decertification of the existing product and in severe cases, bar new
>products from that vendor from being considered for certification.
>
>5) In addition, we ask that the FCC review and rescind the rules for
>anything that conflicts with open source best practices, and/or which
>causes the vendors to believe they should hide the mechanisms they use
>by shipping undocumented “binary blobs” of compiled code.  This had
>been an ongoing problem to all in the internet community trying to do
>change control and error correction on safety-critical systems.
>
>
>On Fri, Sep 25, 2015 at 9:16 PM, David P. Reed <dpreed at reed.com> wrote:
>> Those of us who innovate at the waveform and MAC layer would argue
>> differently.  The cellular operators are actually the responsible
>control
>> operators and hold licenses for that. They may want to lock down
>phones'
>> cellular transmitters. But U-NII and ism bands are not licensed to
>these
>> operators. There is no license requirement for those bands to use
>particular
>> waveforms or MAC layers.
>>
>> So this is massive overreach. The control operator of the "licensed
>by rule"
>> Part 15 radios in your phone or home are licensed to the device user
>and not
>> to the mfr at all. For example, the user is responsible that the
>device not
>> interfere with licensed services, and that the device stop
>transmitting if
>> such harmful interference is called to their attention, *even* if the
>device
>> passed certification.
>>
>> Lock down has not been demonstrated to be necessary. This is all due
>to
>> fearful what - if speculation by people who have no data to justify
>the
>> need, plus attempt to stop innovation by licensees who want to
>exclude
>> competitors from being created, like LTE operators proposing LTE-U
>which
>> will be locked down and is the stalking horse for taking back open
>part 15
>> operation into a licensed regime based on property rights to
>spectrum.
>>
>>
>> On Sep 24, 2015, Dave Taht <dave.taht at gmail.com> wrote:
>>>
>>> a commenter that I will keep anonymous wrote:
>>>
>>>
>>> Regarding the FCC firmware lockdown issue, I’m sure you’re aware
>that
>>> baseband firmware in cellphones has been subject to similar
>>> restrictions for some time. In fact, the FCC effectively mandates
>that
>>> baseband functionality is implemented on a whole separate subsystem
>>> with its own CPU to make it easier to isolate and protect. Also, the
>>> cellphone system is designed so that a misbehaving node can be
>easily
>>> identified and blocked from the network, making it useless and
>>> removing most of the incentive to find ways around regulatory
>>> restrictions. Wi-Fi devices have none of these protections.
>>>
>>> I believe this new attention to Wi-Fi devices is a consequence of
>many
>>> factors:
>>>
>>> The precedent from cellphone baseband firmware control; regulators
>are
>>> easily inspired by success stories in related areas
>>> The substantial increase in flexibility offered by SDR
>implementations
>>> Technical ignorance, for example of the difference between OS,
>>> protocol, and UI firmware and baseband firmware
>>> The expansion of allowed capabilities in Wi-Fi hardware (from 5.8
>GHz
>>> ISM to the U-NII bands, increases in transmit power allowances,
>etc.)
>>> The improved spectrum utilization of newer Wi-Fi modulation schemes
>>> Inconsistencies among international regulations for spectrum
>allocation
>>> Spectrum sharing between Wi-Fi and life safety applications
>>> The relative lack of attention to (and sometimes, the deliberate
>>> flouting of) regulatory constraints in open-source firmware
>>> The increased availability of open-source firmware for higher-power
>>> and narrow-beam Wi-Fi devices (not just the WRT-54G :-)
>>>
>>>
>>> And probably more I can’t think of off the top of my head, but which
>>> regulators are obsessing over every day.
>>>
>>> Although I agree with the spirit of your FCC email draft letter, it
>>> does not address most of these factors, so it’s likely to be seen as
>>> missing the point by regulators. If you want to reach these people,
>>> you have to talk about the things they’re thinking about.
>>>
>>> What you ought to be pushing for instead is that Wi-Fi devices be
>>> partitioned the same way cellphones are, defining a baseband section
>>> that can be locked down so that the device can’t operate in ways
>that
>>> are prohibited by the relevant local regulations, so that the OS,
>>> protocol, and UI code on the device can be relatively more open for
>>> the kinds of optimizations and improvements we all want to see.
>>>
>>> It’s possible that the partition could be in software alone, or in
>>> some combination of hardware and software, that doesn’t require a
>>> cellphone-style independent baseband processor, which would add a
>lot
>>> of cost to Wi-Fi devices. For example, the device vendor could put
>>> baseband-related firmware into a trusted and _truly minimal_ binary
>>> module that the OS has to go through to select the desired
>frequency,
>>> power, and modulation scheme, even for open-source solutions. That
>>> doesn’t mean the source code for the binary module can’t be
>published,
>>> or even that there can’t be a mandate to publish it.
>>>
>>> I’m sure that doesn’t sound like a great solution to you, but making
>>> it easy for end users to configure commercial devices to transmit at
>>> maximum power on unauthorized frequencies using very dense
>modulation
>>> schemes doesn’t sound like a great solution to regulators, and the
>>> difference between you and the regulators is that they are more
>>> determined and, frankly, better armed. It will do you no good to
>>> constrain the range of the solutions you’ll accept so that it
>doesn’t
>>> overlap with the solutions they will accept.
>>>
>>> .               png
>>>
>>>
>>> On Sep 21, 2015, at 5:10 AM, Dave Taht <dmt at millcomputing.com>
>wrote:
>>>
>>>
>>> Dave,
>>>
>>>
>>> Huh. I have been interested in mesh networking for a couple of years
>>> now, and curious about Battlemesh, but I had no idea I knew someone
>>> who was active in it.
>>>
>>>
>>> Are there any other reports online from this year or last year? The
>>> website doesn't seem to serve any purpose beyond announcing the
>event.
>>>
>>>
>>>
>>> As you can tell I am way, way behind on my email. I've mostly been
>>> chasihg funding for my main project, make-wifi-fast for over a year
>>> now - I added in the mill and the "cake switch chip" to that overall
>>> list as I tried to climb the financial ladders. My funding at google
>>> dried up suddenly (due to the re-org), and I was forced to chase
>other
>>> avenues. I think i got a grant from comcast coming in, but it is for
>>> 1/10th the total I needed for make-wifi-fast... and it is hung up in
>>> legal, and in the fact the work has to mostly happen in europe.
>>>
>>> So I've moved to europe, trying to find bases in bristol, england,
>>> berlin, and sweden. That's taken a while (I dropped out of the mill
>>> process in may or so due to the sudden google silences, and the lack
>>> of compiler - and I view mill's biggest problem is funding, so it
>>> seems like just combining my own quest with yours the right thing)
>>>
>>> I was very involved in the early days of wireless networking but
>>> dropped out by 2002 or so, much to my now, later regret. The only
>devs
>>> left that understand it at more than one level all go to battlemesh,
>>> so I've been there twice. I still find it quite discouraging how few
>>> grok the minstrel algorithm, or what is wrong with packet
>aggregation.
>>> A billion+ users that all think wifi "just works", and "always
>>> sucked"... :( I gave a talk on the latter as well at at this
>>> battlemesh.
>>>
>>> anyway the videos and results from this battlemesh are all now
>online.
>>> I am pushing on all fronts, but being a manager was a bit wearying
>so
>>> I took time out to do some recording at a place called
>theconvent.net
>>> for the past 2 weeks. Haven't played the piano so much in 5 years!
>>>
>>> Youtube videos:
>>>
>>> https://www.youtube.com/channel/UCxfh-2aOR5hZUjxJLQ2CIHw
>>>
>>> blog post:
>>>
>https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/
>>>
>>> The test results were dismal, as expected. Finally knocking a few
>>> heads to use abusive network tests like what toke and I developed
>were
>>> hopefully an eye-opener, and a lot more people grok what
>>> make-wifi-fast is really about, and how to do it.
>>>
>>> http://docs.battlemesh.org/
>>>
>>> one very positive outcome of the fcc talk was a level of net outrage
>>> and organisation over some new fcc rules I have not seen before. My
>>> letter to the fcc, in progress, with vint cerf and other
>>> co-signers is up for review at:
>>>
>>>
>>>
>https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing
>>>
>>> A similar letter has to go to the eu, as they just passed similar
>rules.
>>>
>>> as much as I would like to be working on the mill, it seems
>politics,
>>> finance, and organisation are in more need of my attentions right
>now.
>>> but I will keep plugging y'all at every opportunity.
>>>
>>> But, but... as I said, I just took a few weeks off and am picking up
>>> the pieces and trying to figure out what to focus on, at the moment.
>>>
>>> If you wish a faster response to my email, please use
>dave.taht at gmail.com
>>>
>>>
>>>
>>
>> -- Sent with K-@ Mail - the evolution of emailing.

-- Sent with K-@ Mail - the evolution of emailing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150925/7e0bdd1b/attachment-0002.html>