1. DetNet WG IETF #97, Seoul Use Cases Draft Ethan Grossman, editor
Tuesday, November 15th, 2016
Ethan Grossman, editor
Use Case Authors
Pascal Thubert (Cisco) Wireless for Industrial
Craig Gunther (Harman) Professional Audio
Ethan Grossman (Dolby)
Patrick Wetterwald (Cisco) Electrical Utilities
Jean Raymond (Hydro Quebec)
Jouni Korhonen (Broadcom) Cellular Radio Access Networks
Bala’sz Varga (Ericsson) Industrial Machine-to-Machine (M2M)
Janos Farkas (Erickson)
Juergen Schmitt (Siemens)
Franz-Josef Goetz (Siemens)
Subir Das (Applied Comm Sci) Building Automation Systems
Yu Kaneko (Toshiba)
Yiyong Zha (Huawei) Internet-Based Apps
Xavier Vilajosana (Worldsensing) Utilities - Wind Farm
Toktam Mahmoodi (King’s College London)
Spiros Spirou (Intracom Telecom)
Petra Vizarreta (Tech Univ Munich)

2. Contents Updated Use Case draft Recent discussion topics
draft-ietf-detnet-use-cases-11
Goals
Status
Future
Common themes
Recent discussion topics
DetNet security – starting the discussion

3. Use Case Draft Goals Provide Industry context for DetNet goals
What are the use cases?
How are they addressed today?
What do we want to do differently in the future?
What do we want the IETF to deliver?
Highlight commonalities between use cases
Yardstick for functionality of any proposed design
To what extent does it enable these use cases?
This DetNet use case draft explicitly does not
State specific requirements for DetNet
Suggest specific design, architecture, or protocols

4. Use Case Draft Status Added “Wind Farm” example to Utilities
Recent discussion topics
Latency matching
Time accuracy
Reliability (availability)
Migration path – legacy to DetNet
DetNet security
Topics from a first-pass analysis

5. Use Case Draft Future Plans
Continue to review the ongoing architecture and design drafts to identify cases in which they may not support user needs (as described in the Use Cases draft)
Adapt and clarify the Use Cases draft to be in alignment with practical considerations of the proposed architecture and design
Subject to agreement from the WG

6. DetNet Use Cases Presented at IETF93, 94, and 95 Common themes
Professional audio
Electrical utilities (now with wind power!)
Building automation systems
Wireless for industrial applications
Radio/mobile access networks
Industrial Machine-to-Machine (M2M)
Common themes
Presented at IETF 95, 96

7. Common Themes (1/2) Unified, standards-based network
Extensions to Ethernet (not a ”new” network)
Centrally administered (some distributed, plug-and-play)
Standardized data flow information models
Integrate L2 (bridged) and L3 (routed)
Guaranteed end-to-end delivery
Replace multiple proprietary determinstic networks
Mix of deterministic and best-effort traffic
Unused deterministic BW available to best-effort traffic
Lower cost, multi-vendor solutions

8. Common Themes (2/2) Scalable size
Long distances (many km)
Many hops (radio repeaters, microwave links, fiber links...)
Scalable timing parameters and accuracy
Bounded latency, guaranteed worst case maximum, minimum
Low latency (low enough for e.g. control loops, may be < 1ms)
Ability to create symmetrical path delays
High availability (up to % up time, even 12 nines)
Reliability, redundancy (lives at stake)
Security
From failures, attackers, misbehaving devices
Sensitive to both packet content and arrival time
Deterministic flows
Isolated from each other
Immune from best-effort traffic congestion

9. Recent Topics App wants latency matching between paths
Open – maybe network will support min/max latency, or maybe app will query, then buffer accordingly
App wants to know accuracy of timekeeping
Consensus: Query existing time protocols
App wants to know availability/reliability (9’s)
Open – per flow basis, options presented by network?
Migration path from present day to DetNet
Relevant IEEE work
802.1Qcc (enhances TSN API for e.g. MaxLatency)
Link-local Registration Protocol (facilitate creation of app protocols to distribute information through a network)
Should DetNet formulate a migration strategy?

10. DetNet Security Topics
Based on recommendations from
Professor Andrew J Hacker,
Cybersecurity Expert in Residence,
Harrisburg University of Science and Technology and
CEO, MistIQ Technologies, Inc.

