Hi Watson, Many thanks for the review and the comments. Right, a compromised node can make trouble not only for DetNet flows but any other MPLS traffic as well. In the draft we intend to include "exclusively security considerations which are specific to the DetNet MPLS data plane". So, we have referred to RFC5920 (Security Framework for MPLS and GMPLS Networks) in section "10. Security Considerations" and not included general MPLS security concerns and their mitigation. I hope these clarifies your comments. Thanks & Cheers Bala'zs -----Original Message----- From: Watson Ladd via Datatracker <noreply@xxxxxxxx> Sent: Sunday, August 30, 2020 12:03 AM To: secdir@xxxxxxxx Cc: last-call@xxxxxxxx; draft-ietf-detnet-mpls.all@xxxxxxxx; detnet@xxxxxxxx Subject: Secdir telechat review of draft-ietf-detnet-mpls-11 Reviewer: Watson Ladd Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is has nits. First the good parts: this document has a very well-thought Security Considerations section that describes the threats unique to this setting and makes a reference to an upcoming architecture draft. However, I found analysis of how the protocol should be deployed or configured or is designed to address those threats to be lacking in a few places. The discussion of DOS attacks is good: it says to avoid impacts on the DetNet services traffic must be policed or dropped at the edge. I would like to see a similar statement made about the consequences and mitigations for interior network corruption. It reads almost like a sentence or two was inadvertently deleted. However, if I understand the MPLS architecture correctly a compromised node can inject a label stack that results in interference with the DetNet flows, and this is quite difficult to avoid in the general case. I'm not knowledgeable in this area by any means. Perhaps it's necessary to say that all the MPLS nodes are assumed to be trusted and otherwise the DetNet services cannot be provided. I think this can be addressed pretty quickly. Sincerely, Watson Ladd -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
