Re: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Kireeti Kompella <kireeti.kompella@gmail.com> Wed, 05 June 2019 05:38 UTC

Return-Path: <kireeti.kompella@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 D1AE9120448; Tue, 4 Jun 2019 22:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5h6OKyNTvdhs; Tue, 4 Jun 2019 22:38:41 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 0E583120397; Tue, 4 Jun 2019 22:38:41 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id c3so21840262otr.3; Tue, 04 Jun 2019 22:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zxgS/yQSB7Rxj+tDhqyzoFmqZuavJtgKze722U8EG7Y=; b=rdKdHJGIiGZS/j6b1HQfgRPktFi60irECPoBYgIUHZKTiQ89j1Mj3BePtd30JAU+xQ Pl1TVWrhx8asnNtB8YbjnBMnVIs3k7dFvIFa6CdG/GjQJfXXrWYQiFsbKPUDkfQHx8iv gKpkZlvLgYV28tuYFDAmKZhLMwPkDWhUQWsUJlu+eUr2+JUKzju52nMfe4TKag/HW7hE DUaGwFYLhnZlVGdKE32cYg9yMcgKN2l4P1aXdwLw3L1mD+uAxzLz8T3zgPb2gJmvgLPO 4CAy9I6k13qUZOeW0BEIycsnxwN853Rc89bwNy1Bbkf6XUzwVx4kbh8s/Oufot+3G8Iu NUgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zxgS/yQSB7Rxj+tDhqyzoFmqZuavJtgKze722U8EG7Y=; b=nPEDdYk7Yuan+dhgvV5MxyH62wzuSP4QUNiv7poUfb99URZTpBG2MdcXt2Q5zotvCg Kfl1Xf0hAlynhuHX8xKrISesu8lS0AcCmvaUYclNWO+yCeZDaNhcTreRYZZsoj7077uB PijNWWhPQvLDiRJCYK8RqihZfI5oTnFQRT6s7XxAKOrQBPPVFxB7SMwo8khwn+2lXypu ZzWRKYhZFv5+k2aYlLxHE6Mxj2CrutFV55tC9riTjuqiaKIgxny8Bmgk8hSKRmhbHqcz +ARg1GKwyfhbhItBzFu/+A0gYSmnoWGmCI1rx5Hdt0kF75IzxLfQ8yc7/PXXbggzpqFG KuZw==
X-Gm-Message-State: APjAAAX8rzfPBXbvVhrPz8hdMmPBGK7nboF9YBrb8XcVUHjpkTpu30iR WfpgyEMJ1IwguorTcN8Dj0KxwV7L
X-Google-Smtp-Source: APXvYqzJWvePS4H91k244VjNBuUcYS8H8EfaP0o6G8///pYCqI3bC8MnKkz5BjpBoXlJyDxQ7ez4TA==
X-Received: by 2002:a05:6830:150e:: with SMTP id k14mr7172320otp.92.1559713120220; Tue, 04 Jun 2019 22:38:40 -0700 (PDT)
Received: from ?IPv6:2600:1702:1d00:1dd0::7ca? ([2600:1702:1d00:1dd0::7ca]) by smtp.gmail.com with ESMTPSA id x20sm7230880ote.18.2019.06.04.22.38.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 22:38:39 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kireeti Kompella <kireeti.kompella@gmail.com>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
Date: Tue, 4 Jun 2019 22:38:38 -0700
Cc: rtg-dir@ietf.org, draft-ietf-mpls-rmr.all@ietf.org, mpls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <01BD9D6B-9D90-4AB4-86FE-15F48B4F1057@gmail.com>
References: <154989728538.29584.3746504660070934932@ietfa.amsl.com> <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/v90k6sJDTcs0x7IgpbbmrXrCShs>
Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 05 Jun 2019 05:38:44 -0000

Sue,

I hear you.  But this is not an RMR issue — _networking_ is by nature distributed.  “IS-IS + open linux without security” or “BGP + open linux without security” or ... would all be bad ideas.  That said, do you have a suggested change/addition?  I’ll be happy to amend the sentence.

Thanks for pointing out the superfluous comma.  Will delete. 

Cheers,
Kireeti

