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

[Donatas Abraitis <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr