Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

[John E Drake <[e-mail]>]

Hi,

What he said.

Yours Irrespectively,

John

From: Idr <[e-mail]> On Behalf Of Robert Raszuk
Sent: Friday, October 19, 2018 3:08 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; Yoav Nir <[e-mail]>; [e-mail]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi Sue,

It seems that we have arrived here at a point that indeed further discussion and clarification is needed.

Yes RFC7752 has issues in the way it is designed ... those issues are there since day one.

Just to name a few:

* Point to multipoint protocol is used as a container to distribute point to point information.
* Fate sharing separation is not enforced in any way and various address families are send via the same BGP infrastructure
* The growth of the amount of information being carried by BGP-LS can impact bgp processing (ex: update generation) of other types of SAFIs
* More and more applications want have a free ride on this transport - othen only because it is already there.

We should discuss those in a separate thread if RFC7752bis is needed or perhaps other work can offer alternate transport for BGP-LS be it
an enforced different TCP session or in general for link state type of data (BMP analogy for IGP).

However IMO non of the above is about security.

SAFIs just do not get advertised automagically to attackers. For further scoping tools like local BGP policy is already in place today. As mentioned
use of NO-EXPORT can be applied today with no new draft needed.

So to proceed I would like to see a list of valid security issues of RFC7752. If none will be produced all companion work should be progressed
with their current security sections just referencing RFC7752 or RFC4271.

Kind regards,
Robert



On Fri, Oct 19, 2018 at 7:07 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
Les:

I apologize if my email message was unclear.   We both agree that your draft is not related to SR routing.   SR routing is related to BGP-LS as a transport mechanism for information.

I agree that RFC7752 had traffic engineering information.  However, that traffic engineering information almost got that draft rejected by the IESG at the time.  As my previous message to this list indicated, we got agreement on RFC7752 based on limiting that information and the assurance that BGP-LS nodes were deployed on a separate set of nodes.  Expanding the traffic engineering information beyond RFC7752 re-opens all the security issues and questions from RFC7752’s original review.

The security directorate reviewer is asking these security questions.  The security directorate does have people with both routing and security experts.

SR routing is also expanding the information past the original RFC7752.   The expansions requested by SR routing also re-open those original security questions and issues.

One way to answer these questions is to provide a  RFC7752bis with an updated security section.  If you agree with this approach, I suggest simply referring to a RFC7752bis that in your security section.   If you disagree that an update to the RFC7752bis is required, we can start a thread on that point.

Did this message clarify my earlier brief message?  Do you want to continue to discuss the need for RFC7752bis?

Cheerily, Sue