Network Traffic end datestamp for single packet flows

["maybe" <maybe@sybr.work>]

Hi cti-users,

I submitted an issue on Github for this [0] but it doesn't seem like the
tracker is being actively looked at so figured I'd raise it here instead.
Please excuse the ^c^v below:

> I have an implementation capturing and describing network traffic and have
> noticed that the STIX 2.1 spec specifically states that network-traffic
> observables' end property must be strictly greater than the start property if
> both are defined.
>
>     If start and end are both defined, then end MUST be later than the start
>     value.
>
>     -- ref the table in section 6.12.1
>
> This causes issues for me describing single packet UDP flows which get timed
> out because I then set the end time to the start time. It would be incorrect
> IMO to set the end time to anything else since there was no activity
> associated with it after the start time, and I'd prefer to include the end
> time to be explicit rather than relying on a downstream system to interpret
> what the absence of an end datestamp and is_active: False means.
>
> I can also see an issue with systems which have limited clock resolution
> which observe flows which complete within a single tick. I've not seen this
> behaviour personally but it seems like a thing which might reasonably occur,
> e.g. if observations were being made by software without access to a high
> resolution timer.
>
> What would you suggest the expected behaviour here should be? Is there any
> particular reason why the start and end property cannot have the same value?

At present I'm working with the spec as defined by omitting the end datestamp
if it's <= (obviously generally ==) the start datestamp, but it would be nice
to get some feedback on the rationale here and if it would be reasonable to
expect any change in a future release of the spec.

Thanks,
~m

[0] https://github.com/oasis-tcs/cti-stix2/issues/232