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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 1 Oct 2019 13:12:20 +0000

Hi Ben, this thread is for closure of your comments (Discuss items handled separately).

> On Sep 3, 2019, at 10:52 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6man-segment-routing-header-22: Discuss
> 
> ----------------------------------------------------------------------
> 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”.

Will do

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

That is not defined in this document, and as such a segment may define its use of Tag.  A source may set it for use by the segments it places in the SRH.

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

I believe section 7.5 "Applicability of AH” covers this.

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

Yes exhaustive

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

Will fix

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

Thanks, lets replace that text as follows
<NEW>
  Type: An 8 bit value from Segment Routing Header TLVs Register TBD IANA Reference.  Unrecognized Types MUST be ignored on receipt.
  Length: The length of the Variable length data in bytes.
</NEW>

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

Added the work entries
<NEW>
  Type Length Value (TLV) entries contain OPTIONAL information that may be use
  by the node identified in the Destination Address (DA) of the packet.
</NEW>

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

Added (bit0)
<NEW>
  The highest-order bit of the TLV type (bit 0) specifies whether or not the
  TLV data of that type can change en route to the packet's final
  destination:
</NEW>

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

<DELETE>
     Padding TLVs are used for alignment.
</DELETE>

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

Replacing the offending sentence.

<NEW>
A Pad1 TLV MUST NOT be used if more than one consecutive byte of padding is required.
</NEW>

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

Ack, s/semantics/semantic/

> 
> 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 RESERVED bits are for future expansion if necessary (eg. D bit added)

I’ll see if we can make this variable length... others have mentioned the same,  it seems a good observation.

The 32bit KEY ID is based on the 32 bit SPI in ESP/AH.
ESP SPI is destination scoped, 32 seemed like a good precedent.
As discussed separately the KEY ID would be SR Domain scoped.
With ESP there are seldom/ever millions of connections to a single endpoint.
Given this is 32bit still overkill?

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

ACK, we’ll replace with 
<NEW>
  The HMAC TLV is used to verify that the SRH 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 authorized for use.
</NEW>

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

Lowest order as in an array of bytes octet[0] is lowest order.

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

replace that sentence with 
<NEW>
  If HMAC verification is successful processing proceeds as normal.
</NEW>

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

I see no value in this text.. Others have questioned it too. 
It is likely a security issue – if I support key ID 0 in code I may just
authenticate the SRH with key id 0 and continue processing.

<DELETE>
and except that a value of 0 means that there is no HMAC field.
</DELETE>

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

Closed with global scope key ID.

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

Infact we do mean an IPv6 packet.  An SRH is not required

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

ACK replacing with your text

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

replace that text with the following:
<NEW>
TLVs (including HMAC) may be set according to their specifications.
</NEW>

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

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

The term SID has been used the document to represent the behavior or the value. 
In this context the behavior is being discussed.
I believe the current text says what is needed quite plainly.

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

Both are normative.

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

ACK

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

ACK

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

The sub bullet is correctly scoped.

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

when adding an extension header to an IPv6 header chain the next header field must be set correctly This is covered by RFC8200 so I think is clear to an implementor.

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

Closed with scope of KEY ID.

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

“Correct” as in the destination address of the socket associated with the TCP, UDP, IP tunnel session/instance.
I think the following clarifications in the text will help.

<OLD>
   For the source of an invoking packet to process the ICMP error
   message, the correct destination address must be determined.  The
   following logic is used to determine the destination address for use
   by protocol error handlers.

   o  Walk all extension headers of the invoking IPv6 packet to the
      routing extension header preceding the upper layer header.

      *  If routing header is type 4 (SRH)

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

   ICMP errors are then processed by upper layer transports as defined
   in [RFC4443].
</OLD>
<NEW>
   For the source of an invoking packet to process the ICMP error
   message, the ultimate destination address of the IPv6 header may
   be required. The
   following logic is used to determine the destination address for use
   by protocol error handlers.

   o  Walk all extension headers of the invoking IPv6 packet to the
      routing extension header preceding the upper layer header.
      *  If routing header is type TBD IANA (SRH)
         +  The SID at Segment List[0] may be used as the destination address of
            the invoking packet.
   ICMP errors are then processed by upper layer transports as defined
   in [RFC4443].
</NEW>

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

