Re: [Idr] Review of draft-abraitis-bgp-version-capability-07

"RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org> Thu, 20 August 2020 18:55 UTC

Return-Path: <rfc-ise@rfc-editor.org>
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 1907E3A12D9 for <idr@ietfa.amsl.com>; Thu, 20 Aug 2020 11:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 peXmD1WyJftJ for <idr@ietfa.amsl.com>; Thu, 20 Aug 2020 11:55:36 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007A43A12D8 for <idr@ietf.org>; Thu, 20 Aug 2020 11:55:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 79856F40757; Thu, 20 Aug 2020 11:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo9Yc4VAznHw; Thu, 20 Aug 2020 11:55:12 -0700 (PDT)
Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 1E2F1F40754; Thu, 20 Aug 2020 11:55:12 -0700 (PDT)
Received: from 84.51.128.121 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Thu, 20 Aug 2020 11:55:12 -0700
Message-ID: <63466e0fde345b64395b7d12c0ac40ca.squirrel@www.rfc-editor.org>
In-Reply-To: <CAMMESsyqTuPfxCMWO6GQCO8nc2z8+PxQVomL0HX0xQLrBLYEQA@mail.gmail.com>
References: <CAMMESswJfjShCjr0ZOhshWD058eosBAStOcXVAr77rv6RvFMDg@mail.gmail.com> <37f90ca874e87bd4f8b4245518cd3a3b.squirrel@www.rfc-editor.org> <CAMMESsyqTuPfxCMWO6GQCO8nc2z8+PxQVomL0HX0xQLrBLYEQA@mail.gmail.com>
Date: Thu, 20 Aug 2020 11:55:12 -0700
From: "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
To: "Alvaro Retana" <aretana.ietf@gmail.com>
Cc: rfc-ise@rfc-editor.org, donatas.abraitis@hostinger.com, "IDR List" <idr@ietf.org>
Reply-To: rfc-ise@rfc-editor.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nXxlBZXUWfJxs4DeKazDTveK_u0>
Subject: Re: [Idr] Review of draft-abraitis-bgp-version-capability-07
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, 20 Aug 2020 18:55:37 -0000

Lovely. Thanks for the quick convergence, Alvaro.

We'll wait to see what Donatas makes of all this.

Best,
Adrian

Alvaro Retana wrote:
> On August 20, 2020 at 9:28:42 AM, RFC ISE wrote:
>
>
> Adrian:
>
> Hi!
>
>
> ...
>> > (1) You do a very good job to highlight potential threats in the
>> > Security Considerations section.
>> > But you also Normatively recommend (SHOULD) the use of encryption in
>> > the BGP Session.
>> > While sensible, there are no Standards Track documents that currently
>> > do the same.
>> >
>> > This recommendation, even if the draft points out that it "is not an
>> > IETF Standards Track document", can create confusion and potentially
>> > disrupt other IETF work.
>>
>> At this point, I don't see that as a problem. This is a recommendation
>> that *if* you use this extension you should also use encryption. The
>> fact
>> that no standards track documents recommend encryption means that if you
>> don't use this extension you are not recommended to use encryption.
>
> This extension is only present in the OPEN message (1 message), while
> a BGP session is (hopefully) long-lived.   Recommending any
> transport-related functionality is really a recommendation for the
> whole BGP session.
>
>> Can you supply examples of the confusion or disruption? (It is certainly
>> not our intention to confuse or disrupt!)
>
> TL;DR: The objective is consistency with current practice and
> expectations related to BGP documents.
>
>
> Over the years, the need for "upgrading" BGP's security, specifically
> in terms of authentication, integrity and confidentiality has been the
> subject of many conversations and reviews, including many from the
> SecDir and SEC ADs.  The summary of those discussions has been to not
> change the recommendations/requirements in documents specifying
> enhancements (like this one), but to do so in the base specification,
> which is the one dealing with the specification of the transport for
> BGP.
>
>
> Given that you don't have any objection to the new text I proposed for
> the Security Considerations, I think we're settled. :-)
>
>
>
> ...
>> > (2) As currently specified ("SHOULD be no greater than 64" and "it is
>> > RECOMMENDED to exclude the Version Capability"), the Capabilities
>> > Length Overflow (§3.1) handling represents a significant threat to a
>> > BGP session.
> ...
>> However, I would be comfortable with:
>> - SHOULD be no greater than 64 bytes
>> - MUST be left out if would constrain inclusion of any other Standards
>> Track capabilities
>
> That works for me too.
>
>
> ...
>> > Suggestion (for the Security Considerations)>
>> > A rogue node can prevent the proper operation of a BGP session, or
>> > the advertisement of other Capabilities, by not excluding the Version
>> > Capability as required in Section 3.1. This risk is equivalent to a
>> > rogue node simply not advertising a specific Capability and is not
>> > new to BGP.
>>
>> Sorry, but by your own text, this is at best unhelpful. A rogue node can
>> do anything! A rogue node can decide to omit or lie about capabilities;
>> it
>> can add new and unknown capabilities that fill up the the attribute; it
>> can violate any MUST from a protocol spec; it can generate random
>> streams
>> of bytes.
>>
>> Adding your text would, I think, not be very harmful, but it gives the
>> appearance that this protocol extension introduces a new threat. It does
>> not. So if you wanted something added it would need to say "BGP includes
>> no protection against rogue or subverted implementations. This
>> specification does not introduce any security measures to address that
>> problem." Personally, I don't think that this is the place for a
>> commentary on the general deficiencies of BGP.
>
> The SEC Area has been putting some emphasis lately on the effect that
> a rogue node can have, related to the specified functionality.  That
> is the reason that I suggested the text.
>
> I am ok if the author doesn't decide to include the text above.
>
>
>
>> > [major] The length to be considered is not 255 octets of Capabilities,
>> > but of Optional Parameters -- take a look at rfc4271/§4.2.
> ...
>> 2. How do you stop the version capability crowding out other optional
>> parameters?
>
> That's maybe a better way of stating my concern about the ability to
> affect the operation of a BGP session...  [The only Optional
> Parameters currently used are Capabilities.]
>
>
>
> I'm ok with all your other comments and suggestions.
>
> Thanks!
>
> Alvaro.
>
>


-- 
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org