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

[Mirja Kuehlewind <[e-mail]>]

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.

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

Thanks!
Mirja



> On 31. May 2019, at 12:35, Ketan Talaulikar (ketant) <[e-mail]> wrote:
> 
> 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.
> 
>