Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

[Lou Berger <[e-mail]>]

Hi Benjamin,

     Please see below.

On 2/20/2019 11:07 AM, Benjamin Kaduk wrote:
> Hi Lou,
>
> On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote:
>> Hi Benjamin,
>>
>> I'm responding as doc shepherd (and chair). Thank you for your
>> comments.  Please see below for specific responses.
>>
>> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote:
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-detnet-architecture-11: 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-detnet-architecture/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> I note that the DETNET WG is explicitly chartered with a work item for the
>>> "overall architecture: This work encompasses ... and security aspects".
>>> It seems incomplete to specify an architecture for a topic such as
>>> deterministic networking without specifically considering what threats are
>>> and are not in scope to be protected against.
>> The working group certainly recognizes that security is an important
>> topic and necessary part of the work. The WG's  approach to ensure that
>> this significant topic is sufficiently covered is to have a  document
>> dedicated to the topic.  As you note below this work,
>> draft-ietf-detnet-security, is not at the same level maturity - so
>> please stay tuned.  Of course, the WG would welcome any input on this
>> security draft now or even a full early-review or security area advisor.
> I do appreciate that the WG has taken the time to work on a dedicated
> security document, that goes through the (tedious!) effort to tabulate the
> various known attacker capabilities, threats, and their interactions.
>
> What I think is missing from the high-level architecture document is a
> sense for what security goals the architecture intends to achieve.  It's
> fine to have this be separate from the nitty-gritty stuff in the separate
> document, but these high-level questions can have an impact on the
> high-level design of the protocol ecosystem as a whole.  We have mounds of
> examples of "come up with a design; bolt security on as an afterthought"
> working poorly or being nigh-impossible, and I haven't seen any attempt at
> justification for why doing so here is likely to be any different.
> Including the security concepts from the start and wholly integrating them
> into the system tends to produce a much more elegant design and smoother
> outcomes all around.

We went back and forth on how much of the security topic to include in 
the architecture document and settled on the current text of section 5 
where just high level security requirements are identified.  From your 
list below, the architecture covers the points you raise (non-detnet 
traffic impacting detnet traffic, and detnet traffic trying to use more 
than its allocation) mainly from a service delivery perspective.  It 
does mention "shaping" as a security concern, the document could expand 
these if helpful. But I think the real discussion point is how much of 
the security details should be in the base (vs dedicated) document  -- 
and that you disagree with where the WG has drawn the line.  Is this 
correct?

Thanks,

Lou


>> (We have one from the transport area.)
>>
>>> Some easy questions should
>>> be whether the system is expected to be robust in the face of an attacker
>>> that generates non-DetNet traffic?  Or an attacker that generates DetNet
>>> traffic in excess of reservations?  It can even be a fine engineering goal
>>> to produce a solution that only protects against media corruption and
>>> hardware crashes and leaves active attacks out of scope, but the actual
>>> intended scope of the work needs to be clear.  At the other end of the
>>> spectrum, protecting against as potent an attacker as a malicious traffic
>>> policer is probably a lost cause, especially if the policer is authorized
>>> to direct remote nodes to take action to terminate "misbehaving" flows.
>>> The referenced draft-ietf-detnet-security is not at a comparable maturity
>>> level to this document and also fails to present a clear threat model for
>>> the DetNet architecture.  (The section entitled "Threat Model" reads as
>>> more of a taxonomy of threats than a model for what threats are and are not
>>> to be addressed.)  It also presents the usage of cryptographic mechanisms
>>> as mitigation techniques without provisioning for the prerequisties of such
>>> mechanisms (e.g., using HMAC for message integrity protection without
>>> mention of infrastructure for distributing the keys for keying the HMAC).
>>>
>> These are all great input for draft-ietf-detnet-security - I'll touch
>> with authors to ensure that they are aware of your comments.
> I noticed a few other things of note while skimming; I'll try to send those
> over as well.
>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> I agree with Alexey that Informational would (also) be a fine status in
>>> which to publish this document.
>> I defer to the IESG and our AD.
>>
>> I think the authors can address/respond to the remaining comments.
> Sounds good.
>
> -Benjamin
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>