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

[Lou Berger <[e-mail]>]

Hi Benjamin,

On 2/20/2019 4:21 PM, Benjamin Kaduk wrote:
> 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?"

I'll get with authors (of both the architecture and security docs) and 
see how much they think can be reasonably be added to this document -- 
to be clear you *are* asking for a change in how the WG decide to 
address this topic and what would go in which document.

Lou

> -Benjamin
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>