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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 19 October 2018 14:51 UTC

Return-Path: <ginsberg@cisco.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 BD4CF128D68; Fri, 19 Oct 2018 07:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 PsGOXaqOtkFX; Fri, 19 Oct 2018 07:51:37 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B1912958B; Fri, 19 Oct 2018 07:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24562; q=dns/txt; s=iport; t=1539960697; x=1541170297; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HwaKMPbCyxy1zAg8hiy4yHyjGte6Tps3SCFMVgtZOPQ=; b=Y6JZ2S2M0GXiuQmOWGyfM2Yp/Z+YCq1dQ79p90wjbvhsWCXJSGyRX2U6 3/mzSXmwlYj5gx6VWmxrS9fO+yDSY9df+kw7a0pbcDdG/YOFrwwVekP7n Bq4IJyIOTC1XvAgrVoweNvGG58KHGI56GhxhZUaNRa63o/K018IJBbsWZ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAADo7slb/5xdJa1kDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENSC9mfygKg2uIGIwbgg2IeIhPhUiBegsBASOESQIXhG8hNA0NAQMBAQIBAQJtHAyFOQEBAQEDIwpFBxACAQgRBAEBAScDAgICHxEUCQgCBAENBQgMC4MDgR1MAxUPpnGBLodzDYITBYtPF4FBP4ERgmQuglZFAQECAYF1H4JNglcCjjKGEIlRLgkChlyCYYQJgxwfkCmMVHiIXwIRFIEmHTiBVXAVgyeCJheIXIUEOm8BAYokgR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,400,1534809600"; d="scan'208,217";a="458439793"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2018 14:51:35 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9JEpaGZ002770 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2018 14:51:36 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 19 Oct 2018 09:51:35 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Fri, 19 Oct 2018 09:51:35 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, "kaduk@mit.edu" <kaduk@mit.edu>
CC: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-te-pm-bgp.all@ietf.org" <draft-ietf-idr-te-pm-bgp.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
Thread-Index: AQHUZZW9XPWYyIUJa0CAw27zofyhmaUihppwgAGMV4D//8FaoIABtlGA///AT8CAAMKMAIAAa5YAgAAtaFA=
Date: Fri, 19 Oct 2018 14:51:35 +0000
Message-ID: <c22b55313bc54157853d5668a146038c@XCH-ALN-001.cisco.com>
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>
In-Reply-To: <CAOj+MMH1=SBV=ikiNE6UHEe1mzf5xKLPOZXnnqPEvyFHTC=83A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.113.215]
Content-Type: multipart/alternative; boundary="_000_c22b55313bc54157853d5668a146038cXCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/amxh-2Qwb0yiqSEX1uTQ_l0tBb4>
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: Fri, 19 Oct 2018 14:51:40 -0000

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 ). 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. 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


From: Robert Raszuk <robert@raszuk.net>
Sent: Thursday, October 18, 2018 11:52 PM
To: kaduk@mit.edu
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; idr@ietf.org; draft-ietf-idr-te-pm-bgp.all@ietf.org; ietf@ietf.org; ynir.ietf@gmail.com; secdir@ietf.org
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Benjamin,

Not sure if you have spotted similar comment made to IDR regarding this topic, but your comment seems to indicate that here we are about to define ways to carry nicely scoped IGP information into BGP. Well that has already happened with RFC7752 and your comment or for that matter Yoav's remarks are indeed spot on but to the security discussion on RFC7752 and IMO not any follow up extensions of it.

Sure - as observed by Sue - one may argue that providing more information about the network to the potential attacker makes the network weaker, but the cure for that is to prevent the leaks and reduce probability of intercepting new information by unauthorized parties.

BGP-LS is already defined in a new SAFI what by itself does provide nice level of isolation. RFC7752 is pretty clear on that too and says:

"BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information."

If someone would be still concerned about configuration mistakes and negotiating SAFI 71 or 72 to those who should not get this data I recommend we reissue the RFC7752 as -bis version and restrict the scope of the distribution even further by mandating default use of NO-EXPORT community with ability to overwrite it for the selective eBGP peers. Or perhaps we could progress Jim's One Administrative Domain draft (draft-uttaro-idr-oad-01).

In either case while both of your comments are great they seems a bit late in the game here or at least targeting wrong document.

Kind regards,
Robert.


On Fri, Oct 19, 2018 at 2:27 AM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
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.

-Ben