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

Donatas Abraitis <donatas.abraitis@hostinger.com> Tue, 25 August 2020 04:09 UTC

Return-Path: <donatas.abraitis@hostinger.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 DB6D23A08FD for <idr@ietfa.amsl.com>; Mon, 24 Aug 2020 21:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hostinger.com
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 McL-HOcrQ4dI for <idr@ietfa.amsl.com>; Mon, 24 Aug 2020 21:09:37 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 8B8433A08E9 for <idr@ietf.org>; Mon, 24 Aug 2020 21:09:36 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id c15so5655690lfi.3 for <idr@ietf.org>; Mon, 24 Aug 2020 21:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hostinger.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=CZriysC6Ewgf8K27dEaR+ZXPJGLe6pqVe8cFKDQ/xok=; b=FzZ7LRAnRLsVagm6iy6dEkn1QsfY5esgY3atEUWoCa9mXKx9RmMcLitwiwvNfXx7gO L3esZFHE51FwPd2jJD0rp92TM3bAVN8lPq9ayoOtNnR5cHZOE9N8Sv/OMLMnt+q40U9f zTW46OLIJ20/iv3K5u5UVTDtqdAj6LNOkbca0X9OvBOJ7oCbs8I0Pzjydx28JnaKF9j+ /1WUldTASl+mccujHcueynyXFNzqNqA8UVIMNkp1b4StjMgrat1KvAuOs/beaqXVdfCQ jMGOvueQaQQSRPdWMA6CDitD6etLsWGvB58W4W/jRiq3xlf2a3PcYN1AqmftPG4tC5ql Msgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=CZriysC6Ewgf8K27dEaR+ZXPJGLe6pqVe8cFKDQ/xok=; b=WafoihU9Zh7NTkedFfAHoYvtHoVB/Ivhmk21TYQcmTMovdV/TuaXQDCq0dKUb7BaRg d6ItlLRIwV7zBheIeC3yum55E7KV4FI3JlttmWYLm011iilhhY6vKO0lJ1Dj3bzhk2B/ j7JEmKukOupXmfyH+xUD1TKDYHtC5GOPAz5uhF50z/oxtXn6t2dUvxjVm5Av3RgHX178 a6J3mb1DvLqTajm40ijhRzhuSMG9RQ8Kf1k3dyg1BGK1mZ7aPqZqPD7kt+xJxU5n9tL2 nr9a8I07lOveXSK2BcUlX7aNd/TP6SvDDcQ3z5mTDjaaYpvvYDkpCaIJZ4zk7RhmSuME 4nqg==
X-Gm-Message-State: AOAM533BubJFY277+KNIReYMHtJ07k57fi2PEZXaJ53h4F5CHdOfBWtC cyUBi6LbZcH2Pir9Qh2ViGJgyw==
X-Google-Smtp-Source: ABdhPJwnkRI7CWGbP/+cTtV+ofRUWRHaU1dRuhju+HNc1q8ekOEZS6n9W2OYh93LoRH1PSXMmXgRug==
X-Received: by 2002:ac2:44a9:: with SMTP id c9mr3727609lfm.99.1598328573966; Mon, 24 Aug 2020 21:09:33 -0700 (PDT)
Received: from [10.133.98.133] (md-188-69-194-133.omni.lt. [188.69.194.133]) by smtp.gmail.com with ESMTPSA id g186sm2543653lfd.88.2020.08.24.21.09.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Aug 2020 21:09:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Donatas Abraitis <donatas.abraitis@hostinger.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 25 Aug 2020 07:09:32 +0300
Message-Id: <A3ECA269-03A3-43CF-AE11-2BAF1746CB45@hostinger.com>
References: <CAMMESsyqTuPfxCMWO6GQCO8nc2z8+PxQVomL0HX0xQLrBLYEQA@mail.gmail.com>
Cc: rfc-ise@rfc-editor.org, IDR List <idr@ietf.org>
In-Reply-To: <CAMMESsyqTuPfxCMWO6GQCO8nc2z8+PxQVomL0HX0xQLrBLYEQA@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: iPhone Mail (17G68)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QYjLRUNf7TeuyCxQtvbqZ0fa9EU>
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: Tue, 25 Aug 2020 04:09:39 -0000

Hello, Alvaro,

thank you clarifying this to me. I'll update the document as per your recommendations. 

> On 2020-08-20, at 21:21, Alvaro Retana <aretana.ietf@gmail.com> 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.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr