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

[Linda Dunbar <[e-mail]>]

Deb,

Is our proposed text okay with you?

Thank you,

Linda

From: Linda Dunbar
Sent: Tuesday, January 30, 2024 11:14 AM
To: Deb Cooley <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22

Deb,

The proposed scheme is for striking a balance between mitigating the complexity of managing many IPsec tunnels in a large-scale SD-WAN network and improving security. It is a compromise, specifically Section 5.1, for improving IPsec Tunnel Management.
How about we add the following paragraph to the Security consideration?

  *   Striking a balance between improved IPsec tunnel management outlined in this document and maintaining robust security is a delicate consideration. Simplifying the IPsec tunnel management to reduce management complexity for large SD-WAN networks might come with the inherent risk of decreased security. Careful consideration of the specific deployments, coupled with regular security assessments, is crucial to ensure the integrity and confidentiality of the transmitted data.

Please let us know if the change is acceptable.

Thank you,
Linda
From: Deb Cooley <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, January 24, 2024 5:59 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, January 17, 2024 4:57 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, January 11, 2024 6:55 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, April 25, 2023 9:02 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Deb,

Thank you for the additional comments.

Resolutions to your comments are inserted below:

Linda

From: Deb Cooley <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 20, 2023 9:44 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Sunday, April 9, 2023 6:28 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
> ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Fsecdir&data=05%7C01%7Clinda.dunbar%40f
> uturewei.com<http://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<http://ietf.org/>%2Ftrac%2Fsec%2Fwiki%2FSecDirReview&data=05%7C01%7Clinda.dunb
> ar%40futurewei.com<http://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