Date: Thu 2024-11-07 Time: 09:30–11:30 (UTC, also venue time zone)
Agenda and further Details:
https://github.com/t2trg/2024-ietf121
(Video links are in the individual items below)
Note takers: CA, AK, AP
9:30 — https://youtu.be/OUeWFyPuHtc?t=136
AK doing introductions.
AK(p8-p9): scope & goals -- IoT tech IP and above and opportunities for
IETF
AK(p11): Document status. Please review RESTful design for IoT, focus on
publication, heading for RGLC. (Also review others!)
AK (p12): IETF 121 Hackathon: "SDF at work" evolved from what was "NIPC
in ASDF" before.
AK (p13): meeting plans. Always interested in academic conferences to
co-locate with.
09:40 — https://youtu.be/OUeWFyPuHtc?t=850
CB presenting.
CB(p2): 11 years depend on what you count.
CB(p3): (slide from 2013)
CB(p5): Will need a summary/overview for the 45 unpublished drafts.
CB(p6): The interaction with other SDOs / WGs
CB(p8): When you have a data format, you have these 3 layers.
Information Model, Data Model (often derived from JSON, which is one of
the data representation formats), Serialization (data representation
format comes with one). Here, we focus mostly on the Information Models,
as the others are typically handled elsewhere.
CB(p9): Motivation for working with information models.
CB(p11): Not just about static models, but about derivation activities.
Generic model like SDF (a way to write down generic data models) from
which application specific models (e.g., a YANG model) can be derived.
Vertical axis: Generic model provides way to do instances (which need a
representation format; ASDF has nothing yet but may get one).
CB(p12): Security has data modeling aspects, but more: participants,
roles; objectives. Without knowing the security objectives of the
participants, we cannot really know what is needed to ensure security.
CB(p14): New coming up: Sustainability (we always did that)
LT: Not just energy, also producing things for specific task, so
re-usability should be a point.
AP: +1 on LT. Another point: Interoperability, enabling living for a
long time.
CP: Thanks for all your efforts, successful group, looking forward to
more years.
09:55 (10:02) — https://youtu.be/OUeWFyPuHtc?t=1958
NM presenting remotely.
NM: Bachelor thesis on conversion.
NM(p2): Intro to Matter -- connectivity for smart home.
NM(p4): List of direct mappable data items. For others, some information
needed to be processed to be mapped.
NM(p6): SDF on left, Matter on right (mapping file not shown)
NM(p7): SDF was sufficient to contain necessary information from Matter
data model. It can be integrated in a Matter bridge. Matter bridge is a
type of device in Matter.
NM(p8): a bridge Matter ⇆ SDF ⇆ LwM2M was implemented. Able to run
bi-directional communication.
NM(p10): Link to the code is provided, the code is much richer. Also
soon to be published bachelor thesis.
CB: played around with this in the hackathon; thesis in German but can
use translator tools
MGi (chat): This is so cool!
AP: Did you contact Matter to discuss? Open to integrate this kind of
work?
NM: Not yet; would be good idea for future; data model and schema are
currently missing.
AP: How difficult was it to use SDF format for LwM2M mapping? Would it
take long to map YANG?
NM: SDF-to-LwM2M was not from me; pre-existing and just used. Depends on
complexity of data model. Matter was pretty complex b/c spec was complex
and unclear. Realistically, took 1-2 months.
MGi (chat): Live demo soon? Volunteer to bring LwM2M toys.
CB: we probably want to locate a specific event to play with this. In
particular when Niklas has finished documentation.
10:10 (10:17) — https://youtu.be/OUeWFyPuHtc?t=2832
MGu presenting remotely.
MGu(p2): Looking into YANG'ifying SenML. Structures are similar.
MGu(p3): Terminology and references.
MGu(p4): YANG model can constrain and describe relations between data
items more than SenML CDDL. CoREConf can be more efficient for items.
MGu(p6): Overview of the SenML structure. Expressing constraints.
MGu(p7): The YANG model tree was shown.
MGu(p8): Representation of the SenML fields and how field names can be
expressed as integer for efficient CBOR encoding.
MGU(p10): Presents the transformation. The SIDs corresponding to the
SenML identifiers are chosen such that the deltas in the delta encoded
YANG-CBOR correspond to the SenML's CBOR Label integer values.
MGu(p11): By right choice of SIDs, rest of payload becomes SenML.
MGu(p14): Could different label for SenML "n" be used?
MGu(p15): Benefits? Once YANG-SenML is usable, can be easily integrated
in YANG environments.
MGu(p16): there is a web site coreconf.manojgudi.com where you can
play with the data
CA: Why model including base parameters? SenML can equivalently move
data between bn and n; constraints would be on logical bn|n. (Or, the
unit constraint of p9 might be violated because it's in bu). Might break
equal-bytes parts if SenML producer does equivalent changes.
MGu: Interesting proposition. Trying to do an as-rigid-as-possible
definition for SenML.
AP: Had discussion that n can be expressed as a string. If you just send
that as a string, then it'll have the equivalence.
MGu(p22): Yes, that's consistent with CoREconf that allows numeric and
textual mixed. But it breaks SenML-CBOR spec.
AP (on the chat): I'm not sure the "n" hack breaks the SenML spec. The
way I read it, it's OK
AK: Interesting, I like that it works as SenML with minimal additions
AK: n and bn can sometimes be used interchangeably, can help with the
zero issue. We should take a closer look in a follow-up meeting.
10:30(10:34) – https://youtu.be/OUeWFyPuHtc?t=3870
MT presenting.
MT(p1): A compact overview of components.
MT(p2): Background we'll need.
MT(p7): Assembly of components.
MT(p8): Chronological order here – but pedagogically we'll go through
components in reverse order.
MT(p10..): Building up.
MT(p14): OSCORE-in-OSCORE was not allowed, also because we had no use
cases. Now we do.
MT(p15): Instead of one notification per client, this allows sending a
single multicast notification.
MT(p17): Now on to the management components.
MT(p22): With all those parts, assembling story.
MT(p24): Combining this into an efficient firmware update for a group of
devices.
MT: More slides starting p27 to give all details
CB: Amazing presentation, esp. in this small amount of time. Will need
to put this separately in YouTube
DK: Great work. Seems intricate. Have you done security analysis? What
can go wrong?
MT: No formal analysis; many security considerations
10:50 (10:55) — https://youtu.be/OUeWFyPuHtc?t=5166
CA: played around with the CoRE building blocks to see if something like
ToR could be made of these
CA: Use a chain of proxies, neither sender nor receiver trust any of the
proxies
CA(p3): List of building blocks, OSCORE, EDHOC, + some more — only one
appears to be needed specifically this draft (globally federated address
table)
CA(p4): OSCORE in OSCORE — but this is recursive (you can have another
OSCORE within the inner OSCORE without being able to tell)
CA: naming things with hashes still TBD work. Base32 encoded name /
public key in URL now.
CA: think core work and specs are there. Whether it can work in
practice, exploring as part of experiment. Working towards having
implementations. Roll into experimental RFC and gather experience. How
to find which proxies are eligible.
CB: Considered recent attacks on Tor?
CA: if attacker can monitor all the hops and has sufficient timing info,
hard to go around them. In EDHOC setup associate security setup with
timing criticalness, if no urgency, client could indicate in security
context setup expectations on RTTs. Proxies create secure connections
and keepalive. Proxies not constrained, they could have housekeeping
data for keepalive. Considering sizes of messages, totally realistic
proxies could send for each connection ongoing one MTU / packet per
second. Could be padding. Response would come back and no visible data
on having the random data along.
CB: it came up this morning (in IAB review) that draft is thin on use
cases. Need to just write them down here.
11:05 (11:10'ish) — https://youtu.be/OUeWFyPuHtc?t=6083
MCR(p3): NIST activity that brings together people with different
onboarding strategies.
MCR(p4..): Overview of participants -- WiFi DCC, BRSKI, Thread.
MCR(p7): Getting private keys in secure elements; NDAs getting in the
way, still tried.
MCR(p8): High-level architecture. Now how do things map into this?
MCR: Take-home-message: We all fit into this diagram.
MCR: No-one did QR codes.
MCR(p12): Network-layer onboarding, application-layer onboarding.
EAP-TLS may get you into the network, but where does data go up?
MCR(p13): Caring about continuous verification service. Prolog inference
engine reasons about whether device can still be trusted.
MCR(p14): Various secure elements. OpenSSL architecture changes don't
help here.
MCR(p15): Late binding with integration service.
MCR(p16-17): My diagram/network. Unexpected issues with SHA-1 (only)
support in VirtualBox etc.
MCR(p19): Black bit on top has private key, and this gets carried over
to floor.
MC: lots of pictures and refs to long docs here. Happy to get feedback
on the documents, e.g., what is not clear.
MCR: Outcome: There are solutions to zero-touch onboarding. There are
even many, XKCD927 applies.
AP: Are all these documents public?
MCR: p3 bottom link goes to documents, all are published drafts, NIST
will publish them publicly.
MCR: DPP spec is behind marketing wall which has requirements (IPR
issues).
AP: When next event?
MCR: It's finished. I do think a do-over is in order, maybe in 2y, maybe
interop/ETSI/INRIA.
11:25 (11:27 -- short'ish) — https://youtu.be/OUeWFyPuHtc?t=7053
AK: Will set up follow-ups on Matter/SDF and YANG/SenML, probably in
common meeting; also for security topics.