Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)
Huub van Helvoort <huubatwork@gmail.com> Thu, 25 May 2017 09:36 UTC
Return-Path: <huubatwork@gmail.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 18E271201FA; Thu, 25 May 2017 02:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ms8NhTkWAv1l; Thu, 25 May 2017 02:36:11 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 AE5AC12EA6A; Thu, 25 May 2017 02:36:10 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id g15so32011397wmc.2; Thu, 25 May 2017 02:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:references:to:cc:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OAkvKCokLPEXiIKbSrqlOl2i7559zD/IV9KIZPKy9nw=; b=Mbs14JncRnenQggnDyNSU2aGi83Gg0rc9KG0QS7S03UsR+thH4nkk1DAduJUvADsCc IfvuUwo4GfaLx1lDRvhLB1vHvH3qkRFcoW64rIDwksk/FVBCO8m1lKsbY/QqkhuXd1Ng 0v9mCk2Tg+U/Gv/3iFxcnFII7e/QvX+ksB+lT+3BEYKPBCTNnpQ5JbzbsGQve3iM94MT trZEl4dhFeiLtKhudn0WkbgNi34zXq4bG5102K93BLIdkDElkTjnHTKGSSeiGbKUoQ+u t9rL8nRoV3ILF4c5lqT1lRIZAWkk9e7wcQBdDmGsdhj6thUqBtRRZw9m+0G+9q8+74iA MikA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=OAkvKCokLPEXiIKbSrqlOl2i7559zD/IV9KIZPKy9nw=; b=pm07igrI5YdpyqIEwZhYUAP/xg/ABo35Yr39g8OFgVTfDxkrf7OcP1GGOpksWs34K9 kWgo0PO7oVgMzedpI2HtxHM8dvdwNqg+DJBAPQfyo9Gn8Td8ZPyKNBIa3pnTXMFuJpbW 5NPUIUCr3wplTfkBh6j7ksjTG3+06bKoDbmq8a4gM+VC8PrlXIeYBIyFW0cYNAzsbFKs s7l3O0RTfXstXn432QoM41FIO7y2TkwmeAh91U/jM9111aH6a+Reza62OmciqbRd7j9Q y/VxGDPZciecYGXl5JlD5YnkQ7HfFNehUDwWQYNXxsNeOh6y8lIIvDSsZgToTVUyoIO4 th8w==
X-Gm-Message-State: AODbwcB1vdU+OajwHMdHjf5SvPr4z/T9g/5qa4ghkLLHI++gl45/iSb2 rqpz/H0izteRyQ==
X-Received: by 10.80.169.42 with SMTP id l39mr29330893edc.105.1495704969197; Thu, 25 May 2017 02:36:09 -0700 (PDT)
Received: from McAsterix.local ([92.109.37.136]) by smtp.gmail.com with ESMTPSA id t55sm2408745edd.23.2017.05.25.02.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 02:36:08 -0700 (PDT)
Reply-To: huubatwork@gmail.com
References: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-tp-shared-ring-protection@ietf.org, Eric Gray <Eric.Gray@Ericsson.com>, mpls-chairs@ietf.org, mpls@ietf.org
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <71a35d11-69b4-6f77-350d-92b99f7f1fda@gmail.com>
Date: Thu, 25 May 2017 11:36:07 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <149560689201.28401.2592268750185030462.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Ua9JOUbnnY8GWgi_UmclIYaBl3s>
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 09:36:13 -0000
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-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. [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. > 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. > 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...
- [mpls] Eric Rescorla's Discuss on draft-ietf-mpls… Eric Rescorla
- Re: [mpls] Eric Rescorla's Discuss on draft-ietf-… Huub van Helvoort
- Re: [mpls] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [mpls] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF