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.