Apologies, it has been a busy week...I recognize that writing a draft like this is difficult.
My remaining concerns are: Section 4, sentence 1: Grammar - 'will be mixed of different' should be 'will be a mix of different'. This now says 'a mixed of different'. Most definitely the smallest of nits. New: Section 4.3, para 3: I am unfamiliar with MPLS VPNs, are they really 'more secure' than IPSec? I can easily believe that they have better quality services, and may perform better. New: Section 5.1: The discussion about the security risk of IPSec group encryption should be added to section 7. Deb Cooley On Fri, Apr 14, 2023 at 6:51 AM Deb Cooley <[email protected]> wrote: > I'm including my final set of comments. I made the mistake of submitting the > wrong version. I've noted the ones you have addressed already in blue. I > apologize for the confusion. > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 > <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/22/> > Reviewer: Deb Cooley > Review Date: 2023-04-06 (early review) > > Please note that I know almost nothing about BGP, MPLS or routing. > > The summary of the review is 'not ready'. > > Section 3: perhaps move this whole section to Section 7? Sections 4, 5, and > 6 > seem like they should come before Section 3 anyway? > > > partially done (moved Section 3.5 to 7) > > Section 3.1, para 1, sentence 2: Grammar: 'with more variety of parties' could > be 'with a larger variety of parties.' > > > Apologies, I meant this sentence: 'Cloud GWs need to peer with more variety > of parties, via private circuits or IPsec over public internet.' > > Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? Or > something else? > > > done > > Section 3.1, para 3: By setting up default eBGP routes, these don't count as > routes from an external entity? The rest of the paragraph addresses the > handling of exceeding the maximum route threshold? But there appears to be an > option to keep the BGP session? This paragraph is confusing. > > > done > > Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying to say. > > > done > > Section 3.2, paragraph 3: If there is a site failure, how is the Cloud GW > 'running fine'? Is this GW using a different site? BFD expands to what? > > > done - I understand... > > Section 3.2: Para 1 states why a site might go down. Para 2-6 outline the > routing (?) issues that occur when a site goes down. I think these could be > better organized. Only the last para suggests mitigations. > > > I think most of this fits better into Section 7? > > Section 3.3 I'm not an expert, but isn't this an issue to any routing > scenario? > Can this be combined with Section 3.6? > > > ok > > Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it is a > problem, can you say why? > > > done - this is better! > > Section 3.6, last paragraph: A globally unique name won't 'resolve the same > way from every perspective'? Other than being restricted (previous > paragraph), > what does this mean? If this is covered in the previous para, I would > recommend > deleting the phrase. > > > fine > > Section 4, sentence 1: Grammar - 'will be mixed of different' should be 'will > be a mix of different'. > > Section 4.2, para 2: Use of a shared key in IPSec implies that IKE isn't used > (shared key was only possible with IKEv1 I believe, which is deprecated). I > would remove the phrase 'using a shared key'. > > > On Wed, Apr 12, 2023 at 4:09 PM Linda Dunbar <[email protected]> > wrote: > >> Deb, >> >> We really appreciate your review and comments to the document. Please see >> below for the resolution to your comments. >> >> Linda >> >> -----Original Message----- >> From: Deb Cooley <[email protected]> >> Sent: Sunday, April 9, 2023 6:28 AM >> To: [email protected]; >> [email protected]; [email protected] >> Subject: Re: [secdir] Secdir early review of >> draft-ietf-rtgwg-net2cloud-problem-statement-22 >> >> Note: I hit ‘send’ too early, ugh. Please see the comments on the >> datatracker for the correct version. >> >> Deb Cooley >> >> > On Apr 9, 2023, at 6:59 AM, Deb Cooley via Datatracker < >> [email protected]> wrote: >> > >> > Reviewer: Deb Cooley >> > Review result: Not Ready >> > >> > I have reviewed this document as part of the security directorate's >> > ongoing effort to review all IETF documents being processed by the >> > IESG. These comments were written primarily for the benefit of the >> > security area directors. Document editors and WG chairs should treat >> > these comments just like any other last call comments. >> > >> > Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 >> > Reviewer: Deb Cooley >> > Review Date: 2023-04-06 (early review) >> > >> > Please note that I know almost nothing about BGP, MPLS or routing. >> > >> > The summary of the review is >> > >> > Section 3.1, para 1, sentence 2: Grammar: 'with more variety of >> > parties' could be 'with a larger variety of parties.' >> > >> [Linda] Per RTGarea Director suggestion, the text has been changed to the >> following. Is it Okay with you? >> *Site failures include (but not limited to) a site capacity degradation >> or entire site going down. The reasons for these capacity degradations or >> failures can include: a) fiber cut for links connecting to the site or >> among pods within the site, b) cooling failures, c) insufficient backup >> power, d) cyber threat attacks, e) too many changes outside of the >> maintenance window, or other errors. Fiber-cut is not uncommon within a >> Cloud site or between sites.* >> >> >> > Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? >> > Or something else? >> > >> [Linda] changed. >> >> > Section 3.1, para 3: By setting up default eBGP routes, these don't >> > count as routes from an external entity? The rest of the paragraph >> > addresses the handling of exceeding the maximum route threshold? But >> > there appears to be an option to keep the BGP session? This paragraph >> is confusing. >> [Linda] The intent is to say: >> When inbound routes exceed the maximum routes threshold for a peer, the >> current common practice is generating out of band alerts (e.g., Syslog) via >> management system to the peer, or terminating the BGP session (with cease >> notification messages [RFC 4486] being sent). However, it would be useful >> if IETF can specify some in-band alert messages to indicate the inbound >> routes exceeding the threshold. >> > >> > Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying >> to say. >> > >> [Linda] changed to domain. >> >> > Section 3.2, paragraph 3: If there is a site failure, how is the >> > Cloud GW 'running fine'? Is this GW using a different site? BFD? >> [Linda] Failures within a site like a fiber cut between two racks. So the >> GW is still running fine. >> >> > >> > Section 3.2: Para 1 states why a site might go down. Para 2-6 >> > outline the routing (?) issues that occur when a site goes down. I >> > think these could be better organized. Only the last para suggests >> mitigations. >> [Linda] changed to the "Failures within a site". >> >> > >> > Section 3.3 I'm not an expert, but isn't this an issue to any routing >> scenario? >> > Can this be combined with Section 3.6? >> [Linda] Section 3.3 is to introduce the problem of multiple instances >> available at different sites for one service (such as using ANYCAST >> address). The site with the shortest distance might not be the optimal >> service instance as the site might be overloaded. >> Section 3.6 is about DNS resolution at different sites. . >> >> >> > >> > Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it >> > is a problem, can you say why? >> [Linda] Item 1 is meant to say: >> The difference of routing distances to multiple server instances in >> different edge Cloud is relatively small. Therefore, the edge Cloud that is >> the closest doesn’t contribute much to the performance. >> >> > >> > Section 3.5: I would suggest moving this to Section 7. There are a >> > couple of mitigations listed - anti-DDOS, DTLS, IPSec, monitoring. >> > >> [Linda] Good suggestion. Changed. >> >> > Section 3.6, last paragraph: A globally unique name won't 'resolve >> > the same way from every perspective'? Other than being restricted >> > (previous paragraph), what does this mean? If this is covered in the >> > previous para, I would recommend deleting the phrase. >> > >> [Linda] DNSOPS director insisted on adding this paragraph to empathize >> that not all globally unique names can be resolved. >> >> >> > Stopped at Section 4. >> > >> > >> > >> > _______________________________________________ >> > secdir mailing list >> > [email protected] >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> > ietf.org%2Fmailman%2Flistinfo%2Fsecdir&data=05%7C01%7Clinda.dunbar%40f >> > uturewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240189c75 >> > 3a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3d8eyJW >> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% >> > 7C%7C%7C&sdata=2SVXI%2BaoyU%2Bc4Aa8RRvb6BEQUIMmwTz%2BsqF6Z5o%2FnuU%3D& >> > reserved=0 >> > wiki: >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac >> > .ietf.org%2Ftrac%2Fsec%2Fwiki%2FSecDirReview&data=05%7C01%7Clinda.dunb >> > ar%40futurewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240 >> > 189c753a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3 >> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> > C3000%7C%7C%7C&sdata=vbmjW7gi%2BOgn9xbql5S4grf6NZayrZ%2B%2BgFYC3%2B0yK >> > cE%3D&reserved=0 >> >> >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
