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

[Eric Rescorla <[e-mail]>]

On Thu, May 25, 2017 at 5:36 PM, 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.
>

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.


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.


Loss of traffic is not the only kind of attack.


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


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

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


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


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

It seems like the document should specify this.

-Ekr


>
> Best regards, Huub.
>
>
> --
> ================================================================
> Always remember that you are unique...just like everyone else...
>
>