Subject: Reflections from IETF 97

From: IETF Chair <[email-masked]>
Date: Thu, 5 Jan 2017 15:28:27 +0200

I wanted to send a post summarising my thoughts of
the discussions at IETF 97. We had 1042 people from
52 countries on site in Seoul, very active development
on a number of fronts, and I thought a successful meeting!

(Apologies for sending this post out late, other tasks,
holidays, etc intervened.)

Here’s the post:

https://www.ietf.org/blog/2017/01/reflections-from-ietf-97/

Jari Arkko, IETF Chair

---

From: IETF Chair <[email-masked]>
Date: Wed, 11 Jan 2017 16:37:14 +0200

Dave Dolson asked me a question, and (with permission) I wanted
to respond on the public list, since the topic is probably interesting
for others as well.

> I'm reflecting on this statement:
> 
> "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. "
> 
> I'm probably showing my ignorance, but is there any kind of standard for automatic software updates?
> As far as I know, this is an area reinvented by every development team.
> And It is also an area of pitfalls and land mines.
> 
> I did find this: https://tools.ietf.org/html/draft-iab-iotsu-workshop-00 , but it is unclear to me if more work will be done.
> 
> Should the IETF specify protocols and design patterns for software updates?
> 
> I see this as relevant to everything from routers to browsers, video games and automobiles, not just IOT devices.
> 
> Thanks for any thoughts you might provide,

Yes, it is relevant for many things.

We do have RFC 4108, but I don’t know how widely it is used. And of
course many of the other generic tools that the IETF has worked on
can be applied to the software update case.

I think additional software components, standards, and industry
consolidation on their usage would be helpful. But like so many
other things, the need and the will to use some of the existing
or new things needs to come from the those build the stuff.
Software updates are also somewhere between systems engineering
and communications; the IETF hasn’t done that much work on
systems engineering. Nevertheless, the push for work has to
come from the community.

Do we have people who believe there are unmet needs, and
would be willing to work to address those? What specific things
would you like to work on? Should we have a working group?
And as noted before, January would be a perfect time to start
talking about that :-)

Jari

P.S. I should also say that my original statement — specifying a
minimum bar, broader than software updates — is potentially
controversial. The IETF is primary about producing stuff that
people want to use; we’ve had limited success in commanding
people to use <important technology> by merely listing it as
a requirement. People will use what they will use. One might
classify the suggested minimum bar as wishful thinking, and
that IETF resources would be better spent on building those
missing software update standards or other pieces of tech.

The reason why I had a different opinion in this case was not
so much the direct ability to influence, but rather the indirect
effect that we might have for instance if people affected by 
attacks, insurers, governments, etc. would be able to point 
to an IETF document and say that not even the minimum
bar was met :-) But opinions will certainly differ on this.

There’s also a category between issuing requirements
and working on new tech, documenting state of the
art and missing pieces/challenges; that is always
useful. The IAB workshop on software updates was
in that category. The document from the workshop
is out: https://tools.ietf.org/html/draft-iab-iotsu-workshop-00

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Jan 2017 11:25:28 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-