Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16

[Juergen Schoenwaelder <[e-mail]>]

Alissa,

thanks for your review - much appreciated. Some of the questions
indeed touch on the question 'what needs to be dealt with in an
information model and what can be left out', which I think has no
clear answer. Please see my response inline...

On Mon, Jan 23, 2017 at 02:22:25PM -0500, Alissa Cooper wrote:
> I have reviewed this document in preparation for IETF last call. I have a few substantive comments and questions that I’d like to discuss before issuing the LC. I’ve also included some nits and minor comments that should be resolved together with any IETF LC comments.
> 
> Substantive comments and questions:
> 
> For a number of my comments below, it might be the case that you think the detail I'm asking for does not belong in the information model, but would be more appropriate in a specification of a specific data model or protocol. I'm not particularly wedded to any of these details appearing here, but I do think they need to appear somewhere, so if they're not going to be specified here I think this document needs to explain that data models and/or protocols need to specify them.
> 
> = String type definition =
> 
> Is it expected that data models and/or protocols will define what character encoding is expected for the string data type? If so, it would be good to say that somewhere.

My assumption always was that a string means a (possibly restricted)
set of Unicode or ISO/IEC 10646 characters. The '(possibly restricted)'
comes from the fact that data modeling languages such as YANG excludes
certain control characters, surrogate blocks and noncharacters.

I will get back to this at the end.

> = Credentials: Section 3.1, 3.2, 3.8, 6 =
> 
> I have a couple of questions about how credentials are defined and used in this document:
> 
> (1) Is it expected that data models and/or protocols will define the 'credential' type and format? If so, it would help to make that clear up front.

Yes. I will get back to this at the end.
 
> (2) Are ma-preconfig-credentials and ma-config-credentials meant to be credentials only for the MA to be authenticated by a Controller or Collector? I assume that the credentials that allow the MA to authenticate other endpoints, and to protect communications to those endpoints, are stored in ma-channel-credentials, but it would help to clarify which set of credentials each of these fields is referring to.

This is a very good question and I do not recall how we got to what we
have. The channel credentials are the credentials used between an MA
and a Controller or Collector. It is less clear what the other device
credentials are really used for. Trevor, do you recall and can you
clarify the situation? My interpretation is that the configured
credentials are, for example, the credentials needed for trusted X.509
authorities, i.e., they are not channel specific - the credentials an
MA has to use for a specific channel but the credentials needed to
verify the credentials of a remote peer. Trevor?

> (3) I'm a little concerned that both ma-config-control-channels and ma-config-credentials are mandatory fields in ma-config-obj, and that the point of having them specified there is to override the pre-configuration information. If I'm understanding correctly, this means that an MA could be preconfigured with certificates it uses to authenticate and encrypt its initial request to a Controller, and the Controller could then respond by saying, "don't use those credentials for yourself or for me, but use these other ones instead." How can an MA then distinguish between a Controller it should trust and one that has been compromised? I know the bootstrapping process is generally out of scope for LMAP, but that scenario seems to imply a security threat that was not specifically contemplated in the framework. Since the fields are being defined here, I think this document needs to discuss these implications, or explain whether there is some (two-way) exchange expected between the MA and the Controller using all the pre-configured credentials that needs to happen before the MA agrees to use different sets of credentials provisioned by the Controller.

I think the assumption here is that the MA trusts the controller which
has credentials matching the MA's pre-configured credentials. If this
trusted controller then later installs new credentials, this leads to
a trust relationship to another controller. Are you requesting that this
should be more clearly discussed in the Security Considerations? Or are
you saying this is a bad idea and we should not allow a controller to
provision any credentials?

> = Section 3.1.1, 3.4.1, 3.5.3 =
> 
> I think you need to specify the scope within which uuids are expected to be unique, and whether the same uuids are expected to be re-used for config, logging, and status.

I think the idea is to use version 4 uuids which have a very low
probability of collision. Generally, the expectation is that these
uuids are unique within an installation of a large-scale measurement
system.

I will get back to this at the end.

