A question was asked:
> "At the very least, I think it would be beneficial for the IETF
> community to continue to call attention to folks that the minimum bar
> when introducing a large number of devices (or any device) to the
> Internet includes things like automatic software updates and avoiding
> default passwords. "
Some background: I have used the Freescale based redwire econotag in a number
of projects, going back to before the term "IoT" was around. (as an aside
[please change the subject if you reply] I contend that 90% of the Web
Connected Things we are having problems with are not actually IoT as the
*IETF* thinks of it).
The econotag has 96K of EEPROM, and 128K of ram. When I first started using
it, that number seemed to be 96K of EEPROM and 32K of ram. Definitely a
class 2 device. It turns out that the default mode of operation is to
copy the EEPROM into ram, and then run from ram as the EEPROM, while
directly addressable, is much slower and more power hungry to access.
My Contiki build, with debugging and RPL and some actuator code was 60K.
Ugh. How can I field upgrade the device if I can't double bank the code?
Could I optimize the build down to 47K? (2*47K + 2K for some failsafe boot
code I'd never update).
Should I instead wait for Moore's law to give me 128K of EEPROM?
I never did solve the problem for this device, and I think that many
engineering managers go through this same struggle. In the end, Moore's law
doesn't help, for two reasons:
1) bigger devices are expected to do more to justify their cost.
2) over time, code will expand to deal with flaws, and so will eventually
break the double-bank boundary.
In the case of the econotag, I observed that I probably could do something
like update the EEPROM code while running from RAM, and maybe I could even
make things fit through compressing the code in EEPROM and extract it to RAM.
But, it got me thinking about how the network could help here.
In the olden days (and in my lab today, with uBoot on a variety of
platforms), one uses tftp to boot the image you want. tftp has a ton of
problems. They range from congestion collapse of low speed links if multiple
clients power on at the same time, to IPv4 only, to insecurity of the
traffic... The USB ethernet on the RPI is unreliable under uboot, and I had
to resort to plugging them into dumber switches, because GbE PHY
negotiation often timed out after a cold boot, leaving the unit with a failed
DHCPv4. All of these are quality of implementation issues, not protocol
issues.
So what I want is something as simple, code-space-wise, as TFTP, but secure
and fast as HTTPS transfering signed S/MIME objects, or 4108 blobs. I want
to do all the crypto setup and certificate parsing in the main body of my
code, using the full capabilities of my "OS", and then leave enough session
key around in the eeprom so that the update blob can be downloaded with the
stupidest, simplest bit of code possible. Such that the device can actually
restart if it loses network or power part-way through the upgrade.
I had originally envisioned some kind of TLS with a session resumption
ticket. SLAAC host configuration with a stable private address (no routing
protocol, just 6lo/6man/efficient-ND). Use CoAP block mode rather than TFTP.
This is the protocol profile that I think woud be valuable for the IETF
to define. It's not enough to let it be vendor defined, because we need the
code bases (servers and clients and perhaps relays) to be widely available.
We need them to be in PC BIOSs ("press F3 to enter secure reflash mode"), and
Mobile Phone "Recovery" ROMs.
Writing the above, I realize that there is an alternative as well: HTTP/2
with QUIC satifies much of the requirements, from what I understand.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature