Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Open Information Model & Tooling

Space shortcuts

Expand all   Collapse all
Child pages
  • 2020-03-12 OIMT Meeting notes

Date

Attendees

Joined late due to DST change (sad)

Apologies

Agenda

  • Admin
    • Daylight Saving: Meeting time changes - reminder
    • ONF CLA (Contributor License Agreement)
    • Lifecycle state - update
    • Work item wiki page – any further comments
    • Location and Party - update
    • Decide on the date/topics of the April 13 week calls
  • Security in Streaming

Discussion items

Time

Item

Who

Notes


Administrative
  • Daylight Saving: Meeting times are set in US timezone
    • US changes this weekend, 8 March, so meeting will be one hour earlier than usual for others next week and onward (Europe changes 29 March)
  • CLA:
  • Lifecycle states update: Malcolm posted latest at  oimt2020.MB.001-draft-TR-512.3_v1.5.docx. Nigel will take this and make necessary model and document changes.
  • Work items - any further comments?
    • Considering an incremental form of LTP port addition to remove compatibility issue. This will complicate the model but if the model is explained via uncluttered diagrams this may be sufficient. LTP port could then be in the 1.x series with controlled deprecation. This is somewhat like what we did with FD port (although much more complicated (sad)).
      • May need to consider compatibility is a more subtle way
  • Location/Party update
    • Document mainly updated
  • Calls during week 13 April (3 days, 2 hours per day 6:00 - 8:00 EDT)
    • Topic candidates
      • Compatibility
      • Landscape of information flow (streaming) characteristic and strategies to deal with them. 

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

Limit sending

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.

Keys updated. 


Future call topics

Action items

  •