[Detnet] DetNet Security Draft 12 Update Notes

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

Hi All,
I have addressed all of the open review comments (from Adrian Farrel and Benjamin Kaduk) into draft 12, with thanks to Stewart, David, Lou, Deborah and Janos for their insights. My notes on our discussion of each item are below, consisting of the comment and our resolution (marked with "-->"). (Disclaimer: the final draft text is not always word for word what is in my discussion notes.) 

There is one pending suggestion that I am leaving open for now: 
=============== TODO ============================
3) Comment: "having a taxonomy of threats titled "threat model"".
EAG: This is the only one we did not completely resolve. The proposal (from Deborah) is to take the current threat model format (based on RFC7384, Time Protocol Security) and merge into it the threat model of RFC7835 (Locator/ID Separation Protocol (LISP) Threat Analysis). We have made some steps in this direction by changing MITM/Injector terminology to on-path/off-path; the latter terms are used in RFC7835 and thus our model is no longer "strictly" based on RFC7384, so I added mention of RFC7835. 
We already distinguish between internal/external and data/controller plane. 
If we are going to do more re-org, we can do it starting from here. 
=================================================

Also, per Tal's suggestion I took over the first author slot, leaving Tal as second author. I also moved Andrew Hacker from Contributor to Author, since he was the first contributor of substantial text and organization which got the draft off the ground. If anyone else would like to be listed as an author going forward, please remind me of the extent of your contributions, and my apologies in advance for not having recalled that history properly. 

As always any input is welcome. 
Ethan (as Editor, DetNet Security draft)

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

OK I1) It's a security document, so I searched for the word "privacy" and found it in just two places.  Is it possible that these are the only two examples of privacy-impacting issues with DetNet?  If so, I suggest adding a section ("Privacy Considerations") where you point to these two cases and explain that there are no other privacy concerns. But, more likely, there is more you can say on the tpoic and should call out with additional text. You may find RFC 6973 to be useful.
FWIW, only 5.2.7.1/6.7 seemed immediately relevant to privacy.

--> Added new Section:
Privacy Considerations
Privacy is maintained by the base technologies specific to the DetNet and user traffic. For example TSN can use MACsec, IP can use IPsec, Applications can use IP transport protocol-provided methods e.g. TLS and DTLS.  MPLS typically uses L2/L3 VPNs combined with the previously mentioned privacy methods. 

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

OK I2) It would be nice to avoid the term "man-in-the-middle" (and coresponding
"MITM") in favour of the term "on-path attacker". It is less problematic as a term, and no less accurate.

--> Convert MITM/Injector terminology to on-path and off-path respectively. 

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

OK I2A) Section 5.1 has the terms "active" and "passive" but doesn't define them. Need to define.
--> Add definitions inline. 

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

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

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

--> Result: Added section: 


          <section title="Compromised Controller">
            <t>An attacker can subvert a controller, or enable a compromised controller to falsely
              represent itself as a controller so that the network nodes believe it to be authorized
              to instruct them. </t>
            <t>Presence of compromised nodes in a DetNet is not a "new" threat that arises as a
              result of determinism or time sensitivity; the same techniques used to prevent or
              mitigate against compromised nodes in any network are equally applicable in the DetNet
              case. However this underscores the requirement for careful system security design in a
              DetNet, given that the effects of even one bad actor on the network can be potentially
              catastrophic. </t>
            <t>Security concerns specific to any given controller plane technology used in DetNet
              will be addressed by the DetNet documents associated with that technology.</t>
          </section>

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.

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

OK I4) 8.1.2
I'm not really comfortable with your choice stated in this section to exclude attacks on the control plane from consideration. It seems to me that a network can be rendered entirely dysfunctional by attacking the control plane so that control packets are delayed, reordered, lost, or misdelivered. I don't see why you consider manipulation or inspection of control plane packets as in scope (I agree they should be in scope), but attacks on the control plane itself as out of scope. In fact, I don't see how you attack a control plane packet without attacking the control plane.

Furthermore, I don't think that this "reveal" should be tucked away in this section: the statement is not specific to the subject of this section.

EAG: I think this stems from the original charter of DetNet WG to address data plane only. Now that the WG is re-chartered to address controller plane, given that this Security draft is still in progress, it probably is time to reconsider that limitation. 

