Re: [Last-Call] Genart last call review of draft-ietf-6man-ipv6-alt-mark-06

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call