Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-tp-shared-ring-protection-05: (with DISCUSS and COMMENT)
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 25 May 2017 13:06 UTC
Return-Path: <spencerdawkins.ietf@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 7499012944A; Thu, 25 May 2017 06:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FsYZfh5e0K98; Thu, 25 May 2017 06:06:16 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 0A7741200C5; Thu, 25 May 2017 06:06:15 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id p73so91806212ywp.0; Thu, 25 May 2017 06:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+/W6IenDB08/ZqDAFDCaGgMuaBNLgeTJGFcMxfTOYQA=; b=vLB07ckMT+owI1LczG3gGJV58dIDK6cJvJIz2IuJx7FHc3anGlhNQMpJUs9zKDD2oH V2EaNTHlXPFGhNEMRusueCWuZYHOvbE63Qo8kA4Cs+omSM0QLrhkcAHmLrzn6CtCdCmR 2Yrw9Kjn9sZXLb1Osk66fxZnF9VYkkuGhcaP/WxK5HsfNgSIQpQ76AO9t4CKF5u11Ioy nTHjJnNm9rt2HAxDiLnRf/gqH/oFZYe/S4ChFHVVVGi7z444fjAgYRv42D9TPcmBpp3f gX2q38y5/wvjxS3Q/IuVCLxZu0X5JkI9n6wDWPnbtXje8ayEpMseo0QWJhJlMNjhXnJu +SkQ==
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=+/W6IenDB08/ZqDAFDCaGgMuaBNLgeTJGFcMxfTOYQA=; b=KpUfN4JQWVJ1PX+zvDGsy3bvTer85lzIcKjNeaF+whmBWOHPDV0KeCN3kfJ2mfdnuX zvAy/Nkh6H3XzlcCDdQZVd47+Yj17bPX+u0h/Ih6pticVW6+tC4BR3kpUiIozxQXggVT oqcJjHzQYHAABjX2FH0AIhqr9xkRSADwfr0JVD8a8VniUXZT5GP6s4n8EWsDRMHBb30v yyELWainEvGdEXCM/VT8jUzYgTHawJv7/UvBoLrvhtXUzOOMHkGQLJiS/cC6HcmfIzhU XFcjjoS1Up81Bnn6lfIUHNYTG5Ws5hvBqYWZ9ASEPKoc25/aioBzEOWTSdLqTio6ypFE k6Xg==
X-Gm-Message-State: AODbwcC8PRYqpiECp5qjFwZmC5O3bT+e3Qgm6EPNbLkBQaPGNJdUwpM+ 4xgHvYssxjunHsoMftj6svWskCYnBw==
X-Received: by 10.13.228.69 with SMTP id n66mr466890ywe.275.1495717575187; Thu, 25 May 2017 06:06:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.163.130 with HTTP; Thu, 25 May 2017 06:06:14 -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: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 25 May 2017 08:06:14 -0500
Message-ID: <CAKKJt-cwjDmChrT2foL=u7MuEAnewVb25V2dqY__g3+J0doWEg@mail.gmail.com>
To: huubatwork@gmail.com
Cc: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-tp-shared-ring-protection@ietf.org, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, Eric Gray <Eric.Gray@ericsson.com>
Content-Type: multipart/alternative; boundary="94eb2c034ce4c0f7dd055058e25d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/jlYhSB1KTpSa5YuRTrxB7KoHlNM>
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 13:06:19 -0000
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 <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. > > 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... > >
- [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