[Idr] Shepherd Write-up for draft-ietf-idr-ext-opt-param-09.txt

Susan Hares <shares@ndzh.com> Thu, 12 November 2020 21:18 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9E8CD3A0982 for <idr@ietfa.amsl.com>; Thu, 12 Nov 2020 13:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.224
X-Spam-Level: *
X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iDehIsiPAzGx for <idr@ietfa.amsl.com>; Thu, 12 Nov 2020 13:18:13 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net []) (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 ADA403A0980 for <idr@ietf.org>; Thu, 12 Nov 2020 13:18:13 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Date: Thu, 12 Nov 2020 16:17:58 -0500
Message-ID: <032201d6b939$4feaa320$efbfe960$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0323_01D6B90F.67158580"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ada5LTwl4ka7lgq1TayIhcfRwKiQ/Q==
Content-Language: en-us
X-Antivirus: AVG (VPS 201112-6, 11/12/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/I-NJotd8_5TFgJ_kSdcKI-mQim8>
Subject: [Idr] Shepherd Write-up for draft-ietf-idr-ext-opt-param-09.txt
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: Thu, 12 Nov 2020 21:18:16 -0000

Enke, John and Jeff Hass. 


The extended optional parameter provides a useful addition to BGP Opens with
RFC4271.  Thank you for a well written document and Jeff Haas for an
excellent implementation report from Juniper.  I agree this extension to the
optional parameter length is backward compatible and clearly defined.


I am concerned that your brief security statement will not be sufficient for
the IESG.  This does not mean I believe that a well-written BGP
implementation will have a security issue with this feature.   My suggestion
is to unpack the security section to explain why this feature does not
additional burdens on overflow buffers for the BGP open or the space for
processing the optional parameters.   I have provided you with some sample
text below.  


I am forwarding this to IESG for publication and asking for early security
directorate review by 12/7/2020.  


I suspect due to IETF 109 and the length of Alvaro's queue, that you may
receive the security directorates early review before Alvaro gets to this


Thank you for hard work on this technology over years!





Potential comment: 



/This extension does not change the  underlying security issues

Inherent in the existing BGP [RFC4271]. 




/This extension does not change the underlying security issues 

Inherent in the existing BGP [RFC4271].  


To expand on why the security issue are not changed, 

Consider that the implementations for RFC4271 

must handle BGP open packets with length exceeds the packet length. 

Inclusion of a longer optional parameters section does not 

change the RFC4271 check for the size of the BGP Open 

message.  Overruns of the space for optional parameters should not  

occur old BGP speakers since any RFC 4271 receiving an 

optional parameter length of 255 will not have a valid 

packet and discard the packet.  Implementations 

of this specification require BGP speakers which 

use the new optional to check the Extended 

optional parameter length.  Implementations 

of this specification should allocate sufficient 

space to handle longer optional parameters.