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

Hi János,

Thanks for the new text.  These are some great things to be thinking about,
but I'm a little worried that it's just specifying mechanism without
describing the motiviations; in fact, it may even be more detailed than we
need for this document.  More inline...

On Sat, Mar 02, 2019 at 07:22:15PM +0100, János Farkas wrote:
> Hi Benjamin,
> 
> Thank you for your review!
> 
> Focusing on the main point now: Section 5 Security Considerations. We 
> could consolidate the section to address your comment. Would it be 
> helpful to replace the section with the following text?:
> 
> 
> Security considerations for DetNet are described in detail in 
> [I-D.ietf-detnet-security]. This section considers exclusively security 
> considerations which are specific to the DetNet Architecture.
> 
> Security aspects which are unique to DetNet are those whose aim is to 
> secure the specific quality of service aspects of DetNet, which are 
> primarily to deliver data flows with extremely low packet loss rates and 
> bounded end-to-end delivery latency. A DetNet is implemented using MPLS 
> and IP (including both v4 and v6) technologies, and thus inherits the 
> security properties of those technologies at both the control plane and 
> the data plane.
> 
> Security considerations for DetNet are constrained (compared to, for 
> example, the open Internet) because DetNet is defined to operate only 
> within a single administrative domain (see Section 1).  The primary 
> considerations are to secure the request and control of DetNet 
> resources, maintain confidentiality of data traversing the DetNet, and 
> provide uninterrupted availability of the DetNet quality of service.

"secure" (verb) can mean many different things in different contexts.  So
when we want to "secure" the request and control of resources, that would
presumably be something like denying unauthorized entities the ability to
use the resources, and probably also to limit the consumption of any
given entity.  This probably also means that the ability of resources
external to DetNet to disrupt the DetNet resources should be limited in
some fashion, but the exact details are still unclear to me.
Similarly, the "uninterrupted availability" is not without qualifications:
an EMP or nuclear blast may not be something in the threat model that we
need to defend against.  But if we just say "uninterrupted availability",
the reader has no way to know that.

To be clear, I'm not saying that this introductory text has to change, but
if we keep it, the follow-on paragraphs need to provide the
motivation/reasoning that is missing here.

> To secure the request and control of DetNet resources, authentication 
> and authorization must be provided for each device connected to a DetNet 
> domain, most importantly to network controller devices. Control of a 

We require authn/authz because there is/are some risk(s) that we are trying to
protect against.  What is/are that risk?

> DetNet network may be centralized or distributed (within a single 
> administrative domain). In the case of centralized control, precedent 
> for security considerations as defined for ACTN can be found in RFC8453, 
> Section 9. In the case of a distributed control protocols, DetNet 
> security is expected to be provided by the security properties of the 
> protocols in use. In any case, the result must be that manipulation of 
> administratively configurable parameters is limited to authorized entities.

Deferring on control protocol security is a fine thing to do.

> To maintain confidentiality of data traversing the DetNet, application 
> flows must be protected through whatever means is provided by the 
> underlying technology. For example, encryption may be used, such as that 
> provided by IPSec for IP (Layer 3) flows and by MACSec for Ethernet 
> (Layer 2) flows. DetNet flows are identified on a per-flow basis, which 

(I wouldn't care whether the "For example" sentence is present or not; we
aren't necessarily obligated to provide it.)

> may provide attackers with additional information about the data flows 
> (when compared to networks that do not include per-flow identification); 
> this is an inherent property of DetNet which has security implications 
> which must be considered when determining if DetNet is a suitable 
> technology for any given use case. Similar consideration may need to be 
> given to the use of replicated packet flows, which result in increased 
> surface for Reconnaissance attacks. In any case, the result must be that 
> the confidentiality of the data is maintained to a degree sufficient for 
> the use cases addressed by the given DetNet implementation.

I could consider putting this in a new paragraph.  I'd also consider
trimming it down: the key point at this level is that detnet provides a new
type of information on packets that can be used by an attacker in the
network looking at metadata.  The specific details of that could be shunted
off to the other document with no real harm.

> To provide uninterrupted availability of the DetNet quality of service, 
> provisions must be made against DOS attacks and delay attacks. To 
> protect against DOS attacks, excess traffic due to malicious or 
> malfunctioning devices must be prevented or mitigated, for example 
> through the use of traffic admission control applied at the input of a 
> DetNet domain, as described in Section 3.2.1.1, and through the fault 
> mitigation methods described in Section 3.3.2.

This is getting closer to the sort of thing I was looking for -- we need to
provide availability *in the face of DOS attacks and delay attacks*.  We
could probably say more about where the boundary is between "external"
entities that could threaten DOS and "internal" entities that we assume
behave properly -- is it the boundary of the DetNet domain, or will we
consider the risk of misbehaving/compromised equipment in the domain?

> To prevent DetNet packets from being delayed, protection must be 
> provided against Man-In-The-Middle attacks, for example through use of 
> authentication and authorization of devices within the DetNet domain.

(nit: maybe join this into the previous paragraph, since that paragraph's
topic sentence also mentions delay)
This is also pretty close to what I hoped for: it implies that we need to
keep the traffic inside our trusted elements (by avoiding the MITM), since
the MITM is untrusted and could introduce delay, but the internal elements
are trusted to not delay.  So this could be "prevent DetNet packets from
being delayed by external network entities", which implicitly disclaims an
attempt to protect against a compromised DetNet router.

> Time synchronization methods are not specified by DetNet, however any 
> time synchronization method used with DetNet must also be secured, using 
> the security methods available for the given time synchronization 
> mechanism, for example as described in [RFC7384].
> In any case, the result must be that the DetNet is protected from DOS, 
> delay, and time manipulation attacks to the extent sufficient for the 
> use cases addressed by the given DetNet implementation.

I'd consider rephrasing this more like "Because DetNet mechanisms can make
heavy use of methods that require precise time synchronization, the
accuracy, availability, and integrity of time synchronization is of
critical importance.  Extensive discussion of this topic can be found in
[RFC7384]."  We may not need the rest of the details in this document.

> DetNet use cases are known to have widely divergent security 
> requirements. The intent of this section is to provide a baseline for 
> security considerations which are common to all DetNet designs and 
> implementations, without burdening individual designs with specifics of 
> security infrastructure which may not be germane to the given use case. 
> Designers and Implementers of DetNet systems are expected to take use 
> case specific considerations into account in their DetNet designs and 
> implementations.

This is good.

-Benjamin

> 
> Regards,
> Janos
> 
> 
> 
> On 2/21/2019 9:32 PM, Lou Berger wrote:
> > 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
> >> detnet@ietf.org
> >> https://www.ietf.org/mailman/listinfo/detnet
> >>
> >
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
> 