Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-ioam-data-15: (with DISCUSS and COMMENT)

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Ben,

Thanks a lot for another really thorough review. GREATLY appreciated.
We just published -16 to address your comments and your discusses below.
Please also find responses inline.

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]>
> Sent: Tuesday, 12 October 2021 00:30
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Al Morton <[e-mail]>; [e-mail]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-ippm-ioam-data-15: (with
> DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ippm-ioam-data-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for the many updates and email discussion about the relationship
> between limited (network) domains, IOAM domains, IOAM namespaces, and the
> like -- I think I do now have a pretty clear picture of how they're expected to
> interact!  However, I think there may still be a couple places in the document
> that need to get updated in order to match that vision.  One point here, and
> some (more minor) instances in the COMMENT section...
> 
> Section 5.2 has:
> 
>    The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
>    node is always performed within a specific IOAM-Namespace.  This
>    [...]
>    described above, that is added in a future revision.  An IOAM
>    decapsulating node situated at the edge of an IOAM domain MUST remove
>    all IOAM-Option-Types and associated encapsulation headers for all
>    IOAM-Namespaces from the packet.
> 
> The "MUST remove [...] for all IOAM-Namespaces" at the end seems to conflict
> with the notion of the role of IOAM-decapsulating node being performed within
> a specific IOAM-Namespace.  Indeed, later on in Section
> 5.3 we see that namespace identifiers "allow devices which are IOAM capable to
> determine: [...] o  whether IOAM-Option-Type(s) have to be removed from the
> packet, e.g., at a domain edge or domain boundary."  If a decapsulating node
> always had to remove IOAM options from all namespaces, then the namespace
> identifier is irrelevant to whether option type(s) are removed from the packet.

...FB: Good catch. This is a left-over from earlier discussions and indeed inconsistent with how Namespaces are defined now.
The sentence: " An IOAM decapsulating node situated at the edge of an IOAM domain MUST remove all IOAM-Option-Types and associated encapsulation headers for all IOAM-Namespaces from the packet." got removed.

> 
> 
> [the following paragraph is retained unchanged from my ballot position on the -
> 12, since the topic seems to still be open.]
> 
> As foreshadowed in
> https://mailarchive.ietf.org/arch/msg/last-call/Ak2NAIKQ7p4Rij9jfv123xeTXQY/
> I think we need to have a discussion about the expectations and provisions for
> cryptographic (e.g., integrity) protection of IOAM data.
> >From my perspective, IOAM is a new (class of) protocols that is seeking
> publication on the IETF stream as Proposed Standard.  While we do make
> exceptions for modifications to protocols that were developed before we
> realized how important integrated security mechanisms are, it's generally the
> case that new protocols are held to the current IETF expectations for what
> security properties are provided; the default expectation is that a protocol is
> expected to provide secure operation in the internet threat model of RFC 3552.
> This draft currently only provides a brief note in the security considerations that
> there exists an individual draft (draft-brockners-ippm-ioam-data-integrity) that
> might provide ways to protect the integrity of IOAM data fields.
> Shouldn't the security mechanisms be getting developed side-by-side by the
> protocol mechanisms, to ensure that they are properly integrated and fit for
> purpose?  (This does not necessarily have to be in the same document and could
> be part of a cluster of related documents, but I don't think that an informative
> reference to a non-WG draft really
> qualifies.)
> 
> [new disucssion on this topic as of the -15] The discussion on this topic was over
> a rather protracted timescale, for which I share much of the blame.  I think that
> the latest message is
> https://mailarchive.ietf.org/arch/msg/ippm/POycw2NpSl5cIruqSimTa_4WrwI/
> where I make a proposal to have some text about how actual use of these data
> fields in a protocol or encapsulation needs to provide some (possibly optional)
> mechanism for cryptographic integrity protection, which could be draft-
> brockners-ippm-ioam-data-integrity but could also be native to the
> encapsulation format.  I think that such a construction would allow this
> document to proceed to RFC without waiting for the other one to be complete.

...FB: The new version -16 includes the following paragraph - following your suggested approach, and also referencing I-D.ietf-ippm-ioam-data-integrity, which is the WG adopted version of draft-brockners-ippm-ioam-data-integrity.

   IETF protocols require features to ensure their security.  While IOAM
   data fields don't represent a protocol by themselves, the IOAM data
   fields add to the protocol that the IOAM data fields are encapsulated
   into.  Any specification that defines how IOAM data fields carried in
   an encapsulating protocol MUST provide for a mechanism for
   cryptographic integrity protection of the IOAM data fields.
   Cryptographic integrity protection could be either achieved through a
   mechanism of the encapsulating protocol or it could incorporate the
   mechanisms specified in [I-D.ietf-ippm-ioam-data-integrity].
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> All-new (okay, almost all) comments as of the -15.
> 
> Mentioning here for lack of a better place, I happened to follow the reference
> to draft-brokners-opsawg-ioam-deployment, which seems to still be using the
> old definition of transit node and should get updated to match this document's
> definition.
> 
> Section 5.2
> 
>    IOAM is expected to be deployed in a specific domain.  The part of
>    the network which employs IOAM is referred to as the "IOAM-Domain".
> 
> In light of the (new) text up in §5, we might consider rewording this part as well,
> mostly to avoid mentioning "network" that risks confusion about "network
> domain" (pre previous discussion).

...FB: Section 5.2 starts off now with "Section 4 already mentioned that IOAM is expected to be deployed in a
   limited domain [RFC8799]."

> 
>    An "IOAM transit node" read and/or write and/or process one or more
>    of the IOAM-Data-Fields.  If both the Pre-allocated and the
>    Incremental Trace Option-Types are present in the packet, each IOAM
>    transit node based on configuration and available implementation of
>    IOAM populates IOAM trace data in either Pre-allocated or Incremental
>    Trace Option-Type but not both.  [...]
> 
> Since we redefined transit nodes to include only reading, in addition to
> modifying, it doesn't seem 100% accurate to say that "each transit node
> populates [one or the other but not both]" -- it seems valid for a transit node to
> populate zero of the trace option types.

..FB: Good catch. Given that no change is indeed an option, we changed "populates" to "might populate".

> 
> Section 5.3
> 
>    An IOAM-Namespace can be associated to a subset or all of the the
>    IOAM-Option-Types and their corresponding IOAM-Data-Fields.  IOAM-
> 
> This sentence seems confusing to me.  It talks about namespaces as if they
> contain options, but if we go on to examine the actual data structures each
> option has a field to indicate the associated namespace.
> We even go on to say that the IOAM-Namespace field "MUST be included in all
> future IOAM-Option-Types" (side note: might be worth calling that out in the
> guidance in the IANA considerations, and also to specifically say that it's the first
> field of the option).  So it's really not clear to me what this sentence is adding --
> would it be safe to just remove it?