-> Remove statements that say we're not addressing controller plane - above additions should address controller plane. 
Attacks on a DetNet controller plane are identical to attacks on any other network control plane and are mitigated using the same strategies. Any future DetNet controller plane documents are expected to provide details and references specific to that document. 

---

OK I5) In general I support you not wasting any time discussing the concern of a "subverted" node within the DetNet. That is, a router that has been attacked so that it "lies" about conditions in the network, or harvests data in some way. However, this is a concern that is repeatedly expressed by the security community.

Thus, I think it is worth adding a section to describe:
- How extremely bad this situation would be for the whole DetNet (viz.
  it is a closed system in which one bad actor can immediately break the
  whole in very many bad ways)

--> Integrated into text added above. 

- How protection against such issues is not just a DetNet concern but
  applies to all routing sub-system

--> Same. 

- What measures (outside the scope of DetNet) may be taken to protect
  and verify software loads (signing of software loads, etc.)

--> This is beyond the scope of a protocol specification, and is not introduced by DetNet.  

Note that you do talk about "plug-and-play" in the context of not allowing rogue devices to be added to the network, and that is a good part of the solution, but does not approach protecting against subverted nodes.

--> Already covered above. 
--------------------------------------------
== Minor Issues ==

OK M3) I struggled a little with determining the value of section 3 given the existence of section 5. In many cases, I found that section 3 started the conversation, but left a lot of open questions about threat models that are not answered until section 5.

--> Agree this is a valid stylistic comment, however others have requested that they want this section to be present, and that they like the section, so we will leave it. 

---

OK M4) In 3.1 you have

   It is the responsibility of the component designer to ensure that
   this condition is met; this implies protection against excess traffic
   from adjacent flows, and against compromises to the resource
   allocation/deallocation process.

This is good, but I feel it dodges what measures a component designer should take to protect against attacks on / failures by other components in the network.

--> For example through the use of traffic shaping and policing. 

---

OK M5) 3.3

   responsibility of the system designer to define these relationships
   with the appropriate security considerations

The word "appropriate" should be a red flag for you. How is the reader to determine what is appropriate unless you tell them? Either include a pointer to the relevant sections of this document, or explain what would be appropriate.

--> There is nothing unique to redundant path support from an integrity perspective, therefore this paragraph will be deleted.

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

OK M6) Similarly in 5.1

   Most of the
   direct threats to DetNet are active attacks, but it is highly
   suggested that DetNet application developers take appropriate
   measures to protect the content of the DetNet flows from passive
   attacks.

-->    "Most of the direct threats to DetNet are active attacks, but it is highly suggested that DetNet application developers take appropriate measures to protect the content of the DetNet flows from passive attacks, for example through the use of TLS or DTLS."

-----------------------------
OK M7) 9.1 has
   So the network must provide sufficient
   isolation between flows, for example by protecting the forwarding
   bandwidth and related resources so that they are available to detnet
   traffic, by whatever means are appropriate for that network's data
   plane.
That's a little more excusable, but it is still a bit hard for the reader to know what to do.


-->    So the network must provide sufficient
   isolation between flows, for example by protecting the forwarding
   bandwidth and related resources so that they are available to detnet
   traffic, by whatever means are appropriate for that network's data
   plane, for example through the use of queueing mechanisms. 

---

OK M8A) 3.3
   At the data plane the implementation of PREOF depends on the correct
   assignment and interpretation of packet sequence numbers, as well as
   the actions taken based on them, such as elimination.  Thus the
   integrity of these values must be maintained by the component as they
   are assigned by the DetNet data plane's Service sub-layer, and
   transported by the Forwarding sub-layer.

Depending on the meaning of "component" (a term you use without definition in this document - although you do give "such as routers") 

--> 	Added def of term “component”: “A component of a DetNet system is used here to refer to any hardware or software element of a DetNet network which implements DetNet-specific functionality, for example all or part of a router, switch, or end system.”

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

OK M8B) I should think you have exposed an issue that is not clear to me. You seem to be saying that it is a component's responsibility to maintain the integrity of the packet sequence number values as they are transported across the network. This is at least the responsibility of a pair of adjacent components in cooperation (for example, if the packet is hashed in some way to prevent the value being tampered with). 

-->    
Old: 
At the data plane the implementation of PREOF depends on the correct assignment and
          interpretation of packet sequence numbers, as well as the actions taken based on them,
          such as elimination. Thus the integrity of these values must be maintained by the
          component as they are assigned by the DetNet Data Plane's Service sub-layer, and
          transported by the Forwarding sub-layer.
