From: "Susan Hares" <shares@ndzh.com>
To: "'Kireeti Kompella'" <kireeti.kompella@gmail.com>
Cc: <draft-ietf-mpls-rmr.all@ietf.org>,
	<rtg-dir@ietf.org>,
	<mpls@ietf.org>
References: <154989728538.29584.3746504660070934932@ietfa.amsl.com>
 <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
 <01BD9D6B-9D90-4AB4-86FE-15F48B4F1057@gmail.com>
In-Reply-To: <01BD9D6B-9D90-4AB4-86FE-15F48B4F1057@gmail.com>
Date: Wed, 5 Jun 2019 09:49:09 -0400
Message-ID: <00a201d51ba5$73abcb50$5b0361f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQHzVcVMghl3uypfFapdOB3o1ep0cwJFUP9KAiYnRn+mLUHoMA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/GMkRNwSO9w8x57JlMNUvbJ1iDTY>
Subject: Re: [mpls] [RTG-DIR] Rtgdir early review of draft-ietf-mpls-rmr-09
Precedence: list

Kireeti: =20

If I could think of a sentence that would fix the problem, you would =
have had it in my response.=20

I flagged it for two reasons:=20
1) OPS-DIR and SEC-DIR reviews - may think of a sentence to add for =
operators which I could not.=20
=20
2) By stating it - the IESG members who review the mail will know the =
issue and
why this sentence was written this way.  Hopefully, it will reduce =
churn.=20

I'm excited to see this technology be standardized. =20

Cheers, Sue=20

-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Kireeti =
Kompella
Sent: Wednesday, June 5, 2019 1:39 AM
To: Susan Hares
Cc: draft-ietf-mpls-rmr.all@ietf.org; rtg-dir@ietf.org; mpls@ietf.org
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of =
draft-ietf-mpls-rmr-09

Sue,

I hear you.  But this is not an RMR issue =E2=80=94 _networking_ is by =
nature distributed.  =E2=80=9CIS-IS + open linux without =
security=E2=80=9D or =E2=80=9CBGP + open linux without security=E2=80=9D =
or ... would all be bad ideas.  That said, do you have a suggested =
change/addition?  I=E2=80=99ll be happy to amend the sentence.

Thanks for pointing out the superfluous comma.  Will delete.=20

Cheers,
Kireeti

> On Jun 4, 2019, at 11:28, Susan Hares <shares@ndzh.com> wrote:
>=20
> Draft-ietf-mpls-rmr-10.txt resolves 98% of my specific comments. =20
>=20
> Remaining Item: Security section
> Change status: optional. =20
>=20
> Problem:=20
> The security section has been improved, but the following sentence in=20
> the second paragraph of section 9 still could be strengthened.
>  This sentence is:=20
>=20
> Current: /One can also ask whether the semantic content of these=20
> extensions can be used to compromise a network or initiate a denial of =

> service attack. To do so would require either compromising the control =

> plane processing these requests, or manipulating the content of the=20
> messages."
> /
>=20
> Discussion:=20
> The authors are precise in this sentence, the import of this sentence=20
> may be lost on individuals or companies deploying this technology.
>=20
> Routing control plane do get compromised.  And when they get=20
> compromised with a network using RMR, they may have network
> wide problems.    Therefore, the authors assume that=20
> when you buy RMR from a vendor make sure it comes from with  control=20
> plane with good security.
> For example,  RMR + open linux without security - is probably a bad =
idea. =20
>=20
> This is an acceptable choice for routing  but not self-evident from=20
> the text.
> I pose the question to the authors, do you think most people will=20
> understand that this is the requirement you are placing for the=20
> "outside the scope option"?
>=20
> If not, will it help to provide additional text?=20
>=20
> Why mention it now?: =20
> If either the security directorate or OPS-DIR reviewer has strong=20
> routing clue, the person will probably also notice the issue.  By=20
> stating it up front, I hope to save the security reviewers time.
>=20
>=20
> Editorial on -10.txt
>=20
> Page 3, section 1, paragraph 3, sentence General comment:  ", and" -=20
> does not seem to make entire sense.
> Old: The intent is not to construct rings in a mess network, and use=20
> those for protection./
> New: The intent is not to construct rings in a mess network and use=20
> the rings in the mess network for protection/
>=20
> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: Monday, February 11, 2019 10:01 AM
> To: rtg-dir@ietf.org
> Cc: draft-ietf-mpls-rmr.all@ietf.org; mpls@ietf.org; ietf@ietf.org
> Subject: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
>=20
> Reviewer: Susan Hares
> Review result: Not Ready
>=20
> This is a routing directorate review.  As such, it should be=20
> considered the same as other later WG LC review.
>=20
> overall-comment: Well-written and an exciting new direction.  I=20
> appreciate Kireeti and Luis work on this topic.
>=20
> major concerns:
> 1) security (section 8),
> 2) long-term stability of architecture discussion,
> 3) FRR/Protection sections (3.6/3.7), and
> 4) amount of traffic that auto-discovery will place on the network.
>=20
> caveat:  I have not been an WG participant for these discussions.   As =
such,
> I
> am a "fresh" pair of eyes to read the current specification.
>=20
> Major concerns
> =3D=3D=3D=3D=3D=3D=3D
>=20
> 1) Section 8 - Security considerations.
>=20
> "This section states 'It is not anticipated that either the notion of=20
> MPLS rings or the extensions to various protocols to support them will =

