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

[Donatas Abraitis <[e-mail]>]

Hello Alvaro and Adrian,

thank you for the detailed review. I'll look at that carefully next week.

By the way, should I upload a new version with fixes or send a
generated txt here (or pastebin/gist) to review again before pushing
to draft revision?

On Thu, Aug 20, 2020 at 9:55 PM RFC ISE (Adrian Farrel)
<[e-mail]> wrote:
>
> 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]
>


-- 
Donatas Abraitis
Systems Engineer
@: [e-mail]
W: www.hostinger.com