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

[Benjamin Kaduk <[e-mail]>]

Hi Ethan,

On Mon, Feb 25, 2019 at 06:31:16AM +0000, Grossman, Ethan A. wrote:
> Hi Benjamin,
> As editor and co-author of the DetNet Security draft, I thank you very much for your comments regarding the security aspects of the DetNet Architecture and Security draft. Indeed it is our intent to ensure that security is considered throughout the design process and not "bolted on" at the end; this is why we have been developing the Security draft in parallel with the Architecture, Data Plane and other drafts.  Here are a couple of my initial thoughts on your comments; I present them for discussion, not as a defense of a pre-determined outcome. 

Understood.

> I follow your concern that we have not made a distinction between the laundry list of possible threats versus those threats that designs based on the architecture must address in order to satisfy the security requirements of the architecture. Excellent point, in that I for one have not considered the topic in that light before, and I appreciate the need to do so now. 
> 
> Up until this point, i.e. prior to your comments, we have been working
> based on at least two guiding principles. One is that we are only
> addressing security considerations which are specific to time-sensitive,
> routed, centrally-administered networks, so anything that could be
> considered to be "covered elsewhere" we have intentionally omitted. For
> example you cite "using HMAC for message integrity protection without
> mention of infrastructure for distributing the keys for keying the HMAC";
> I would expect that this topic could be regarded as "covered elsewhere",
> but please correct me if I'm missing something here. 

I think it's fine to say that DetNet only needs to provide solutions for
addressing security considerations that are specific to these
time-sensitive networks, but that doesn't necessarily mean that we can
completely ignore the more mundane "generic" considerations.  That is, we
can and should still be aware of what security properties we expect of the
traffic flowing through detnet installations, and choose the other
technologies that are used to build solutions accordingly.  As a complete
example, not necessarily even relevant to detnet, we can say that if we
want confidentiality protection for IP traffic, IPsec is an option, but we
also would need to know that to actually use IPsec we'd either need to pull
in IKE or have pre-established shared keys to use.  Similarly for HMAC to
provide integrity protection -- the underlying technology and its usage is
well-understood, but comes with the caveat that the participants need some
way to share the secret keys it uses.  The idea is not necessarily to say
that detnet must specify a single way of doing things, but rather to be
clear about what it does (and does not!) require, and to have pointers for
how a solution *could* be built using existing technologies, without
requiring it to be done in that way.

> Another main thread running through almost every aspect of DetNet is that as noted in the Use Cases draft, there are many and diverse applications for DetNet, spanning networks contained within a single machine all the way through networks spanning a nation. As such it is difficult to make generalizations about almost anything in DetNet - everything has to be framed as "scalable" so that we don't mandate something that makes sense for one use case but not for another. 
> 
> So the intent of the Security draft (in conjunction with security text in the other DetNet drafts) thus far has been to provide some insights into the aspects of security that are introduced with time-sensitivity to routed networks, with a nod as to how they might be addressed, while being almost completely non-prescriptive about it, leaving the details as an exercise for the reader based on their particular use case. 
> 
> In other words, as soon as we say "a DetNet must include [any specific security property]", someone will inevitably come up with a use case for which that didn't make sense (insufficient time, insufficient CPU cycles, not required in this case because blah, etc.) For example when I look at your questions like "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?" my thought would be to say "well it depends on the use case, i.e. the specific implementation". 

In a similar vein to what I note above, I think that at the architectural
level the questions we want to ask are things like "does the architecture
need to support use cases where the deterministic traffic is given
confidentiality protection by the network?"  We don't need to require that
it be used, and potentially not even require that every instantiation of
the architecture have the ability to provide it (though for confidentiality
protection in particular that will definitely be a discussion to have), but
we establish it as something that we need to think about in the protocol
design.  The flip side of this, of course, is that we also have the ability
to explicitly disclaim responsibility for some types of protection, and not
have to worry about that in the protocol design, thus leaving any
protections for that threat to be at a different layer.

> So at this point I don't know whether this stance is valid, or whether it is an abdication of our responsibility, or whether there are some stakes in the ground that we can actually claim will fit all use cases, and thus we should be stating as mandatory. Certainly we would like to avoid the outcome that the architecture leaves open questions as to whether a given implementation satisfies its security requirements. We also want to avoid being overly prescriptive such that "exceptions" would need to be made to accommodate diverse use cases. 

At this point I'm not necessarily looking for hard security requirements,
but rather a requirement for things that we include in the security
analysis of the system.  The answer may well be that (e.g.) it's hard to
defend against an attacker that can delay packets, so all we can do is
document the threat and move on; there could be other cases where a
technical defense is possible, but expensive, so we can provide an optional
mechanism and document the tradeoffs, so that individual use cases can make
their own decisions.

Hope this helps,

Benjamin

> Please let us know how this line of thinking affects your assessment of our situation, if at all. My short term goal here is to unblock publication of the Architecture draft, but not at the expense of adequate coverage and integration of security. 
> 
> Thanks again for your review, 
> Sincerely,
> Ethan (as editor and co-author of the DetNet Security draft and the DetNet Use Cases draft). 
> 
> 
> -----Original Message-----
> From: detnet <[e-mail]> On Behalf Of Lou Berger
> Sent: Thursday, February 21, 2019 12:32 PM
> To: Benjamin Kaduk <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]
> Subject: Re: [Detnet] Benjamin Kaduk's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
> 
> 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
> >
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet