Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

From: <[email-masked]>
Date: Fri, 15 Jan 2021 10:00:35 +0000

Hi Linda,

> From: Linda Dunbar [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2020 4:38 PM
> 
> Bruno,
> 
> Yes, your explanation makes sense. It would be useful to add your
> explanation to the Security Consideration.

As a follow up, FYI, we have just published revision -22.

> The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/
> A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-22

Note that -22, hence the diff, also includes other comments.

Following your review and comments, we seem to be in sync with regards to the analysis. (discussed on the list and copied below). i.e. that the use of a different IGP location  to compute the interior cost toward the BGP next-hop does not change the underlying security issue compared to using BGP Route Reflection.
You proposed to include that specific analysis in the security section in the draft.
The main point is that if an attacker can modify the configuration of the router, bad things may happen.
That point seem generally valid for all features allowing configuration of parameters, in particular to BGP and BGP RR, so in other word not specific to this document.
We discussed that suggestion among authors, and at this point we don't feel that this text specifically belongs to this document. 
We'll wait for more feedback on this point. 

Thanks again for your review and comments.

--Bruno

> Thank you.
> 
> Linda
> 
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Wednesday, December 16, 2020 4:54 AM
> To: Linda Dunbar <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Secdir early review of draft-ietf-idr-bgp-optimal-route-
> reflection-21
> 
> Hi Linda,
> 
> Thanks for your review.
> Please see comments in line
> 
> > From: Linda Dunbar via Datatracker [mailto:[email-masked]]
> >
> > Reviewer: Linda Dunbar
> > Review result: Has Nits
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.
> >  Document editors and WG chairs should treat these comments just like
> > any other  last call comments.
> >
> > This document alters how  BGP Route Reflector computes the optimal
> > routes on behalf of clients. Instead using its own IGP cost to the AS
> > Exit points, the document describes the steps for RR to compute the
> > optimal route by using Clients' position to the AS Exit points. The
> > described method is useful when RR is centralized.  For deployment
> > with distributed RR closer to the clients, the described method
> > doesn't have any benefits.
> >
> > Security Concern:
> > If RR's information of its clients topology is compromised, then the
> > optimal paths selected by the RR might not be accurate anymore.
> 
> I agree with the analysis.
> But it's not clear to me whether you are asking something to be added in the
> draft.
> I'm seeing two cases:
> - If the selected IGP location is configured on the router (RR), the attack
> requires the ability to change the configuration of the router. If an attacker
> can do this, it can do virtually anything (within the router capability). I don't
> feel that "securing access to the router configuration" is a typical point added
> in the security consideration although it probably applies to many
> documents.
> - If the selected IGP location is implicit by using the IP address of the client
> IBGP session there is no new thing to compromise.
> 
> 
> > Minor nits:
> > Page 7: Section 3.2.
> >
> > "If the routing routing optimization requires ..."
> > Is it a typo? duplicated word "routing"?
> >
> > Last sentence: "This needed for use cases ..."
> > Do you mean "This is needed for use cases ..."
> 
> Thanks for the nits.
> Corrected in my local version.
> 
>  Cheers,
> --Bruno
> 
> > Cheers,
> > Linda Dunbar
> >
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> 
> <p></p>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.