...FB: Indeed. The sentence does not add anything. We removed "An IOAM-Namespace can be associated to a subset or all of the the  IOAM-Option-Types and their corresponding IOAM-Data-Fields. "
  The IANA section now also has a note that asks for checks for newly defined Option-Types.
 
> 
>    o  IOAM-Namespaces can be used by an operator to distinguish
>       different operational domains.  Devices at domain edges can filter
>       on Namespace-IDs to provide for proper IOAM-Domain isolation.
> 
> I suggest tweaking the wording to clarify that the "different operational
> domains" in the first sentence are precisely the "IOAM-Domain"s of the second
> sentence.

...FB: Good point. The paragraph now reads: 
     "IOAM-Namespaces can be used by an operator to distinguish
      different IOAM-domains.  Devices at edges of an IOAM-domain can
      filter on Namespace-IDs to provide for proper IOAM-domain
      isolation."

> 
>       *  Assigning different IOAM Namespace-IDs to different sets of
>          [...]
> 
> There are two instances of a bullet point that talks about assembling a full trace
> from partial traces, but the text has substantial differences.  I suspect that one is
> just an editing artifact and should be removed, but am less sure which one has
> the intended text (I would guess the latter, for what it's worth).

...FB: Uuuups. My bad. The first bullet got removed. It was indeed redundant and a left-over from editing.

> 
> Section 5.4
> 
>    "IOAM tracing data" is expected to be collected at every IOAM transit
>    node that a packet traverses to ensure visibility into the entire
>    path a packet takes within an IOAM-Domain.  [...]
> 
> Since we redefined transit nodes to include only reading, this "is expected to be
> collected" doesn't seem entirely representative anymore.

...FB: Fully agreed. The sentence ""IOAM tracing data" is expected to be collected at every IOAM transit
   node that a packet traverses to ensure visibility into the entire
   path a packet takes within an IOAM-Domain." is at best a statement about potential deployments.
   It does not really fit into the document - and thus got removed.

> 
>    [...].  If not all nodes within a domain support IOAM functionality
>    as defined in this document, IOAM tracing information (i.e., node
>    data, see below) will only be collected on those nodes which support
>    IOAM functionality as defined in this document.  [...]
> 
> Similarly, I might s/will only/can only/ here for the same reason.

...FB: Done.

> 
> 
> Section 5.4.2
> 
>    Some IOAM-Data-Fields defined below, such as interface identifiers or
>    IOAM-Namespace specific data, are defined in both "short format" as
>    well as "wide format".  "Short format" refers to an IOAM-Data-Field
>    which comprises 4 octets.  "Wide format" refers to an IOAM-Data-Field
>    which comprises 8 octets.  [...]
> 
> We have definition entries for short/wide format in Section 3, so these
> clarification sentences may not be needed.

...FB: Removed the two sentences which restated the definition of short/wide format.

> 
> Section 5.5
> 
> draft-ietf-sfc-proof-of-transit might be undergoing significant changes
> prompted by the results of its secdir review thread.  I don't object to leaving this
> discusison in place but it may be prudent to think about paring down what we
> say here.  In particular, there seems to be some (admittely, small) chance that
> the SFC doc will not have exactly two POT types.

...FB: Given the uncertainties around draft-ietf-sfc-proof-of-transit, draft-ietf-ippm-ioam-data-16 no longer uses draft-ietf-sfc-proof-of-transit as a reference. 
The key fields for POT Type 0 - PacketID and Cumulative are generic, straight forward and thus don't require the SFC draft.
Per what you state above: The note on the particular flag to signal the active profile was very specific to the current method used in the POT draft.
It got removed. Should a future POT solution require it, it can be specified in a corresponding draft.

> 
> Section 6.3
> 
> It seems that in going from the -12 to -15 we lost the paragraph about leap
> seconds here.  My understanding is that posix timestamps *are* affected by leap
> seconds, and so it is correct to include such a statement.  My ballot comment on
> the -12 was conditioned on the use of TAI for the epoch, and thus my comment
> on the -12 is irrelevant.

...FB: The draft now references RFC8877 and other timestamp sources, rather than it tries to reexplain timestamp formats. As a consequence, there is indeed no discussion on leap seconds etc. Hope this works for you. Otherwise the document ends up loaning from other specs without adding much - and potentially leading to misalignment and confusion. 

> 
> Section 10
> 
> We should probably say that the opaque snapshot, namespace specific data,
> etc., will have security considerations corresponding to their defined data
> contents that should be described where those formats are defined. [ed. this
> remains unchanged from my comment on the -12; I'm not sure if the intent to
> add some text just got overlooked, but don't intend to rehash any discussions
> that were already made.]

...FB: The following paragraph got added to reflect your note above:

This document does not define the data contents of custom fields like
   "Opaque State Snapshot" and "namespace specific data" IOAM data
   fields.  These custom data fields will have security considerations
   corresponding to their defined data contents that need to be
   described where those formats are defined.

> 
> Since we clarified the definition of transit nodes to include read-only transit
> nodes, we might want to say something about how transit nodes that only
> implement support for one or the other trace option types (as is clearly
> permitted) will have an incomplete picture of the trace in cases where both
> trace option types are used for the same packet.  In many cases that is
> innocuous, of course, but it does not seem guaranteed to always be so.

...FB: Good point. -16 now states:

IOAM deployments which leverage both IOAM Trace Option-Types, i.e.,
   the Pre-allocated Trace Option-Type and Incremental Trace Option-Type
   can suffer from incomplete visibility if the information gathered via
   the two Trace Option-Types is not correlated and aggregated
   appropriately.  If IOAM transit nodes leverage the IOAM data fields
   in the packet for further actions or insights, then IOAM transit
   nodes which only support one IOAM Trace Option-Type in an IOAM
   deployment which leverages both Trace Option-Types, have limited
   visibility and thus can draw inappropriate conclusions or take wrong
   actions.

> 
>    allowing attackers to collect information about network paths,
>    performance, queue states, buffer occupancy and other information.
> 
> One possible application of such reconiassance is to gauge the effectiveness of
> an ongoing attack (e.g., if buffers and queues are overflowing).  I don't know
> whether it's particularly useful to mention that scenario here or not, though, and
> the lack of response the previous time I made the comment suggests that it's
> not actually useful to mention it.

...FB: It is useful to be mentioned of course. -16 now adds:

" One
   possible application of such reconnaissance is to gauge the
   effectiveness of an ongoing attack, e.g., if buffers and queues are
   overflowing."

> 
>                   Indeed, in order to limit the scope of threats
>    mentioned above to within the current network domain the network
>    operator is expected to enforce policies that prevent IOAM traffic
>    from leaking outside of the IOAM domain, and prevent IOAM data from
>    outside the domain to be processed and used within the domain.
> 
> On the -12, I said "it would be great if we could provide a bit more detail on the
> scope of consequences if the operator fails to do so."
> Some of the follow-up discussion suggested that draft-brockners-opsawg-ioam-
> deployment would be a better home, which I don't object to; I'm retaining this
> comment just in case there was actual desire to put such content in this
> document.  No specific reply is expected or required, either way.

...FB: ACK.

> 
> NITS
> 
> Section 5.3
> 
>       controllers.  For example, the node identifier field (node_id, see
>       below) does not need to be unique in a deployment (e.g., if an
>       operator wishes to use different node identifiers for different
>       IOAM layers, even within the same device; or node identifiers
>       might not be unique for other organizational reasons, such as
>       after a merger of two formerly separated organizations), the
>       Namespace-ID can be used as a context identifier, such that the
>       combination of node_id and Namespace-ID will always be unique.
> 
> This looks like a comma splice (maybe put a sentence break after the long
> parenthetical?).

...FB: The monster got split up: 
     The node identifier field (node_id, see below) does
      not need to be unique in a deployment.  This could be the case if
      an operator wishes to use different node identifiers for different
      IOAM layers, even within the same device or node identifiers might
      not be unique for other organizational reasons, such as after a
      merger of two formerly separated organizations.  The Namespace-ID
      can be used as a context identifier, such that the combination of
      node_id and Namespace-ID will always be unique.

> 
>       *  Assigning different IOAM Namespace-IDs to different sets of
>          nodes or network partitions and using the Namespace-ID as a
>          selector at the IOAM encapsulating node, a full trace for a
>          flow could be collected and constructed via partial traces in
>          different packets of the same flow.  Example: An operator could
> 
> I think s/Assigning/By assigning/ (note the comment that indicates there are
> "two copies" of this text).

...FB: Done.

> 
> Section 5.4
> 
>    o  Time of day when the packet was processed by the node as well as
>       the transit delay.  Different definitions of processing time are
>       feasible and expected, though it is important that all devices of
>       an in-situ OAM domain follow the same definition.
> 
> I think we've been standardizing on the "IOAM domain" spelling.

... FB: Done. Good catch :-)


Thanks again for all your comments and the really thorough review.

Cheers, Frank
> 
>