New: 
Add: 
This is no different than the integrity of the values in any header used by the DetNet (or any other) data plane, and is not unique to redundant paths. From the sequence number injection perspective, it is no different from any other protocols that use sequence numbers. 

OK M8C) There is also the issue of insertion of packets with spurious sequence numbers to be handled.
--> Modify above text: 
At the data plane the implementation of PREOF depends on the correct assignment and
          interpretation of packet sequence numbers, as well as the actions taken based on them,
          such as elimination (including elimination of packets with spurious sequence numbers)
----------

OK M11) Should 5.2.4 specifically mention amplification?
EAG: I think this is a good idea, but I will defer to WG on this. Here is what I find for a definition (https://security.radware.com/ddos-knowledge-center/ddospedia/amplification-attack/): 
Amplification Attack: An Amplification Attack is any attack where an attacker is able to use an amplification factor to multiply its power. Amplification attacks are "asymmetric", meaning that a relatively small number or low level of resources is required by an attacker to cause a significantly greater number or higher level of target resources to malfunction or fail.

--> Add bullet to 5.2.4.2 : 
* Amplification - an attacker who injects packets into a flow that is to be replicated will have their attack amplified through the replication process. This is no different than any attacker who injects packets that are delivered through multicast, broadcast, or other point-to-multi-point mechanisms. 
---

OK M12) In 5.2 I was looking for how DetNet's choice of paths is based on the recorded properties of those paths (e.g., latency, jitter, loss) and how the choice of path can be manipuated by causing short-term changes to the properties of individual links in the network.

--> This topic is not discussing manipulation of latency (Sec 5.2.1, Delay), it is about manipulation of paths. Path choice is a controller plane function, which is already covered in section 5.2.6, Controller Plane.  
so this should be included in the next section which is Controller Plane 5.2.6. 
--> So text of 5.2.5.1 is duplicative and will be removed. Text in
--> 5.2.5.2 will be moved to the end of 5.2.6.2

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

OK Mx) Shouldn't 7.7 (or somewhere else) discuss the security issues introduced by the monitoring mechanisms? For example, if the reporting mechanism is attacked or subverted, or if the monitoring system is tricked. It seems you have introduced a mechanism that can be used to detect attacks, but not acknowledged that this mechanism can, itself, be attacked giving flase positives or hiding negatives.

--> This is not unique to DetNet; it is identical to the case of any monitoring mechanism. 
--> Add: " If the monitoring or reporting mechanism is attacked or subverted, this can result in malfunction of the network. The design of the monitoring system needs to take this into account based on the specifics of the monitoring or reporting system being considered". 

---

M15) 8.1.4 is, perhaps, a little brief. What attacks can be achieved using this new surface?

--> This is no different than for any other protocol which introduces a new YANG model; there is no DetNet specific consideration here. 

---

OK M22) 8.1.24 (actually 8.1.23) 

I think the reader looks to this document to answer the qustion you pose and not simply say that it is TBD. (By the way, you would need to expand 'TBD' and say which table/figure you are referring to.)
EAG:	Yes that text is an unresolved holdover from my initial pass at these sections, which phrased them all as questions, which were eventually substituted with “answers”. We didn’t have any answers for this one, but it still is a valid question, I would say. In a way it is the same question as the “watchman” item above (M14). 

--> Rewrite section 8.1.23: 
Old: 
A DetNet network must be made secure against devices failures,  attackers, misbehaving devices, and so on. Does the threat affect  such security measures themselves, e.g. by attacking SW designed to  protect against device failure?
 This is TBD, thus there are no specific entries in the mapping table  Figure 4, however that does not imply that there could be no relevant  attacks.
New:
--> A DetNet network must be made secure against devices failures, attackers, misbehaving component, and so on. If the security mechanisms protecting the DetNet are attacked or subverted, this can result in malfunction of the network. The design of the security system itself needs to take this into account based on the specifics of the security system being considered. The general topic of protection of security mechanisms is not unique to DetNet; it is identical to the case of securing any security mechanism for any network. The text of this document addresses these concerns to the extent that they are relevant to DetNet. 

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

