[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 [127.0.0.1]) 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [50.245.122.97]) (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=50.107.115.222;
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 text. Thank you for hard work on this technology over years! Sue ------------- Potential comment: Old: /This extension does not change the underlying security issues Inherent in the existing BGP [RFC4271]. / New: /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. /