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

Benjamin Kaduk <kaduk@mit.edu> Fri, 19 October 2018 00:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98B130E69; Thu, 18 Oct 2018 17:59:04 -0700 (PDT)
X-Quarantine-ID: <V49rv8ydJHl0>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 V49rv8ydJHl0; Thu, 18 Oct 2018 17:59:02 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686C0130E64; Thu, 18 Oct 2018 17:59:01 -0700 (PDT)
X-AuditID: 12074424-4efff700000071e7-5a-5bc92c52291d
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 03.71.29159.35C29CB5; Thu, 18 Oct 2018 20:58:59 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9J0wuaG018684; Thu, 18 Oct 2018 20:58:57 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9J0wpE7018594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 20:58:54 -0400
Date: Thu, 18 Oct 2018 19:58:51 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "idr@ietf.org" <idr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-idr-te-pm-bgp.all@ietf.org" <draft-ietf-idr-te-pm-bgp.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Message-ID: <20181019005851.GY19309@kduck.kaduk.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> <2d123b3a118a4a9ca0023be33af8a067@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2d123b3a118a4a9ca0023be33af8a067@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixCmqrBusczLaoP2HisWxtTdYLTb82chu 8er2MyaLZxvns1h8WPiQxWLpsQ9MDmweU35vZPXYOesuu8eSJT+ZApijuGxSUnMyy1KL9O0S uDIebdMp+CFdMadtFmsD4yaxLkZODgkBE4nn646zdTFycQgJrGGSONz3lBXC2cgoceP/AnYI 5y6TxItlk5hAWlgEVCW2bz8MZrMJqEg0dF9m7mLk4BARMJJY/FwbpJ5Z4DOjxPmNqxlB4sIC HhJ77+iAlPMCbbtx8QgjxMwDzBL9fddYIRKCEidnPmEBsZkF1CX+zLsENpNZQFpi+T8OiLC8 RPPW2cwgNqeAq0T3wr+MILaogLLE3r5D7BMYBWchmTQLyaRZCJNmIZm0gJFlFaNsSm6Vbm5i Zk5xarJucXJiXl5qka65Xm5miV5qSukmRlAcsLuo7GDs7vE+xCjAwajEw3vi+IloIdbEsuLK 3EOMkhxMSqK8Beono4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8H7dDlTOm5JYWZValA+TkuZg URLnndiyOFpIID2xJDU7NbUgtQgmK8PBoSTBm6sNNFSwKDU9tSItM6cEIc3EwQkynAdoeCRI DW9xQWJucWY6RP4UozFH29PrM5g5OkCkEEtefl6qlDivCEipAEhpRmke3DRQKpPI3l/zilEc 6Dlh3gKQKh5gGoSb9wpoFRPQqhOmIH8UlyQipKQaGOe4ODNsftn/L+v4/EuFVz7lrxBS2DzH 893+L/v2rJdXyewMuuVxpVpDhe/Q81VPO38v5rKpfrx3/rw6eYHYAM2Dz9kPW1t5L0mOZ2US XFOhFvBO7Bnf+dkvaq+z7kpQZrstaHDnoSsH97OLX5Piha8KhW1Onqu+rqkraN+/Y15sjU3N Tt/YHiuxFGckGmoxFxUnAgBwQWvaQAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/l4gV_8xeQXcHu_sGr77iq65Urj4>
Subject: Re: [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2018 00:59:05 -0000

On Fri, Oct 19, 2018 at 12:40:51AM +0000, Les Ginsberg (ginsberg) wrote:
> Ben -
> 
> Inline.
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@mit.edu>
> > Sent: Thursday, October 18, 2018 5:27 PM
> > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> > Cc: Yoav Nir <ynir.ietf@gmail.com>; idr@ietf.org; ietf@ietf.org; draft-ietf-idr-
> > te-pm-bgp.all@ietf.org; secdir@ietf.org
> > Subject: Re: [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
> > 
> > On Thu, Oct 18, 2018 at 06:00:13PM +0000, Les Ginsberg (ginsberg) wrote:
> > > Yoav –
> > >
> > > In regards to the risks associated with advertising the specific information
> > covered in this draft we have a statement in the IGP drafts:
> > >
> > > From RFC7810
> > >
> > > “The sub-TLVs introduced in this document allow an operator to
> > >    advertise state information of links (bandwidth, delay) that could be
> > >    sensitive and that an operator may not want to disclose.”
> > >
> > > In regards to the risks associated with sending information via BGP-LS we
> > have a number of statements in RFC 7752 – most relevant is:
> > >
> > > “Additionally, it may be considered that the export of link-state and
> > >    TE information as described in this document constitutes a risk to
> > >    confidentiality of mission-critical or commercially sensitive
> > >    information about the network.”
> > >
> > > So long as there are references to both the IGP RFCs and RFC 7752 I am
> > therefore hard pressed to understand what else could be usefully said.
> > > Certainly the risks associated with the BGP-LS transport mechanism are not
> > altered by adding some new TLVs – and since the IGP RFCs have already
> > covered risks associated with the specific class of information (not simply the
> > risks associated with the transport mechanism) you are going to have to
> > provide more specifics on what can meaningfully be said that is not already
> > covered in the references.
> > 
> > My apologies for jumping in in the middle, but IIUC the IGP RFCs have
> > covered the risks associated with a specific class of information, *under the
> > assumption that the transport mechanism is within a single AS and
> > administrative domain*.  Yoav is pointing out that the risks for that
> > information may change when the distribution is over a broader domain than
> > the one for which the previous analysis was performed.
> > 
> 
> [Les:] IGP RFCs talk both about the risks associated with the transport (which are indeed bound to a single AS)  and the risks associated with the particular class of information.
> 
> RFC 7752 talks about the risks associated with distribution using BGP-LS as the transport and the risks associated with the class of information.
> 
> Please read https://tools.ietf.org/html/rfc7810#section-11 and https://tools.ietf.org/html/rfc7752#section-8 in their entirety.
> 
> Unless you want to argue that the risk associated with distributing the information defined in this document is qualitatively different than the risk associated with (for example) "Unreserved Bandwidth" defined in https://tools.ietf.org/html/rfc7752#section-3.3.2  I have no idea what to say. You are going to have to help me here.

I'm not sure I can commit to that reading list until the document gets on a
telechat (this week's is a pretty big one), but hopefully Yoav can work on
a faster scale than me.  Thank you for the specific references; it does
seem like we can converge pretty quickly.

-Ben