[Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-flow-spec-v6-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A fairly minor point, but I think that allowing Type 13 (flow label)
component values to be encoded as 2-byte quantities encourages the
selection of non-random flow label values, and thus violates the
guidance from RFC 6437 that these values "should be chosen such that
their bits exhibit a high degree of variability" and that "third parties
should be unlikely to be able to guess the next value that a source of
flow labels will choose."  While having the short 1-byte encoding for a
flow label of 0 might be reasonable, a 2-byte label can represent at
most 16 bits of the 20-bit identifier space, discouraging the use of the
high 4 bits, when such bits of unpredictability are scarce already.
Let's discuss how big an issue this is and what might be done to
mitigate it.

Please also confirm that we are providing all the information required of
us by RFC 5701 and 5575bis (see comments on Section 6.1); I am not sure
whether I am reading the references correctly in these regards.

There seems to be an error in the sample code (flow_rule_cmp_v6()): the
snippet
               if comp_a.offset < comp_b.offset:
                   return A_HAS_PRECEDENCE
               if comp_a.offset < comp_b.offset:
                   return B_HAS_PRECEDENCE
duplicates the condition, whereas the condition should be swapped for
correct operation.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this straightforward and easy-to-read document!  Just a few
minor comments.

Section 3.3

   This component uses the Numeric Operator (numeric_op) described in
   [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 3 component values
   SHOULD be encoded as single octet (numeric_op len=00).

Why only SHOULD?  (Likewise for Section 3.4, 3.5, etc.)

Section 3.7

   Contains a list of {numeric_op, value} pairs that are used to match
   the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3).

[It seems that RFC 8200 §3 just points to RFC 8200 §6, which itself
mostly points to RFC 6437.  I don't know if it is useful to
short-circuit some of those references.]

Section 3.8.1

   The following example demonstrates the prefix encoding for: "packets
   from ::1234:5678:9A00:0/64-104 to 2001:DB8::/32 and upper-layer-

Where is the "/64-104" notation introduced?  I did not see it in RFC
4291.  (It also appears in §3.8.2, though the latter uses "/65-104"
to demonstrate the operation of padding.)

Section 4

   The definition for the order of traffic filtering rules from
   [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new
   consideration for the IPv6 prefix offset.  As long as the offsets are
   equal, the comparison is the same, retaining longest-prefix-match
   semantics.  If the offsets are not equal, the lowest offset has
   precedence, as this flow matches the most significant bit.

I will note just to confirm my understanding that this procedure seems
to give higher precedence to, e.g., 1234::/1-4 than to
::1234:5678:9a00/81-128 even though the latter is inspecting more bits
of the address/prefix.  (To be clear, some choice has to be made and I
have no reason to prefer a different one over this one, I am just
exploring the consequences of this choice.)

It is again (as per 5575bis) surprising that we allow for a "not-equal"
comparison of differently encoded (e.g., flow label) values that have
the same semantic meaning, but I expect the same response (and no
document change) as when I made the comment the first time.

Section 5

   The validation procedure is the same as specified in
   [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a)
   of the validation procedure should now read as follows:

Are there also any AFI/SAFI differences from 5575bis to consider in
terms of "routes received over"/etc.?

Section 6.1

   This extended community uses the same encoding as the IPv6 address
   specific Route Target extended community [RFC5701] Section 2 with the
   high-order octet of the Type always set to 0x80 and the Sub-Type
   always TBD.

RFC 5701 suggests that since we are allocating the "TBD" sub-type value,
we should also state what the semantics of the "local administrator"
2-octet field are.

   Interferes with: All BGP Flow Specification redirect Traffic
   Filtering Actions (with itself and those specified in
   [I-D.ietf-idr-rfc5575bis] Section 7.4).

I think we are supposed to also state what action to take when
encountering interfering actions.

Section 7

It was a little surprising to me that the inability to match (e.g.) TCP
flags or Port values on non-initial IP fragments was not reiterated in
the security considerations of 5575bis.  I don't think it would make
sense to mention that just in this document's security considerations,
though -- if we are to change anything it should be in 5575bis.  But I
guess we had that conversation already, at
https://mailarchive.ietf.org/arch/msg/idr/zvpLPjllvKWFuyraZUVz8lB8Wz0/
and thus no change is expected.

Section 8.1.2

(side note) it seems a little weird to have the IPv4 version be the one
that gets the unqualified (e.g., "Destination Prefix") name.