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

[Giuseppe Fioccola <[e-mail]>]

Hi Stewart,
Thank you for your thorough review.
We will work on a new version soon to address your comments.
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Stewart Bryant via Datatracker <[e-mail]> 
Sent: Monday, June 7, 2021 1:44 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Genart last call review of draft-ietf-6man-ipv6-alt-mark-06

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.

[GF]: We will update the draft and try to modify the text according to your comments. I agree that a standard track needs to be more precise. We will also try to improve the security section.

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

[GF]: Good input. I also think that a summary of the analysis in I-D.fioccola-v6ops-ipv6-alt-mark can be reported. This can also help to clarify the design decision in the draft.

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

[GF]: I will revise the sentence based on your suggestion. We have tried to explain that in the last paragraph of Section 4 << the three high-order bits of the Options Header defined in this draft are 000 and, in theory, as per [RFC8200] and [I-D.hinden-6man-hbh-processing], this means "skip if do not recognize and data do not change en route". [RFC8200] also mentions that the nodes only examine and process the Hop-by-Hop Options header if explicitly configured to do so.  For these reasons, this HbH Option should not affect the throughput >>. But, of course, there is a difference between the theory and the real implementation and we also highlighted that <<it is important to be aware for the implementation that the things may be different and it can happen that packets with Hop-by-Hop are forced onto the slow path, but this is a general issue, as also explained in [I-D.hinden-6man-hbh-processing]>>

===========

SB> I will be interested in what the SecDir review says, but I have 
SB> 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.

[GF]: This kind of attack can surely be added in the security section. However, the precondition is that the AltMark is applied to a controlled domain and this can help to mitigate this issue as well.

SB> To some extent in Section 2.1 the authors try to mitigate this with 
SB> 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?

[GF]: I agree. The application to controlled domains needs to be a strong requirement. We can also reinforce the concept and highlight the need to reject packets with AltMark options entering and leaving domains. Regarding the possible SD-WAN application, I think it could be allowed since the user wants to test and he is also aware of the kind of risks of the on-path telemetry techniques such as AltMark. 

===========

   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 
SB> are
free to pick any length you wish, it would be helpful to know why 20 bits was picked as a size.

[GF]: We picked up 20 bit since it is a reasonable value and a good compromise in relation to the chance of collision if it is set pseudo randomly by the source node.

===========
SB> Operation in an SRv6 context is discussed rather briefly. I think 
SB> there
needs to be a more detailed definintion to ensure correct operation

[GF]: Bob and Ole had some concerns about the description of the SRv6 application in this document and suggested to focus on IPv6 in general. For this reason we also proposed a companion document in SPRING for the SRv6 application (draft-fz-spring-srv6-alt-mark-00)

===========

5.3.  Flow Monitoring Identification
SB> I would have expected this earlier in the document as it sets up a 
SB> lot of
background.

[GF]: I think you are right. It would be better for a reader to find this section earlier in the document.

===========

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

[GF]: We tried to find a compromise. The FlowMonID could be set in two ways: (a) by a Controller, that knows the topology and can set the value properly to avoid/minimize ambiguity, or (b) by the source node, that can set it pseudo-randomly with some chance of collision. So, we picked up 20 bit since this value implies a low rate of ambiguous FlowMonIDs that can be considered acceptable in most of the applications.

   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 
SB> standards
track RFC it needs to be specific on the point of the size.

[GF]: Ok, I can modify the text to be specific in relation to the size as it is defined in the draft.

==========

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

[GF]: We can add more considerations in particular with regard to the FlowMonID and related coordination (if it is set by the source node, the intermediate nodes can read the FlowMonIDs from the packets in flight and act accordingly or they can also be instructed by the controller). But, for more details, it would be better to define the control plane and management mechanisms in separate documents. As an example, we are already working in this direction: e.g. draft-ietf-idr-sr-policy-ifit, draft-chen-pce-pcep-ifit. Once the AltMark option is defined as standard, we can also proceed and define a YANG Model.

==========
6.  Security Considerations

SB> See earlier comments on security and the use of the option as a 
SB> 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.

[GF]: Agree. The reference to RFC8799 will be added and the requirement of the controlled domain will be emphasized.

==========
   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 
SB> easier
to do first stage packet classification and thus reduce the work of the attacker.

[GF]: This can also be highlighted.

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

[GF]: Good point! I will also add the consideration about GPS and related attacks.

==========

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.

[GF]: Ok will clarify and try to make 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….

[GF]: Ok

========

   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/

[GF]: Ok

=========

Para starting    Note that the FlowMonID is different from the Flow Label field
of the
   IPv6 Header ([RFC8200]).

This needs significant copy editing

[GF]: Ok

=========

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*

[GF]: Yes

==========

   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.

[GF]: Ok

==========