Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

"Susan Hares" <shares@ndzh.com> Sun, 21 October 2018 23:26 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 274E4130DDB; Sun, 21 Oct 2018 16:26:48 -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 wBFe-bBw6IyW; Sun, 21 Oct 2018 16:26:46 -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 ED6ED12F1A6; Sun, 21 Oct 2018 16:26:45 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.26.143;
From: Susan Hares <shares@ndzh.com>
To: 'Yoav Nir' <ynir.ietf@gmail.com>, "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>
Cc: idr@ietf.org, ietf@ietf.org, 'Robert Raszuk' <robert@raszuk.net>, secdir@ietf.org, kaduk@mit.edu, draft-ietf-idr-te-pm-bgp.all@ietf.org
References: <153972468642.9298.14442375581871750001@ietfa.amsl.com> <ec43e712e8024930831a206f8e843cbb@XCH-ALN-001.cisco.com> <7655493D-9EF0-42FF-B2D3-B9CE4E78178D@gmail.com> <feec42a72bd64f31afbcb3b340dad52b@XCH-ALN-001.cisco.com> <1FFA9449-D03C-4EB6-9D08-BA4A1AA93FE3@gmail.com> <92af26fef2da470d853f292c84f026a0@XCH-ALN-001.cisco.com> <20181019002642.GX19309@kduck.kaduk.org> <CAOj+MMH1=SBV=ikiNE6UHEe1mzf5xKLPOZXnnqPEvyFHTC=83A@mail.gmail.com> <c22b55313bc54157853d5668a146038c@XCH-ALN-001.cisco.com> <14949BEE-1EC4-46A0-A1FD-8FE4BCD5D417@gmail.com>
In-Reply-To: <14949BEE-1EC4-46A0-A1FD-8FE4BCD5D417@gmail.com>
Date: Sun, 21 Oct 2018 19:26:40 -0400
Message-ID: <077e01d46995$85c7bb90$915732b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_077F_01D46973.FEB88C90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKgXenR4TO/OdN54mRvtkcFsKB91wGNvGOlAbtG730CGuBt5QG8teXZAq/npckCVX567AF47qlpAUeOFiECkA51CqMGun6Q
Content-Language: en-us
X-Antivirus: AVG (VPS 181021-4, 10/21/2018), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PyrWHgBw3eWyOCIUMoCbLJetHv4>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
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: Sun, 21 Oct 2018 23:26:48 -0000

Yoav:

 

Thank you providing suggested text to resolve your concerns and coming to a resolution with the security issues with Les. 

 

Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, October 21, 2018 1:45 PM
To: Les Ginsberg (ginsberg)
Cc: idr@ietf.org; ietf@ietf.org; Robert Raszuk; secdir@ietf.org; kaduk@mit.edu; draft-ietf-idr-te-pm-bgp.all@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

 

See inline.





On 19 Oct 2018, at 17:51, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

 

Robert’s post addresses points I also want to make.

 

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see  <https://tools.ietf.org/html/rfc7752#section-3.3.2> https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

 

In theory, we could have simply updated RFC 7752 rather writing a separate draft, but practically this would be a poor strategy as it would incorrectly suggest that some change was being made to the existing text in RFC 7752.

 

I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752. 

 

[YN] Right, and as such, I believe that this document should address the part that it adds to RFC 7752. IOW it should state that the new IGP information that will now be sent through BGP does not present new/different risk to the information already defined in 7752. This is information that has up until now only been sent in IS-IS and OSPF and will not be sent in BGP, so we need a statement that it’s OK to send these attributes in BGP as well. Of course, such a statement could be challenged in WGLC or IETF LC, but it should be made.





The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion.

 

I think it is important that you note this relationship, because the nature of BGP-LS is that whenever IGP extensions are defined to advertise new information it is necessary to define corresponding BGP-LS codepoints. This is not the first such BGP-LS extension document – and it is safe to say it won’t be the last. It would be helpful to all if we reached a common understanding or this discussion will take place every time a BGP-LS extension document is being reviewed – which will cost us all time needlessly.

 

   Les