Last Call Review of draft-ietf-mpls-rmr-12
review-ietf-mpls-rmr-12-secdir-lc-atkins-2019-11-07-00

Hi,

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 with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary:

* Ready to publish from a security analysis PoV, but I think this
  document Needs work.

Details:

* I feel that the issue of malicious code claiming a noce to be a Ring
  Master should be duplicated in the Security Considerations section.
  Specifically, a malicious node can bring down a ring.

* I am wondering if the authors have looked at Radia Perlman's
  Spanning Tree Protocol when looking to detect loops/rings?  The main
  difference I can see is that in STP the goal is to find and
  eliminate loops, whereas here the goal is to leverage loops for
  resiliancy.  (NB: STP should also leverage loops for resliancy if a
  link goes down).  If nothing else, STP should be referenced as an
  informational reference.

* How does this protocol handle nodes with more than 2 links?  For
  example, let's assume you have two rings that overlap by 2 nodes.
  For example:

                                R0 . . . R1
                              .             .
                           R7                 R2
              Anti-     |  .        Ring       .  |
              Clockwise |  .                   .  | Clockwise
                        v  .      RID = 17     .  v
                           R6                 R3
                              .             .
                                R5 . . . R4
                              .             .
                           R13                R8
              Anti-     |  .        Ring       .  |
              Clockwise |  .                   .  | Clockwise
                        v  .      RID = 18?    .  v
                           R12                R9
                              .             .
                                R11. . . R10

 When R4 sends messages to R3 and R8, how are R3 and R8 supposed to
 know that they are in different rings?  All I can imagine is that
 this only works if both R4 and R5 are specifically (and manually)
 configured, because I don't see how the promiscous mode discovery
 protocol described here would work.

 I feel the protocol, as described, is missing something.  Perhaps the
 issue is that a node needs to hear the same RID from neighbors on two
 different links to know that it is a part of a ring.  Also, it needs
 to ensure it never "sends back" a message.  What I mean is that,
 assume R4 sends R8 a TLV saying R18/CW.  R8 can then forward R18/CW
 to R9, but should not send (yet) R18/AC back to R4.  Similarly, R5
 sends to R13 R18/AC.  Only once the two sets of announcements make
 their way around does the ring "form".  At least, intuitively, I feel
 that's how it *should* work, but I don't feel this document actually
 captures this.

-derek
-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant