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

[Alvaro Retana <[e-mail]>]

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.