Genart last call review of draft-ietf-6man-ipv6-alt-mark-06

[Stewart Bryant via Datatracker <[e-mail]>]

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.

==========