> cause security loopholes."
>=20
> This statement provides an opinion of the authors without any=20
> reasoning behind it.  As such, it provide no utility to the reader. =20
> Inquiring minds would like
> to know "why" the authors feel this true and on what basis.   =
Launching a
> new
> type of structure within the MPLS cloud that auto-configures it self=20
> with a great deal of message exchange does not appear to have these =
qualities.
> Surely, these authors have considered or tried these issues.
>=20
> 2) Long-term stability of document - in the face of repeated=20
> statements of a future version of this document.
>=20
> If this is just an interim document, then why is it being=20
> standardized.  In a specification that is going to include an RFC=20
> track, the sttaements of scope seem inappropriate in sections 1, 3.3,=20
> 4.5,  5, 7.1, and 7.2).  This scope should be gathered to a particular =
place and stated in another.
>=20
> I agree with the concept of deployment and then refinement of the=20
> protocol mechanisms.  However, this document seems to anticipate quick =

> refinement of the basic architeture.  If this is really true, then why =

> is this document going ot the IESG.  If this is not true, then the=20
> scoping in above sections needs to be refined.
>=20
> 3)  Fast re-routing installation puts details (3.6) before concepts of =

> protection. Only after I read section 3.7, did section 3.6 start to=20
> make sense.
>  If you re-ordered the sections, perhaps you could provide additonal=20
> depth to section 3.6.
>=20
> 4) paragraph 4.3, last sentence  "The nodes that set their M bit=20
> should be extra careful in advertising their M Bit in subsequent =
tries".
>=20
> As an engineering, I find this description to avoid many of the=20
> problems about how long the bidding for master will take.  Is there a=20
> potential for the bidding to repeat over and over.  If so, how does=20
> the operator detect it.  Can something drop the nodes into membership=20
> phase or re-identification phase
> repeated?   While the ring announcement and ring identification cycle =
become
> a
> denial-of-service attack on the IGPs announcing the information?  I=20
> suspect the authors have investigated these points, but the=20
> architeture document is the place to indicate why the architecture =
prevents these problems.
>=20
> As an editor, I find the anthropomorphism to be unwarranted in the =
text.
> While it took me to flights of fantasy where the nodes became=20
> intelligent silicon
> life forms, I suspect that is not what the authors wanted.   Perhaps =
after
> clarifying the engineering point, the authors can rewrite the sense of =

> the text.
>=20
> brief editorial nits:
>=20
> 1) page 4, node index linke
> /upto/ to /up to/
>=20
> 2) page 5 (Q_jk): - not define earlier, please define it.
>=20
> 3) page 5, section 3 paragraph 2, sentence file
>=20
> sentence:
> current: /The default is to send traffic along the shortest path./
> new:  /The default policy is to send traffic along the shortest path./
>=20
> 4) page 6, section 3.3 sentences 2
>=20
> current:/ The last attribute means/
> new: /The "auto-bundled" attribute means/
>=20
> While the authors first formi is current, the change makes a=20
> specification clear.
>=20
> 5) page 3.5 - please spell out the first use of UHP
> 6) section 3.6/3.7 - could use a diagram.
> 7) page 11, section 4.3, paragraph 2, sentence 2 (spelling) -
>=20
> old/exaclty one;/
> new/exactly one/
>=20
>=20
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>=20