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