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

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

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

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.
EAG HOLD
---


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."
2) "the use of HMAC without a co-located discussion of the need for key distribution "
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.

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

These I don't know what to do with: 

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."
Stewart commented: 
The incorrect operation of many elements of a routed network can be pretty catastrophic. An incorrectly operating routing system supporting multicast would have very similar failure modes to PREOF. So I don’t think we are dealing with anything unusual here.


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."
 
+++++++++++++++++ End ++++++++++++++++++++++++