Minutes interim-2018-t2trg-01: Fri 09:00
minutes-interim-2018-t2trg-01-201811090900-00

T2TRG Bangkok work meeting

November 9, 2018 (IETF103 Friday)
https://github.com/t2trg/2018-11-bangkok

Note takers: chairs, (anonymous helpers)

# Chairs: Welcome & Short Introduction. T2TRG/IETF work.

Slides:
https://github.com/t2trg/2018-11-bangkok/blob/master/slides/T2TRG-2018-IETF103-work-meeting-slides.pdf

Carsten presented T2TRG work. Different to IETF as we look for consensus for
(only) if something is a good research topic.

Hannes Tschofenig: planning to do the edge in the same session with COIN?
Erik Nordmark: seems to make sense to do as one

# Jungha Hong: Problem Statement of IoT integrated with Edge Computing

https://github.com/t2trg/2018-11-bangkok/blob/master/slides/Slides-Problem%20statement%20of%20IoT%20integrated%20with%20Edge%20computing-01.pdf

Using EdgeX for enabling edge computing. Got latency down to 6 ms in the use
cases.

Jungha showed videos of the two use cases. Construction site with a sensor box
in the site. Collected noise, vibration, and gas information. Simple scenario
for scaling the video resolution based on sensor data triggers.

Another use case with an inverted pendulum. Goal of the system to balance the
pendulum. Edge computing function used to make it happen. Video at youtube:
https://www.youtube.com/watch?v=IDQreD-RBWo

Erik: interesting; didn't know EdgeX foundry supports real-time scheduling (as
is generally available in Linux). Is such used here?

Jungha: No, EdgeX does not support real-time scheduling. Monitoring system was
based on EdgeX. Real-time control system was at edge node.

Ravi Ravindran: what is locally at the construction site?

Jungha: edge node at the construction site. Collects information there. When
anomaly detected, only then send video as full HD to the cloud. Otherwise using
lower quality. Uses LTE and is optimizing cost (money).

# Erik Nordmark: Computing at the Edge

Slides:
https://github.com/t2trg/2018-11-bangkok/blob/master/slides/Computing%20at%20the%20edge.pdf

Slide 5: Privacy is not among the list, as the data can still be private while
they are sitting in a data center somewhere

Slide 8: device-to-"gateway" -- this means making up a physical topology that
matches the application topology for a single application (generally discusses
decoupling network topology from application technology)

Dirk Kutscher: network API description interesting. Depends on the kind of
application envisioned. Edge computing for industrial bus technologies, for
example, some have critical timing requirements. Might want to specify more on
what they need and expect. And also what they expect from the platform. "Can I
run this as latency bound"?

Erik: definitely the case. Want to specify if need certain protocols or reserve
resources. Or if some service should have specific Ethernet driver for
industrial Ethernet. Presumably want some resource management. People already
have built this kind of stuff. For example, in automotive using hypervisors
that can define "this process will always have at least one core".

Dirk: if think about data analytics, privacy preserving analytics could be
important feature. If I trust a function to do something on data, is it only
used for that purpose. Can the platform owner see the data, etc.

Carlos Bernardos: Very good stuff. Did you consider making use of local context
information? MEC and multiple access kind of things.

Erik: example of a video camera in parking lot and communication of what is
available there -- location more important information.

Carlos: there is a concept of the edge where it is possible to have end-user
devices; called fog computing.

Erik: single asset owner scenario might be more in industrial IoT. Samsung
selling a fridge needs to be connected to the back end. But people may not want
to give all data. My eating habits should not end up with insurance provider.

Ravi: how about mobility; if edge is part of decision making group. Something
you are considering?

Erik: yes, car or airplane could be hosting the edge. Might be something you
want to expose to application.

Carsten really liked disagreeing with the term gateway. We should get rid of
that. Who interested to work on terminology for this?
 (Dirk, Niklas, ...)

Niklas Widell: lots of organizations in Edge area. How IETF could be producing
value here?

Erik: the last slide had some difficult research problems.

Niklas: networking perspective?

