Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other review comments that you receive, and strive to resolve them through discussion or by updating the draft bearing in mind the consensus of the working group. Document: draft-ietf-detnet-security-10.txt Reviewer: Adrian Farrel Review Date: 2020-07-31 IETF LC End Date: Not yet scheduled Intended Status: Informational == Comments == I am not a security expert, and would hope that significant security reviews are commissioned before this document goes to IETF last call. It is really good to have such a substantial document describing security considerations for a new technology/deployment. This is really important, and I thank the authors and the working group. I believe that this document is basically ready for publication (subject to security reviews), but there are quite a few issues that should be addressed first. Best, Adrian == Medium Issues == 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. --- 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. Although "man-in-the-middle" is well established, I think you could easily avoid it and if you feel necessary you could use "An on-path attacker (formerly known as a man-in-the-middle) ..." --- 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. --- 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. --- 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) - How protection against such issues is not just a DetNet concern but applies to all routing sub-systems - What measures (outside the scope of DetNet) may be taken to protect and verify software loads (signing of software loads, etc.) 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. == Minor Issues == You make use of several terms that are not defined in this document. I suspect that they are inherited from the main DetNet work so that is not a problem, but it would be useful to have a pointer so that this document can be read with easy context. For example, "resource segmentation" and "resource slicing", but there are probably others. Resource segmentation may be particularly important to clarify as the other use of "segmentation" is in 6.3 which is possibly a different concept. Somewhere around section 2 would be a good place to add the pointer. --- I think the first paragraph of the Introduction needs a reference to RFC 8655 where term "DetNet" is introduced. --- 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. --- 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. --- 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. 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. 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. --- 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") 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). There is also the issue of insertion of packets with spurious sequence numbers to be handled. --- 3.4 Should this case also discuss the damage you can do if you can make it look like a packet violates the time window or reserved bandwidth? For example, it looks like you could make a link shut down I also wonder at your use of "Logging of such issues *may* not be adequate." Shouldn't you turn this into stronger guidance since (presumably) the DetNet component doesn't know about the applications that running are running data flows, it has to be the case that logging is never adequate. --- Should 5.2.4 specifically mention amplification? --- 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. Maybe this is 5.2.5.1? --- Would be nice if the column headings from Figure 2 part 1 were expanded somewhere. Some of the row names are also a little terse. --- 6.3.2 o add/remove end-stations to a multicast group (loss of privacy) I think that 'remove' has a different result, i.e., not loss of privacy --- Isn't 7.4 also an attack vector? --- 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. --- 8.1.4 is, perhaps, a little brief. What attacks can be achieved using this new surface? --- 8.1.6 Packets may also be dropped due to malfunctioning software or hardware. It's true. But is it anything to do with the security considerations in this document? --- 8.1.13 seems to be to be derogatory and unnecessary! There is nothing to say that an expensive implementation from a bespoke vendor will be secure, and nothing to suggest that a high-cost product from an established vendor will be well implemented. I would suggest striking this section unless you want to rewite it as "substandard implementations" pointing out that implementations that are not well made amy include vulnerabilities and other defects that risk the security of the DetNet - the mitigation remains the same. --- 8.1.12, 8.1.13, and 8.1.14 seem to have a good chunk of text in common. At best that is distracting, but it is probably a sign that you should ratoinalise the text. --- I am personally not very keen on the mention of the Mirai exploit as an example here. I think you may be kaing some assumptions about why this attack was possible, and it might be better to not enter that debate. The example does not, in any case have much of a bearing on DetNet. --- 8.1.16 has ", perhaps like the Stuxnet attack)". If you keep this, it needs a citation. But I would suggest removing it without any loss of specificity in your text. --- 8.1.16 Of the attacks we have defined, the ones identified above as relevant to "large" networks are the most relevant. I'm not sure, but I think the only mention of network size to this point was in 8.1.15. So I think you should reference that section rather than leave the reader to wonder whether they should search the document for other mentions of network size. --- 8.1.24 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.) --- 8.2 In the text you should refer to your tables by figure number for clarity as the text may be moved around in the edit process. --- The section numbers in Figure 4 seem to be all wrong. --- 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. --- 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. == Style Issues == Abstract is too long. You should aim for a maximum of 25 lines. I see 35 lines of text, and some blank lines. I would remove: It is assumed that both classes of reader are already familiar with network security best practices for the data plane technologies underlying a given DetNet implementation. Component-level considerations include isolation of data flows from each other, ingress filtering, and detection and reporting of packet arrival time violations. System-level considerations include a threat model and a taxonomy of relevant attacks, including their potential impacts and mitigations. and A given DetNet may require securing only certain aspects of DetNet performance, for example extremely low data loss rates but not necessarily bounded latency. Therefore --- Abstract as defined in the DetNet Use Cases. I suspect you are attemting to refer to RFC 8578. While you can't have citations in the Abstract, you can mention documents by name. So I would write: as defined in RFC 8578, "Deterministic Networking Use Cases". --- Section 2 has two quotes you appear to attribute to Wikipedia. Please include URL citations for these quotes. --- I don't understand the choices of subsection indentation in 5.2. --- 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. --- It seems to me that 8.1.7 and 8.1.8 are virtually identical text and you might roll them into one section. --- I'm ssurprised that you have no Normative references. Is it not necessary to understand some basic DetNet documents in order to understand this document? == Nits == Does "DetNet" mean "deterministic networking" or "deterministic network" You have both. I also found "DetNet-enabled network" --- Abstract additional security measures may be needed whose purpose is exclusively to secure the intended operation Why "exclusively"? Are we not allowed a security measure that does more than one thing? --- You have both "data plane" and "Data Plane" --- Why is "operational technology" lower case when "Information Technology" is capitlaised? (Except when you reverse this!) --- s/controller plane/control plane/ throughout --- s/The latter include threat modeling/The latter includes threat modeling/ --- Introduction (based on the Use Case Common Themes section of the DetNet Use Cases). Please include a reference to RFC 8578. --- 3. s/Each of these have/Each of these has/ --- 3.2 s/(However, is acceptable/However, it is acceptable/ s/failure)./failure. --- 3.3 has As noted in Section 7.2, Packet Sequence Number Integrity Considerations, Section 7.2 has a different name. --- 4. s/However DetNet also introduce/However DetNet also introduces/ --- 5.1 OLD (explored further in Section 5.2 (Threat Analysis) NEW (explored further in Section 5.2, Threat Analysis) END --- 5.2.4.2 An attacker can manipulate the replication-related header fields (R-TAG). Does "R-TAG" stand for "replication-related header fields"? Seems improbable. --- In figure 1 you have one "+" out of alignment |Delay attack | + | + | + | + | --- 6.3.2 o modify the DetNet flow attributes (affecting available bandwidth Missing close brace --- 7.5 Alternatively, if the payload is end-to-end encrypted at the application layer, the DetNet nodes should not have any need to inspect the payload itself, and thus the DetNet implementation can be data-agnostic. This paragraph might usefully be reworded to sort out the cause and effect implications. Something like: DetNet nodes do not have any need to inspect the payload of any DetNet packets making them data-agnostic. This means that end-to- end encryption at the application layer is an acceptable way to protect user data. --- 8.1.1 should have a citation for 802.1Qbv --- 8.1.5 "MPLS-PW" is not a well known abbreviation s/to L2,L3/to L2-L3/ --- 8.1.17 Reconnaissance could be used to characterize flows and perhaps target specific flows for attack via the controller plane as noted above. Could you give a section reference rather than "above"? --- 8.1.19 Attacks on the controller plane (as described in the Level of Service theme) and Delay and Time attacks (as described in the Bounded Latency theme) both apply here. Maybe these "themes" could be section references, or are you refering to "the themes shown in Figure 5"? --- 8.1.22 Any attack on the system, of any type, can affect its overall reliability and availability, thus in our table we have marked every attack. Can you say which table (i.e., which Figure)? --- 8.3 OLD OAM (Operations, Administration and Maintenance) NEW OAM (Operations, Administration, and Maintenance) END OLD For purposes of this discussion NEW For the purposes of this discussion END