I looked at version 26, and apologies for top posting. Section 4, grammar: done!
Section 4.3 para 3: This seems to be better - no mention of MPLS, just private VPNs, which I think is suitably agnostic. Section 5.1: I certainly agree that N*N keys are unmanageable, but I do still think that group key management warrants a mention in Section 7. Deb On Mon, Apr 24, 2023 at 4:53 PM Linda Dunbar <[email protected]> wrote: > Deb, > > > > Thank you for the additional comments. > > > > Resolutions to your comments are inserted below: > > > > Linda > > > > *From:* Deb Cooley <[email protected]> > *Sent:* Thursday, April 20, 2023 9:44 AM > *To:* Linda Dunbar <[email protected]> > *Cc:* [email protected]; > [email protected]; [email protected] > *Subject:* Re: [secdir] Secdir early review of > draft-ietf-rtgwg-net2cloud-problem-statement-22 > > > > 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. > > [Linda] thanks for catching it. > > 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. > > [Linda] Section 4.3 has now changed “Extending Private VPNs to Hybrid Cloud > DCs.”. Private VPNs, including private circuits, MPLS based VPN, use network > service provider’s physical links/wavelengths. Their traffic running over > Private VPNs don’t mix with Internet traffic. Therefore, more secure. > > > > New: Section 5.1: The discussion about the security risk of IPSec group > encryption should be added to section 7. > > > > [Linda] Section 5.1 is about Scaling IPsec, instead of Pairwise Tunnels which > needs N square number of tunnels, the draft suggest improvement. > > > > > > 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 > <https://www/>. > > > 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 > <https://trac/> > > > .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