11. Goals of this Presentation
DetNet strategy so far is “don’t break security”
Next steps
Now: enumerate DetNet technologies that have potential security implications
Eventually: identify those DetNet technologies for which we must either
Create a security related protocol that doesn’t already exist, or
Modify an existing protocol for use with DetNet

12. Overall Recommendations
Consider DetNet security using “CIA” principle
Confidentiality
Path choices, predictability/unpredictability, encryption, privacy/masking
Integrity
Ingress device and message authorization and access control, device code validation, required code reviews, buffer/field/queue integrity validations, parameter/config validations, vulnerability management
Availability
Availability versus attack surface, denial of service, manipulation of time sensitivity
This preso uses this organization, by DetNet function

13. Documentation Recommendations
Consolidate security discussions into a DetNet Cybersecurity doc
Ethan has done a first cut at this – should it be submitted as a DetNet draft?
If so, then should security discussions in existing drafts be replaced with a reference to the new security draft?
Define DetNet-specific security components
Refer to specific existing standards where possible
Create spec for those we must create
Determine which use cases require which security components

14. DetNet Functions with Security Implications (1/3)
Packet replication & elimination
Effect on existing security protocols?
HTTPS?
Ipsec tunneling?
Encrypted packets/payloads?
How does the predictability/unpredictability of the results of the algorithms used for reliability affect the overall security of the system?
IEEE 802.1cb, Frame Replication and Elimination
Effect on attacker’s ability to inject and validate malicious packets?
Effects of trade-off between increased availability and attack surface?

15. DetNet Functions with Security Implications (2/3)
Path choice(s) and information about path choice(s)
Effect of increased attack surface?
Can an attacker predetermine a path or flow?
Possibility/effect of attacker changing, influencing, adding a path or flow?
Logical segmentation between DetNet/non-DetNet paths and flows
Requirements?
Network slicing?
Query/response/process execution considerations/differences
Information Technology vs
Operational Technology

16. DetNet Functions with Security Implications (3/3)
Packet fields which require encryption/obfuscation
Examples
Path routes
Timing fields
Duplicate packet flags
Packet content (e.g. control messages)
Device authorization and access to DetNet domain
At ingress, egress, along path
Part of DetNet or higher level application?
Message authorization
(If vulnerabilities in DetNet affect a message, then it is passed up to a higher level application, that may affect its ability to assess the message)

17. Runtime Monitoring Runtime mechanisms to
Detect and disconnect misbehaving components and/or devices
Monitor OAM integrity and DetNet security framework integrity
Monitor performance - provide alerts and corrective action at appropriate points
Validate sensitive/critical parameter configurations
Validate (and prevent manipulation of) time-sensitive algorithms/values
Use backup algorithms for this?
Log operations (which operations require logging?)
Validate active DetNet devices’ executable code?
Embed portions of DetNet security intelligence directly into data
Packets can contain dynamic data in addition to content calculated by network infrastructure
Refer to the author’s research and IP on this topic, for example a cybersecurity framework that places functionality and intelligence directly within data packets to provide dynamic and contextual correlation of information to improve control and precision over packet security, privacy and network flow

18. Considerations for DOS attacks
Validation, priority mechanisms must account for
Global device overruns making DetNet goals unobtainable
Attacker pre-provisioning DDOS conditions
Service lost due to malicious timing changes

19. Implementation/Development Process
Certification/validation of DetNet components
HW components
SW components
Devices
Reviews of DetNet SW, HW designs
Buffers
Important fields
Duplication/deduplication/path and packet management
OAM management algorithms
How much of this is in DetNet scope?
None?
Work with AVnu?

20. Additional Security Topics (1/2)
How much time required to set up and/or validate security relationships at power up, or to check them after power up?
What effect do various encryption/validation choices have on latency and latency variation?
Given that on-time delivery can be just as important to the proper functioning of some applications as correct data, and that encrypting data does not prevent attacks based on manipulating the delivery time, what are the advantages/disadvantages of end-to-end vs hop-by-hop trust relationships?

21. Additional Security Topics (2/2)
What is the impact of security appliances (or other ‘middlebox’ on a DetNet path) on the DeNet service. For example many firewalls are bad at handling high throughput flows. (Are such devices even allowed in a DetNet?)

22. Known Related Security Work
NTP/TICTOC working on time security
IEEE 1588 group defining security (in terms of profiles/prongs) for the 1588 protocol