Early Review of draft-ietf-rtgwg-net2cloud-problem-statement-22
review-ietf-rtgwg-net2cloud-problem-statement-22-secdir-early-cooley-2023-04-09-01

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 <linda.dunbar@futurewei.com>
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 <debcooley1@gmail.com>
> *Sent:* Wednesday, January 17, 2024 4:57 AM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org;
> secdir@ietf.org; rtgwg@ietf.org
> *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 <linda.dunbar@futurewei.com>
> 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 <debcooley1@gmail.com>
> *Sent:* Thursday, January 11, 2024 6:55 AM
> *To:* draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org
> *Cc:* secdir@ietf.org; rtgwg@ietf.org
> *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 <linda.dunbar@futurewei.com>
> 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 <debcooley1@gmail.com>
> *Sent:* Tuesday, April 25, 2023 9:02 AM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* secdir@ietf.org;
> draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org
> *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 <linda.dunbar@futurewei.com>
> wrote:
>
> Deb,
>
>
>
> Thank you for the additional comments.
>
>
>
> Resolutions to your comments are inserted below:
>
>
>
> Linda
>
>
>
> *From:* Deb Cooley <debcooley1@gmail.com>
> *Sent:* Thursday, April 20, 2023 9:44 AM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
> *Cc:* secdir@ietf.org;
> draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org
> *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 <debcooley1@gmail.com> 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 <linda.dunbar@futurewei.com> > 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 <debcooley1@gmail.com> > Sent: Sunday, April 9, 2023 6:28 AM >
To: secdir@ietf.org; >
draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org >
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 <noreply@ietf.org> > 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 > > > secdir@ietf.org > > >
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 > > > >