Time: Tuesday, 2020-04-14, 13:00-15:00 UTC
Chairs: Carsten Bormann, Ari Keränen
Note takers: Christian Amsüss, chairs
Repository: https://github.com/t2trg/2020-ietf107
Video of meeting: https://youtu.be/cKE7jkSPBKo
Agenda:
| 13:00 | Chairs: Intro, RG status, upcoming meetings and activities |
| 13:05 | Chairs, various: Reports from WISHI, Pre-IETF OneDM workshop, WISHI-hackathon, W3C WoT |
| 13:20 | Carsten Bormann: OneDM update and tutorial |
| 13:45 | Lars Eggert: Towards Securing the Internet of Things with QUIC |
| 14:15 | Mohit Sethi: Bootstrapping terminology |
| 14:30 | Tiru Reddy: MUD (D)TLS profiles for IoT devices |
| 14:40 | Xavier de Foy: IoT Edge Challenges and Functions |
| 14:55 | Chairs: Wrap-up |
| 15:00 | end of meeting |
Ari Keränen doing introductions: note well, blue sheets (fill out below), repository (see above), presenting agenda
queue management ad-hoc (as we’re a small group) or q+/q-
T2TRG scope / goals, interaction with IETF (CoRE, LWIG). This is a summary meeting (standing in for the physical meeting); monthly WISHI calls happen
Documents: RESTful Design and Edge & IoT upcoming. Others ongoing but not presented today (YOUPI, CoRE apps, Layer 3 considerations). Edge & IoT needs reviewers. WISHI notes planned to become more formal (RG documents).
WISHI: latest meetings focused on OneDM (see later); versioning of data models and development of number spaces. Approaches presented, and semantic proxying between LwM2M and OCF based on OneDM SDF models. Friday-before-Hackathon meeting: focused on OneDM, versioning (vs. feature definitions), evolution.
Charter of WoT WG: five deliverables
Thing description and Architecture just became W3C recommendations, April 9, and the other deliverables became W3C notes.
Ege gave a very quick view at the architecture.
WG is now going to a maintenance round. v1.1 planned for in one year.
New task force: Discovery as a new topic. More streamlined Testing. Outreach ongoing. More info and links on slides (esp. wiki with calls and minutes).
Carsten Bormann presenting:
https://github.com/t2trg/2020-ietf107/blob/master/slides/21-onedm-update-and-tutorial.pdf
[This is now extracted in a video at https://youtu.be/sTrqa5jYVKo]
See also Michael’s recent presentation at the pre-IETF106 Friday meeting – this now will be more high-level (components).
Why OneDM? Ecosystems have bespoke data models, but applications interact with devices from several ecosystems for non-trivial cases. Translating data models is harder than translating protocols.
OneDM is a liaison group, several SDOs included. Common format shows common components and differences. BSD-licensed models. NDAs around participants, but shared results in GitHub (https://github.com/one-data-model/). Harmonization around SDF (simple definition format).
SDF: current status at https://github.com/one-data-model/language
Describes class of things as opposed to Thing Description describing an individual thing. Things have interactions with their peers (“clients” – used here for everything that’s not a thing) called affordances here. Popular choice: group affordances into interaction patterns (property, action, event) – those do have “data” that can be (data)modelled, not the devices themselves.
Interaction patterns (see table on slide 5). What data is processed, where is it sent, who starts it, what’s it called in REST. Properties match well with REST GET and optionally PUT (in same affordance). Actions is like “remote procedure call” as many people see it, or POST in REST. Events are not supported well in classic REST. However mapped in REST, the initiative is with the REST server.
About Action: Distinguish between properties (data that is set / read) vs. actions that have input/ouput and may take time to perform, data might arrive later than the confirmation. This is the only pattern with two different data models involved.
SDF also has “observable properties”: initial initiative with client, but then reversed – not too far from an event, no clear boundary. Event is different and not that well defined; data-model-wise it’s easy; some semantic differences are not modelled (eg. whether it’s observe-style or more heavyweight where each event is precious, like insertion of a coin into a device) – there’s some openness in the specification.
Question from Ege: Had discussion as well around observable properties and events. What we roughly do now (don’t spec but think): Events need configuration to set up (delivery mechanism etc), that’s where the heavy stuff is. properties have more details how to set and get. If want to send every second the location of a robot, that would be an event stream.
CB: Knowing that you have recent data about a property is valuable knowledge as well.
(CB continuing) Data definition: What should be there (think schema languages); can be inline in affordance definition or separate. Subset of json-schema.org terms, and SDF-specific terms (eg. contentFormat, scales etc) – evolving this needs more discussion, currently it’s what we found for immediate use. Terms are usable, but not necessarily the most obvious terms.
odmThing, odmProduct: Affordances (using data definitions) are used to build groups (eg. thermostat w/ writable set point and readable current temperature) in objects. Objects combined into things. Things can reuse things (but how to model composed things of multiple things of the same class is unclear yet). Products are combinations of things that are not harmonized but describe specific products.
More concretely on the specification itself: Represented in JSON (makes tool usage easier) linked with JSON pointers between documents and to point into documents. Pointing allows reuse of other specifications; some core set might be defined soon.
SDF needs specification as well; done using json-schema.org format at the moment. (Can be confusing – json-schema.org is used to describe SDF, but also as terms inside it). Different specifications used to validate documents. Playground at https://github.com/one-data-model/playground with hundreds of data models.
SDF specification is now stable enough to submit data models. SDOs have started to build tools for conversion. (OCF is still WIP, but coming soon.) Use of tools means having good coverage without huge workloads.
OneDM is planning an upcoming online conference until end of May.
Next steps: model consumers (which will prove that this all is useful). Interesting to look how W3C WoT TDs can be made to work together with OneDM models.
Nice thing about model conversion: Can make non-compatible changes and just change tools.
How will it become a real-world specification? Find venue (IETF? to be discussed) to do this.
Q:
Mohit Sethi: if part of the ecosystem what’s the motivation to publish things in SDF. Who would be doing the proxies. CB: Motivation is that you want other people be compatible with your devices – you are opinion leader for this particular kind of thing. How to work in that space? Currently have to be affiliated with one of the ecosystems to join the OneDM meetings. As things are happening in the open, you can send PRs to playground. CA: who is doing the proxies? CB: people who are working on specific ecosystems and try to make their ecosystems useful are interested to do the proxies. To test if we have everything we need but also validate ecosystem specific side that it can be done and nothing is missing.
CA: would have expected that one proxy would do this – but sure does not cover the transport aspects. CB: have to have protocol bindings for specific ecosystems. There are proxies already – like IKEA box talks ZigBee and CoAP. People who build these proxies will also enter the work at some point.
MJK: For demo, plan to use W3C Web of Things implementation in the Eclipse foundation, called ThingWeb Node WoT, which has good support for existing protocols, in the form of protocol bindings. SDF model used to do build a tree for which ThingWeb has protocol bindings to build the proxy.
AK: running low on time now but if people are interested on the topic recommend to join the upcoming WISHI OneDM meetings.
Lars Eggert presenting
about paper presented in previous workshops
Can you run QUIC on an IoT device?
Motivation: Research; and leverage engineering of QUIC on the devices where it can be used. There’s a line below which this is not feasible – at least for some devices we know it can be done.
Basis: minimal stack written for using 40Gbit network card easily
On devices with LWIP (RIOT GNRC has no zero-copy; own backend but ugly). Particle Argon easily usable because LWIP present.
Based on that, QUIC stack (Quant): using picotls, several other small libraries
board introduction (Particle Argon, ESP32) see slide 24 devices have much RAM and flash (256k and 1MB / 520kB and 4MB) different OSs used to show it can be done
measured flash consumption against baseline application: some differences between applications in terms of features, but barely visible in diagram anyway. Total in both cases <100 kB ROM before later optimizations
some nastiness from QUIC because heavily assumes 64bit (but can be worked around), or limited in application (which dev sends >2**32 pkgs). Server and client mode present. TLS crypto can be slimmed down; actually using hardware crypto could save some more. Shortening error messages helps as well. No HTTP/3 itself implemented in those stacks, only QUIC.
Stack/heap usage: no instrumentation in crypto functions because a) messy (doesn’t terminate) and b) obsolete when hardware cyrpto is used. Diagrams on p37 show lower bound of stack use because crypto is missing. Public key phase needs much more stack – but doesn’t help much. Argon device needs a lot of heap due to its operating system.
energy and performance: much handwaving. Comparing 0-RTT and 1-RTT; advantage to 0-RTT as expected, but much uncertainty.
Potential for future work – scaling it down? Probably it can be done in half the space.
Q:
Mohit: Would be happy to host this at LWIG. Technical: fine with IoT device as client – but then 0RTT makes sense to have in there, as amount of energy consumed for radio is much more than local computation. Gut feeling is using more Flash for code or more computing pays off in saving on sending and receiving. Hardware crypto we should definitely use. See how far can we go. About 16-bit: Already hard to find, no point in this. 32-bit are sometimes more energy efficient. BLE or .15.4: would be happy to see results on that.
Mohit Sethi presenting
Secure IoT Bootstrapping: A Survey
New goal: document terminology, define bootstrapping (“onboarding”, “commissioning”, …: who uses which terms. Related?) Pick terms to be favored in IETF (CB: Yes!) Original goal: Provide examples of bootstrapping techniques (IETF and non-IETF: OMA, OCF, ..) Possibly classify by requirements (server? smartphone application?)
Current terms
LwM2M: “provisioning” using bootstrap server in different setups, “registration” during lifetime. OCF: “onboarding” before operation (including “configuring” the owner, including “just works” (TOFU during initialization), shown PIN; onboarding tool is typically smartphone application; can also be certificate or vendor specific). Bootstrapping server comes later. DPP (out of WiFi alliance): “configurator” (eg smartphone application), “enrollees”; in phases “bootstrap”, “authentication”, “configuration”. Z-Wave: key pair, QR code, ECDH (just describing the method, no names for the steps)
Found patterns (slide 8): Suggested general term: “bootstrapping” with some steps in there
IETF protocols to be included in next draft
Bootstrapping, factory reset, ownership transfer: Is factory reset a good thing for ownership transfer? (eg. Android: Can’t reset without having Google account to make it unusable to thieves, but legitimate transfers like flea market?) Physical access required to revoke keys (eg. kick out of network after having sold device)? Often overlooked, but fundamental to bootstrapping process.
Looking forward to feedback and eventually RG adoption.
Tiru Reddy presenting
Manufacturer Usage Description
ACLs for permitted behavior
Differences in malware and legitimate TLS usage (subject name, cipher suites)
Flaws in legitimate software (Samsung fridges)
MUD works even after IoT devices learned new skills (TLS parameters don’t change)
YANG model updated for observable profile parameters, eg. CAs
Malware not expected to be able to mimic the right profile on the right device
Looking for comments
Q:
Mohit: three questions:
Xavier de Foy presenting
history of draft
updates of -02/-03
content and structure now more stable (notes for reviewers on slide 5)
CB: Who would review? Thomas Fossati, Marie-Jose
CB: reminder about adoption, we need to only agree that the document is useful. We don’t need to agree on all the details.
(38 in Webex)