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

[Lou Berger <[e-mail]>]

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

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

...

Thanks,

Lou