draft-ietf-spring-network-programming defines other SID behaviors that can be used for multi-domain deployments, including the binding SID.
RFC8402 describes how multiple domains can share segments using global and local blocks, similar strategies can be defined for SRv6.

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

So far it has not...

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

Lets fix with..
s/is secured/implements ingress filtering/

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

Adding the phrase “without SRH” below.
<NEW>
   If the SR Policy contains only one segment (the egress router 4), the
   ingress Router 3 encapsulates P3 into an outer header (A3, S4) without SRH.  The
   packet is…
</NEW>

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

Lets remove the confusion and delete that text.  It is incorrect to call them “non SR source nodes”.
s/to non SR source nodes//

> 
> 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"…

Correct, it could be replaced with apply. s/add/apply/

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

I think you mean s/The HMAC key/The HMAC key ID and key associated with the HMAC TLV/. 
Node 5 is in fact the verifying node so it does need the key.

> 
>   Node 8 originates packets with the received SRH with HMAC TLV.
> 
> nit: I suggest s/with HMAC TLV/including HMAC TLV/

ACK

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

This section says “bandwidth exhaustion” for example is mountable from within the domain.  This covers that attack.
 
> 
> 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/.

ACK.

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

The latter, no statement.

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

It looks like we’ll change this to IETF review as per other comments, so this will be removed. However a pointer is all that was needed.

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

OK

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Oct 2019 11:21:25 -0700