Erik: networking pieces there, discovery, trustworthy communication. Also, even
in that world, what kind of networking attributes we want to expose? For
example, wifi could be cheaper than LTE. What APIs to expose on what networks
are available? Maybe that changes in multiple asset owner space.

# Thorsten Dahm: Automated IoT Security

Slides:
https://github.com/t2trg/2018-11-bangkok/blob/master/slides/IoT%20Security%20Profiles%20-%20IETF103.pdf

Automation is the only way to win security race on IoT. The presented draft is
an easier-to-digest version of the draft presented earlier.

Protocol for Automatic Security configuration proposed as potential solution.

(ran out of time in the plenary part; rest of the discussion below is from the
security breakout)

Thorsten: Other people interested in helping and contributing? One bigger thing
needed: running code. My company does smart buildings. Have started with SDN
based solution. Working with university of Wales. Huge potential to collaborate
also on code side.

Jim Schaad: haven't looked into this. Sounds very similar so SACM, security
tokens, maybe even DOTS. And MILE. Have you gone through these groups and see
what is the overlap?

Thorsten: not personally, sent e-mails, but no answers.

Eliot: have gone through some of the work. Trimmed down MUD because of that.
Vulnerability for example. Manufacturers are not good at self-describing.
Rather just give URI and we'll take it from there. Nobody wants to boil the
ocean.

Thorsten: which IETF groups would be best groups to go to? Definitely want to
use the protocols that are available.

Ari: IoT directorate can help with this coordination

Carsten (remotely): RATS -- that's your PAVA

Thorsten: but not complete PAVA.

Eliot has read the draft, but not others.

Ari: Would be good to get reviews and opinions if this is something RG should
be working on. Will have a call with IoT directorate to coordinate where many
IoT security work would fit. Let's take this also there.

Thorsten: maybe make sense to split PASC and PAVA to separate docs. And could
have another with more research aspects.

Carsten (remotely): RATS might take on PAVA once there is a good RG prototype.

# Mohit Sethi: Enabling Network Access for IoT devices from the Cloud

Slides:
https://github.com/t2trg/2018-11-bangkok/blob/master/slides/t2trg-nw-access.pdf

Presented at the last T2TRG; ended up later as article at The Register. Lots of
people seemed to be positive on this approach.

If device vendor goes out of business, new peering arrangements can be done to
still make things work. But requires transfer of credentials before
manufacturer goes out of business. To avoid hijacking, draft now proposes
mutual authentication with EAP methods.

Could still end up connecting to wrong APs, but with RADIUS have more fine
grained control for this. Have implementation of this to see which AP is used.

Also few deployment modes, for example for blank devices.

Erik: this week Eliot Lear pulled together IoT onboarding side meeting. This is
related.

# John Mattsson: CBOR certificates

https://github.com/t2trg/2018-11-bangkok/blob/master/slides/2018%20-%20IETF%20103%20T2TRG%20CBOR%20Certificates.pdf

X.509 not designed for IoT. Results in high memory and power consumption.
Earlier work with gateways compressing certificates. New protocols encrypt
certificates, so such intermediaries will not work in the future. How to
minimize overhead caused by certificates? Which aspects should we focus on?

Zach Shelby: remember back 7-9 years ago when we tried to introduce RPKs.
Thought it would be magical. What we found out was that the IT departments have
a say on what gets deployed. Anything that wasn't officially called certificate
would not fly. Got horrible push-back for RPKs. What we need to do to
understand to not repeat that? How do we make sure that this gets stamped as
being a "real certificate". Is more political than technical but that matters.

John: something we have thought about. Googling for different cert formats,
people have used different formats before. They don't fly because try to
replace x.509. Migration strategy and get trusted in the minds of people using
this is very important.

Padhu Subramani: good point from Zach. Not security expert but trying to
address Zach's concern. Validations can happen in-band while defining the
protocol.

Zach: don't think this is threat-validation problem. RPKs were fine with that.
It's perception. Maybe need NIST to put a stamp on it. What bodies would have
to get behind a new cert for IoT so that it is perceived to be trusted.

Padhu: agree.

