Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
"Susan Hares" <shares@ndzh.com> Tue, 04 June 2019 18:28 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620D8120373; Tue, 4 Jun 2019 11:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 b_5Q1dQv3zmR; Tue, 4 Jun 2019 11:28:26 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 406FC12036F; Tue, 4 Jun 2019 11:28:26 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.215.70;
From: Susan Hares <shares@ndzh.com>
To: rtg-dir@ietf.org
Cc: draft-ietf-mpls-rmr.all@ietf.org, mpls@ietf.org
References: <154989728538.29584.3746504660070934932@ietfa.amsl.com>
In-Reply-To: <154989728538.29584.3746504660070934932@ietfa.amsl.com>
Date: Tue, 04 Jun 2019 14:28:22 -0400
Message-ID: <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHzVcVMghl3uypfFapdOB3o1ep0c6ZPVaDg
Content-Language: en-us
X-Antivirus: AVG (VPS 190604-2, 06/04/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/4uQ5ZAFbKbbrKep-cwI52khUZEA>
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 18:28:29 -0000
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
- [RTG-DIR] Rtgdir early review of draft-ietf-mpls-… Susan Hares
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… Susan Hares
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… Kireeti Kompella
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… Susan Hares
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… LUIS MIGUEL CONTRERAS MURILLO
- Re: [RTG-DIR] [mpls] Rtgdir early review of draft… Susan Hares