Benjamin Kaduk's No Objection on draft-ietf-6man-segment-routing-header-25: (with COMMENT)

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-segment-routing-header-25: No Objection

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-6man-segment-routing-header/



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

Thank you for addressing my Discuss points (including by having a discussion to
clarify that some of them are in fact non-issues)!

Please also consider the following comments on the -25, none of which quite
rise to Discuss-level, but some of which are significant.

I wonder whether we will ever want to have the HMAC protect (some of)
the other TLVs associated with the SRH; the current formulation is quite
rigid about what the HMAC input is (and trying to change that later,
e.g., by the presence of some other TLV, seems like a bad idea).  What
we have here is fine for now, though, and we could always define a new
"HMACplus" TLV with richer semantics if a need arises.

With respect to the "changing that later seems like a bad idea" point, I
do see this text in Section 2:

   New SIDs defined in the future MUST specify the mutability properties
   of the Flags, Tag, and Segment List and indicate how the HMAC TLV
   (Section 2.1.2) verification works.  Note, that in effect these
   fields are mutable.

I'm coming at this from a perspective of the operational considerations
when an HMAC verification node might implement only [this document] and
thus anything attempting to generate an HMAC according to a modified
procedure specified in some future document would produce an HMAC value
that would fail to verify.


Section 2.1.2 has:

   o  RESERVED: 15 bits.  MUST be 0 on transmission and ignored on
      receipt.

yet those bits are used as input to the HMAC calculation, which seems to
defy the "ignored" portion.


Section 2.1.2.1 has:

   An implementation that supports the generation and verification of
   the HMAC SHOULD support the following default behavior as defined in
   the remainder of this section.

which seems like it might have some vestiges of the previous model where
most of the HMAC verification procedure was up to local configuration; I
think we are now at a place where the following behavior is the only
behavior (not "default") and there's no need to qualify it with
"SHOULD".

Also, it might be possible to spend some thought and convince ourselves
that the 'D' bit is not strictly needed, since an entity creating an SRH
for which the 'D' bit might be needed could just choose to not use the
reduced SRH in cases where verification of the first segment would be
needed.  But I did not spend the time to reason through this, so I'm not
advocating for removing the 'D' bit at this time.

Section 2.1.2.2 has:

   At the HMAC TLV generating node, the Text for the HMAC computation is
   set to the IPv6 header fields and SRH fields as they would appear at
   the verification node, not necessarily the same as the source node
   sending a packet with the HMAC TLV.

   Pre-shared key roll-over is supported by having two key IDs in use
   while the HMAC TLV generating node and verifying node converge to a
   new key.

which implies a single verification node (my recollection is that we
settled on multiple verification nodes being possible).  (Section
2.1.2.1 also has "as it would be reeived at the node verifying the
HMAC", in a similar vein.)


Section 4.3.1.1.1 has:

   Example 2:
   For any packet received from interface I1
     If first TLV is HMAC {
       Process the HMAC TLV
     }
     Else {
       Discard the packet
     }

This shows the location of the HMAC TLV as being up to local policy.
This is ... probably okay from a security point of view, but I mention
it in case our previous discussions have caused us to not want to
endorse this being a part of local policy.