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

Alvaro Retana <> Thu, 20 August 2020 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 137C23A11C2 for <>; Thu, 20 Aug 2020 11:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iZi3bsKHOrax for <>; Thu, 20 Aug 2020 11:21:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 652483A11C1 for <>; Thu, 20 Aug 2020 11:21:33 -0700 (PDT)
Received: by with SMTP id b2so1076867edw.5 for <>; Thu, 20 Aug 2020 11:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=Tg1avPCwh+je38nRNiyUIKb0zpOqFwlh9SmE603WYSU=; b=Rsk7W/JsrAgaSifEhFLR7DzBtXLkAgcJuZk+HAMf7KUVFY+gFAdkgNQTbXQBboxNps Vj8FscWuQ+67iEnqKr3vMH2/0nc1o0FNamI/TKHGgq741CKXMThdA28hScSSFMuZM8dM xy6Wk6W9KLKhpHiveNvccot23e7gJ7Lk86WUq5kM3SzVpZ9wKieafVEq5DZdJxocsGmh AVuhsFsWLV+bvApn+Fw+GL9+McuimxEuLmfYpCfEhBtlsIA2OAp3p6JFM/mmQJM3LMEp 64pGTlhfpAe6HSEchXZaY04wPcc4kevq2NXSaq4//8m9lg9qjKhOXapkFF2s9JVfzmEv baPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=Tg1avPCwh+je38nRNiyUIKb0zpOqFwlh9SmE603WYSU=; b=jka+0U2TPIJegpxe1TuDgKucBuD+UH1tgKTI9SyLevOl3e/beW4vRFOVxVe7Sjqt28 7z34HpOHprukIRBxH8xupOQXhA6wMCnJHo6pqvz2N2YCAso/ftsVHQhWmDKznUahLoq7 VmV+AGxsUsjeALHFNnEEUJA1KuTY9dJ/tIBXI+k2oDj2RINpnGUNNXlzNjZzpmpsGgua KHM6CjKIXMa1EbRAzkAXLlSoyJVkyr1mlAhbjRJsw1ShwopWHGuta27xFLVgOwVxjkSL c+91fM2dPE5f18zww7dQdtGuXwj50ybPU85RWOSHYuiDUtBWq4Rzt4dygzxY77f2RIAC Hq1Q==
X-Gm-Message-State: AOAM533AVnOFPf+I3A0bTofNH7cCXyBg5mdIXXeV6qBCn655GKuJNw6C BXjjdkWZCG8F2Ceslc3N1E8ZI73LMNh9VPGWk60=
X-Google-Smtp-Source: ABdhPJyU1vuMutmKwnlJFsZvSmIY98DToBhfegHWH39E2VCpBqIABF1Zsqoms3o5lIoJbLKPjs73/wzo5XRn3qjGYi4=
X-Received: by 2002:a50:ba85:: with SMTP id x5mr3995548ede.38.1597947691654; Thu, 20 Aug 2020 11:21:31 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 20 Aug 2020 13:21:30 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Thu, 20 Aug 2020 13:21:30 -0500
Message-ID: <>
Cc:, IDR List <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Idr] Review of draft-abraitis-bgp-version-capability-07
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: Thu, 20 Aug 2020 18:21:35 -0000

On August 20, 2020 at 9:28:42 AM, RFC ISE wrote:



> > (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

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.