This document discusses selecting a Time-Sensitive Networking (TSN)-based architecture that preserves determinism for safety-critical applications in the presence of Fake Data Injection (FDI) attacks. It proposes using a Network Controller (NC) to provide optimal switch configuration and minimize network costs while maximizing quality of service. The document evaluates different TSN architectures through simulation and finds that using IEEE 802.1Qci for ingress filtering provides the best schedulability of safety-critical traffic, regardless of FDI load. Future work is needed to study combined ingress-egress configurations and other security mechanisms with IEEE 802.1Qci.
83778-77756 ( HER.SELF ) Brings Call Girls In Laxmi Nagar
Selection of FDI-Tolerant Time-Sensitive Networking (TSN)-Based Architecture
1. Selection of FDI-Tolerant Time-Sensitive
Networking (TSN)-Based Architecture
for Preserving Determinism of Safety-Critical
Applications
Voica Gavriluţ1 2
Christian Madsen1
Michael Berger1
1: Technical University of Denmark (DTU)
DTU Electro
2: Comcores Aps
Kongens Lyngby, Denmark
2. Motivation (1/2)
Networked systems are more complex
▶ Chip-augmented and networked objects are more pervasive
Being used even in safety-critical areas
Such as Intelligent Transportation Systems (ITSes), urban
infrastructures, medical devices and industrial automation
▶ Ethernet not enough anymore ⇒
Area-specific Safety-critical protocols as CAN, AFDX or EtherCAT
⇒
Replaced by general purpose Time-Sensitive Networking (TSN)
▶ TSN addresses multiple requirements through different features ⇒
Selected features = TSN architecture
2 / 15
3. Motivation (2/2)
Preventing spread of fake news
▶ Networked systems increasingly dynamic
E.g. V2X (Vehicle to Everything) of ITSes
V2X = V2V + V2I + V2P
▶ high and rapid dynamicity exposes to aggresive cyber-attacks
Such as denial of service, Fake-Data Injection (FDI) and replay
attacks
▶ Keypoint: Need to protect safety-critical networked systems
Our work focuses on FDI attacks
3 / 15
4. TSN Features
TSN: a toolkit for addressing timeliness, reliability and
fault-tolerance
Requirement Standard/Amendment
Reliability
· · ·
Also centralized
Path reservation
IEEE 802.1Qcc
Clock synchronization IEEE 802.1AS
Fault-Tolerance
Failing applications IEEE 802.1Qci
· · ·
Timeliness
Asynchronous IEEE 802.1Qav
Synchronous IEEE 802.1Qbv
· · ·
4 / 15
6. Model — Application
Table: Example of distributed application (incl. SC). The example contains 16
messages: 5 TS, 7 BS and 4 BG messages.
Id TS BS Src Dest P T
1 Yes No Info ADAS 60 B 10 ms
2 Yes No Body Chassis 4 B 10 ms
3 Yes No Chassis ADAS 230 B 10 ms
4 Yes No ADAS Chassis 625 B 10 ms
5 Yes No ADAS Chassis 625 B 10 ms
6 No Yes Info Body 2 B 125 µs
7 No Yes Info Body 2 B 125 µs
8 No Yes ADAS Body 2 B 125 µs
9 No Yes ADAS Body 2 B 125 µs
10 No Yes ADAS Info 1250 B 125 µs
11 No Yes ADAS Info 1250 B 125 µs
12 No Yes ADAS Body 1250 B 125 µs
13 No No Info Body [64, 1500] B 30 µs
14 No No Body Chassis [64, 1500] B 30 µs
15 No No Chassis ADAS [64, 1500] B 30 µs
16 No No ADAS Body [64, 1500] B 30 µs
Note: The TS and BS messages have the default deadline!
6 / 15
7. Problem Formulation
2 Goals
Given:
▶ The network and
▶ The set of safety-critical and non-critical messages with their
properties and requirements for safety-critical traffic
Additional Given:
▶ Set of TS-FDI loads
(20%, 40%, 60% and 80%)
Determine:
▶ The FDI load that deteriorates
the deadline the most
Additional Given:
▶ The FDI load
▶ Set of available TSN features
Determine:
▶ The TSN architecture
▶ Network-wide configuration
Such that:
▶ The performance of legitimate
traffic is preserved
7 / 15
8. Solution — Network Controller (NC)
What is NC?
Network Controller (NC) = automatized
Network monitoring and/or coordination and/or management
Why NC?
Minimizes network cost while maximizes QoS
How to use NC?
Holds holistic network state and decides best node configuration
Provides optimal switch configuration
Contains software application
8 / 15
9. Solution — NC (Cont.)
How to use NC?
Each switch must:
▶ Listen to the NC
▶ Configure accordingly
▶ In this context, implement IEEE 802.1Qav, IEEE 802.1Qbv and IEEE
802.1Qci
Software application provides solutions for:
▶ Routing problem
▶ *Scheduling problem and
▶ *Bandwidth allocation problem
Note: Marked problems are addressed for ingress filtering and egress
shaping!
9 / 15
10. Solution — Simulation
Network performance
evaluated in simulation
▶ OMNeT++ is very suitable
for modeling wired or wireless
communication
▶ CoRE4INET is a framework of
OMNeT++ that implements
TSN features that we analyse
▶ We extended module of IEEE
802.1Qci
By implementing the Token
Bucket Meter (TBM)
To fully satisfy the
specification
TL>PS
Incoming
Packets
No
Yes
TAR
Maximum
Burst Size
TL
Drop Packet
Update TL
Send Packet
Figure: Representation of TBM, where
TAR is the Token Accumulation Rate
and TL is the Token Level.
10 / 15
11. Evaluation (1/2)
(a) MAE2ED results for non-controll
network architecture
(b) MAE2ED results for egress
configured network
Figure: Results for network architectures. The traffic patterns are on X axis and
MAE2ED (expressed in µs) on Y axis. MAE2ED of TS traffic type is with red
circle, of BS type with green triangle and of BG type with blue cross.
11 / 15
12. Evaluation (2/2)
(a) MAE2ED results for ingress
configured network
(b) MAE2ED results based on 95th
percentile for ingress configured network
Figure: Results for network architectures. The traffic patterns are on X axis and
MAE2ED (expressed in µs) on Y axis. MAE2ED of TS traffic type is with red
circle, of BS type with green triangle and of BG type with blue cross.
12 / 15
13. Discussion
▶ Quick check is schedulability of SC traffic;
A message is schedulable if it arrives at destination,
In the worst-case, before its deadline
▶ All TS messages are schedulable (for all architectures and traffic
patterns);
Large deadline of TS traffic (10 ms)
▶ BS schedulable most of the times;
For nonCtrl, 3 out of 7 BS messages are schedulable for about 3 out
of 5 traffic patterns
For egress configuration, BS not schedulable
For ingress configuration, BS fully schedulable
▶ No clear trend over different loads of FDI
13 / 15
14. Future Work
▶ Limitation: egress configuration does not contain IEEE 802.1Qbv;
In simulation, clocks of traffic generators and egress queues are not
synchronized ⇒
Non-deterministic queuing delays at sources
▶ IEEE 802.1Qci complemented by other security mechanisms;
Study co-existence of IEEE 802.1Qci and MACsec
▶ Include packet loss rate metric for checking network performance
▶ Study performance when egress configuration includes IEEE
802.1Qbv
With suitable simulation tool
▶ Consider full configuration;
Ingress + egress configurations
14 / 15
15. Closing Remarks
Summary
▶ Addressed the impact of FDI on SC legitimate traffic
▶ Analyzed multiple TSN architectures and configurations
▶ Solution (network-wide configuration): usage of NC
▶ Solution (network performance): an extension of OMNeT++
network simulator
▶ Results: so-far, usage of IEEE 802.1Qci gives the best schedulability
in presence of FDI
Disregarding FDI loads
Message
▶ Computation of configuration parameters for IEEE 802.1Qci is not a
trivial problem;
Too few allocated resources lead to Removal of legitimate traffic
Too many allocated resources lead to existence of FDI traffic
▶ We need tools to
(1) Synthesize ingress and egress configurations for TSN networks
and
(2) Implement and/or extend simulation models that adhear to the
specifications
15 / 15