Eliot: had long discussion with Zach. Setting up a best practice. Going to
stack up on Jim's desk. Anything below mid-range doing nothing on security
today. If we can develop here mechanisms, or IETF, and have clear model -- even
if not single way forward -- then we have ball game.

Carsten (remotely): Certificates were chosen by people who read that term in a
magazine.  The big web uses them, so they must be good.  And of course there
were marketing departments of big stakeholders that were too happy to agree.

Zach: like said, it's political

Eliot: we can work this. Let's have technical solution that works for
constrained IoT

Carsten (remotely): +1

John: CoRE coid draft has very similar problem statement but different
solution. Good questions. Don't need to be certificates for this. Would be nice
to see a presentation of this draft. What kind of architectures it can be used
and what kind of savings can be achieved.

John presented the draft basics. From strict profiling of X.509 with CBOR
encoding to more compact presentation.

Zach: what is the vision on how different X.509 strict profiling is to CBOR
compressed vs. CBOR native. How different would they be? Could you process with
same tooling? Convert between them?

John: only difference is that in one case signature covers x.509 structure. In
native it covers the CBOR structure.

Zach: but in practice same function? Could be very important way for showing
that it's doing the same thing. If issue native CBOR certs it's still the same
functionality. Could be advantageous.

Jim: if look at the doc from Henk, Carsten, and Bob. They dragged me in a
session in Singapore. Haven't read the doc, but during the process went through
x.509 cert to see what we needed and what not. I assume the other draft is
result of those discussions. If can do same type of processing as x.509 but
different tool chain.

Eliot: the 450 number (from slide) for x.509 matches my own experience

John: at slide 6 can see byte sizes of different ways. Just CBOR is quite small
for being a certificate. Can get better compression than with generic
compression algo.

Slide 20 shows results from implementations. Energy consumption lower.
Processing increases.

Peter: question, 1 hop 50 and 2 hops not double the energy consumption?

John: don't have the details on this

Ari: in the room some nodding that this seems to make sense in general and some
head-shaking

# Syed Muhammad Sajjad: An Architecture for Collaborative Security and
Proactive Defense against IoT Botnets

Ari: next steps good to share the draft on the mailing list and see if there is
interest in the group to work on the research topics of this

Syed: Is this the right group or should this be OPS area?

Eliot: makes sense to develop further here and then move to OPS.

# Other things

Eliot: have coordination thing ongoing for IoT onboarding. Looking to catalog
all mechanisms proposed, not only in WGs, but also across SDOs. There is a
github repo. If want to add mechanisms there, just add or drop me e-mail.

Carsten (remotely): Do you want to create a group for that, do it on the side,
or host it in T2TRG?

Eliot: Ari and I need to talk about where to host this. Suresh said we can have
a mailing list. If want to take to the IoT directorate or take to RG, open to
this. Directorate needs to coordinate with SAAG, Sec ADs etc.

Carsten (remotely): Having a mailing list is great.  But have that discussion
with Ari...

Eliot: have done

Ari: will take a break now, continue until 12:00 (one hour) with the COIN
breakout and then come back here for the final session together.

# Plenary (discussion, next steps)

# Consolidating results from the breakouts

Ari: reporting from security breakout: CBOR certificates was presented; much
smaller structures than before but can use some of the existing infrastructure.
But not only technical factors that matter, also political issues (e.g., are
these considered "secure" and "something familiar"). But we should work here on
a working technical solution. Eliot pointed out a need to also coordinate more
the work around the IoT security area. Ongoing IoT directorate activity on
this. Thorsten's and Oscar's draft to be taken as part of this activity. IoT
botnet protection was presented shortly and discussion will continue on the
list.

Erik: what will be output of the IoT coordination?

Ari: at least web site with relevant work, etc.

Hannes: challenging considering what we think is relevant for IoT

