Subject: [lmap] Calculation of Cycle-Number

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 27 Jun 2016 21:19:50 -0400

LMAP,

At the latest Interim meeting, I agreed to prepare text that
calculates the variable part of a Cycle-ID. This is planned
to be the numeric index to a specific *recurring* event, 
or cycle among many cycles in the results.
We are referring to the numeric part as Cycle-Number.
(The other part of Cycle-ID is the Cycle-Context-ID, which 
can be alphanumeric and is not intended to be modified at the MA 
or elsewhere.)

See the meeting notes for further background:
https://www.ietf.org/proceedings/interim/2016/06/13/lmap/minutes/minutes-interim-2016-lmap-3

I propose to calculate the Cycle-Number based on the time and 
date of each recurring schedule event, which is a component of
the Measurement Schedule. The MA has to calculate the time and
date of each recurring schedule event, and may use its own format. 
See below for generation of a Cycle-Number.
Measurement Actions may be aligned with event time or have
some random time offset.

Since the LMAP Collector does not possess the Measurement Schedule
as described in Section 5.4 of RFC 7594,
it has no knowledge of recurring event time and dates, and
cannot perform the same calculation. Section 8.4.2 of RFC 7594
identifies the Measurement Schedule as sensitive information,
so this should remain as described by the LMAP Framework.

For a Collector to infer the Cycle-Number 
from the time and date of Measurement Results, the Collector
needs to know the times of recurring schedule events, 
or at least: one of the event times, 
the duration of the recurring event, and
confirmation that the event timing has not been changed
(changes may be needed to avoid an attacker who intends to
bias the measurements). According to the LMAP Framework,
the Collector has none of this information.

Even if the Collector has information necessary to infer the 
Cycle-Number, its calculations can be subject to errors from
the following sources:

* There may be overlapping measurements from concurrent 
  recurring schedules (which would likely use different cycle
  durations, referenced to different recurring events). 
* There may be a 'wait for X' step in a measurement task that
  causes an Action/Measurement to be delayed such that the 
  actual measurement time occurs in a subsequent cycle.

with inference of the wrong Cycle-number as the result.
Overlapping Measurements are described in Section 5.3.2 of RFC 7594.

Measurement Time alone does not lead to the correct 
recurring schedule event for calculation of the Cycle-Number.

-=-=-=-=-=- Note: there are many date, time and datetime formats
in various languages, this is a simple approximation -=-=-=-=-=-=-=

The MA calculates that the next recurring event will occur on
Date = YYYY-MM-DD, at Time = HHMMSS, according to information 
from the Controller.

A simple Cycle-Number can be formed by converting the date and
time to strings, and concatenating the strings:

Cycle-Number = print( str(Date) + "-" + str(Time) ) #possibly truncate time to HHMM

All MAs have synchronized clocks, so they all produce the same
Cycle-Number and report it with the measurement results for that
recurring event when they are operating on the same recurring schedule.