On Tue, Oct 01, 2019 at 12:58:08PM +0000, Darren Dukes (ddukes) wrote:
>    Thanks Ben, I think we may be able to close these discuss items.  Please
>    see inline.
> 
>      On Sep 20, 2019, at 4:47 PM, Benjamin Kaduk <[email-masked]> wrote:
>      Hi Darren,
> 
>      I was also delayed, unfortunately.
> 
>      On Thu, Sep 12, 2019 at 07:35:39PM +0000, Darren Dukes (ddukes) wrote:
> 
>        Hi Ben, I got delayed replying, please see inline.
> 
>          On Sep 5, 2019, at 5:03 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
>          On Thu, Sep 05, 2019 at 01:52:41PM +0000, Darren Dukes (ddukes)
>          wrote:
> 
>            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.
> 
>          Sure, thanks for the preliminary thoughts. (inline)
> 
>              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
> 
>                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.)
> 
>            I'll give this some thought.
> 
>        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.
> 
>      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.  Perhaps we
>        could limit the `local configuration' by stating "potentially
>        indicates whether destination address is included in the HMAC".
> 
>      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?
> 
>    I suggest new text in 2.1.2 to resolve this and the other concerns with
>    the paragraph you quoted.
>    I like your suggestion to modify the process of verifying HMAC vs using
>    local configuration.
>    I think we can take the looseness out of the definition now by protecting
>    the RESERVED bits with the HMAC and allowing further innovation in those
>    bits at a future date if useful.
>    Let's change that text as follows.
> 
>    Section 2.1.2
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      Type     |     Length    |D|        RESERVED             |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                      HMAC Key ID (4 octets)                   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                              //
>       |                      HMAC (32 octets)                        //
>       |                                                              //
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    <NEW> 
>         * D: 1 indicates the Destination Address verification is disabled due
>    to reduced segment list.
>    </NEW>
>     
>    Section 2.1.2.1 HMAC Generation and Verification
>     
>    Local configuration determines when to check for an HMAC.

nit: just "check for" could read as "an HMAC is present", with no position
on validating that it's the correct HMAC value.

>    <DELETE>. 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.
>    </DELETE>
>     
>    ...
>    The HMAC verification begins by checking the current segment is equal
>    to the destination address of the IPv6 header.
>    <NEW>  
>      i.e.  the check is successful when either:
>    - HMAC D bit is 1 and Segments Left is greater than Last Entry.
>    - HMAC Segments Left is less than or equal to Last Entry and destination
>    address is equal to Segment List [Segments Left].
>    </NEW>
>    ...
>       o  Text: a concatenation of the following fields from the IPv6 header
>    and the SRH, as it would be received at the node verifying the HMAC:
> 
>          *  IPv6 header: source address (16 octets) 
>          *  SRH: Last Entry (1 octet)
>          *  SRH: Flags (1 octet)
>    <NEW>
>          *  SHR: HMAC 16 bits following Length (2 octets)
>    </NEW>

I think that looks good.
Remind me if we talked about why the SRH "Tag" can't be included?

>          *  SRH: HMAC Key-id (4 octets)
>          *  SRH: all addresses in the Segment List (variable octets)
> 
>                (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.)
> 
>            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?
> 
>        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."
> 
>      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.
> 
>    Indeed, lets step back.
> 
>    This host/application, directly connected to the SR domain, can send
>    traffic to destinations within the SR domain and the domain trusts that
>    the source owns the source address it uses.
>    When the host/application cannot be fully trusted to use its assigned
>    address(es) BCP 84 defines methods to verify it uses only the source
>    address(es) it is permitted to use.
>    Strict RPF being the most relevant to this case.
> 
>    Now we come to ensuring the source node, with its permitted source
>    addresses, use only the SRH provided to it by the SR domain.
>    This is where the HMAC comes into play.
> 
>    I suggest the following modification to the last paragraph in section
>    2.1.2:
> 
>    "The HMAC TLV is used to verify the source address of a packet

(I think "address" in "source address" is also <NEW>, and an important,
good, change.)

>     is permitted to use the current segment in the destination address
>     of the packet and ensure the segment list is not modified in transit.
>    <NEW>
>     The SR Domain ensures the source node is permitted to use the source
>     address in the packet via ingress filtering mechanisms as defined in 
>     BCP84, or other strategies as appropriate.
>    </NEW>

That looks good, thanks.

>            Packet payload can be protected by ESP.
> 
>                (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).
> 
>            As mentioned above, the HMAC is present to validate the SRH.  
>            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.
> 
>        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.
> 
>      That seems like a reasonable approach.
> 
>                (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.
> 
>            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 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.
> 
>    OK, let me step back here too.  I see three choices for Key ID scope:
>    1 - Destination Address
>    2 - Source Address
>    3 - SR domain
> 
>    We know 1 is no good as you've mentioned.
> 
>    If we choose 2, and explicitly pair key ids to sources we may eliminate
>    some usecases where groups of sources are permitted to use a specific key
>    ID and segment list.
> 
>    Therefore, Key IDs should be SR domain scoped (3), but may be assigned by
>    the key management protocol for specific sources or sets of sources to
>    use.

I agree.

>    The following change should add clarity in section 2.1.2.2 :
>    <OLD>
> 
>     the destination address with the Key ID allows for overlapping key
>     IDs amongst different HMAC verification nodes.  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.
> 
>    </OLD>
>    <NEW>
>       At the HMAC TLV generating and verification node the Key ID uniquely
>    identifies the
>       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.
>    </NEW>

I think that works, though I'm not sure I see a case where the SRH fields
(used as HMAC input) would differ from source node to verification node.
(To be clear: this text is clear about what needs to be done, so I don't
have a problem with it; I just don't know whether the extra flexibility is
likely to ever be needed.)

>                (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.
> 
>            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!
> 
>        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>
> 
>      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.
> 
>    OK, I think this is better and includes the tweaks too.
>    <NEW>
>    The HMAC TLV generating node may need to revoke an SRH it previously
>    generated
>    an HMAC for. Revocation is achieved by allocating a new key and key ID,
>    then rolling over 
>    the key ID associated with the SRH to be revoked. The HMAC TLV verifying
>    node drops 
>    packets with the revoked SRH.
>    </NEW>
>    Thanks
>      Darren

Yup, it looks like we're in good shape.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Oct 2019 11:46:27 -0700

> Hi Ben, this thread is for closure of your comments (Discuss items handled separately).

Comments only when I have something other than "looks good" or "I agree" to
say...

> I believe section 7.5 "Applicability of AH” covers this.

I think I wrote this while I still misunderstood how the setup worked, so I
agree.

> > other limitations possible?

I can't decide whether it's worth saying that explicitly ("MUST process all
other variations") or not.

>   Type Length Value (TLV) entries contain OPTIONAL information that may be use

nit: s/use/used/

> Given this is 32bit still overkill?

Given that it's domain-scoped, I no longer think 32bit is overkill.

> The sub bullet is correctly scoped.

The sub-bullet list is introduced as "with the following logic"; what
"logic" is being described here?

> RFC8402 describes how multiple domains can share segments using global and local blocks, similar strategies can be defined for SRv6.

Thanks for the pointers!

> Node 5 is in fact the verifying node so it does need the key.

I agree that I was confused about this; sorry about that.

Thanks!

-Ben