Carsten: each of us has idea what should be on the web site. When we run
consensus process it gets difficult. At RoHC had a personal view draft what I
considered relevant. These documents turned out to be extremely useful. Doing
roadmap work is good. But impossible to do with consensus process. But personal
views are very useful. What we could try to do is find a few people who like
doing roadmaps and build something that used to be called "web ring". And start
referring to each other. That would provide us curated but not necessarily
consensus based approach. Hannes also has interesting views so that would be
interesting doc too.

Erik: have been standing at IAB and IESG meetings about onboarding and trust
models. Not the same thing. What is the relationship between players. Have
volunteered to write something on this space.

Carsten: have had about 10 different approaches from Cullen's mother ship
approach. Behcet et al also had a draft. Eliot's thing.  Getting bit of
taxonomy is good. Something RG could operate on. Maybe less on the details of
the mechanisms but more on what is the architecture.

Carsten: also have terminology issue with hypermedia. With forms people
sometimes think we want to do GUIs for temperature sensors. Useful to have
another taxonomy effort in that area. Like term gateway today. Not maybe the
most interesting research area but very good way to get started in the field.
Will get citations and will be considered as expert in the area. Taxonomy
papers good in that area.

Carsten: one observation, RATS activity. Not very succesful BoF but doesn't
mean the work won't happen. Thorsten had protocol for continuously checking
health of device. RATS does that for remote attestation. Something to bring
together in this work.

Zach: what was the other attestation use case? RATS all about device
attestation. Particular set of claims.

Carsten: tons of other use cases. Whole industry looking into ways of attesting
health of system components. If want to know if remote board in my system is
healthy, it could be considered device but really a piece of system. Isolated
component.

Zach: in RATS BoF data attestation was mentioned. They had difficulties on
defining claims around data. Only one could come up with was time stamps.
Warning bells on this to me was that making anything useful you don't need even
a protocol but a token is enough. Keeping that group in device attestation
makes sense. Lots of concrete use cases there. Don't think the BoF went badly.
RATS architecture is a train-wreck. Want to boil the ocean. But something that
could come up from the work. Should we try to piggy-back on that to do software
attestation? No idea. Not sure how useful for generic SW components.

Erik: side meeting last time had a bit more discussion on concrete use cases.
Walking through them is useful. More software focused, e.g., banking app. Could
more care about "this thing that is doing this, invoking RESTful API, is the
app I distributed, not someone else's".

Carsten: many mechanisms are modulated by the risk. Risk in a banking app is
limited. Money will flow but will be sucked up by the bank. Like credit card
can be misused but we know how to manage that risk. Other places have more
serious things.

Erik: bank may not think that way

Carsten: Banks understand risk management. Could be completely fine for a bank
to know that "this is Samsung phone and two entities are ready to vouch for it"
and would be sufficient. But not enough for many other cases. Idea of RATS is
you can make use of more elaborate protocols to make sure of the state of the
system.

Erik: some more meat on this needed.

Carsten: lots of drafts on this. In this BoF the interesting stuff was not
presented. People think the simple 3-legged architecture is all there is. This
was difficult BoF since BoF should explain to non-experts what is this about.
That didn't happen.

Zach: could suggest; the 3-legged architecture is a black hole. Maybe some of
that belongs here rather than IETF group.

Hannes: lots of stuff outside of IETF.

Zach: could define lots of architectural work to teach people. And then there
are some practical tools we can use today. Interesting thing to talk to ADs on
RATS and figure out what to do.

Carsten: interesting work here done by suppliers of network components.

Zach: Cisco presentation was great. They have done a simple thing and have good
experience. But not sure they depend on the big picture?

Carsten: they do. Whole RATS protocol can be expressed in tokens. Hard part is
to understand the flow between different stakeholders to do useful
determination. Idea can't be to have architecture to compose all those flows.
But to have a kit to enable specific flows.

Zach: not sure how much of that needs to be standardized. Siemens for example
have lots of their own products and can do it their own way. TBD how much needs
to be standardized. Some architecture maybe to explain things better. Maybe
this group is better for that.

Hannes: TCG terminology does not help here either

Erik: this RG could be place to discuss other parts of architecture. If
RATS/EAT done in IETF it would start in very narrow scope. What does it mean to
manufacture things? Nothing that needs to be standardized. Cisco has been doing
that for decades. Not sure if people are willing to talk about this, lots of
proprietary. Writing down things would help advance state of the art.

