Reviewer: Stewart Bryant Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-6man-ipv6-alt-mark-06 Reviewer: Stewart Bryant Review Date: 2021-06-07 IETF LC End Date: 2021-06-15 IESG Telechat date: Not scheduled for a telechat Summary: Regrettably I think that this document needs significant editing before it can be published. The document still includes a lot of discussion about options that is suited to a early text proposing the concept, but THIS text is a standards track RFC and needs to be precise about how the idea works and what independent implimentors need to implement. I am concerned that there is insufficient text on how a measurement is set up/configured and the results reported. I am also concerned that the security implications are not sufficiently documented. Major issues: 2. Alternate Marking application to IPv6 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. Consequently, a robust choice is to standardize a new Hop-by-Hop or Destination Option. SB> I-D.fioccola-v6ops-ipv6-alt-mark looks like it will always be an ID and not progress to RFC. Also within the scope of this standards track text “consequently” is quite a leap. I think that this should perhaps be SB> I-D.fioccola-v6ops-ipv6-alt-mark demonstrated that that a new Hop-by-Hop or a new Destination Option was the best approach. SB> However, if I-D.fioccola-v6ops-ipv6-alt-mark is not to be published, a summary of the analysis in section 2 of that document could usefully be incorporated in this memo as an appendix so it is clear why the approach was taken. SB> Alternatively you could perhaps include a short new section 2 summarising the design decision. ========== o In case of Hop-by-Hop Option Header carrying Alternate Marking bits, it is not inserted or deleted, but can be read by any node along the path. The intermediate nodes may be configured to support this Option or not and the measurement can be done only for the nodes configured to read the Option. Anyway this should not affect the traffic throughput on nodes that do not recognize the Option, as further discussed in Section 4. SB> Perhaps "As discussed in Section 4 the presence of the hop-by-hop option should not affect the traffic throughput on nodes that do not recognise this option" SB> However I am not sure that you have demonstrated that to be correct. It will certainly take cycles to find the option or skip the option if another is present, and how do you know what the node will then do and how many cycles this will take? =========== SB> I will be interested in what the SecDir review says, but I have Privacy concerns ringing in my head as I read this and looking forward to the security section there is no mention of what is in essence a flow tracking cookie added at source. SB> To some extent in Section 2.1 the authors try to mitigate this with a reference to "controlled domains", I think that this needs to be as strong as Alt Mark IPv6 MUST NOT be deployed outside a controlled domain. It may also need text about the need to reject Alt Mark packets entering and leaving domains. That said I am not sure what happens if a DO is used because a user wants to test their SD-WAN? Should that be allowed of depricated? =========== o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is described in Section 5.3. SB> Given that this not being put in an IPv6 flow ID and given that you are free to pick any length you wish, it would be helpful to know why 20 bits was picked as a size. =========== SB> Operation in an SRv6 context is discussed rather briefly. I think there needs to be a more detailed definintion to ensure correct operation =========== 5.3. Flow Monitoring Identification SB> I would have expected this earlier in the document as it sets up a lot of background. =========== 5.3.1. Uniqueness of FlowMonID It is important to note that if the 20 bit FlowMonID is set independently and pseudo randomly there is a chance of collision. SB> I am not sure the method of setting is specified. SB> Also 20 bits is a somewhat interesting size since it is too large for local lookup in an NPU, but may not be long enough to avoid collisions. Given that h/w is likely going to need to use one of its main lookup engines, why is a longer key not used? So, in some cases, FlowMonID could not be sufficient for uniqueness. In general the probability of a flow identifier uniqueness correlates to the amount of entropy of the inputs. For instance, using the well-known birthday problem in probability theory, if the 20 bit FlowMonID is set independently and pseudo randomly without any additional input entropy, there is a 50% chance of collision for just 1206 flows. For a 32 bit identifier the 50% threshold jumps to 77,163 flows and so on. 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. SB> This text is useful in a design discussion memo, but this is a standards track RFC it needs to be specific on the point of the size. ========== 5.5. Data Collection and Calculation The nodes enabled to perform performance monitoring collect the value of the packet counters and timestamps. There are several alternatives to implement Data Collection and Calculation, but this is not specified in this document. SB> Since it is needed for deployment, where is it specified? SB> Indeed I think that there needs to be a lot more text describing how the Flow IDs are co-ordinated along the path? Are nodes expected to know these a-priori or to glean them from the packets in flight. Is this a configured measurment or can it just start? How and to whome is the measurement data collected? SB> This was thought through with RFC6374 and I wonder is some sort of adaptation of that would be a better approach. ========== 6. Security Considerations SB> See earlier comments on security and the use of the option as a tracking cookie. This at least needs a reference to the security section of RFC 8799. Unlike MPLS these packets can leak onto the Internet, or may even be deployed on the Internet by those studying, for example, SD-WAN packet performance. ========== The privacy concerns of network measurement are limited because the method only relies on information contained in the Option Header without any release of user data. Although information in the Option Header is metadata that can be used to compromise the privacy of users, the limited marking technique seems unlikely to substantially increase the existing privacy risks from header or encapsulation metadata. SB> One could argue that in a pervasive surveillance attack it would be easier to do first stage packet classification and thus reduce the work of the attacker. ========== The Alternate Marking application described in this document relies on an time synchronization protocol. Thus, by attacking the time protocol, an attacker can potentially compromise the integrity of the measurement. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384]. SB> RFC7384 seems to be assuming timing over packet. It does not seem to handle the local GPS case well, and I can imagine that local GPS will become rather common but has its own attack vectors. That said GPS attacks tend to be high profile and are a priority item for spectrum regulators. ========== Minor issues: SB> In the section starting: where: o Option Type: SB> I think this could be made a lot clearer to the reader with some examples. Nits/editorial comments: This approach is compliant with [RFC8200]. The Alternate Marking SB> Perhaps The alternate marking approach specified in this memo is compliant…. ======== o In case of Destination Option Header carrying Alternate Marking bits, it is not processed, inserted, or deleted by any node along the path until the packet reaches the destination node. Note that, if there is also a Routing Header (RH), any visited destination in the route list can process the Option Header. SB> s/the Option/the alternative marking Option/ ========= Para starting Note that the FlowMonID is different from the Flow Label field of the IPv6 Header ([RFC8200]). This needs significant copy editing ========= 3.1. Data Fields Format The following figure shows the data fields format for enhanced alternate marking TLV. This AltMark data is expected to be SB> Shouldn’t that be *is encapsulated* ========== The AltMark Option is the best way to implement the Alternate Marking method and can be carried by the Hop-by-Hop Options header and the Destination Options header. SB> it *is* carried that way. ========== -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
