# IoT Operations * Date: Thursday, March 24, 2021 * Time: 10:00-12:00 (UTC + 1) * Meetecho: https://meetings.conf.meetecho.com/ietf113/?group=iotops&short=&item=1 * Jabber: iotops@jabber.ietf.org * Notes: https://notes.ietf.org/notes-ietf-113-iotops ### Chairs * Alexey Melnikov alexey.melnikov@isode.com * Henk Birkholz henk.birkholz@sit.fraunhofer.de ### Scribe Michael Richardson Jorge Amodio ## MINUTES ## ABREVIATIONS cAM - Alexey Melnikov cHB - Henk Birkholz MR - Michael Richardson BM - Brendan Moran ### 10:00 Administrivia (5 min; chairs) cAM: Welcoming, Note well, Agenda Introduction ### 10:05 IoTSF ManuSecured SUIB: Browsing local web resources, in a secure usable manner: Examining IoT device configuration as a special case [URL here] (10+5 min; Michael Richardson) MR: Followup from previous IETF meeting. Problem statement, issues with devices like appliances not having names. Proposing some solutions for discussion. No solution is perfect, browser security warnings may discourage users, change browser behaviour trying to make it less scary. Try to Hack DNS, embed physical address, factory installed certificate with a wilcard, connects to a HTTP server that redirects to a HTTPS to do a secure query. There are some underlying issues but the solution is there. Use DNS to register new device via update. Still a certificate needs to be provisioned. Hack local "Smart" kind of app or skill that interacts with the device to do the onboarding and enroll the device in a private PKI. Problem is how do I propagate the information through the home network. Hack IETF standard, home gw runs the PKI, requires proper OnBoarding. These are described on the documents. Questions/Comments: BM: Concerns about malicious implants regarding Try to Hack DNS. Can we both prevent actions by malicious actors and don't leak information about device use to vendors? Toerless Eckert: Can we have a secure port at home (or something like this) which can be used to securely enroll devices? ### 10:20 Virtualization of PLC in Industrial Networks - Problem Statement https://datatracker.ietf.org/doc/draft-km-iotops-iiot-frwk/ (15+5 min; Kiran Makhijani) Kiran presents virtual PLCs and the various ways to slice the problem (placement/disaggregation). Disaggregation obviously requires security, as well as controlled latency. Also, there is a rendezvous problem. **Henk** mentioned the problems with interoperability regarding the "old" protocols and how to align them. It may be possible to introduce an abstraction layer to transform these *old* protocols into some more modern generic structure e.g., using CBOR or JSON. Carl-Heinz Genzel asks about the state of DETNET, since from his perspective relyable real-time communication is key to virtualized PLCs. Hannes: Would be good to drag along Siemens etc. They are not using off the shelf hardware. ARM has R-class processors for this, which have isolation (including memory isolation); virtual memory however introduces unpredictable latency. Kiran not proposing to use off the shelf hardware. ### 10:40 Future-Proof Zoning for OT Networks https://netsec.ethz.ch/publications/papers/devaere2021tableau.pdf (15+5 min; Piet De Vaere) https://datatracker.ietf.org/meeting/113/materials/slides-113-iotops-tableau-future-proof-zoning-for-ot-networks-00 MCR: Diagrams are all IPv4 :-( Eliot: (1) hidden: "heterogeneity" has to be carefully used, propose defining it (2) problem statement is spot on, but magic is in the policy, not in the enforcement. We have many ways of flattening networks. Maybe speak more about policy, merging, ... A Re 1: different security enforcement, different firewalls that are independent products; notion that attacker would have to find holes in all these firewall. A Re 2: ? Eliot: how do you program access, how do you decide what is an access violation? A: Not a final solution; access management is done on the level of zones, which zones can you transition to; enterprisey -- hard to get access to real-world data Toerless: What is Tableau doing, then? Need some technical content. Take this discussion to the list. ### 10:55 (~ 11:17) Low Latency, Reliable, and Secure Communication for Energy Grid Operations (10+5 min; Carl-Heiz Genzel, Markus Dahlmanns) https://datatracker.ietf.org/meeting/113/materials/slides-113-iotops-low-latency-reliable-secure-communication-for-energy-grid-operation-systems-00 Toerless: when you say "protection", what do you mean? Markus: At the energy level Carl-Heinz: Safety, not IT security -- shut off before stuff breaks Lifecycle of a protection system: Configure once run it until de-commission. Protections systems act local and report to a central grid control only. No new parameters are set remotely. In the future new parameters must be configured remotely not just reporting. Bidirectional communcation is necessary and thread model changes. MPTCP or QUIC for using all paths to get data reliably sent. Maybe SDN for dynamic network changes. For more Security Looking at TEEP, SUIT, RATS, ... Carl-Heinz: To which IETF WGs should we turn to, what do you think about the problems we could face? Toerless: Unsure about scope of project; a lot should be solved by work going on. Also look to Syncrophaser Grids, IETF Detnet and IEEE TSN. MCR: IETF is always looking for operator input. What would help us the most: use cases that you need to fulfill... Even though RATS arch is mostly done; your use case may fit. Dave Robin: Important is the real-time aspect of some of this. But how are you handling simultaneous actions that need to be executed on different systems when a network failure renders one system not reachable; a solution pre negotiated timed action e.g., "at 13:30 we all switch, please agree". But this simultaneous actions problem would be considered an application problem and maybe not IETF? (MCR: their ask is for guidance and feedback) cabo: You should split your case in use cases, subproblems, and see how IETF tech fits, report back to WGs and to T2TRG for a more global picture. ### 11:10 (11:35) TLS/DTLS 1.3 Profiles for the Internet of Things https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/ (10+5 min; Hannes Tschoffenig) Hannes: one major change is deprecation of CCM_8. Please comment. Bring your comments to UTA WG. Toerless: Haven't read the draft, but thank you for bringing it to the IOTOPS WG attention. In ANIMA we wanted to have TLS 1.2 support, so it is good to hear that people are working on TLS 1.3 now. Would want to start mandating TLS 1.3 or some specific profiles of that. ### 11:25 Initial Discussion about IoTOPS WG Deliverables (20 min; chairs) One potential document: #### draft-moran-iot-nets-00 Expired MCR: Could have used the same slides for IPv6 presentation None of these layers of firewalling were designed as firewalls, there were all NAT44 You can't talk about decentralized communication without being able to communicate. Eliot: I'm going to slightly disagree with both of you. initial draft showed how things are put together, which was good; now overthinking it. Brendan: The why led to a threat model, which pointed to a missing architecture. Table of the things that could go wrong, and how various techs fix them. Carl-Heinz: ISO 27001, IEC, BSI-Grundschutz, ... worst kind of work I ever had to do. Your document would be useful. Toerless: Closing remarks (rant): Harry Potter game, don't name the firewall; distributed firewall architecture, MUD stuff -> firewall, "security gateways" -> firewall, ... Can't do this as a side topic. "Firewalls in IoT"! Brendan: I have an answer for that: You are right; focus on firewalls for a portion of the problem; MUD... Alexey: Let's talk more about deliverables during the next IOTOPS meeting. Henk: And get a deliverable from this.