Subject: Benjamin Kaduk's Discuss on draft-ietf-6man-segment-routing-header-22: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 03 Sep 2019 19:52:45 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-segment-routing-header-22: 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-6man-segment-routing-header/

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

(1) Section 2.1.2.1 says:

   Local configuration determines when to check for an HMAC and
   potentially indicates what the HMAC protects, and a requirement on
   where the HMAC TLV must appear (e.g. first TLV), and whether or not
   to verify the destination address is equal to the current segment.

I'm uncomfortable about leaving so much of the semantics of a
security mechanism up to the local configuration.
Specifically, the "potentially indicates what the HMAC protects" and
"whether or not to verify the destination address is equal to the
current segment", which leaves some of the key security properties of
the system in the hands of someone that is potentially quite
inexperinced in reasoning about the relevant security properties.
I do think we can still specify something useful and interoperable that
still allows flexibility about when to check and where the TLV can
appear.  (This may in practice also allow flexibility about what it protects,
if the semantics are something like "it protects everything prior to it"
and we allow for other TLVs to appear after it, but the actual *rules*
for what it protects would be well-specified.)

(2) I also think we should discuss what is protected by the HMAC.  I note in
the COMMENT that this seems to be more about protecting the SRH contents
than the packet payload, but at present there is no binding at all to
the containing packet or flow, which seems to in effect present the SRH
as a self-contained, "signed", policy blob, which can be detached from
packet data and transferred at will.  It's probably also best practice
to include a fixed "contxt string" like "IPv6 SRH HMAC" even though the
risk of key reuse and cross-protocol attacks seems quite small here.
It's also pretty tempting to pull in the representation of the
"immutable TLVs", though there are probably some tricky details to
describing how to do that, and that can present complexity challenges
if/when nodes not trusted with HMAC keys are expected to apply varying
TLVs at runtime.  (The lack of defined TLVs other than HMAC and padding
make it hard for an outsider to gague the intent for TLV usage.)

(3) I'm concerned that this mechanism may not be consistent with BCP 107's
guidance on automated vs. manual key management, with respect to
directly using the long-term HMAC key to key the HMAC.  Most modern
designs will introduce an intermediate key-derivation step that mixes
some message- or flow-specific data into the intermediate key that is
then used to key the per-message MAC.  Section 5.5 seems to suggest that
the IPv6 flow label may be usable (i.e., fixed within the domain for a
given flow) for this purpose, but I may be missing a subtlety about
intra- vs. inter-domain traffic, and it may not be feasible to involve a
central controller into flow identifier assignment.
If the HMAC is solely intended to make self-contained "authorized policy
blobs" that are infrequently changing, then the direct use of the
long-term key may not be as problematic as it first seems.
Additionally, if the SDN-oriented or "trusted key distribution protocol such as
[RFC6407]" cases are used, then this is somewhat less of a concern,
though there may still be key usage lifetime considerations to worry
about and potentially force somewhat-rapid key turnover (i.e., weeks or
months).

(4) I'm not sure that the scoping of key IDs per destination node is
consistent with the use cases depcicted.  I mention this in the COMMENT
section in a few places, but the short version is roughly "if the HMAC
is fixed for the life of the packet, then we can either have the key ID
namespaced by destination address but only have one verifier, or we can
have multiple verifiers on the path but the key ID space is global".  We
do currently have text that talks about verification being performed at
multiple points on the path, so I'm not sure which scenario is intended.

(5) I think we need to have some discussion about key
revocation/rotation.  The mode of operation for the HMAC TLV that
appears to be envisioned by this document is that there is a central
trusted service that computes "blessed" segment routes with an
accompanying HMAC "signature" (not a real signature, but a sign of
aproval in some sense), and that the resulting token of (SRH including
HMAC TLV) is distributed by SDN configuration.  These SRH tokens are
treated by many nodes as opaque blobs, applied to outgoing traffic
according to the procedure configured alongside the token.  Some other
(trusted) nodes in the network may look inside the SRH to verify the
MAC, and check that the rout in question should be coming from that
direction, but those nodes may be a minority of nodes.  In this
scenario, we need to consider the behavior when the central controller
changes what routes are to be used, and effectively wants to "revoke"
the old ones and ensure that the deprecated routes are not in use in the
SR domain.  The only mechanism for doing so seems to be to rotate the
HMAC key in question so as to discard all HMACs generated by the key in
question (since keeping something akin to a CRL of "revoked" HMAC values
seems infeasible in general); I think we should have some discussion
about needing to do a key rotation to effectuate such "revocation" (that
is, cryptographically ensure that previously configured/"blessed" routes
are no longer in use).  It would also be pretty easy to tie this in to
text about recovering from a compromised HMAC key.

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