Hannes: Henk likes attestation case from TCG. If we want something easy to
explain conceptually. FIDO attestation probably easier to start with, low
hanging fruit.

Carsten: particular kind of fruit. If focus on endorser only scenario, will be
losing the manufacturers, like Cisco, who need something more powerful.

Hannes: good to start with something simple

Carsten: Cisco had a demo that was not allowed to be shown by BoF chairs

Erik: small part of overall system. Useful for Cisco customers to know if
someone changed a config. But different to know if someone changed something in
software or hardware. When something went wrong in the system.

Zach: we deal with some of the manufacturing bits. More than happy to look at
the aggregate, this is manufacturing piece that will be deployed, and want to
assess correctness / health of that. In attestation token formats could be
interesting on "onionability". Maybe a research topic. For mCU from a fab need
to know if is ST or a Chinese knock-out. If want to attest that is a piece of
hardware you expect. Could have another layer of attestation after chip parts
that verifies as a whole? Could keep on adding layers of attestation. Could
become part of manufacturing a product. Something interesting there.

Carsten: that's why I like "system component" term. Need to put these things
together. Overall security depends on the components.

Zach: important research work

Carsten: have Concise Software IDs (coswid). Some of this work is already
happening. Actually an ISO standard that we're trying to fix and make usable in
constrained space. Maybe should look at the whole attestation space in more
detailed way than was possible here. PAVA is interesting here -- that's the
holy grail -- can look at the system and with each piece can monitor the
health. Useful, but not sufficient, to use the manufacturer.

# Edge / COIN recap

Erik: some of this meeting felt like "active networking" years ago. We have now
more programmable things than we used to have. Can get higher efficiency.
Example "p4 language". Some things aligning on NFVs. Full servers out there,
VMs / containers. Need to find and use them. Personal perspective: how generic
is this -- if something Turing-complete and people want to deploy computers
next to forwarding elements. If it's capable for running NFV firewall it is
capable for running analytics? Maybe not having GPU but have flexibilities.
Interesting to do something in this space but not sure of specifics.

Carsten: Dave Oran asked: Where are the big-win applications? One interesting
observation: data center space so different from the rest of the space that
they probably have their own problems, use cases, etc. They do stuff at 100s
GBps that we might not do.

Erik: group is considering covering data center, telco path, and on-premises
path as well. One question was are there commonalities.

Carsten: also interesting question; what is really networking here? Putting
servers up somewhere not that interesting. What is really the deep integration
with network can give here.

Erik: people today build overlay networks but not coupling where is the compute
done etc. How to schedule things across the whole thing.

Carsten: the new COIN group is aware that there is overlap with other groups,
T2TRG, DINRG, ICNRG. Brings opportunities for doing things together. Core
subjects of edge computing could move to this group, but there are still IoT
aspects that could be interesting for this group.

Hannes: anyone looking at computer architecture side of things? To accelerate
some things?

Carsten: starts from if you want to do really high speed things, need to do
switch programming. p4 programming language etc. People thinking how you can
decompose programming.

Hannes: anyone in the meeting working on this?

Erik: some in the room were talking about these things. Not changing hardware.
But in industry players asking for p4 support for products that don't have it.
But in this space one needs to know a lot what can you achieve. Today done by
people building switches. Companies asking to take current switches with
low-power chips that run routing only. But replace with more powered CPU and
then can do more things in software. Companies that have built this kind of
things.

Carsten: had quick glance at architectural things. Mostly coming from new
programming models. For really fast things need something like functional
languages. When you know you have more functional components, you'll start
changing the architecture accordingly. Hard to make predictable from time point
of view. Hard to model how such system will behave. But can be solved. Data
flow programming have come out of fashion some years ago, but coming back now.

Niklas: on switching bit, someone else providing things on top. If doing
gigabit links, can be much faster than putting things in cloud. Was talking
with a guy doing FPGA who were doing high-speed trading next to a switch. Not
only constrained cases.

