Temporal Periodicity

[alevere]

I propose we consider a way for a producer to select a particular time frame that already exists (e.g. fridays at 5pm EST) rather than specifying a new absolute value for each request. This makes it easier for most actuators to comply. Also, organizations may have specified change windows for these type of changes. Maybe we need a way to query for time slots, then specify one of the returned slots. A returned slot could have no end date, or it could have an end date.

[Vasileios-Mavroeidis]

This is a complex situation but also relevant. How can we solve this without adding to the spec? The orchestrator sends a command with a time argument. The consumer is responsible to identify if this time-frame is defined already as part of other rules in the SLPF-capable device. If yes the same time-frame/range list will be used.

I wont argue though to have SLPF-relevant-only query:time-something, to get the time frames

[jmbrule]

I am NOT in disagreement (or for that matter agreement). This is just a thought. Machines (and I mean essentially ALL machines) know what time it is in terms of seconds since Jan 1, 1970. If we need to issue a command and have it executed at let's say 5:00 PM on a Friday then so be it, and let's make sure we address all the issues such as leap year, understanding that the every March 10 is not a Friday, keep in mind that 5:00PM in Wash DC is different than 5:00PM in CA and that the US has this stupid daylight savings time .... These problems are not insurmountable, but why impose it on all the actuators?
I would err on the side of the orchestrator and mission manager needs to know that the actuators are using the unix epoch and it is up to the openc2 producer to convert from julian calendar to the unix epoch prior to sending the command. Thoughts?

[Vasileios-Mavroeidis]

Joe,

I think what you describe is another thing to consider.

What Alex mentions is to have visibility and ability of reusing time-lists in firewalls. Some of the packet filters when you want to define temporality for a particular rule, do this independently. For example, you define a time-list (lets say every Friday at 1700 to 1800) and then when you add a new firewall rule you can attach it to this time-list (the time-list has a unique name/identifier). So instead of creating a new time-list every time you want to have a rule at the same time executed (activated) you can use an already existing one (if it exists). You would need somehow to have visibility on those lists though. This was an issue I mentioned at the plugfest. Even though this would support specific vendor-technologies I think that we need to investigate how other vendor firewalls treat the periodicity. If it is similar then we can consider bringing something new to the spec. If its something different there is no reason to come up with a standardised way of doing it. Let for example the actuator checking if there is a list available identical with the OpenC2 command time args and if yes use the existing, if not create one.

-Vasileios

On 13 Feb 2020, at 20:54, Joe Brule notifications@github.com<mailto:notifications@github.com> wrote:

I am NOT in disagreement (or for that matter agreement). This is just a thought. Machines (and I mean essentially ALL machines) know what time it is in terms of seconds since Jan 1, 1970. If we need to issue a command and have it executed at let's say 5:00 PM on a Friday then so be it, and let's make sure we address all the issues such as leap year, understanding that the every March 10 is not a Friday, keep in mind that 5:00PM in Wash DC is different than 5:00PM in CA and that the US has this stupid daylight savings time .... These problems are not insurmountable, but why impose it on all the actuators? I would err on the side of the orchestrator and mission manager needs to know that the actuators are using the unix epoch and it is up to the openc2 producer to convert from julian calendar to the unix epoch prior to sending the command. Thoughts?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter/issues/123?email_source=notifications&email_token=AG6ZQAWU4R6NQTKFUUEY7ETRCWQONA5CNFSM4KTFPGFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWMNUA#issuecomment-585942736, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG6ZQAR5LX7DYJJZRQ3QEKLRCWQONANCNFSM4KTFPGFA.

[jmbrule]

I am tracking what you are saying and I think I did a poor job of communicating my thought. Simply stated, in 'acutator-speak', a particular time is the Unix epoch which has dimensions of seconds since Jan 1970 which will be some integer such as 1579478400 (which happens to be my 30th anniversary). The thing on the wire that was at the egress of the orchestrator and the ingress of the actuator is 1579478400. Everything else (that is the special needs of humans or widgets) is done within the orchestrator or actuator and we (from an openc2 perspective) dont concern ourselves with it

[jmbrule]

I think our judgment is getting clouded because we are use to thinking in terms of a human agent issuing a command. We need to think in terms of machine to machine communication. If we do that, then this issue becomes easier.
The SLPF is an actuator that receives a command from an orchestrator. For temporal arguments, machine can process and deal with some big integer (well at least until 2038, but that is a separate issue). Aevere spelled out a real need to accommodate more descriptive time, but given that it is easy enough to convert to and from the unix epoch when humans need this to be done, and given that machines are adept at processing the unix time, then does it not make sense to converge on unix time and leave any conversions that need to be done 'North' of the ingress? Suggest we consider adding text that amplifies that the SLPF will consume and produce unix time at the wire and any conversions to a Julian calendar is beyond the scope of openc2.
Thoughts?