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 11:34:11AM -0500, Lou Berger wrote:
> On 2/20/2019 11:07 AM, Benjamin Kaduk wrote:
> > On Wed, Feb 20, 2019 at 09:33:34AM -0500, Lou Berger wrote:
> >> On 2/19/2019 10:44 PM, Benjamin Kaduk wrote:
> >>> 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?

Well, it's not as much that I disagree about where the line is drawn, as
that I disagree with the characterization as "high level security
requirements".

The first paragraph covers topics worth including here, certainly -- an
attacker that can introduce delay can inherently break the DetNet
guarantees, and there is no further defense.  But the text could probably
go further than its current version and explicitly call out that no
technical measures can defend against such delay, other than by
rerouting/avoiding the compromised position.

The second paragraph also covers a topic worth noting, that entropy and
Murphy as as important of risks to consider as active attacks.

The rest of the section/list don't seem to match up with the high-level
view, though -- "protection of the signaling protocol", but protection
against what?  Authentication and authorization are important parts of
security, but authorization is tied to actions and entities, not just
entities in vacuo.  For "identification and shaping of DetNet flows", if
security must cover them, what security properties are needed.  Do we need
to provide integrity protection for the marking, or confidentiality
protection, too?  Does authentication/integrity need to be provided for
in-line or are out-of-band considerations in play?

The rest of the document presents a good high level picture of what pieces
will be involved in a system, and how they fit together.  I'm hoping to see
a high-level picture of what attacks/failures the architecture does and
does not aim to protect against.  It's somewhat implied that we need to
protect against the failure of any single node or link (except at the
boundary) due to random faults; explicitly saying this would be a perfect
hting to include in the security considerations here!  Once we get beyond
entropy as an attack, into more active attack scenarios, though, we need to
consider what capabilities an attacker might have.  Do we protect against
an entity with the ability to inject various forms of traffic?  Modify or
drop valid traffic?  Are there any (classes of) credentials that we assume
must be securely held, or will we attempt to protect against attackers that
have some privilege within the system?  (Note that misbehaving hardware can
sometimes present as similar or identical to such an attacker.)

Does this give a better picture of what I'm thinking of as "high-level
security requirements"?  I don't necessarily need details of specific
hardware or credentials at play, and certainly not for the solutions, but I
want to have a clear picture of what the scope of future security analysis
will be.  "How will I be able to tell if the actual protocols meet the
security requirements of the architecture?"

-Benjamin