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

Eric Rescorla <ekr@rtfm.com> Thu, 25 May 2017 10:05 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEF612EAA4 for <mpls@ietfa.amsl.com>; Thu, 25 May 2017 03:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c6mmik3qSqT for <mpls@ietfa.amsl.com>; Thu, 25 May 2017 03:05:15 -0700 (PDT)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4ED12EA95 for <mpls@ietf.org>; Thu, 25 May 2017 03:05:14 -0700 (PDT)
Received: by mail-yb0-x22e.google.com with SMTP id 187so45054584ybg.0 for <mpls@ietf.org>; Thu, 25 May 2017 03:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fBarIjs3qT/dz4n7KbUv5pF5+Mmizw62ZsgjsY5WFXY=; b=0Co5yMGgIHjBUCa1DYU4LuwY5ypLDRGrD4JoyuUT/HwqRvZj2bmR624unbmsilj2QL 3M9f83WWchzrYRAI+rDZZS8hlfpXnbFX8pgIifjkWWZfEXqNFURLIhF9XEMJLJ55MoWP DgAWfFw2wnpAR+Mez9XtD3M+72I2Jd+gGEvwVvR43mOKm8m6y2rQnT4gMYGerXCkjFfV O69iNqIFh79IT0jI/j3GnXFOBTLKy56a/dHtGtJ8DOdadeYg+hb10d8BpUp4G5gdz9T4 LGMuGYkBjz+E+1Xsfbgm1rHVBCKGO7jZ9aOhUiUywRf0caWPMB8QbQAxilIr+7negtQm CmKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fBarIjs3qT/dz4n7KbUv5pF5+Mmizw62ZsgjsY5WFXY=; b=VvOUVJVLrutpTBxFqeW3S/MF7gErwdnPUzL5FDMkX3fSRRz2kTWmXx4hkKKWCK5wDG N2S7M4LArgY0WJryx65z74Bh3eKHiKntal8AlzpGW+LW4AzTVFowRdF4dcT0kXFENOsl Me8/adas41IXoMcBv7mnsDJlYufbu0WLD7ihlQ7+Zi+bmQTspPjuDqe/dQg8N/uxGEHz jTQf4/Ly8vcxyYez+pf/3DtM7qfLVG45YuCWkOrPBKYdAivEjVezKItEmGHzcafmwFgZ pE0bgOCy/2pXvWYL2xjVB/c6l+fKvOQ5JnpX4PRq3YUdnNdx2GhARLjD5hOd7/ACcVQx vi8A==
X-Gm-Message-State: AODbwcAUgxsQb9AgiqpOr+eVIKAQFhxETnUZG7Hf970OJk33JMC1jM8P llhkomE2rOAW2fKvZEvXBi2zZHiDRLnn
X-Received: by 10.37.173.21 with SMTP id y21mr32197698ybi.52.1495706713123; Thu, 25 May 2017 03:05:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Thu, 25 May 2017 03:04:32 -0700 (PDT)
In-Reply-To: <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com>
References: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com> <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 25 May 2017 18:04:32 +0800
Message-ID: <CABcZeBO3Sgk8Q44g5c8FChVa5k7EZeBVYbTHWv+MaMW-pqZZOw@mail.gmail.com>
To: huubatwork@gmail.com
Cc: The IESG <iesg@ietf.org>, draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray <Eric.Gray@ericsson.com>, mpls-chairs@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="f403045db94e5309420550565bc7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/EMGlB9XpO4nLXL-5bVcOItl9um8>
Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 10:05:18 -0000

On Thu, May 25, 2017 at 5:36 PM, Huub van Helvoort <huubatwork@gmail.com>;
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...
>
>