OK M24) The section numbers in Figure 4 seem to be all wrong.
EAG: And so it is. This is a bad implementation of a table that contains references, since it is done as “artwork” with “manual text” for the section numbers. Does anyone have a clever idea how to do this? Maybe reformat as a bullet list? 
--> Delete the Section column. 
--------------

OK M25) Figure 5 shows six themes that have no vulnerability to any attack. Is that really right? It seems remarkable enough that you might add a note to help the reader know that this is indeed what you intended the table to show, and possibly to give a reason.

--> "The row items which have no threats associated with them are included in the table for completeness of the list of Use Case Common Themes, and do not have DetNet-specific threats associated with them". 
------------------

OK M26) 8.3

   Thus OAM traffic presents no additional (i.e.  OAM-specific) DetNet security considerations.

Isn't it the case that if an attacker is able to engineer a situation where there is a massive increase in OAM traffic, this can have a negative impact on the ability of the DetNet to deliver its services.
There are three ways such an attack can have an effect:
- the OAM traffic impedes the user plane traffic (such as consuming
  bandwidth, requiring critical processing, impeding timely delivery)
- the additional OAM traffic masks other OAM traffic that reports a
  genuine network issue
- the OAM traffic clogs up the control/management plane bandwidth of
  processing so that the operator is not able to properly control the
  network

There are various ways in which an attacker can stimulate the network to generate excess OAM traffic.
Additionally, of course, fake or modified OAM can lead the management system to believe that there are faults in the network causing traffic to be rerouted onto othe paths resulting in lower levels of service or interception of traffic.
And finally, modified or filtered OAM packets may lead the system to fail to notice real network problems.

--> Rewrite paragraph: 
Old: 
"Thus OAM traffic presents no additional (i.e. OAM-specific) DetNet security considerations." 
New:
"From the perspective of an attack, OAM traffic is indistinguishable from DetNet traffic and the network needs to be secure against injection, removal, or modification of traffic of any kind, including OAM traffic. A DetNet is sensitive to any form of packet injection, removal or manipulation and in this respect DetNet OAM traffic is no different. Techniques for securing a DetNet against these threats have been discussed elsewhere in this document."

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


OK M27 (from Adrian email of 31Jul20)) I noticed in section 9 that there is discussion of the sub-layer security measures for IP and Ethernet networks, but (of course?) no mention of security for MPLS encapsulations.
In that context I wondered if Detnet has any interest in https://www.ietf.org/archive/id/draft-ietf-mpls-opportunistic-encrypt-03.txt

--> Add "New work on MPLS security may be applicable, for example [add 
--> reference to draft-ietf-mpls-opportunistic-encrypt-03.txt]

== Style Issues ==

OK S7) I'm surprised that you have no Normative references. Is it not necessary to understand some basic DetNet documents in order to understand this document?

--> Agree to put all standards track documents into normative references section (not non-normative ones). 
--> I put IP, MPLS and Architecture under Normative. 

++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++
Resolutions from second work session: 

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

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

--> Added new paragraph to Resource Allocation section: 

        <t>As an example, consider the implementation of Flow Aggregation for DetNet flows (as
          discussed in <xref target="I-D.ietf-detnet-data-plane-framework"/>) . In this example say
          there are N flows that are to be aggregated, thus the bandwidth resources of the aggregate
          flow must be sufficient to contain the sum of the bandwidth reservation for the N flows.
          However if one of those flows were to consume more than its individually allocated BW,
          this could cause starvation of the other flows. Thus simply providing the calculated
          aggregate bandwidth may not be a complete solution - the bandwidth for each individual
          flow must still be guaranteed, for example via ingress policing of each flow (i.e. before
          it is aggregated). Alternatively, if by some other means each flow to be aggregated can be
          trusted not to exceed its allocated bandwidth, the same goal can be achieved. </t>

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

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

-->  Added text for this: 
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.

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

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

OK 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. 
--> Added text to Security draft 3.3. Redundant Path Support: 
Old: 
It is the responsibility of the component designer to ensure that
          the relevant PREOF operations are executed reliably and securely.
New: 
It is the responsibility of the component designer to ensure that
          the relevant PREOF operations are executed reliably and securely, to avoid potentially
          catastrophic situations for the operational technology relying on them.

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

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.  
--> EAG: I don't see a need for the requested additional text to be added to the Security draft.
 
+++++++++++++++++ End ++++++++++++++++++++++++