> On Jun 4, 2019, at 11:28, Susan Hares <shares@ndzh.com>; wrote:
> 
> Draft-ietf-mpls-rmr-10.txt resolves 98% of my specific comments.  
> 
> Remaining Item: Security section
> Change status: optional.  
> 
> Problem: 
> The security section has been improved, but the following sentence in the
> second paragraph of section 9 still could be strengthened. 
>  This sentence is: 
> 
> Current: /One can also ask whether the semantic content of these extensions
> can be used to compromise 
> a network or initiate a denial of service attack. To do so would require
> either compromising the control plane
> processing these requests, or manipulating the content of the messages."
> / 
> 
> Discussion: 
> The authors are precise in this sentence, the import of this sentence may be
> lost
> on individuals or companies deploying this technology. 
> 
> Routing control plane do get compromised.  And when they get 
> compromised with a network using RMR, they may have network 
> wide problems.    Therefore, the authors assume that 
> when you buy RMR from a vendor make sure
> it comes from with  control plane with good security. 
> For example,  RMR + open linux without security - is probably a bad idea.  
> 
> This is an acceptable choice for routing  but not self-evident from the
> text. 
> I pose the question to the authors, do you think most people will understand
> that
> this is the requirement you are placing for the "outside the scope option"?
> 
> If not, will it help to provide additional text? 
> 
> Why mention it now?:  
> If either the security directorate or OPS-DIR reviewer has strong routing
> clue, 
> the person will probably also notice the issue.  By stating it up front, I
> hope to save
> the security reviewers time.  
> 
> 
> Editorial on -10.txt 
> 
> Page 3, section 1, paragraph 3, sentence 
> General comment:  ", and" - does not seem to make entire sense.
> Old: The intent is not to construct rings in a mess network, and use those
> for protection./ 
> New: The intent is not to construct rings in a mess network and use the
> rings in the mess network for protection/
> 
> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: Monday, February 11, 2019 10:01 AM
> To: rtg-dir@ietf.org
> Cc: draft-ietf-mpls-rmr.all@ietf.org; mpls@ietf.org; ietf@ietf.org
> Subject: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
> 
> Reviewer: Susan Hares
> Review result: Not Ready
> 
> This is a routing directorate review.  As such, it should be considered the
> same as other later WG LC review.
> 
> overall-comment: Well-written and an exciting new direction.  I appreciate
> Kireeti and Luis work on this topic.
> 
> major concerns:
> 1) security (section 8),
> 2) long-term stability of architecture discussion,
> 3) FRR/Protection sections (3.6/3.7), and
> 4) amount of traffic that auto-discovery will place on the network.
> 
> caveat:  I have not been an WG participant for these discussions.   As such,
> I
> am a "fresh" pair of eyes to read the current specification.
> 
> Major concerns
> =======
> 
> 1) Section 8 - Security considerations.
> 
> "This section states 'It is not anticipated that either the notion of MPLS
> rings or the extensions to various protocols to support them will cause
> security loopholes."
> 
> This statement provides an opinion of the authors without any reasoning
> behind it.  As such, it provide no utility to the reader.  Inquiring minds
> would like
> to know "why" the authors feel this true and on what basis.   Launching a
> new
> type of structure within the MPLS cloud that auto-configures it self with a
> great deal of message exchange does not appear to have these qualities. 
> Surely, these authors have considered or tried these issues.
> 
> 2) Long-term stability of document - in the face of repeated statements of a
> future version of this document.
> 
> If this is just an interim document, then why is it being standardized.  In
> a specification that is going to include an RFC track, the sttaements of
> scope seem inappropriate in sections 1, 3.3, 4.5,  5, 7.1, and 7.2).  This
> scope should be gathered to a particular place and stated in another.
> 
> I agree with the concept of deployment and then refinement of the protocol
> mechanisms.  However, this document seems to anticipate quick refinement of
> the basic architeture.  If this is really true, then why is this document
> going ot the IESG.  If this is not true, then the scoping in above sections
> needs to be refined.
> 
> 3)  Fast re-routing installation puts details (3.6) before concepts of
> protection. Only after I read section 3.7, did section 3.6 start to make
> sense.
>  If you re-ordered the sections, perhaps you could provide additonal depth
> to section 3.6.
> 
> 4) paragraph 4.3, last sentence  "The nodes that set their M bit should be
> extra careful in advertising their M Bit in subsequent tries".
> 
> As an engineering, I find this description to avoid many of the problems
> about how long the bidding for master will take.  Is there a potential for
> the bidding to repeat over and over.  If so, how does the operator detect
> it.  Can something drop the nodes into membership phase or re-identification
> phase
> repeated?   While the ring announcement and ring identification cycle become
> a
> denial-of-service attack on the IGPs announcing the information?  I suspect
> the authors have investigated these points, but the architeture document is
> the place to indicate why the architecture prevents these problems.
> 
> As an editor, I find the anthropomorphism to be unwarranted in the text.
> While it took me to flights of fantasy where the nodes became intelligent
> silicon
> life forms, I suspect that is not what the authors wanted.   Perhaps after
> clarifying the engineering point, the authors can rewrite the sense of the
> text.
> 
> brief editorial nits:
> 
> 1) page 4, node index linke
> /upto/ to /up to/
> 
> 2) page 5 (Q_jk): - not define earlier, please define it.
> 
> 3) page 5, section 3 paragraph 2, sentence file
> 
> sentence:
> current: /The default is to send traffic along the shortest path./
> new:  /The default policy is to send traffic along the shortest path./
> 
> 4) page 6, section 3.3 sentences 2
> 
> current:/ The last attribute means/
> new: /The "auto-bundled" attribute means/
> 
> While the authors first formi is current, the change makes a specification
> clear.
> 
> 5) page 3.5 - please spell out the first use of UHP
> 6) section 3.6/3.7 - could use a diagram.
> 7) page 11, section 4.3, paragraph 2, sentence 2 (spelling) -
> 
> old/exaclty one;/
> new/exactly one/
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>