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

[Benjamin Kaduk <[e-mail]>]

Hi Giuseppe,

Also inline...

On Thu, Aug 12, 2021 at 09:06:11AM +0000, Giuseppe Fioccola wrote:
> 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.

Thanks for the additional explanation.  I might suggest s/identify
different flows/can be used to identify flows based on different criteria/

>    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.

Ah, I definitely was not thinking of 5-tuple as the subject of the
comparison, so making that explicit would be useful.
That said, the component fields of the 5-tuple have a lot more than 20 bits
among them!  Yes, not all can be freely chosen, but I think that "finer
granularity" is only justified if (as came up in a different IESG review)
the FlowMonID is scoped to the 5-tuple (or 3-tuple).

> 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)

Thanks.

>    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.

I agree that double marking is preferred (and the draft is clear on why).
Thanks for re-working this text; if you want to keep the suggestion I might
phrase it as something like "the two approaches provide slightly different
pieces of information and the data consumer can combine them to have a more
robust data set".

> 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.

Thanks.  As was the case for another AD, I did not assume that the
Controller-assigned values would also be random, so making that clear will
help a lot.

>    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.

(I think I will leave this topic to the other ADs' Discuss ballots, but
thank you for providing the historical background here; it's very helpful
to know what had already been discussed.)

Thanks for all the updates,

Ben

> 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
>