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

["RFC ISE (Adrian Farrel)" <[e-mail]>]

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),
[e-mail]