Subject: Security Compromises and SRH

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Mar 2019 11:37:07 -0400

The SRH draft contains an HMAC TLV.
There is a justification described in the draft for why one might use 
such a HMAC.

I have a serious concern with the example.  It claims to describe a 
situation in which a host is given an SRH to use for reaching a certain 
destination, and the top-of-rack switch can check that the host is using 
the SRH properly.

Technically, it does what it says.

But if you stop and think about the problem an operator needs to solve, 
it does not match.  Let us assume that the SRH is being used for traffic 
engineering.  It is very rare that one wants to traffic engineer all the 
traffic between hosts A and B in ones network the same way.  But that is 
the only granularity this mechanism works at.  It has no means to 
enforce that the SRH is used for the right traffic.

And it is even worse than tthat.  If the destination is outside the 
domain, the TOR can only check that this SRH is valid for reaching a 
given exit from the domain, as the actual destination needs to be in the 
encapsulated packet.

It seems to me that as defined, the HMAC TLV adds complexity to the 
specification and implementation, while adding insufficient enforcement 
value to actually be useful.   If the operator trusts the host enough to 
use the SRH for the right subset of traffic, then he probably trusts the 
host enough to use the SRH for the right destinations, and to use the 
right SRH.  If the operator does not trust the hsot, then the available 
checking is insufficient.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 25 Mar 2019 08:30:13 +0000

Hi Joel, I'm glad you see no technical issue with the HMAC in the deployment model.
I do not agree with your assertion of "Security Compromises" however.

It is entirely up to a host in the use case to determine what path to steer which traffic on, and that is the way it should be.
The host is the one who knows how to steer traffic onto a segment list it has been given, it knows what applications require in this use case.  The TOR is responsible for verifying the segment list and thus paths that a host is permitted to use.  The TOR could do accounting as necessary depending on the service or paths it's verifying.

Darren

On 2019-03-15, 11:37 AM, "ipv6 on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    Yours,
    Joel
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Mar 2019 09:48:42 +0100

You assert that the host "knows how tosteer traffic onto a segment list" 
  The premise of using the HMAC is that the host is not trusted to use 
the right segment list if it were not forced to behave.  If it is not 
trusted to use the right segment list, why is it trusted to steer the 
right traffic onto that segment list?
Put differently, it is actually the network control, which provides the 
segment list, that knows what traffic the list is for.  The host does 
not "know" this.  If it does "know" this, and it is trusted to do it 
right, why is it not trusted to use the segment list it is sent without 
needing the HMAC?

Yours,
Joel