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

[Benjamin Kaduk <[e-mail]>]

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