Skip to main content

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 revision 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 , Andrew G. Malis , Stewart Bryant , Jouni Korhonen
I-D 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
Request Telechat review on draft-ietf-detnet-mpls by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/lt-ZpR-zHcjUz2_XhCz2CtWftyw
Reviewed revision 11 (document currently at 13)
Result Has nits
Completed 2020-08-29
review-ietf-detnet-mpls-11-secdir-telechat-ladd-2020-08-29-00

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