> = Section 3.2 =
> 
> I think it would be good to provide some guidance about how NOT to construct a group ID. E.g., I would assume putting sensitive information like "low-income neighborhood" or similar in the group ID would be ill-advised, because even within the single administrative domain where MAs are communicating with Controllers and Collectors, there may be people who are authorized to process the measurement data but not know that level of detail about which kind of group a device/connection belongs to. In that kind of case a mapping between an opaque identifier in the group ID and more contextual information on the Controller/Collector back-end would be wise. I think the draft would benefit from some explanation of that here or in Section 6 with a cross-reference back to here.

I agree. And I think this is not only relevant for group IDs but equally
applies to tags or other names that can be freely choosen. What about this
at the end of the Security Considerations:

   [...] In addition, users of this Information Model are
   advised to choose identifiers for Group IDs, tags or names of
   information model objects (e.g., configured tasks, schedules or
   actions) that do not reveal any sensitive information to people
   authorized to process measurement results but who are not authorized
   to know details about the Measurement Agents that were used to
   perform the measurement.
 
> = Section 3.5.2 =
> 
> What would be the cause for defining different versions of the same task? Also, since the two different versions would have the same name (presumably), I think you need to state of the expected scope of uniqueness of the task name.
>

Names of objects are generally assumed to be unique within an MA.

The version here is essentially used to be able to distinguish
different versions of an implementation of a given metric. I might
have MAs with an old version of a metric implementation with specific
bugs and I might have MAs with a new version of a metric
implementation with different kind of bugs.

