Re: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22

[Deb Cooley <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> *Sent:* Wednesday, January 17, 2024 4:57 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Thursday, January 11, 2024 6:55 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Tuesday, April 25, 2023 9:02 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]>
> wrote:
>
> Deb,
>
>
>
> Thank you for the additional comments.
>
>
>
> Resolutions to your comments are inserted below:
>
>
>
> Linda
>
>
>
> *From:* Deb Cooley <[e-mail]>
> *Sent:* Thursday, April 20, 2023 9:44 AM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]>
> Sent: Sunday, April 9, 2023 6:28 AM
> To: [e-mail];
> [e-mail]; [e-mail]
> 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 <[e-mail]>
> 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
>
> > [e-mail]
>
> > 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
>
>
>
>