As something of a general note, this document (specifically, the HMAC
portions) was initially challenging for me to read, since in the
security community we tend to have HMAC (or MACs in general) apply to
specific messages and protect the content from end to end.  The usage
here seems rather different, in that the HMAC is protecting not the
packet payload, but (essentially) just the SRH, which is to a large
extent a fixed (e.g., per-flow) artifact that reflects routing policy.  So the
MAC is serving to authenticate policy, more than messaging, and there
was very little in the document that tried to make that distinction.
I've tried to indicate some locations/changes that would improve readability
in this regard.

Section 1

   The Segment Routing Architecture [RFC8402] describes Segment Routing
   and its instantiation in two data planes MPLS and IPv6.

nit: we need some form of punctuation after "data planes".

Section 2

   o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  Tag is not used
      when processing the SID defined in Section 4.3.1.  It may be used
      when processing other SIDs which are not defined in this document.
      The allocation and use of tag is outside the scope of this
      document.

At what scope does its use need to be defined?  Can it be defined on a
per-segment basis or must it be deployment-global?

   The mutability of the TLV value is defined by the most significant
   bit in the type, as specified in Section 2.1.

It seems like this presents the design as one where we rely on the
participants to be trusted to properly respect the (im)mutability, and
there are not external mechanisms (e.g., cryptography) to enforce them.
So, we have SR nodes that are in a hybrid state of not being trusted
with HMAC keys (and thus to generate routing policy) but are trusted to
"be implemented correctly" and not mutate fields that are supposed to be
immutable.  This multi-tier trust system should probably be discussed in
the security considerations.

Section 2.1

   An implementation MAY limit the number and/or length of TLVs it
   processes based on local configuration.  It MAY:
   [...]

Is this list an exhaustive enumeration of the granted permissions or are
other limitations possible?

   o  Limit the number of consecutive Pad1 (Section 2.1.1.1) options to
      1, if padding of more than one byte is required then PadN
      (Section 2.1.1.2) should be used.

nit: comma splice

   Type: An 8 bit value.  Unrecognized Types MUST be ignored on receipt.

   Length: The length of the Variable length data.

Do we want to give a pointer to (e.g.) the registry for these type
values?
I see we say in the next entry that Length measures bytes, though
perhaps it is more natural to mention it here.

   Type Length Value (TLV) contain OPTIONAL information that may be used
   by the node identified in the Destination Address (DA) of the packet.

nit: there seems to be a singular/plural mismatch of sorts here, in that
the current TLV incarnation mostly acts as a singular.  I'd suggest
adding another word like "entries" or "structures" after the
parenthetical, as a resolution.

   The highest-order bit of the TLV type specifies whether or not the
   TLV data of that type can change en route to the packet's final
   destination:

For clarity: that's bit '0' in the above figure?

Section 2.1.1

      Padding TLVs are used for meeting the alignment requirement of the
      subsequent TLVs.
      [...]
      Padding TLVs are used for alignment.

Is there some redundancy here we could deduplicate?

Section 2.1.1.1

   required.  If more than one byte of padding is required a Pad1 TLV
   MUST NOT be used, the PadN TLV MUST be used.

nit: comma splice

Section 2.1.1.2

      Padding: Length octets of padding.  Padding bits have no
      semantics.  They MUST be set to 0 on transmission and ignored on

[Elsewhere in the document we've used "semantic" as a singular; it might
be worth a pass to check for consistency of usage]

Section 2.1.2

