Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp
"Susan Hares" <shares@ndzh.com> Fri, 05 October 2018 13:30 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558BF130DEB; Fri, 5 Oct 2018 06:30:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 Uum25vzD51GZ; Fri, 5 Oct 2018 06:30:37 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 27674130DC6; Fri, 5 Oct 2018 06:30:37 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.230.11.155;
From: Susan Hares <shares@ndzh.com>
To: "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>, idr@ietf.org
Cc: draft-ietf-idr-te-pm-bgp@ietf.org
References: <001701d45c18$8d087820$a7196860$@ndzh.com> <800a8356a4f44e4db70f13a36c6f5552@XCH-ALN-001.cisco.com>
In-Reply-To: <800a8356a4f44e4db70f13a36c6f5552@XCH-ALN-001.cisco.com>
Date: Fri, 05 Oct 2018 09:30:29 -0400
Message-ID: <007701d45caf$96612c90$c32385b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01D45C8E.0F51FD90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLCwtiZ0+4gZbYnoIH3A8XnFv6NZgFFJ6E3oymtRTA=
Content-Language: en-us
X-Antivirus: AVG (VPS 181005-0, 10/05/2018), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/SmiX3QL-tIMcsTdRIhweqJXglys>
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 13:30:40 -0000
Les: Thank you for quickly responding to my Shepherd's report. As far as I can tell, we have the following item to discuss on the list: 2) Security Section - Consider whether you want to add additional comments in your security section about the distribution of IGP TE information in BGP. Even if the node inputted the data into BGP-LS has the appropriate permissions, BGP blindly sends this to the entire BGP infrastructure supporting BGP-LS guided only by policy set on nodes. Is this what you want? If so, I will forward this to the security directorate for their review. [Les:] I am having some trouble understanding the motivation for your comment. IGP TE information has been distributed via BGP-LS since RFC 7752. Why do you believe that the addition of the IGP TE information defined here requires additional security comments? I would like to structure this discussion in two fashions: technical information and shepherd's requirements. As a BGP technical expert I have specific concerns regarding this information. However, as a shepherd my technical concerns are only informational and not required to be resolved prior to standardizing this document. As a shepherd, all I require is that you consider this technical information before we go forward to standardization. I have requested a security directorate review for this document regarding my concern. Why? The reason for requesting this security review now is that you do not have your implementation reports completed, and I anticipate issues with the security ADs. I can make use of this time while we wait for implementation report to get an early security review of this issue to resolve any potential issues early. Technical information: IGP information may provide information on places within a network that have high or critical load. An attacker could use this information to launch a directed attack. Shepherd requirement: Please simply consider this area and decide if you wish to change your text. Please send me email if you wish to change your text so that I can review it. Please let me know if you have any questions regarding my response. Cheerily, Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Friday, October 5, 2018 2:49 AM To: Susan Hares; idr@ietf.org Cc: draft-ietf-idr-te-pm-bgp@ietf.org Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp Sue - Thanx for the review. Responses inline. From: Susan Hares <shares@ndzh.com> Sent: Thursday, October 04, 2018 12:29 PM To: idr@ietf.org Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; draft-ietf-idr-te-pm-bgp@ietf.org Subject: Shepherd's review of draft-ietf-idr-te-pm-bgp Les, Stefano, Qin, Jeff, and Clarence: This document is generally in excellent shape. I note the following four things need to be fixed prior to submitting this to Alvaro Retana: 1) Editorial: Page 3 states "Unidirectional Packet Loss", but section 3.4 says "Unidirectional Link Loss TLV" Please fix this editorial error. It is a requirement for sending to the IESG for publication [Les:] I have changed these all to be "Link Loss' - consistent with RFC 7810. 2) Security Section - Consider whether you want to add additional comments in your security section about the distribution of IGP TE information in BGP. Even if the node inputted the data into BGP-LS has the appropriate permissions, BGP blindly sends this to the entire BGP infrastructure supporting BGP-LS guided only by policy set on nodes. Is this what you want? If so, I will forward this to the security directorate for their review. [Les:] I am having some trouble understanding the motivation for your comment. IGP TE information has been distributed via BGP-LS since RFC 7752. Why do you believe that the addition of the IGP TE information defined here requires additional security comments? 3) We do not have any implementations reported. Please put the existence of the implementation on the BGP Wiki - under implementation reports. [Les:] I have an implementation report for one Cisco implementation which I will post shortly. A second Cisco implementation is currently in progress. If other vendors have implementations that they wish to share I would appreciate it if they either contacted me or updated the wiki after I post the initial report. 4) An IPR statement directly from Clarence Fils on this draft. John approved the WG LC based on a related IPR statement, but I fear this will not be sufficient for the current IESG. Please as Clarence to respond to this email with an IPR Statement. [Les:] I have pinged Clarence on this - please expect a reply from him soon. Les The Shepherd's report is online. This document will stay in "Waiting implementation" until John or I receive a report on 2 implementations. Please place this on the Wiki. Cheerily, Susan Hares
- [Idr] Shepherd's review of draft-ietf-idr-te-pm-b… Susan Hares
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Les Ginsberg (ginsberg)
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Susan Hares
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Robert Raszuk
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Susan Hares
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Les Ginsberg (ginsberg)
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Les Ginsberg (ginsberg)
- Re: [Idr] Shepherd's review of draft-ietf-idr-te-… Susan Hares