RE: Benjamin Kaduk's No Objection on draft-ietf-6man-ipv6-alt-mark-08: (with COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Benjamin,
Thank you for your review. 
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[e-mail]> 
Sent: Thursday, August 12, 2021 12:09 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Benjamin Kaduk's No Objection on draft-ietf-6man-ipv6-alt-mark-08: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-ipv6-alt-mark-08: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

My colleagues already made some good reviews, so I don't have any more comments to add at the Discuss level (though I will follow the resolution of the other reviews).  I do have a number of COMMENT-level comments (plus some NITS-level remarks at the end that probably don't need individual responses).

Section 1

   application in an IPv6 domain.  While the case of Segment Routing
   Header (SRH), defined in [RFC8754], is also discussed, it is valid
   for all the types of Routing Header (RH).

Given that it's not required to use a routing header with this option, and the discussion in section 4 explicitly covers the ordering between destination option and (an arbitrary) routing header, I think it might be okay to drop this sentence.

[GF]: Ok

Section 2

   The Alternate Marking Method requires a marking field.  As mentioned,
   several alternatives have been analysed in
   [I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
   IPv6 Address and Flow Label.

If one follows the "replaced by" chain, it seems that draft-fioccola-v6ops-ipv6-alt-mark is listed as a direct predecessor of this document.  So it seems a little odd to refer back to a previous version of this draft (without even acknowledging that it is a previous version of this work) for additional details on a topic that is also treated here in a summary form.  Why not just eliminate the reference and include the needed information here (perhaps in an appendix if needed)?  For what it's worth, I think that the summary in this section can stand on its own without need for further supporting references.

[GF]: Sure. I can remove the reference and add the needed information.

   Furthermore the Flow Label may be changed en route and this may also
   violate the measurement task.  [...]

My (hasty) reading of RFC 6437 is that such changes are strongly discouraged and only allowed in exceptional circumstances.  Perhaps the description here should account for that?

   monitored flow.  Flow Label and FlowMonID within the same packet are
   totally disjoint, have different scope, identify different flows, and
   are intended for different use cases.

Can you explain a bit more (not necessarily in the document) what "identify different flows" means?  It seems like if two identifiers are carried in the same packet they must in some sense identify the same thing, so I'm not sure what the different "flows" would be in this scenario.

[GF]: I only meant that FlowMonID identifies the flow to be measured. You can define a flow with different granularity based on what you want to monitor. For sure there is a relationship between the two identifiers, for example one can be subset of the other.
 
   The rationale for the FlowMonID is further discussed in Section 5.3.
   This 20 bit field allows easy and flexible identification of the
   monitored flow and enables a finer granularity and improved
   measurement correlation. [...]

I'm a bit confused at how "finer granularity" comes in -- if the FlowMonID is 20 bits, isn't that the same granularity as the 20-bit Flow Label?

[GF]: Yes, since we cannot use the Flow Label we needed to define the FlowMonID. I meant finer granularity in comparison to the traditional 5-tuple used to identify a flow. The addition of FlowMonID enables finer granularity.

Section 2.1

   [RFC8799] introduces the concept of specific limited domain solutions
   and, in this regard, it is reported the IPv6 Application of the
   Alternate Marking Method as an example.

I think Roman already touched on this point as well, but RFC 8799 only introduces the concept; it's not the final word on the concept, and
8799 seems to expect that documents using the concept of a controlled domain will add on much more specifics about what is actually meant.

[GF]: Yes I will include the definition of Controlled Domain in the next version (as also replied to Roman)

   Some scenarios may imply that the Alternate Marking Method is applied
   outside a controlled domain, either intentionally or unintentionally,
   but in these cases, IPsec authentication and encryption MUST be used.

I appreciate the sentiment, but a hard MUST requirement for IPsec specifically may be needlessly limiting.  Why would some other VPN technology that provides full packet confidentiality+integrity protection while traversing the external domain be insufficient?

[GF]: Agree. I will revise that sentence and mention also other possibilities.

Section 4

   Options Header to a slow processing path.  In case of the AltMark
   data fields described in this document, the motivation to standardize
   a new Hop-by-Hop Option is that it is needed for OAM (Operations,
   Administration, and Maintenance).  [...]

It seems to also be worth mentioning here that the limitation of use to a controlled domain helps mitigate the risk of arbitrary nodes dropping packets with HbH options.

[GF]: Ok.

Section 5

   This section describes how the method operates.  [RFC8321] introduces
   several alternatives but in this section the most applicable methods
   are reported and a new field is introduced to facilitate the
   deployment and improve the scalability.

If only the "most applicable methods" are reported, and both RFC 8321 and this document say to prefer a batching strategy based on a fixed time interval, doesn't that make the batching strategy based on fixed packet count "not most applicable" and thus undeserving of mention at all in this document?

[GF]: Yes, as discussed with Martin, I will highlight that the method based on counter-based batches is not the preferred solution.

Section 5.2

   The same principle used to measure packet loss can be applied also to
   one-way delay measurement.  Delay metrics MAY be calculated using the
   two possibilities:

Again, how are there two possibilities that are both "most applicable methods"?

[GF]: Ok I will clarify.

   In summary the approach with double marking is better than the
   approach with single marking.  Moreover the two approaches can also
   be combined to have even more information and statistics on delay.

It might be worth saying a little more about how the approaches can be "combined"; my current understanding seems more like they are both executed in parallel on the same input data, but they produce independent result values and any combination of those results is left to the system (or human) processing the results.

[GF]: Yes your understanding is correct, but it is just a proposal. It is up to the implementation. Maybe we can also omit this suggestion to avoid misunderstanding. There are two solutions: double marking and single marking. Double marking is preferred for a number of reasons explained in the draft. I will revise this part.

Section 5.3

   o  First, it helps to reduce the per node configuration.  Otherwise,
      each node needs to configure an access-control list (ACL) for each
      of the monitored flows.  Moreover, using a flow identifier allows
      a flexible granularity for the flow definition.

This seems to only be relevant in the case where there is definitely a central controller involved, if I'm understanding correctly -- if the source is assigning the FlowMonIDs the consumers will still need to look for those flows by ACL.  So maybe this could be rephrased slightly to account for that.

[GF]: Yes will do.

Section 5.3.1

   of collision for 1206 flows.  So, for more entropy, FlowMonID can
   either be combined with other identifying flow information in a
   packet (e.g. it is possible to consider the hashed 3-tuple Flow
   Label, Source and Destination addresses) or the FlowMonID size could
   be increased.

This document is about to become a final, standards-track, RFC.  I strongly suggest removing discussion of things that are not possible once the protocol becomes immortalized in an RFC (that is, increasing the FlowMonID size).

[GF]: Yes, I will remove this sentence.

Section 6

Thank you for putting so much effort into the security considerations section already!  I have a few thoughts on potential additional topics to consider.

[GF]: Thanks.

Not necessarily something that needs to be discussed in the security considerations section itself, but the security considerations in practice will depend on whether the marking is always enabled for all flows, always enabled for a subset of flows, only enabled for specific flows on-demand, etc..  Some kind of scope-setting for the expected usage could be helpful to see, since the expected usage shapes what analysis has been done of the security properties.

[GF]: Yes, as discussed with Martin, I will specify the usage scenarios. For example an ingress router (CPE) encapsulates a received packet in an outer IPv6 header and adds the HbH or DOH if and only if the destination is within the controlled domain.

Separately, it is perhaps too banal to mention, but attacks on the reporting/consolidation of the statistics between the monitoring devices and the analysis platform can interfere with the proper functioning of the system.  The channels used to report back flow statistics should be secured.

[GF]: Agree. I will add.

There are also some considerations to note when the FlowMonIDs are centrally allocated by a controller -- the controller knows a lot about what traffic is flowing!  That might make it the target of an attack, depending on the attacker goals.

Another factor that comes into play when the controller (or anyone,
really) is non-randomly assigning IDs, is that the actual structure of the ID allocation itself can cause issues -- for example, predictable sequential assignment can give an attacker insight into the rate of flow creation, what fraction of flows they have visibility into from their current vantage point, and makes attacks that are contingent on guessing the "next" identifier very feasible.  The considerations in draft-gont-numeric-ids-sec-considerations seem to apply.

[GF]: Yes, FlowMonID is generated by the Controller but in this case it only verifies that there is no ambiguity between different pseudorandomly generated FlowMonIDs on the same path. Anyway I will have a look at draft-gont-numeric-ids-sec-considerations.

   Harm caused by the measurement: Alternate Marking implies

I think Roman already touched on this to some extent, but the FlowMonID in the measurement option adds some privacy considerations that can in some cases mean that the measurement causes harm.

[GF]: Sure, I plan to add some considerations. Anyway the application to a controlled domain helps to mitigate the issue.

      single monitoring point.  The only way for an attacker can be to
      eavesdrop on multiple monitoring points at the same time, because
      they have to do the same kind of calculation and aggregation as
      Alternate Marking requires, and, after that, it can finally gain
      information about the network performance, but this is not
      immediate.

Just my own opinion, but I think this would be more useful if it stopped after "have to do the same kind of calculation and aggregation as Alternate Marking requires."  That is, the attacker doesn't have an advantage over the rightful admin, but can get the same data; we don't need to say anything more, and the mention of "not immediate" is arguably misleading.

[GF]: Ok agree.

   Furthermore, in a pervasive surveillance attack, the information that
   can be derived over time is more.  But the application of the
   Alternate Marking to a controlled domain helps to mitigate all the
   above aspects of privacy concerns.

I suggest adding another clause or sentence about why/how the controlled domain mitigates the privacy concerns (perhaps just as a forward reference to the text currently two paragraphs later than this one, which might be easier to achieve if the security considerations were split into subsections).

[GF]: Ok will do. Maybe I can spit into subsections to make it clearer.

   this document.  As an example, the AltMark Option can be used as Hop-
   by-Hop or Destination Option and, in case of Destination Option,
   multiple domains may be traversed by the AltMark Option that is not
   confined to a single domain.  In this case, the user, aware of the

(This statement might be added to the list that Roman enumerated of places where we do/don't talk about being confined to a limited domain.)

   confined to a single domain.  In this case, the user, aware of the
   kind of risks, may still want to use Alternate Marking for telemetry
   and test purposes but the inter-domain links need to be secured
   (e.g., by IPsec) in order to avoid external threats.  For these

(Interesting that here IPsec is only an "e.g." and not a MUST...even though the "MUST" is repeated in the following sentence!  C.f. my remark on Section 2.1.)

[GF]: As said, I will change the MUST condition and harmonize the text.

   measurement.  A detailed discussion about the threats against time
   protocols and how to mitigate them is presented in [RFC7384].  Also,

NTS was recently published as RFC 8915; it might be worth mentioning here.

[GF]: Sure, will do. Thanks for pointing this out.

Section 9.2

It's not really clear to me that RFCs 8321 and 8889 can be classified as informative.

[GF]: We discussed last year the relationship between this document and RFC 8321 / RFC 8889 with the IPPM chairs, 6MAN chairs and ADs. We could not normatively refer to experimental documents since this draft is a proposed standard. They suggested to have RFC 8321 as informative reference. It was also highlighted that, in the case of RFC 8321, Experimental and Informational can be considered at the same  maturity level. For this reason, the description of the methodology in RFC8321 has been included in this document to enable the informative reference.

NITS

Section 1

   The Alternate Marking is an on-path telemetry technique and consists
   in synchronizing the measurements in different points of a network by
   switching the value of a marking bit and therefore divide the packet
   flow into batches.  Each batch represents a measurable entity

s/divide/dividing/, to match up with the conjugation of "synchronizing"
and "switching".

[GF]: Ok

   unambiguously recognizable by all network nodes along the path.  By

I think that "unambiguously" can fail in the face of extreme reording (relative to the marking window).

[Gf]: I will revise.

   in an IPv6 domain is reported in Section 6.  As for all the on-path
   telemetry technique, the only definitive solution is that this

s/all the on-path telemetry technique/all on-path telemetry techniques/

[GF]: Ok

Section 2

   Hop-by-Hop Option Header is also useful to signal to routers on the
   path to process the Alternate Marking.  However, as said, routers
   will examine this option if properly configured.

I think that "only" should be added, either for "will only examine" or "only if properly configured" (but not both).

[GF]: Ok

   Furthermore the Flow Label may be changed en route and this may also
   violate the measurement task.  [...]

"violate the measurement task" is an unusual phrasing, and I'm not actually sure what meaning it's intended to convey.  Perhaps it's something about invalidating the integrity of the measurement result?

[GF]: Yes, I will revise.

Section 4

   In general, it is needed to perform both end to end and hop by hop
   measurements, and the Alternate Marking methodology allows, by
   definition, both performance measurements.  But, in many cases the
   end-to-end measurement is not enough and it is required also the hop-
   by-hop measurement, so the most complete choice is the Hop-by-Hop
   Options Header.

The paragraph structure here doesn't make much sense: we say that in general, both (end-to-end and hop-by-hop) measurements are possible, but then follow up with a note that "in many cases end-to-end is not enough".  There's no previous situation described where only end-to-end is possible that merits this comparison.  It seems that some specific mention of Destination Options would be needed in order to be able to make such a comparison.

[GF]: I will revise the sentence.

Section 5.1

   single batch between any two nodes.  Each batch represents a
   measurable entity unambiguously recognizable by all network nodes
   along the path.

(Same remark about "unambiguous" as above)

   It is worth mentioning that the length of the batches is considered
   stable over time in the previous figure.  In theory, it is possible

[GF]: Ok

I'd consider "duration" rather than "length", here (indeed, the figure shows batches of both 10 and 11 packets, and possibly 9 as well if "batch 1" is not considered to be truncated

[GF]: sure I can change it

Section 6

      The FlowMonID field is used in the AltMark Option as identifier of
      the monitored flow.  It represents a more sensitive information

"identifier" needs an article; I'm not sure whether "a" or "the" would better match the intended meaning.

[GF]: I will revise