Note takers: Matthias Kovatsch, Chairs
Jabber: Allison Mankin
Slides: https://www.ietf.org/proceedings/99/slides/slides-99-t2trg-chair-slides-00.pdf
Carsten gave intro to the T2TRG. Planned future meetings:
Co-existence one topic in Berlin. Will different network technologies be friendly to each other when there are 50B things. How to avoid one network to be catastrophic to another network.
Follow-on to IoTSI WS. Got together experts and organizations on semantics hypermedia. Variety of organizations: IPSO, OMA LWM2M, iot.schema.org, W3C WoT, OCF, oneM2M, Fairhair, Haystack. See https://github.com/t2trg/2017-07-wishi/
Increment on IAB IoTSI Workshop. Theme of the meeting: how to get closer to have collaboration going. Every organization covers a different aspect; need to get a better understanding what they do. First snapshot in the wiki, will be developed further there. https://github.com/t2trg/2017-07-wishi/wiki/Organizations-roles
Want to collect references to different tools. Want to collect information on approaches that DID NOT work well (which is often not done in academia) Want to figure out license terms and improve their understandability. Facilitate collaboration between organizations.
Applications often interested in their own composition of information resources. Want to improve (e.g., protocols to compose). Metadata often neglected. Want to find better way to declare and deliver.
How to get there:
Interoperability layers: semantic, structural, syntactic. Also recursive in the layers. Also data for security purposes: 6 topics initially listed by Dave Thaler (slide 15).
Secret handshakes: current issue for IoT, related work exists (e.g., SOSP 2003 paper)
(Later, a question was asked on jabber: From wooster@xmpp.jp: Are any of the “secret handshake” auth mech proposals related to the Socialist Millionaire’s Protocol / El Gamal? I thought that was a pretty well-established way to do that sort of secret handshake thing, as used in OTR. Ari: we didn’t go into that much detail during the WS and don’t have answer now. But we can take this off-line. Thanks for the question.)
More online (https://github.com/t2trg/2017-07-wishi/)
Continuation from the Chicago session on the topic. Around 10 in the audience were part of that session. Collection of valid questions, no full answers yet.
Terminology discussed (cf. Fog Computing etc.). Research questions: programming models, networking (how do we communicate/get to the data) and operations, multi-tenancy/isolation, (automatic) scaling. Activities: ETSI Edge Computing, AWS GreenGrass, etc.
In the meantime:
Opportunity to re-think IoT edge computing. Removing cloud dependencies. Could be detailed in a draft.
Carsten: show of hands; who has heard about edge computing? (half of the room, around 100 people) - Who thinks IETF could benefit doing this? (half of the room) - Who would like to contribute? ~20 - Who would like to help with work? 6-7 hands
Delegating access to third party looks simple on slides but has challenges. Implementation limitations with RADIUS. How to limit power of delegates, isolation, interoperability, etc.
Tuomas Aura presented EAP-NOOB as potential solution to this. Out of band authentication for EAP. No pre-existing credentials needed. User assisted authentication.
ECDH in-band exchange and OOB message with secret + hash. Authentication and key confirmation in-band.
EAP-NOOB lessons learned: names and identifiers often not available. Want to avoid re-run of user assisted step at all cost (expensive, doesn’t scale). Human users brings challenges to timers. Algorithm agility hard without master keys.
Next challenges: Third-party AAA server authorizing.
Carsten: sounds familiar; cf. eduroam work from 15 years ago. Interactions with authentication servers without network access. Looking at IP based ways. Came up with form of isolation discussed here. Achieved it at the time by identifying part of the IPv4 address space. Was crude solution, but maybe basic idea of using isolation a lot more and still using IP is useful.
Tuomas: started from there, but how to communicate with back-end. EAP is standard for this, for tunneling. Would be good to have limited network access for such purposes.
Carsten: one of the older solutions was designed by dedicating IP address space to this
Tuomas: communication going through AP, used open AP code to send all data to our router. With current HW can’t have IP layer control.
Carsten: maybe have to think more of isolation features for our networks.
Andrew Sullivan: Rest of the internet also threatened with these devices. Same isolation discussion could also be used to address that problem.
Tuomas: did little bit of that. Had version that FW/router tunneled/isolated VPN tunnel and went back to the cloud server. Sometimes right solution.
Andrew: vendors like to have their GW
Tuomas: once associated to network, want to hand over control to cloud and not keep with AAA server
Andrew: something very fetching(?) in this solution and like it.
Erik Nordmark: If would do this for your house, would have privacy concerns. Would be nice if this was minor problem. Have considered redirecting this and not being only with the big players with data?
Tuomas: now writing our own server and would like to big player to provide server side. But provide service to anybody.
Erik: currently need your own router?
Tuomas: depends on applications.
Michael Richardson: Look forward to reading the draft. The ANIMA/NETFONF/6tisch have to deal a lot with this problem. Number of solutions approaching WGLC. Based on authorizing that “you are the owner of device”. Lots of other work happening here. Interested to see the relationship with this. On limiting access, also happening in ANIMA. Also MUD, spec for manufacturer to say to your FW: expect this device to do this. If doing something else that’s problem. Based on URL shown, could see that device is printer and act accordingly. Would like to interact and work on this together.
Carsten: there is the document “security considerations” that is nearly done and would be good to have few more people look at that. Other docs with security considerations could refer to this doc and not need repeating. Would be good to have useful doc on that. And get reviews. Can save writing for you. Michael R, Dave T, and few others volunteered (please send your names to chairs).