Re: [secdir] Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21 Wed, 16 December 2020 10:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E42983A0902; Wed, 16 Dec 2020 02:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5sxrTg7ygUWx; Wed, 16 Dec 2020 02:54:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BC7F3A08D4; Wed, 16 Dec 2020 02:54:13 -0800 (PST)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 4CwsSh2RMKz5w18; Wed, 16 Dec 2020 11:54:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1608116052; bh=cbVILpLiw0uXpTdb6tmy1FphLGxZMNK6noaH+XLa/q4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wKh7bmdoAueWmI0byb3UVCwShdNkQTROC358VB3xRKpufPq6FroFwoO0RxsLic+bJ 9aOnG5IBoLVNZpAlXw4fqNcn8ZMldrEEGq5h3cFur8KQHFvinIaz664o2JltYwLGYQ Kaq6YcP36uq7bTlaLR0CKCJJEv2/9qaHZecXEUghOTjyZGSm7AnOhDPKLU/vquBKiy H8cdlGObo//KCw9n7RRR7afUhhpwamEnjhdAUtKwipdnfBrW6noqiKfSJAlGntSGTj lq/BkmfiobtD9kKQKVdoTtajgo0eDbO0KjvozSHPkeMP37EEkWYDBwHPz2yYSQpgSx W9nh7sPzJWOCA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by (ESMTP service) with ESMTP id 4CwsSh1H8MzBrM3; Wed, 16 Dec 2020 11:54:12 +0100 (CET)
From: <>
To: Linda Dunbar <>, "" <>
CC: "" <>, "" <>
Thread-Topic: Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
Thread-Index: AQHW0y0btPHeXE3QG0yBotQbgi8tFqn5ilwA
Date: Wed, 16 Dec 2020 10:54:11 +0000
Message-ID: <19398_1608116052_5FD9E754_19398_452_23_53C29892C857584299CBF5D05346208A49056412@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2020 10:54:15 -0000

Hi Linda,

Thanks for your review.
Please see comments in line

> From: Linda Dunbar via Datatracker []
> Reviewer: Linda Dunbar
> Review result: Has Nits
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.
>  Document editors and WG chairs should treat these comments just like any
> other
>  last call comments.
> This document alters how  BGP Route Reflector computes the optimal routes
> on
> behalf of clients. Instead using its own IGP cost to the AS Exit points, the
> document describes the steps for RR to compute the optimal route by using
> Clients' position to the AS Exit points. The described method is useful when
> RR
> is centralized.  For deployment with distributed RR closer to the clients, the
> described method doesn't have any benefits.
> Security Concern:
> If RR's information of its clients topology is compromised, then the optimal
> paths selected by the RR might not be accurate anymore.

I agree with the analysis.
But it's not clear to me whether you are asking something to be added in the draft.
I'm seeing two cases:
- If the selected IGP location is configured on the router (RR), the attack requires the ability to change the configuration of the router. If an attacker can do this, it can do virtually anything (within the router capability). I don't feel that "securing access to the router configuration" is a typical point added in the security consideration although it probably applies to many documents.
- If the selected IGP location is implicit by using the IP address of the client IBGP session there is no new thing to compromise.

> Minor nits:
> Page 7: Section 3.2.
> "If the routing routing optimization requires ..."
> Is it a typo? duplicated word "routing"?
> Last sentence: "This needed for use cases ..."
> Do you mean "This is needed for use cases ..."

Thanks for the nits.
Corrected in my local version.


> Cheers,
> Linda Dunbar


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.