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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Huub,

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

On Thu, May 25, 2017 at 4:36 AM, Huub van Helvoort <[e-mail]>
wrote:

> Hello Eric,
>
> Thank you for reviewing the security aspects of our draft.
>
> Please see my response in-line [Huub]
>
> Eric Rescorla has entered the following ballot position for
>> draft-ietf-mpls-tp-shared-ring-protection-05: Discuss
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-r
>> ing-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.
>>
> [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.
>
> ----------------------------------------------------------------------
>> 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?
>>
>
> [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.


 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.
>>     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).
>>
>
> [Huub] he MUST is a requirement for the SF detection described in RFC6371
> and ITU-T G.806 .
>
> S 4.3.2.1.
>> 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.


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
>>     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?
>>
>
> [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...
>
>