Re: [spring] [RTG-DIR] Review of draft-ietf-spring-segment-routing-msdc-03
> On Mar 7, 2017, at 3:30 PM, Susan Hares <sha...@ndzh.com> wrote: > > Stefano: > > Summary: As I have often said, I believe in helping BGP meet the needs of > operators (DC or BGP), and this includes BGP-LS. If your transition from > OSPF/IS-IS LSPs to BGP in BGP to MPLS is to meet operator needs - great. > Just document the security concern issues (new types of information, privacy > issues on sending link info). > > My "concern" comments on BGP-LS only focus on 3 things: > 1) Upgrade your security section to deal with issues regarding new types of > information and privacy issues on sending link-information (inside DC or DCI) agreed and will do so. Note also that EPE is just one piece of the picture described in the draft. > 1 to 3 paragraphs should be sufficient. I will suggest text. > 2) Be precise in your RFC3107 terminology - agreed. I added some text explaining what we intend by 3107 ebgp and ibgp. > 3) Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as > a legacy issues. ok, will do so. > All response below boil down to this summary. Editorial Nits are your > choice to adopt/not-adopt. IETF LC and IESG review will provide you lots of > feedback on editorial nits. yup, I applied all of them. Thanks. s. > > > Sue > > -Original Message- > From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Stefano Previdi > (sprevidi) > Sent: Tuesday, March 7, 2017 6:21 AM > To: Susan Hares > Cc: rtg-...@ietf.org; spring@ietf.org; i...@ietf.org; > draft-ietf-spring-segment-routing-msdc@ietf.org > Subject: Re: [RTG-DIR] [spring] Review of > draft-ietf-spring-segment-routing-msdc-03 > > Hi Sue, > > thanks for the review. Some comments below. > > >> On Mar 6, 2017, at 5:25 PM, Susan Hares <sha...@ndzh.com> wrote: >> >> Reviewer: Susan Hares >> Review result: Has Issues >> >> The RTG-DIR has the categories: minor concerns or major concerns >> regarding "issues", I wil differentiate my issues by this quality. >> I also have editorial nits regardign under specified text. >> >> Major concerns: >> 1) The security section is not sufficient for any review by the >> Security area >> >> This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that >> defines the BGP Segment attribute. If this attribute is used with >> IPv6, this simply gives more infromation about a link to a next. >> However, the combination of this information with the information >> passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes >> BGP to pass BGP topologies in BGP - requires a better security >> section. BGP-LS was described to be an "information gathering" >> function handled by a few routers on the edge of the network to obtain >> link-state topology information. The BGP peers would carry this >> information in a separate informational stream. With this constraint, >> it was approved by the IESG. > > Stefano: well, we have now different models that have been deployed and > assuming that bgp-ls uses a separate stream is not accurate if we look what’s > in the industry. However, I take your point and I agree that more text in > the security section is required in order to emphasize that the model the > draft addresses is internal (DC and interconnected DC over a > same-administration network). > > Sue: Good. I look forward to your security section. Please note to clearly > state (or reference) whether the interconnected DC is over physically > isolated or logically isolated on shared infrastructure. Please indicated > any privacy issues. > >> draft-ietf-idr-bgpls-segment-routing-epe expands the initial concept >> of BGP-LS from "information gathering" to a full-routing scheme of BGP >> within BGP for data centers and for data center interconnection to the >> network. > > Stefano: EPE defines a model where the topology of the peering point (not the > network, just the peering point) is advertised to an internal server. > Yes, but the topology of peering point may be considered information that > falls under the "privacy" issues in security. The security considerations > should indicate whether you assume the peering point is physically isolated > or shared infrastructure. If shared infrastructure, are you requiring TCP-AO > to e securie. > >> This extension takes it out of the approved range of the BGP-LS. > Stefano: I don’t know what is the “approved range”. To me, bgp-ls carries > topology information. We started with lsdb, then extended to mpls-lsp's,
Re: [spring] [RTG-DIR] Review of draft-ietf-spring-segment-routing-msdc-03
Stefano: Summary: As I have often said, I believe in helping BGP meet the needs of operators (DC or BGP), and this includes BGP-LS. If your transition from OSPF/IS-IS LSPs to BGP in BGP to MPLS is to meet operator needs - great. Just document the security concern issues (new types of information, privacy issues on sending link info). My "concern" comments on BGP-LS only focus on 3 things: 1) Upgrade your security section to deal with issues regarding new types of information and privacy issues on sending link-information (inside DC or DCI) 1 to 3 paragraphs should be sufficient. I will suggest text. 2) Be precise in your RFC3107 terminology - 3) Encourage the use of 4-byte Private AS, and treat 2-byte Private ASes as a legacy issues. All response below boil down to this summary. Editorial Nits are your choice to adopt/not-adopt. IETF LC and IESG review will provide you lots of feedback on editorial nits. Sue -Original Message- From: rtg-dir [mailto:rtg-dir-boun...@ietf.org] On Behalf Of Stefano Previdi (sprevidi) Sent: Tuesday, March 7, 2017 6:21 AM To: Susan Hares Cc: rtg-...@ietf.org; spring@ietf.org; i...@ietf.org; draft-ietf-spring-segment-routing-msdc@ietf.org Subject: Re: [RTG-DIR] [spring] Review of draft-ietf-spring-segment-routing-msdc-03 Hi Sue, thanks for the review. Some comments below. > On Mar 6, 2017, at 5:25 PM, Susan Hares <sha...@ndzh.com> wrote: > > Reviewer: Susan Hares > Review result: Has Issues > > The RTG-DIR has the categories: minor concerns or major concerns > regarding "issues", I wil differentiate my issues by this quality. > I also have editorial nits regardign under specified text. > > Major concerns: > 1) The security section is not sufficient for any review by the > Security area > > This draft depends on IDR WG draft (ietf-idr-bgp-prefix-sid) that > defines the BGP Segment attribute. If this attribute is used with > IPv6, this simply gives more infromation about a link to a next. > However, the combination of this information with the information > passed using draft-ietf-idr-bgpls-segment-routing-epe-09 that utilizes > BGP to pass BGP topologies in BGP - requires a better security > section. BGP-LS was described to be an "information gathering" > function handled by a few routers on the edge of the network to obtain > link-state topology information. The BGP peers would carry this > information in a separate informational stream. With this constraint, > it was approved by the IESG. Stefano: well, we have now different models that have been deployed and assuming that bgp-ls uses a separate stream is not accurate if we look what’s in the industry. However, I take your point and I agree that more text in the security section is required in order to emphasize that the model the draft addresses is internal (DC and interconnected DC over a same-administration network). Sue: Good. I look forward to your security section. Please note to clearly state (or reference) whether the interconnected DC is over physically isolated or logically isolated on shared infrastructure. Please indicated any privacy issues. > draft-ietf-idr-bgpls-segment-routing-epe expands the initial concept > of BGP-LS from "information gathering" to a full-routing scheme of BGP > within BGP for data centers and for data center interconnection to the > network. Stefano: EPE defines a model where the topology of the peering point (not the network, just the peering point) is advertised to an internal server. Yes, but the topology of peering point may be considered information that falls under the "privacy" issues in security. The security considerations should indicate whether you assume the peering point is physically isolated or shared infrastructure. If shared infrastructure, are you requiring TCP-AO to e securie. > This extension takes it out of the approved range of the BGP-LS. Stefano: I don’t know what is the “approved range”. To me, bgp-ls carries topology information. We started with lsdb, then extended to mpls-lsp's, ip tunnels, peering points, and more will come. The security of bgp-ls doesn’t change. It’s the boundary of the network where bgp-ls is applied that matters. Sue: The focus is the security in this sentence. The security case in the original BGP-LS was the transportation of the BGP-LS information (OSPF/ISIS topologies) on a separate network. If you have changed due to customer needs/wants, fine. Just provide the security case in the 3 paragraphs. > Therefore, the security sections in both the IDR WG drafts and this > draft need to describe the new threat scenarios and describe threat > mitigation strategies for deployments. Stefano: I will add more text about the information originated by bgp-ls (or the bgp pr
