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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> wrote:
> >>>> 
> >>>> 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.)
> >> 
> >> 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?

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

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

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

Thanks, and sorry again for the slow response,

Ben