I will change my 'early review' to 'has issues'. With respect to mitigations, it is impossible to tell if the proposed mitigations improve security. The mitigations are documented in either expired I-Ds or individual I-Ds which have not been reviewed.
There are other sections that claim to be improvements (Section 5.1) which are clearly not security improvements. Deb On Wed, Jan 17, 2024 at 1:16 PM Linda Dunbar <[email protected]> wrote: > Deb, > > > > Thanks for the quick confirmations of the resolutions to your comments. > > I removed the ones that you have agreed. > > For the remaining suggestions, please see the resolutions below in Purple. > If they are acceptable, we will upload the revision. > > Can you please change your review status from “Not Ready” to “Ready”? > > > > Thank you very much. > > > > Linda > > > > *From:* Deb Cooley <[email protected]> > *Sent:* Wednesday, January 17, 2024 4:57 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 > > > > Inline.... > > > > On Tue, Jan 16, 2024 at 3:53 PM Linda Dunbar <[email protected]> > wrote: > > Deb, > > > > Thank you very much for the review comments. > > Resolutions to your comments have been addressed in the following. Please > let us know if you have more concerns. > > > > Thank you, > > Linda > > > > *From:* Deb Cooley <[email protected]> > *Sent:* Thursday, January 11, 2024 6:55 AM > *To:* [email protected] > *Cc:* [email protected]; [email protected] > *Subject:* Re: [secdir] Secdir early review of > draft-ietf-rtgwg-net2cloud-problem-statement-22 > > > > > > old, I've attempted to clarify: Section 5.1 para 2: The discussion about > the security risk of IPSec group encryption should be added to section 7 > and at least needs to be mentioned as a risk. Group keys are hard to > securely distribute, and they must be handled securely by every party that > holds them. > > [Linda] do you mean repeat the risks in Section 7 which is already > discussed by Section 5.1? or add the following bullet to Section 7’s > security risks? > > · *Group encryption solutions, which aim to scale IPsec key > management, come with some security risks, such as single point of > compromise, key distribution vulnerabilities, and authentication > weaknesses, to name a few. Out of the scope of this document, more in-depth > security risk analysis is needed for using group encryption solutions.* > > > > [Deb] please add the statemet to Section 7. Any group encryption, re-use > of old keys, or other techniques used to help scale IPsec key management > comes with security risk. > > [Linda] Thanks for the suggested wording. How about changing the above > bullet to the following? > > > - *Any group encryption, re-use of old keys, or other techniques used > to help scale IPsec key management comes with security risks, such as > single point of compromise, key distribution vulnerabilities, and > authentication weaknesses, to name a few. Out of the scope of this > document, more in-depth security risk analysis is needed for those > techniques.* > > > > Section 5.1, paragraph 3: The draft referenced here is expired and the > security of the methods would have to be reviewed. (that is listed in > Section 7) > > [Linda] It is Okay to have an expired draft in the “Informative > References”. I’ve seen many RFCs having expired drafts in their > “Information References”. > > > > Section 7 says “A full security evaluation will be needed before > [SECURE-EVPN] can be recommended as a solution to some problems described > in this document.” Is it good enough? > > > > [Deb} I will leave this to the WG to decide. I just looks a little weird > to my eyes (I spend a fair bit of time convincing customers that they > shouldn't implement (or count on) something specified in an expired draft). > > > > Section 5.1: There are no improvements listed that don't impact > security. The section should be renamed. Originally, this was called > 'Scaling issues' vs 'Improvements'. > > > > [Linda] This title was suggested by one of the reviewers, mainly to focus > on analyzing methods that aim to “improvement of IPsec Tunnels > Management”. Is this a major issue? > > > > [Deb] not a big deal, just misleading for the reader. Maybe quantify why > type of improvements are being suggested? They definitely are not security > improvements. > > [Linda] Agree that they are not security improvements. They are the > improvement techniques aiming to scale large number of IPsec tunnels > management. Mainly for some deployment environment that can tolerate those > security risks. > > > > Section 5.2: The draft referenced in this section is an individual draft, > and again the security of the methods would have to be reviewed. > > [Linda] It is okay to reference “individual draft” in the “Informational > References”. How about we add a statement: > > *“The security risks of the proposed method need to be reviewed.”* > > > > [Deb] and please add that statement to Section 7 with the other draft. > > [Linda] Added the following: > > *A full security evaluation will be needed before [SECURE-EVPN] and > [MULTI-SEG-SDWAN] can be recommended as a solution to some problems > described in this document.* > > > > Deb Cooley > > > > On Tue, Apr 25, 2023 at 11:21 AM Linda Dunbar <[email protected]> > wrote: > > Deb, > > > > Can you elaborate some Security Consideration for the “group key > management” that can be included in the Section 7? > > > > Greatly appreciated. > > > > Linda > > > > *From:* Deb Cooley <[email protected]> > *Sent:* Tuesday, April 25, 2023 9:02 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 > > > > 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
