Re: [Detnet] DetNet Security - Items for Work Session 11Sep20

["Grossman, Ethan A." <[e-mail]>]

Hi All,
Here are the resolutions (marked with "-->" ) that David, Lou and I came to for the remaining open comments on the DetNet Security draft, for review by the WG. 
In the next couple of weeks I plan to incorporate all of the changes into a new revision and republish. 
Thanks again for your help, 
Ethan.

-----Original Message-----
From: detnet <[e-mail]> On Behalf Of Grossman, Ethan A.
Sent: Tuesday, September 8, 2020 7:15 PM
To: [e-mail]; Stewart Bryant <[e-mail]>; Lou Berger <[e-mail]>; Janos Farkas <[e-mail]>; Black, David <[e-mail]>; Dr A. Paventhan <[e-mail]>
Cc: Deborah Brungard <[e-mail]>
Subject: [Detnet] DetNet Security - Items for Work Session 11Sep20

Hi All (read: anyone interested in helping resolve review comments on the DetNet Security draft), Here are the last few remaining items that are on my radar that we would like to resolve at this Friday's work session (11Sep20, 9am PDT).
If you know of any other items I may have missed, please let me know. 
Thanks,
Ethan (as Editor, DetNet Security draft)

+++++++++++++++++++++ Start ++++++++++++++++++++++++++++++++

I3) I looked for, but didn't find issues of bogus or compromised central controllers. This ranges from a node falsely representing itself as a controller so that the network nodes believe it to be authorised to instruct them (and that includes both being discovered as a controller and impersonating a real controller), to software subversion of the real controller. It might even include malicious acts by a network operator.

Much, but not all, of this is hard to protect against. Some of it can be mitigated by monitoring and logging.

--> Any compromised node that participates in the network can cause harm to the network. 
Section 5.3 summary of attacks: do we have a new attack? No. No different than a non-DetNet network. 
But where describe threats, say that compromised router, control plane node or controller can affect that particular threat. Go through section 5 and add line as appropriate. Make sure mentions controller plane also - be clear on that. 
Mitigation for compromised nodes are not impacted by the introduction of deterministic networking. The same techniques used to mitigate compromised nodes are equally applicable in the DetNet case.

--> Add to the last paragraph in sec 5 intro: 
In general, there is no difference between controller plane threats in DetNet networks vs. non-DetNet networks. 

--> In following section (5.2.2, 5.2.5.1 (5.2.6 already talks about it.  ) add: 
This threat also applies to the DetNet controller plane. 

In addition: 
--> 
Old:  
7.3. DetNet Node Authentication
 Description
Source authentication verifies the authenticity of DetNet sources,
 enabling mitigation of spoofing attacks. Note that while
 integrity protection (Section 7.2) prevents intermediate nodes
 from modifying information, authentication can provide traffic
 origin verification, i.e. to verify that each packet in a DetNet
flow is from a trusted source. Authentication may be implemented
 as part of ingress filtering, for example.

New: 
7.3. DetNet Node Authentication
 Description
Authentication verifies the identity of DetNet nodes (including DetNet Controller Plane nodes),
 enabling mitigation of spoofing attacks. Note that while
 integrity protection (Section 7.2) prevents intermediate nodes
 from modifying information, authentication (such as provided by IPsec or MACsec) can provide traffic
 origin verification, i.e. to verify that each packet in a DetNet
flow is from a trusted source. 

----------------------------
S5) I didn't understand the practicality of node authenticaiton as described in 7.3. Is this intended as a check on entry into the network (only authenticated sources can introduce traffic to the network), a check at the destiantion (only authenticated sources can send to this destination), or a per-hop check (is this traffic authenticated to be in the network? Furthermore, are the checks per packet or per flow?

There are obvious scaling and and key exchange issues involved.

--> The new text for I3 above resolves this item also. Scaling issues are dealt with in the controller plane draft; key exchange is addressed by  IPsec and MACsec. 

---

From Ben Kaduk: 

1) "security considerations for when flow aggregation is in play, namely that misbehavior from one component flow can affect sibling flows as collateral damage."

--> Flow aggregation is described in the Framework draft. 

--> At the high level, this is a "don't do that" scenario. Specifically do not aggregate flows when one flow could consume DetNet resources in a manner that could cause a security issue for other flows in the aggregate, e.g. starvation. 
Threat: Given 4 streams aggregated, you multiple resources by 4 - however if one flow uses more than its individually allocated BW, this could affect the others. Countermeasures: 2) Ingress police each flow before it is aggregated. 2) Don't aggregate flows that could do this to each other, i.e. the source of each flow must be trusted not to exceed its share of the assigned resources. 


