Joined late due to DST change
|Security in Streaming|
Chris shared event type information (https://wiki.opennetworking.org/download/attachments/266141701/ONF%20Event%20Types.xlsx?api=v2).
Rate limiting is potentially beneficial
Different policies for different data
Some streams may be continuous others may sporadic
Small devices v large device
Chris will contribute.
Stream needs to be targeted. There needs to be a registration process. If anything changes in terms of rights etc. causes a reevaluation
Stream could overwhelm the receiver/transmitter. Some way of dealing with high rate of flow. Prioritization, second order messaging... this relates to security due to business continuity.
Need some known recovery strategy.
Back pressure mechanism. Buffering challenge. Malicious ignoring back pressure.
Strategies can include compaction.
Use of Kafka direct answers many of the issues.
MQTT to the devices has challenges. Security covered in https://www.hivemq.com/mqtt-security-fundamentals/.
Securing a bus is potentially challenging and not well addressed by the security world. Management of shared key.
Transmitter needs to deal with the worst receiver.
Need a side management channel separate from the UDP messaging. This helps provide the shared key. TLS mixes the key and stream content.
Identities and authorization are point to point. Once this is done, multiple recipients may use the same key. Need an encryption algorithm that is not stateful.
Need to look at the architecture. May expect all receivers to have similar performance if there are many receives.
Different resolutions of stream for different receiver performance.
Need to look at characteristic and strategies for different characteristics
Auditing assessing for threat etc... unexpected changes in characteristics.
Audit against expectation of the stream.
|Future call topics|