Need to add Operational and Security Considerations

[danielkinguk]

Additional requirements if/as needed.

[danielkinguk]

Additional Requirements:

• Manage TVR schedule peers. Do we implicitly trust neighbors for schedule updates, trust but verify?
• How to synchronise clocks, at least we need a Requirement that the (implementation) time is consistent throughout the network.
• Consider that the "clock" and mechanism(s) to provide the time to a TVR node, used to calculate the schedule could also be an attack vector and needs to highlighted as a Security risk.

[danielkinguk]

Question/comment from IETF 118:

AB: mentioned not specify sync mechanism. we depend on time sync especially on distributed yes we need ensure a devices clock is accurate to apply schedule. actual mechanism (NTP) is not something we didnt need to specify, maybe should list examples? AB: nice if we mention to specify mechanism for protocol cTL(chat): require nodes be time synced and mechanism out of scope

[danielkinguk]

Question from IETF 118:

LZ: In the intrinsic mode, is there a need for the managed device to advertise schedules to the managing devices? Can device get schedule from neighbor or need management node?

[danielkinguk]

New text added to Security section.

The security implications for networks using time-variant routing mechanisms must also be considered. Several potential security implications will need careful investigation, these include:

Denial-of-Service (DoS) attacks: Malicious actors could manipulate or disrupt the time information shared within the network, leading to issues with routing protocols and potentially causing DoS attacks. This could impact the network's ability to function properly and deliver services to entities.

Traffic analysis and route prediction: Predicting network activity: By analyzing the shared time information, attackers could potentially predict network activity patterns and routing decisions. This information could be used to launch targeted attacks or plan disruptions.

Identifying user activity: In some scenarios, precise time information might be linked to specific user or device activity or network usage patterns. This could raise privacy concerns if not properly anonymized or protected.

Spoofing and manipulation: Fake or manipulated time information could be injected into the network, leading to incorrect routing decisions and disruptions. This could be used to redirect traffic, launch man-in-the-middle attacks, or gain unauthorized access to resources. <<