I echo the sentiments already expressed about this HMAC format being
likely to reflect substantial wasted space in much common usage.
(Unless the intent is that since TLV support is optional, it's unlikely
to be implemented at all, in which case the wastefulness of a
nonexistent feature doesn't matter?)
In particular, having to specify the details of which bits of the 'HMAC'
field have significance when the HMAC algorithm in use has fewer than 32
bytes of output seems to be just as much effort as making the field
variable length.
Four octets of Key ID also seems like far more than will be needed,
though we don't really discuss the scope (in space/topology and time) in
which it needs to be unique -- we should probably talk about that here!
(I do see a bit of discussion in Section 2.1.2.2 that seems to say that
the key-ID is scoped by the destination IP address.)  On the other hand,
this much Key ID space could be used if there was a desire to have very
fine-grained routing policy and revocation ability (see below), but it's
still unclear that even in a high-churn fine-grained situation there
would be the will to store millions of HMAC keys on the
controller/verifier.

   The HMAC TLV is used to verify the source of a packet is permitted to
   use the current segment in the destination address of the packet, and
   ensure the segment list is not modified in transit.

I'd suggest some revisions to this along the lines of:

%  The HMAC TLV is used to verify that the SR applied to a packet was
%  selected by an authorized party, and to ensure that the segment list is
%  not modified after generation.  This also allows for verification that
%  the current segment (by virtue of being in the authorized segment list)
%  is an authorized use.

since the expected usage seems to not be to give the keys (and thus the
choice of segment lists) to the actual source of the packet, and we are
detecting modification of the Segment List since the HMAC generation,
which could span a broader period of time than just when the packet
carrying the HMAC is "in transit".

Section 2.1.2.1

   For HMAC algorithms producing digests less than 32 octets, the digest
   is placed in the lowest order octets of the HMAC field.  Remaining
   octets MUST be set to zero.

To keep me from second-guessing myself, are these the "lowest order
octets" if we are treating the field as a 32-byte big-endian integer?
(As opposed to an array of bytes enumerated in order per the figure.)

   If HMAC verification is successful, the packet is forwarded to the
   next segment.

Does this really mean "processing proceeds as normal", to allow for the
possibility of local action/modification before forwarding?

Section 2.1.2.2

   The HMAC Key ID field is opaque, i.e., it has neither syntax nor
   semantic except as an identifier of the right combination of pre-
   shared key and hash algorithm, and except that a value of 0 means
   that there is no HMAC field.

"No HMAC field" or "the HMAC field is filled entirely with zeros"?  The
previous diagram/discussion does not suggest that the HMAC field is
sometimes omitted.

   At the HMAC TLV verification node the Key ID uniquely identifies the
   pre-shared key and HMAC algorithm.

   At the HMAC TLV generating node the Key ID and destination address
   uniquely identify the pre-shared key and HMAC algorithm.  Utilizing

This decision to make the key-ID space scoped to the destination address
seems to have some potentially substantial consequences that I don't see
discussed in the draft.  Specifically, since the destination address
will change on every hop, it would seem to preclude a model where the
HMAC TLV is generated by the sender and not modified subsequently (which
itself would probably have knock-on effects).  Is the additional scoping
by IP address of key-ID necessary even with the 4-octet key-ID, or would
scoping the key-ID to be globally unique within a SR domain suffice?
Unless the intent is that there is only a single verification node in a
given path?  The desired usage remains quite unclear to me.

Section 3.2, 3.3

nit(?): We seem to talk about "an IPv6 packet" when we really mean "an
IPv6 packet with SRH", "an SR IPv6 packet", "an SRv6" or similar.

Section 4.1

   A Source node steers a packet into an SR Policy.  If the SR Policy
   results in a segment list containing a single segment, and there is
   no need to add information to SRH flag or TLV, the DA is set to the
   single segment list entry and the SRH MAY be omitted.

nit: "to the SRH flags or to add TLVs"

      HMAC TLV may be set according to Section 7.

Do we want to say anything about other, to-be-specified, TLVs here?
Like "HMAC (or other) TLVs may be set" or "TLVs (including HMAC) may be
set according to their specifications"?

4.1.1.  Reduced SRH

   A reduced SRH does not contain the first segment of the related SR
   Policy (the first segment is the one already in the DA of the IPv6
   header), and the Last Entry field is set to n-2 where n is the number
   of elements in the SR Policy.

This seems to imply that Segments Left is not constrained to point
inside the Segment List (and can point one past it); is that correct?

Section 4.3.1

   This document, and section, defines a single SRv6 SID.  Future
   documents may define additional SRv6 SIDs.  In which case, the entire
   content of this section will be defined in that document.

nit: perhaps this is just me, but I tend to read "defines a single SRv6
SID" as "defines a single SRv6 SID value"; the intent here seems to be
more along the lines of "SID behavior" or "SID processing algorithm".
The second sentence could also be phrased similarly to "Such documents
will need to specify the analogous behavior as is described in this
section and subsections".

Section 4.3.1.1

Is this pseudocode normative, or the text of the following subsections?

Section 5.1

   Nodes outside the SR Domain are not trusted: they cannot directly use
   the SID's of the domain.  This is enforced by two levels of access

nit: "SIDs" (no apostrophe)

   1.  Any packet entering the SR Domain and destined to a SID within
       the SR Domain is dropped.  This may be realized with the
       following logic, other methods with equivalent outcome are
       considered compliant:

nit: comma splice  (also in (2))

       *  Failure to implement this method of ingress filtering exposes
          the SR Domain to source routing attacks as described and
          referenced in [RFC5095]

nit: this doesn't seem like a bullet point in the list, but rather a
standalone paragraph of commentary.
It may also be worth reiterating that failure to do so on even a single
edge node puts the entire network at risk.

Section 5.2

   Consider a top of rack switch (T) connected to host (H) via interface
   (I).  H receives an SRH (SRH1) with a computed HMAC via some SDN
   method outside the scope of this document.  H classifies traffic it
   sources and adds SRH1 to traffic requiring a specific SLA.  T is

I'm having a hard time parsing how the SRH1 that H receives via SDN can
be the same SRH1 that H adds to traffic.  The key insight seems to be
that the SRH received via SDN is not attached to an IPv6 packet as a
"live" routing header, but is rather a piece of configuration data to be
applied as the SRH on flows sent on a given SR.  (The formalism is
slightly weird, as "receiving an SRH" includes the "next header" value,
which is arguably artificially limiting, but this is probably minor
enough to ignore.)  So perhaps we want to say that "H receives, along
with the configuration for applying SR to a given flow, an SRH (SRH1)
with pre-computed HMAC that reflects that SR flow, via some SDN method
outside the scope fo this document."

   An operator of the SR Domain may choose to have all segments in the
   SR Domain verify the HMAC.  This mechanism would verify that the SRH
   segment list is not modified while traversing the SR Domain.

As partially covered above, this seems inconsistent with having the HMAC
key-ID be scoped by the destination SID when the destination SID changes
from segment to segment.

Section 5.4

   For the source of an invoking packet to process the ICMP error
   message, the correct destination address must be determined.  The

"correct" in what sense/for what operation?

      *  If routing header is type 4 (SRH)

(This is still "TBD", formally, right?)

         +  Use the SID at Segment List[0] as the destination address of
            the invoking packet.

Similarly to the first comment on this section, do we want some language
about how this is "use"d "for processing by the upper layer transport"?

Section 5.6

I'm slightly tempted to add a sentence along the lines of "the
mechanisms in this document are known to not be directly transferrable
to multi-domain deployment models without substantial impact on these
properties", but (1) it's an absolute statement that seems like it would
be hard to be 100% confident in, and (2) it's not entirely clear that it
adds much value to the general reader (as opposed to providing a
security disclaimer to make the security AD happy).  So I'm curious to
hear about how much thought has already gone into this, pointers to
ongoing documents on the topic, etc.

Section 6.1

I a little bit wonder if mixing zero-based (Segments Left; Last Entry)
and one-based (S1, S2, S3) indexing is going to cause undue cognitive
load for anyone.

Section 6.2

   o  The SR domain is secured as per Section 5.1 and no external packet
      can enter the domain with a destination address equal to a segment
      of the domain.

I'd suggest using "firewalled" rather than "secured", since "secured"
can mean many different things and we have a more-precise term
available.

Section 6.3.2

Is it worth calling out that P5 does not have an SRH?

Section 6.9

   This section describes how a function may be delegated within the SR
   Domain to non SR source nodes.  [...]

I'm kind of confused about what "non SR source node" means in the
context of a source node that is adding an SRH for verification
elsewhere.

Section 6.6.1

   An operator may prefer to add the SRH at source 8, while 5 verifies
   the SID list is valid.

I note that "add" here means "apply a fixed bitstring to the packet",
not "compute the value of"...

   For illustration purpose, an SDN controller provides 8 an SRH
   terminating at node 9, with segment list <S5,S7,S6,A9>, and HMAC TLV
   computed for the SRH.  The HMAC key is shared with 5, node 8 does not
   know the key.  Node 5 is configured with an IACL applied to the

... since the SRH value is computed by the controller and distributed to
8 as almost an opaque token.  It would be good if we could reword this
to be more clear about how the mechanics work such that 5 does not need
the HMAC key.

   Node 8 originates packets with the received SRH with HMAC TLV.

nit: I suggest s/with HMAC TLV/including HMAC TLV/

Section 7.1

Does the ability to create traffic loops or near-loops (that span the
same links dozens or hundreds of times) merit a specific mention outside
of "DOS/DDOS"?

Section 7.5

   The SR Domain is a trusted domain, as defined in [RFC8402] Section 2
   and Section 8.2.  The SR Source is trusted to add an SRH (optionally
   verified via the HMAC TLV in this document), and segments advertised

I suggest s/verified/verified as having been generated by a
trusted configuration source/.

   The use of SRH with AH by an SR source node, and processing at a SR
   segment endpoint node, is not defined in this document.  Future
   documents may define use of SRH with AH and its processing.

It's not entirely clear to me what this is intended to convey.  It this
saying "SRH MUST NOT be used in the same packet as AH" or something more
like "we make no statements about the use of SRH in combination with
AH"?

Section 8

   RFC will be published.  The Designated expert will post a request to
   the 6man WG mailing list (or a successor designated by the Area
   Director) for comment and review, including an Internet-Draft.

nit: this wording makes it sound like either the DE includes an I-D in
the body of the mail or is the author of the I-D in question; I assume
we just want a pointer or link to the draft requesting the
allocation(s).

Section 12.2

I-D.filsfils-spring-srv6-interop and
I-D.matsushima-spring-srv6-deployment-status are only referenced from
the Implementation Status section (that is to be removed); should the
references be removed as well?

I think RFCs 2104, 6437, and 6438 need to be normative.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 5 Sep 2019 13:52:41 +0000

Hi Benjamin, some preliminary thoughts are attached inline regarding the discuss items.

I’ll follow up in a couple days with more complete responses and read of your items you raise.

Thanks
  Darren

> On Sep 5, 2019, at 9:07 AM, Darren Dukes <[email-masked]> wrote:
> 
> Hello Benjamin, thanks for your thorough review.  I’ll be reviewing the items you raise shortly and responding to the list at that time.
> 
> Thanks!
>  Darren
> 
>> On Sep 3, 2019, at 10:52 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
>> 

I’ll give this some thought.

>> make it hard for an outsider to gague the intent for TLV usage.)

