Minutes IETF113: iotops
minutes-113-iotops-00

# 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.