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

[János Farkas <[e-mail]>]

Hi Benjamin,

I'm glad that we are progressing. :-)
Thank you!

Please see in-line.

On 3/4/2019 4:25 AM, Benjamin Kaduk wrote:
> 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.
"secure is not the right word in this sentence. I suggest to replace it 
with "provide" to get:

           Security aspects which are unique to DetNet are those whose 
aim is to
           provide 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.


> 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.
"uninterrupted availability" is not a good phrase here, can be confused 
with zero loss.
Suggest to replace "uninterrupted availability" with "the" to get:

           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 the availability of the DetNet quality of service.

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

What we want to prevent is having unauthorized device placed within a 
DetNet domain, or attached to the DetNet domain; or unauthorized person 
accessing DetNet domain. This helps preventing some of the attacks, 
e.g., man-in-the-middle, diverging the routes of DetNet flows.

>
>> 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.)
I think the examples are useful to make it clearer what is meant.

>
>> 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.
OK, make it a new paragraph.

A shorter version:

OLD:
           DetNet flows are identified on a per-flow basis, which 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.

NEW:
           DetNet flows are identified on a per-flow basis, which 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 should be considered when determining if 
DetNet is
           a suitable technology for any given use case.

>
>> 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)
OK to merge it.

> 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.
I like your proposal.
to make it clear that external is relative to the DetNet domain, I 
suggest to have:
"To prevent DetNet packets from being delayed by an entity external to a 
DetNet domain, "

Got another comment suggesting not to use "protection" here. With that 
the suggested new text:

                                                                "To 
prevent DetNet packets from
           being delayed by an entity external to a DetNet domain, DetNet
           technology definition must allow for the mitigation of
           Man-In-The-Middle attacks, for example through use of
           authentication and authorization of devices within the DetNet 
domain."

>
>> 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.
I like your proposal.

I suggest to replace

OLD:
"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]."

with:

NEW:
           Because DetNet mechanisms or applications that rely on DetNet 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].

That is, I suggest to add "or applications that rely on DetNet" to the 
text you proposed.
I suggest to capture that time synchronization can be important to the 
application running on an end system. There may be cases when a 
particular DetNet deployment does not rely on time synchronization, but 
it is still needed for an application.

Based on your proposal delete:
"          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."


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

We've got a few more comments. The main one is to remove "must" from the 
security section because the use of security mechanisms is a deployment 
choice, not that of the IETF.

A diff is attached to show the changes described above.

Thank you,
Janos