Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

From: "Susan Hares" <[email-masked]>
Date: Sun, 2 Jun 2019 22:08:12 -0400

Ketan:

Since Mirja has not answered by direct email asking her what portion of the shepherd report she was confused on,  I will respond to your query about what I think she's concerned about.   

John, I and Alvaro have been concerned about the error handling and message expansion due to BGP-LS extensions.  This is general concern regarding BGP-LS based on the latest work in SPRING.  We felt without some work to address this that the BGP handling of the BGP-LS risk.  .   Error handling which is not correctly handled could become a security risk.    The text of the shepherd's report was given to note these issues so that the IESG knew that the IDR chairs had identified these issues as potential general issues.  I hoped the IESG would see this as pro-active work to identify and fix potential issues in an important technology (SPRING, SR routing). 

In our discussions at the last IETF 104, John and I noted two things had occurred to resolve these issues: 
1)  draft-ketant-idr-rfc7752bis -  
2) draft-ietf-idr-bgp-extended-messages-30.txt  - is heading toward the WG 

I hope that draft-ketant-rfc7752bis.txt will be submitted for WG Adoption soon.    Please submit this draft as soon as you and your authors feel it is ready. 

Perhaps someday Mirja will find my email address and let me know what she is concerned about (smile).  

All is good from your end, 
Sue Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 31, 2019 6:35 AM
To: Mirja Kühlewind; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Hi Mirja,

Thanks for your review and your comments. 

Regarding your first comment, we have the following text in the Introduction section that describes the use-case/applicability that you are referring to in the Security Considerations.

   Segment Routing (SR) allows advertisement of single or multi-hop
   paths.  The flooding scope for the IGP extensions for Segment routing
   is IGP area-wide.  Consequently, the contents of a Link State
   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
   of an IGP area and therefore, by using the IGP alone it is not enough
   to construct segments across multiple IGP Area or AS boundaries.

   The flooding scope for the IGP extensions for Segment routing
   is IGP area-wide.  Consequently, the contents of a Link State
   Database (LSDB) or a Traffic Engineering Database (TED) has the scope
   of an IGP area and therefore, by using the IGP alone it is not enough
   to construct segments across multiple IGP Area or AS boundaries.

   This document describes extensions to BGP-LS to advertise the SR
   information.  An external component (e.g., a controller) can collect
   SR information from across an SR domain (as described in [RFC8402])
   and construct the end-to-end path (with its associated SIDs) that
   need to be applied to an incoming packet to achieve the desired end-
   to-end forwarding.  The SR domain may be comprised of a single AS or
   multiple ASes.

Please let know any suggestions for the same or anything that needs further elaboration.

I will let Sue clarify on the shepherd's report. My impression was that many of the concerns raised were not specific to this particular BGP-LS extension but in general on BGP-LS itself. There has been a lot of discussions in the WG on this topic and work is ongoing to address some of those challenges based on our experience with BGP-LS deployments. One such effort is draft-ketant-idr-rfc7752bis. That said, all concerns raised specifically on this BGP-LS extension during the WGLC and follow-on reviews have been addressed AFAIK to achieve consensus.

Thanks,
Ketan

-----Original Message-----
From: Mirja Kühlewind via Datatracker <[email-masked]> 
Sent: 31 May 2019 15:18
To: The IESG <[email-masked]>
Cc: [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-idr-bgp-ls-segment-routing-ext-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is the following statement on the applicability of this approach in the security consideration section:

“The SR traffic engineering
   policies using the SIDs advertised via BGP-LS are expected to be used
   entirely within this trusted SR domain (e.g. between multiple AS/
   domains within a single provider network).  Therefore, precaution is
   necessary to ensure that the SR information advertised via BGP-LS
   sessions is limited to consumers in a secure manner within this
   trusted SR domain.”

As this is every essential to the scope of the document I would like to see this earlier in the document, e.g. in the intro, and own applicability section, or even in the abstract.

One additional comment on the shepherd write-up:
I find the write-up a bit confusing but I assume that this document has wg consensus, even though it might be rough. There is a request to the IESG to make a judgment if this approach should be taken forward in general. However, if there are no technical or security concerns here and there is wg consensus, I don’t think I understand this request; expect this is not seen as covered by the charter, however, I don’t think this is indicated in the shepherd write-up.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 27 Jun 2019 17:37:42 +0000

Hi Mirja,

I've updated the draft text as described in my response to you below. I've not yet seen your views on these proposals, but I hope they address your comments.

The version 16 of the draft has been posted to address your and other comments from the IESG review:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-16 

Thanks,
Ketan

-----Original Message-----
From: Ketan Talaulikar (ketant) 
Sent: 31 May 2019 18:31
To: Mirja Kuehlewind <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Hi Mirja,

Please check inline below.

-----Original Message-----
From: Mirja Kuehlewind <[email-masked]> 
Sent: 31 May 2019 17:50
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-ls-segment-routing-ext-15: (with COMMENT)

Hi Ketan,

There are two points that I think could be made more clear in the introduction: 

a) that the use case is e.g. "between multiple AS/domains within a single provider network” -> Talk about the need of trust between these domain would be good.

[KT] This document refers to RFC8402 for the SR Domain term (https://tools.ietf.org/html/rfc8402#section-2). The need for trust is also described in RFC8402 which we borrow (https://tools.ietf.org/html/rfc8402#section-8) by reference. However, RFC8402 goes more into the details of the high level architecture and more specific the data plane details. Hence, we've introduced the additional text in the Security Consideration sections of this document to extend it so as to cover BGP since BGP sessions are likely to be formed outside of this "single provide network". How about the following change to the last sentence in the Introduction section 1?

OLD
The SR domain may be comprised of a single AS or multiple ASes.
/OLD

NEW
SR operates within a trusted domain consisting of a single or multiple ASes managed by the same administrative entity e.g. within a single provider network.
/NEW

b) A warning about the consequences if these information lease the trusted domain.

[KT] Since the SR information that we are talking about is actually a subset of the IGP link-state information, the implications for it leaving the trusted domain are the same as explained in RFC7752 Security Considerations. Specifically, it has the following text that applies to this BGP-LS extensions as well (indicated by reference to RFC7752 in the Securities Consideration section 5).

   Additionally, it may be considered that the export of link-state and
   TE information as described in this document constitutes a risk to
   confidentiality of mission-critical or commercially sensitive
   information about the network.  

Hence, I didn't think of repeating the same.  How about if we change the following text in the Security Considerations section 5 though to make this more clear?

OLD
Therefore, precaution is necessary to ensure that the SR information advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain.
/OLD

NEW
Therefore, precaution is necessary to ensure that the link-state information (including SR information) advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain. 
/NEW

Thanks!
Mirja

> On 31. May 2019, at 12:35, Ketan Talaulikar (ketant) <[email-masked]> wrote:
> 
> Hi Mirja,
>