2) "the use of HMAC without a co-located discussion of the need for key distribution "

Old: 
7.2 Integrity Protection
 Description
 An integrity protection mechanism, such as a Hash-based Message
 Authentication Code (HMAC) can be used to mitigate modification
 attacks on IP packets. Integrity protection in the controller
 plane is discussed in Section 7.6.

New: 
7.2 Integrity Protection
 Description
 An integrity protection mechanism, such as a hash-based Message
 Authentication Code (MAC) can be used to mitigate modification
 attacks on IP packets. Such MAC usage needs to be part of a security association that is established and managed by a security association protocol such as IKEv2 for IPsec security associations. Integrity protection in the controller plane is discussed in Section 7.6.


3) "having a taxonomy of threats titled "threat model"". Additional comments from Ben that were forwarded by Deborah on 27aug20:

> > I don't know of a recent document that has a dedicated/generic 
> > threat model written out.  In my opinion the model in (Section 3 of) 
> > RFC 3552 still does a reasonable job of listing out the common 
> > threats (though the language is a bit dated, and it includes some 
> > topics that are not very relevant for the detnet cases).  I agree 
> > with you that 7835 is a better fit for detnet's case than 7384 is 
> > (not least because, being concerned only with time protocols, 7384 
> > skips one or two classes of threat that are not relevant for timekeeping).
> > 
> > If I was writing a threat model for detnet, I'd probably keep the 
> > internal/external distinction but pair that with off-path/on-path, 
> > and then further characterize the specific capabilities (some of 
> > which are only possible when on-path): reading valid packets (an 
> > attacker that only does this is "passive on-path"; doing anything 
> > more makes it "active", which is not necessarily on-path), dropping 
> > valid packets, modifying initially-valid packets, injecting packets, 
> > etc.  Some of these capabilities can be combined to provide other 
> > behaviors, which may be worth considering as first-class 
> > capabilities for conveince in the threat model: delaying valid 
> > packets can be achieved by reading, dropping, and later injecting; 
> > replaying valid packets can be achieved by reading and later 
> > injecting; reordering valid packets can be achieved by reading (and storing) and injecting, etc.  RFC 7835 covers most of that but doesn't mention delay, at least.
> > 
> > (FWIW, my present thinking is that a MITM is a special-case of an 
> > active on-path attacker that is doing "connection splicing" and 
> > impersonating both parties on the connections in question.)

Also Deborah wrote: 
Recently, I helped with RFC7835, it was organized with internal/external and on-path/off-path. They used both together, so you may want to look how they defined. It may help also as it does data plane and control plane.

--> EAG/DB notes: Section 5 says based on RFC7384 (Time protocol security). Suggestion is to use RFC7835 - section 2, and rewrite our section 5 accordingly integrating both 7384 and 7835 - not simple. 


4) Re:    "The primary considerations for the data plane is to maintain integrity of data and delivery of the associated DetNet service
   traversing the DetNet network.  Application flows can be protected" - "I'd suggest leading in to this with "As for all communications protocols," to be clear that this paragraph is not trying to cover the bits that are "unique to DetNet" as much as remind the reader of general best practices."

--> This text is from Framework draft -06 Sec 5 paragraph 3 (https://tools.ietf.org/pdf/draft-ietf-detnet-data-plane-framework-06.pdf) and the requested text has already been added there (in draft -06). 

------------------------------------------
5) "This might also be a good place to note that correct operation of the PREOF functions is pretty critical, and failures there could lead to pretty catastrophic situations for the operational technology relying on them.  I don't think there are ways for an attacker to try to attack them directly, but Murphy's Law can be a pretty effective attacker, too."

EAG: This comment is about the Security section of the Framework draft.  The topic of security for PREOF is discussed in the Security draft section 3, Security Considerations for DetNet Component Design, sub-section 3.3. Redundant Path Support. An explicit statement that PREOF failures could lead to catastrophic results seems unnecessary? 

----------------------------------------------------------

6) Re:  "At the management and control level DetNet flows are identified on a
   per-flow basis, which may provide controller plane attackers with
   additional information about the data flows (when compared to
   controller planes that do not include per-flow identification).  This
   is an inherent property of DetNet which has security implications
   that should be considered when determining if DetNet is a suitable
   technology for any given use case." - "I might also note that attackers with access to the controller plan already have pretty significant attacks available to them."

--> This comment refers to text from the Framework draft -06 Sec 5 paragraph 4. (https://tools.ietf.org/pdf/draft-ietf-detnet-data-plane-framework-06.pdf)
--> EAG: I don't see a need for the requested additional text to be added to the Security draft. 


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