Yes, as described in the document, the intent is to verify the source is permitted to use the segment list in the SRH.

Packet payload can be protected by ESP.

>> about and potentially force somewhat-rapid key turnover (i.e., weeks or

As mentioned above, the HMAC is present to validate the SRH.  
Therefore I believe this is less of a concern, as you mention.

>> multiple points on the path, so I'm not sure which scenario is intended.

Understood, I’ll look into the relevant text more and follow up.

>> text about recovering from a compromised HMAC key.

I think describing the revocation of a segment list and the key rotation required could resolve this concern, I’ll expand on this later.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Sep 2019 16:03:53 -0500

> I’ll follow up in a couple days with more complete responses and read of your items you raise.

Sure, thanks for the preliminary thoughts. (inline)

> Yes, as described in the document, the intent is to verify the source is permitted to use the segment list in the SRH.

It's not entirely clear that it succeeds at this, though.  To a large
extent, it seems like the SRH-with-HMAC object is a token, separable from
the packet, that conveys only the sense that the segment list ("routing
policy", in my head) is one that is approved but that the approval in
question is not bound to the actual sender, just the nominal source
address.  That token could be put on many packets by potentially many
actors, not limited to the intended originator of the packet.  Consider a
segment list of <S7, S4> in the topology of Figure 3.  Section 6.3.2 uses
that policy as an example of transit with source address A3, but what
prevents that bit-for-bit-identical SRH from being applied at host 8?  Such
packets would need to be spoofing router 3's source address, but is router
5 always going to be checking that, and is the analogous checking going to
be done for all potential topologies?

> Therefore I believe this is less of a concern, as you mention.

Less of a concern, yes.  It may still be a concern worth addressing,
though -- I can imagine some use cases where it would become relevant,
though for many (common?) ones it would not be relevant.

> I think describing the revocation of a segment list and the key rotation required could resolve this concern, I’ll expand on this later.

Sounds good; thanks!

-Ben

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Sep 2019 19:35:39 +0000

Hi Ben, I got delayed replying, please see inline.

> On Sep 5, 2019, at 5:03 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

When an SRH is added to a packet by an SR Source node, it may not include the first segment in the segment list.  This is called ‘reduced’ in the document.  This is why “whether or not to verify the destination address is equal to the current segment” is present.  i.e node T as documented in section 5.2 may be configured via some SDN method to compare the destination address to the current segment or not.  This is not something that an administrator would toggle or not.

“potentially indicates what the HMAC protects” is more open ended than necessary.  This statement was made to optionally include the destination address in the HMAC calculation if necessary.  Perhaps we could limit the ‘local configuration’ by stating “potentially indicates whether destination address is included in the HMAC”.

> be done for all potential topologies?

Nodes within the SR domain are trusted (RFC8402), so the example you give isn’t quite valid.  Source address spoofing is not something the HMAC is intended to protect against.  
As stated in the HMAC use case in section 5.2, “an operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain, and validation of the contents of any SRH to a more trusted router or switch attached to the host.”

> though for many (common?) ones it would not be relevant.

How about a reference to BCP107 to cover this concern?  
In section 2.1.2.2 the last paragraph could state: “While key management is outside the scope of this document, the recommendations of BCP 107 should be considered when choosing the key management system.”

Other suggestions welcome.

>> Understood, I’ll look into the relevant text more and follow up.

True, the text is not consistent.  The addition of verifiers at multiple nodes was a late addition that is not compatible with the key id space described.
Changing the text to scope the Key ID per source address does allow for both a reduced key id number space and permits the key management system to scope key IDs as appropriate.

However I’m curious if you think such differentiation is necessary in this document or if we should leave it up to the key management system.

>> I think describing the revocation of a segment list and the key rotation required could resolve this concern, I’ll expand on this later.
How about something like:

Section 2.1.2.2
…
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.
<NEW>
The HMAC TLV generating node may need to revoke an SRH it previously generated an HMAC for.  The HMAC generating node must roll-over the key id used to generate the HMAC of the old SRH and segment list. This ensures the SR source only uses the new SRH and segment list when the old key id is no longer supported on the verifying node.
</NEW>

Darren

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Sep 2019 15:47:25 -0500

Hi Darren,

I was also delayed, unfortunately.

> When an SRH is added to a packet by an SR Source node, it may not include the first segment in the segment list.  This is called ‘reduced’ in the document.  This is why “whether or not to verify th…

I think we might be able to finesse this part a bit, e.g., allowing for a
null "verification" when the current segment is defined by the destination
address in the current packet.  So that a node checking HMACs would always
"verify the destination address" but if the segment is not in the list,
that verification is a no-op, as indicated by "segments left" being past
"last entry".  Other verification might be appropriate in that case,
though, such as making sure that the segment indicated by src/dest
addresses makes sense when combined with the explicit segment list.

> “potentially indicates what the HMAC protects” is more open ended than necessary.  This statement was made to optionally include the destination address in the HMAC calculation if necessary.  Perha…

Perhaps, though I'm not sure I've thought enough about how that would work.
Would that configuration have to be global to the SR domain?

> As stated in the HMAC use case in section 5.2, “an operator of an SR domain may choose to delegate SRH addition to a host node within the SR domain, and validation of the contents of any SRH to a m…

Well, there's clearly some level of differential trust going on, or we
wouldn't be bothering with the HMAC and validation at all.  So maybe we
need to step back and discuss in what way the host node in question is
going to be less-trusted such that we need to verify what it's doing.
We definitely need to be precise about what protection the crypto mechanism
is actually providing; I am not entirely convinced that we can say very
much about the source node specifically being authorized for this specific
policy (SRH), in terms of just what the HMAC is guaranteeing
cryptographically, rather, that the policy includes a source address and we
can check that the packet's address is consistent with that policy.  The
connection to the actual source node is more tenuous, requiring (as you
note) some level of trust on *all* entities in the SR domain.

> Other suggestions welcome.

That seems like a reasonable approach.

> However I’m curious if you think such differentiation is necessary in this document or if we should leave it up to the key management system.

I think we need to be clear about how to interpret the key id field, so if
we think someone might need it to depend on source address, we have to say
that in this document.

> The HMAC TLV generating node may need to revoke an SRH it previously generated an HMAC for.  The HMAC generating node must roll-over the key id used to generate the HMAC of the old SRH and segment…

That sould get the job done, thanks.  Further tweaks might be possible
("packets with a revoked SRH applied to them will get dropped at the
verifier", "must allocate a new key and key-id in order to roll-over the
key id", etc.), but the key points are covered.

Thanks, and sorry again for the slow response,

Ben