Carsten: can also use more conventional architectures. For example if only do
100 Mbit/s. Can do generic architectures up to some tens of Gbit/s. At the edge
may not actually need all the p4-stuff. But functional composition still useful.

Carsten: is there something we want for edge?

Erik: we need to keep our eye on COIN; will be making a mailing list.

# Consolidating results from the hypermedia discussions

Carsten: CoRE WG has expressed interest in the CoRAL format. Formal adoption
TBD. As RG mostly understands CoRAL expect perhaps for the form relations. We
have a draft but need to show that it actually works. So some research is
needed.

Matthias Kovatsch: topic of links and forms goes back a while. Had a paper on
this at IAB IoTSI workshop. Klaus and I wrote. Have quite some consensus at the
T2TRG that we have links and forms that are needed. Not just browsing. Also a
concept that is used in W3C WoT. Have form elements that describe how to form
requests. Was the first time when we reached out of the RG. Not many comments
at that time. Now when pushed to other communities, got some pushback. "Forms
huh? HTML elements? How does this fit in?". JSON Schema / OpenAPI community use
forms differently. But when you discuss all actually agree "form" is the right
term when you do this kind of things. Issue that we have at WoT is that we need
to ship our spec soon. So we are settling with this terminology. One thing that
diverging from, on what was discussed at RG, got pushback for the relation
types. As we use it in WoT, links are used to express relations between
resources. But for forms it's more that we express operations, using term "op".
In synch with OpenAPI and JSON schema. But not many people working on this
actively. Somewhat controversial but need to submit something on recommendation
track for WoT. What are opinions in this group for this?

Jim: Not sure how CoRAL and current link formats can be round-tripped. Easier
to understand if you look at /.well-known/core. Good to have clarifications.

Matthias: experience that lot of on-the-fly implementations on this. Not many
implementations on the URI bits that do advanced things. Need also
representation of links in JSON. Was hoping to use link format in JSON. But
some issues that hit was roundtrippability. Space separated words is a problem.
Advantage of JSON is that you can express arrays. But breaks round-trip feature.

Christian Amsuess (remotely): I think it'll be good to have link-format to
CoRAL (and RDF), we just need to decide on the URI labels to use. The
space-separated things just need to stop and be a known list of odd attributes.
Round-trip-ability is not too critical IMO.

Carsten: problem with link format; RFC format does not allow arrays. Then have
ad-hoc stuff. We can nail down what of these have the space separation and be
done with it. Underlying question: do we have to keep the link format JSON
draft alive?

Matthias: we (WoT) can't reference it now anyway. Have something of our own.
How do I use it stand-alone? How many people would use it alone? Common
serialization useful. Don't now if useful to skip that step and go straight to
CoRAL. Or publish now something that is useful to others.

Hannes: is this for IoT devices or back-end?

Carsten: CoRAL designed for very constrained devices. Question is if the format
can be transformed from one to another and back.

Jim: have implementation of link format. If you write something in CoRAL I need
to understand how to send back in link-format and vice versa. Don't expect to
get back exact same stuff. Some things may disappear. But needs to look like
it's representing the same thing.

Carsten: seems like a useful RG work to generate JSON for link format and back.

Matthias: started something in CoRE. Would that be de-facto standard?

Carsten: don't see anyone adopting links-json. But many doing something very
related. OCF has its own JSON variant of link format. Want to maintain cultural
compatibility on this, except for the stupid things. Maybe a document that is
outspoken of the limitations is useful to have.

Matthias: could even broaden a bit and have JSON-LD. Helps to give general
understanding how to apply. And goes way beyond links.

Carsten: who interested to work on such document?

Matthias: can give input

Christian (remotely): I could describe an experimental CoRAL profile, which
describes (almost) round-tripping link-format -- and possibly similar for OCF
and others.

Carsten: wow!

Jim: sounds wonderful

Carsten: seems we have some work to do.

# Closing remarks

Ari: Next T2TRG activities: WISHI calls, IoT directorate coordination on
security, OCF/OMA synch calls coming. Which day works? Thursday got support.