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

["Darren Dukes (ddukes)" <[e-mail]>]

Thanks Ben, please see inline.
Revision 26 (to be published shortly) contains the changes to close your comments.

> On Oct 18, 2019, at 1:40 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6man-segment-routing-header-25: No Objection
> 
> ----------------------------------------------------------------------
> 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.
> 

Ah, lets fix that:
<UPDATE>
 o  RESERVED: 15 bits.  MUST be 0 on transmission.
</UPDATE>

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

Deleting SHOULD
<UPDATE>
 An implementation that supports the generation and verification of
 the HMAC supports the following default behavior, as defined in
 the remainder of this section.
</UPDATE>
> 
> 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.

This would render the reduced option unusable with HMAC.
The D bit keeps the choice up to the generating node.

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

This could be misunderstood: let's change 
"at the verification node” 
to
"at the verification node(s)".

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

Thanks Ben, this example still fits within section 2.1.2.1 definition of when to check for an HMAC.

Darren


> 
>