Stewart, thank you for your review. I have entered a Discuss ballot for this document. Lars > On 2021-6-7, at 14:44, Stewart Bryant via Datatracker <noreply@xxxxxxxx> wrote: > > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
