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

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

Hi Benjamin,

We believe that we have addressed your comments in the most recent 
revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. 
(https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)

Please let us know what else you would like to see done before you clear 
your DISCUSS.

I/we would be happy to meet with you this week if there is anything you 
would like to discuss.

Regards,
Janos


On 3/5/2019 10:40 PM, János Farkas wrote:
> 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