Re: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-17.txt

Ketan:

The addition of the following language in the security considerations that
indicates that this documents operates within a trusted domain of the
segment routing with BGP-LS peer isolation resolves the majority of my
concerns.   

Thank you for adding this language.   I encourage other IDR participants
concerned about the security of BGP for segment routing to consider whether
this language resolves their concerns.  

Sue Hares 
---------------

   BGP-EPE enables engineering of traffic when leaving the
   administrative domain via an egress BGP router.  Therefore precaution
   is necessary to ensure that the BGP peering information collected via
   BGP-LS is limited to specific controllers or applications in a secure
   manner.  By default, Segment Routing operates within a trusted domain
   (refer Security Considerations section in [RFC8402] for more detail)
   and its security considerations also apply to BGP Peering Segments.
   The BGP-EPE policies are expected to be used entirely within this
   trusted SR domain (e.g. between multiple AS/domains within a single
   provider network).

   The isolation of BGP-LS peering sessions is also required to ensure
   that BGP-LS topology information (including the newly added BGP
   peering topology) is not advertised to an external BGP peering
   session outside an administrative domain.
-----Original Message-----
From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] 
Sent: Friday, October 19, 2018 11:53 PM
To: Susan Hares
Cc: idr@ietf.org
Subject: RE: [Idr] I-D Action:
draft-ietf-idr-bgpls-segment-routing-epe-17.txt

Hi Sue,

As discussed in the context of the
draft-ietf-idr-bgp-ls-segment-routing-ext, this EPE draft also draws on both
the BGP-LS security model in RFC7752 and the SR Security model in RFC8402.

IMO this sufficiently covers the security consideration for this BGP-LS
extension and I request you to progress this draft further. 

As discussed earlier, we can evaluate RFC7752 from security perspective and
I can help with addressing them via an update or a bis, as necessary.

Thanks,
Ketan

-----Original Message-----
From: Susan Hares <shares@ndzh.com> 
Sent: 19 October 2018 22:42
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: idr@ietf.org
Subject: FW: [Idr] I-D Action:
draft-ietf-idr-bgpls-segment-routing-epe-17.txt

Ketan: 

I do not see any reference to a revised RFC7752 in the security section of
this draft.   

If you agree we need a revised RFC7752 draft, please add this text to the
security section.  

"RFC7752 security considerations may need to be expanded to cover the
extensions in this draft.   The need to extend the RFC7752 security is
common to many drafts that utilize BGP-LS defined in  RFC7752 so this work
is being undertaken in an RFC7752bis rather than this draft."  

If you add this, I can start the 1 week review on text.  

Cheerily,  Sue 

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Friday, October 19, 2018 10:31 AM
To: i-d-announce@ietf.org
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering
        Authors         : Stefano Previdi
                          Ketan Talaulikar
                          Clarence Filsfils
                          Keyur Patel
                          Saikat Ray
                          Jie Dong
	Filename        : draft-ietf-idr-bgpls-segment-routing-epe-17.txt
	Pages           : 23
	Date            : 2018-10-19

Abstract:
   Segment Routing (SR) leverages source routing.  A node steers a
   packet through a controlled set of instructions, called segments, by
   prepending the packet with an SR header.  A segment can represent any
   instruction, topological or service-based.  SR segments allow
   steering a flow through any topological path and service chain while
   maintaining per-flow state only at the ingress node of the SR domain.

   This document describes an extension to BGP Link State (BGP-LS) for
   advertisement of BGP Peering Segments along with their BGP peering
   node information so that efficient BGP Egress Peer Engineering (EPE)
   policies and strategies can be computed based on Segment Routing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-17
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-segment-routing-e
pe-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-1
7

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr