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

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 May 2017 23:21:32 -0700

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?

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 25 May 2017 11:36:07 +0200

Hello Eric,

Thank you for reviewing the security aspects of our draft.

Please see my response in-line [Huub]

> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/
[Huub] your discuss is applicable to any OAM protocol where an
intermediate node can forge false OAM messages and affect traffic.

Regarding this draft, a forged SF may cause a protection switch if
the protocol does not detect a failure of protocol caused by a wrong
sequence or illegal combination of received RPS messages from the
clock-wise and the anti-clock-wise direction in the ring.
The protection switch itself will not cause a loss of traffic.

[Huub] the working ring tunnel should not be a closed loop. the
protection ring tunnel is closed until a protection switch is activated,
at that time the protection ring tunnel is opened at the appropriate
location to transport the protected traffic.

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

[Huub] he MUST is a requirement for the SF detection described in RFC6371
and ITU-T G.806 .

> Why do you ever not use short wrapping?

[Huub] wrapping is a mechanism that can be used in case an LSP is dropped
in several nodes (p-2-mp application).
Short wrapping can be used only in p-2-p application.

> incoming within what time frame?

[Huub] this time depends on the propagation delay in the ring and the
RPS processing time in each node.
Because of the 50 ms switching objective a 100 ms timer could be used.

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 May 2017 18:04:32 +0800

> intermediate node can forge false OAM messages and affect traffic.

OK, but it's the job of the Security Considerations section to document
this stuff. I'd also ask why you don't specify filtering, which would
prevent at least this form of attack.

> The protection switch itself will not cause a loss of traffic.

Loss of traffic is not the only kind of attack.

> location to transport the protected traffic.

Can you point me to the section of the document where I can read more
about this?

> [Huub] he MUST is a requirement for the SF detection described in RFC6371

OK, so my question is whether you need to add a MUST here.

S 5.1.4.1
> Because of the 50 ms switching objective a 100 ms timer could be used.

It seems like the document should specify this.

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 08:06:14 -0500

Hi, Huub,

I'm replying in the thread on Eric's Discuss, but only because his Comments
are related to my ballot position.

> location to transport the protected traffic.

 The response you provided to Eric made this much clearer to me. It might
very well be helpful to include in the document.

S 4.2.
> Short wrapping can be used only in p-2-p application.

You and I, and Alvaro in his Comment, are already talking about guidance in
choosing between the protection mechanisms in the thread on my Discuss, but
this looks like a FABulous factoid to include in that guidance :D

Spencer

S 5.1.4.1