Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp

"Susan Hares" <> Fri, 05 October 2018 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BED212F1AB; Fri, 5 Oct 2018 07:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.947
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dELrFuZiy0wR; Fri, 5 Oct 2018 07:59:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8E0130DE4; Fri, 5 Oct 2018 07:59:13 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Robert Raszuk'" <>
Cc: "'Les Ginsberg \(ginsberg\)'" <>, <>, <>
References: <001701d45c18$8d087820$a7196860$> <> <007701d45caf$96612c90$c32385b0$> <>
In-Reply-To: <>
Date: Fri, 5 Oct 2018 10:59:05 -0400
Message-ID: <00d601d45cbb$f68ca840$e3a5f8c0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01D45C9A.6F7B0840"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLCwtiZ0+4gZbYnoIH3A8XnFv6NZgFFJ6E3ASvk/esBtDY0dqMSxyog
Content-Language: en-us
X-Antivirus: AVG (VPS 181005-0, 10/05/2018), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Oct 2018 14:59:15 -0000



I agree that 


“So IMO we should not put any obstacles into draft-ietf-idr-te-pm-bgp and allow it to progress”. 


I also agree we should consider the problem at large. 


Part of the progression, is to ask the question of the security directorate before we go to actual AD and IESG review. Then the shepherd, authors, and security directorate have been considered it.   Hopefully, this early consideration will allow the security ADs quickly review prior to publication.  


Susan Hares 




From: Robert Raszuk [] 
Sent: Friday, October 5, 2018 10:13 AM
Cc: Les Ginsberg (ginsberg);;
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp


Hi Sue,


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.


Seems like we have been through this topic already, but it seems to come back :) 


Your point is very valid however it applies to base RFC7752 not to few add-on extensions as proposed here by Les at other co-authors. 


All they are doing here are just defining and loading few additional bags on the plane which do not make it any more vulnerable. Entire plane which seems to be already in operation is a problem .. 


During time of standardization the promise has been made that it will operate separate from any other BGP traffic even including different and separate infrastructure (ex. separate RRs). Well the reality is that this is not something anyone can control and in practice this promise is not met. 


So IMO we should not put any obstacles into draft-ietf-idr-te-pm-bgp and allow it to progress. 


But if you have solid evidence then base RFC7752 should undergo real security review and if decided so should be recalled or transport of it should be clearly decoupled from port 179. 


As example as a trivial start the following draft could be used to decouple it from routing BGP: 


If we want to go further that that we could also move transport of RFC7752 to a message bus (ZMQ, RabbitMQ, NATS or Kafka etc just name a few options). I am sure there would be many more "stuff" in current BGP which would gladly jump over to such new transport model - as example even number of SAFIs could use customized RT based distribution instead of struggling with pushing RTC like filters around to get tiny subset of entire load carried in specific SAFIs. Sure it will not happen overnight - but until we start it will never happen.