[mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-mpls-tp-shared-ring-protection-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The security considerations of this document seem unacceptably
incomplete, as they basically just point to other documents.

   The RPS protocol defined in this document is carried in the G-ACh
   [RFC5586], which is a generalization of the Associated Channel
   defined in [RFC4385].  The security considerations specified in
these
   documents apply to the proposed RPS mechanism.

The security considerations of those documents don't seem that great
either. However, I believe that they miss a new security issue raised
by the mechanism in this draft, which is that a member of the ring
appears to be able to forge reports of errors at other parts of the
ring. Specifically, S 5.1.3.3 says:

   When a node is in a pass-through state, it MUST transfer the
received
   RPS Request in the same direction.

   When a node is in a pass-through state, it MUST enable the traffic
   flow on protection ring tunnels in both directions.

This seems not to involve any filtering, which suggests that node B
can send a forged SF from C->D and from D->C, which at least
potentially
temporarily breaks the link there, causing traffic diversion.

More generally, this system assumes that every node trusts every
other node completely. That must at least be stated.

Incidentally, the text above appears to contain a bug in that it
doesn't talk about processing incoming RPS requests intended for
the receiving node, but I may just have missed the section where
it says that.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 4.1.1.
   protect these LSPs that traverse the ring, a clockwise working ring
   tunnel (RcW_D) via E->F->A->B->C->D, and its anticlockwise
protection
   ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, Also,
an
   anti-clockwise working ring tunnel (RaW_D) via C->B->A->F->E->D, and
   its clockwise protection ring tunnel (RcP_D) via D->E->F->A->B->C->D

Why does the protection tunnel include D on both ends whereas the
working
tunnel does not?


S 4.2.
   packets are periodically exchanged between each pair of MEPs to
   monitor the link health.  Three consecutive lost CC packets will be
   interpreted as a link failure.

Is this a normative statement (i.e., does it need a MUST).


S 4.3.2.1.
Why do you ever not use short wrapping?


S 5.1.4.1
   A node MUST revert from pass-through state to the idle state when it
   detects NR codes incoming from both directions.  Both directions
   revert simultaneously from the pass-through state to the idle state.

incoming within what time frame?