Telechat Review of draft-ietf-detnet-mpls-11
review-ietf-detnet-mpls-11-secdir-telechat-ladd-2020-08-29-00

Request Review of draft-ietf-detnet-mpls
Requested rev. no specific revision (document currently at 13)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2020-09-08
Requested 2020-08-25
Authors Balazs Varga, János Farkas, Lou Berger, Andy Malis, Stewart Bryant, Jouni Korhonen
Draft last updated 2020-08-29
Completed reviews Rtgdir Last Call review of -04 by Carlos Pignataro (diff)
Opsdir Last Call review of -05 by Shwetha Bhandari (diff)
Tsvart Last Call review of -05 by Michael Tüxen (diff)
Secdir Last Call review of -05 by Watson Ladd (diff)
Secdir Telechat review of -11 by Watson Ladd (diff)
Assignment Reviewer Watson Ladd 
State Completed
Review review-ietf-detnet-mpls-11-secdir-telechat-ladd-2020-08-29
Posted at https://mailarchive.ietf.org/arch/msg/secdir/lt-ZpR-zHcjUz2_XhCz2CtWftyw
Reviewed rev. 11 (document currently at 13)
Review result Has Nits
Review completed: 2020-08-29

Review
review-ietf-detnet-mpls-11-secdir-telechat-ladd-2020-08-29


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