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

["Susan Hares" <[e-mail]>]

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:[e-mail]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, May 31, 2019 6:35 AM
To: Mirja Kühlewind; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; 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 <[e-mail]> 
Sent: 31 May 2019 15:18
To: The IESG <[e-mail]>
Cc: [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/idr