> = Section 3.5.3 =
> 
> Why does this object need both an agent ID and a device ID? Is the device ID here expected to be the same as the one that gets pre-configured on the device? What is an MA supposed to put in the device-id field defined here if there was no device ID pre-configured (since in pre-configuration it's an optional field)?

We could make the ma-status-device-id optional to be consistent.

> = Section 3.5.4 =
> 
> Are ma-status-schedule-invocations, ma-status-schedule-suppressions, and ma-status-schedule-overlaps meant to report counters over all of time, or only since ma-status-last-started? I think this needs to be clarified.

Counters are not expected to persist across reboots.

I will get back to this at the end.
 
> = Section 3.5.5 =
> 
> Same question as 3.5.4 for the counters in this section.

Same as above.

> = Section 3.9 and 3.9.1 =
> 
> "Both measurement and non-measurement
>    Tasks have registry entries to enable the MA to uniquely identify the
>    Task it should execute and retrieve the schema for any parameters
>    that may be passed to the Task.
>    ...
> A configured task can be referenced by its name and it
>    contains a set of URIs to link to registry entries or a local
>    specification of the task.
>    ...
> ma-task-functions:        A possibly empty unordered set of registry
>                              entries identifying the functions of the
>                              configured task."
> 
> I have a couple of questions about this:
> 
> (1) Are there any registries being defined for non-measurement tasks, or is this just indicating that such registries could be created? I think it would help to clarify since there is obviously the metrics registry for measurement tasks.

Creating an LMAP task registry was briefly discussed on the mailing
list but so far no concrete proposal has been written. I think the
definition in section 3.9 is actually fine since it does not refer
explicitely to the IPPM metrics registry.

> (2) I don't understand "or a local specification of the task." Is that local specification supposed to be represented with a local URI, the same as other registry objects? Or if not, is ma-task-functions not properly defined, since it's possible to reference something other than a registry entry there?

The set of referenced regristry entry entries can be empty. The phrase
'or a local specification of the task' is indeed confusing. What is
meant here is a task that is essentially well-known by its name. For
example, there is a task called 'traceroute' or 'iperf' and I expect
it to do a traceroute or to run iperf measurements. Perhaps the text
should be changed to read:

   A configured task can be referenced by its name and it
   contains a possibly empty set of URIs to link to registry entries.

> = Section 3.10.1 =
> 
> I don't understand why ma-registry-role is defined here. In draft-ietf-ippm-metric-registry, the role is part of the registry entry, so by specifying the URI, one should know which role is the appropriate one for that entry. 
>

An entry in the metrics registry may define multiple roles. The
ma-registry-role selects which of these roles are instantiated.
 
> Nits and minor comments:
> 
> = Section 1 =
> 
> s/Large Measurement platform/Large-Scale Measurement platform/

fixed

> = Section 3 =
> 
> (1) s/(from a measurement to reporting or communicating with the Controller)/(including measurements or reporting or communicating with the Controller)/

fixed

> (2) It seems a bit odd that Action first appears in Figure 1 but is not included in the enumerated list of objects above it.

I agree - Actions came in later and it still shows. I will see what I
can do to reword this. What about this:

> (3) "Every Action contained in a Schedule is defined as a Task. ... Tasks can implement a variety of different types of Actions." I think this will be confusing to readers because it's circular. It sounds like all Actions are Tasks but Tasks are comprised of Actions; I think the abstraction needs to be explained better, and made consistent. See also sections 3.3 and 3.7: "An Action is a Task with additional specific parameters." I think it would be better to define what an Action is once at its earliest use.

What about this (right below Figure 1):
 
   The primary function of an MA is to execute Schedules.  A Schedule,
   which is triggered by an Event, executes a number of Actions.  An
   Action refers to a Configured Task and it may feed results to a
   Destination Schedule.  Both, Actions and Configured Tasks can provide
   parameters, represented as Action Options and Task Options.

> = Section 3.1.1 =
> 
> s/set of tasks objects/set of task objects/

fixed

> = Section 3.2 =
> 
> OLD
> The reporting of a
>    Group ID without the MA ID allows the MA to remain anonymous
> 
> NEW
> The reporting of a
>    Group ID without the MA ID may allow the MA to remain anonymous
> 
> (Rationale: Given all of the other data and potential identifiers the MA may report, it may still be possible for a Collector or other entity to identify the MA -- not providing an agent ID helps, but does not guarantee anonymity.)

fixed

> = Secion 3.3 =
> 
> s/This enabled fine/This enables fine/

fixed

> = Section 3.3.2 =
> 
> Please add a citation for POSIX.2 fnmatch().

done
 
> = Section 3.5.4, 3.5.5, and 3.5.6 =
> 
> To reduce redundancy I would suggest defining the values 'enabled,' 'suppressed,' 'disabled,' and 'running' outside of all of these sections one time and then within the field definitions just saying which values are valid for each field that uses them.
>

I do no think the benefit is worth the effort. We do not have any notion
of user defined types so far and introducing it to save a few words does
in my view not make the specification clearer.

> = Section 3.6 =
> 
> s/Where the Configuration/Whereas the Configuration/
> 
> (Right? I couldn't quite parse the sentence.)

Yes, fixed.

> = Section 3.6.2 =
> 
> I think it would be good to provide a short explanation in the text as to why RFC 3339 format is not being used for ma-report-result-cycle-number.

The point is that the cycle-number is a fixed-point _number_.

> = Section 3.8 =
> 
> s/it's own/its own/

fixed

> = Section 6 =
> 
> OLD
> This would, for example, allow the MA to remain
>    anonymous
> 
> NEW
> This may, for example, allow the MA to remain
>    anonymous

fixed

To address the questions (above) concerning the semantics of several
base types we have used, I think it makes sense to add the following
to section 2:

   The object definitions use a couple of base types that are defined as
   follows:

   int         A type representing signed or unsigned integer numbers.
               This information model does not define a precision nor
               does it make a distinction between signed and unsigned
               number ranges.  This type is also used to represent
               enumerations.

   boolean     A type representing a boolean value.

   string      A type representing a human-readable strings consisting
               of a (possibly restricted) subset of Unicode and ISO/IEC
	       10646 [ISO.10646] characters.

   datetime    A type representing a date and time using the Gregorian
               calendar.  The datetime format MUST conform to RFC 3339
               [RFC3339].

   uuid        A type representing Universally Unique IDentifier (UUID(
               as defined in RFC 4122 [RFC4122].  The UUID values are
               expected to be unique within an installation of a large-
               scale measurement system.

   uri         A type representing a Uniform Resource Identifier as
               defined in STD 66 [RFC3986].

   ip-address  A type representing an IP address.  This type supports
               both IPv4 and IPv6 addresses.

   counter     A non-negative integer that monotonically increases.
	       Counters may have discontinuities and they are not
	       expected to persist across restarts.

   credentials An opaque type representing credentials needed by a
               cryptographic mechanism to security communication.  Data
               models must expand this opaque type as needed and
               required by the security protocols utilized.

   data        An opaque type representing data obtained from
               measurements.

   Names of objects are generally assumed to be unique within an
   implementation.

A diff of -16 to my working copy (of -17) can be found here:

  http://beadg.de/lmap/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>