Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kireeti Kompella <kireeti.kompella@gmail.com>
In-Reply-To: <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
Date: Tue, 4 Jun 2019 22:38:38 -0700
Cc: rtg-dir@ietf.org, draft-ietf-mpls-rmr.all@ietf.org, mpls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <01BD9D6B-9D90-4AB4-86FE-15F48B4F1057@gmail.com>
References: <154989728538.29584.3746504660070934932@ietfa.amsl.com>
 <028901d51b03$4add0bf0$e09723d0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/v90k6sJDTcs0x7IgpbbmrXrCShs>
Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
Precedence: list

Sue,

I hear you.  But this is not an RMR issue =E2=80=94 _networking_ is by natur=
e 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 ide=
as.  That said, do you have a suggested change/addition?  I=E2=80=99ll be ha=
ppy 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 the
> second paragraph of section 9 still could be strengthened.=20
>  This sentence is:=20
>=20
> Current: /One can also ask whether the semantic content of these extension=
s
> can be used to compromise=20
> 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 messages."
> /=20
>=20
> Discussion:=20
> The authors are precise in this sentence, the import of this sentence may b=
e
> lost
> on individuals or companies deploying this technology.=20
>=20
> Routing control plane do get compromised.  And when they get=20
> compromised with a network using RMR, they may have network=20
> wide problems.    Therefore, the authors assume that=20
> when you buy RMR from a vendor make sure
> it comes from with  control plane with good security.=20
> 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 the
> text.=20
> I pose the question to the authors, do you think most people will understa=
nd
> that
> this is the requirement you are placing for the "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 routing
> clue,=20
> the person will probably also notice the issue.  By stating it up front, I=

> hope to save
> the security reviewers time. =20
>=20
>=20
> Editorial on -10.txt=20
>=20
> Page 3, section 1, paragraph 3, sentence=20
> General comment:  ", and" - does not seem to make entire sense.
> Old: The intent is not to construct rings in a mess network, and use those=

> for protection./=20
> New: The intent is not to construct rings in a mess network and use 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 considered th=
e
> same as other later WG LC review.
>=20
> overall-comment: Well-written and an exciting new direction.  I 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 suc=
h,
> 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 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 reasoning
> behind it.  As such, it provide no utility to the reader.  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 with a=

> great deal of message exchange does not appear to have these qualities.=20=

> Surely, these authors have considered or tried these issues.
>=20
> 2) Long-term stability of document - in the face of repeated statements of=
 a
> future version of this document.
>=20
> If this is just an interim document, then why is it being standardized.  I=
n
> a specification that is going to include an RFC track, the sttaements of
> scope seem inappropriate in sections 1, 3.3, 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 protocol=

> mechanisms.  However, this document seems to anticipate quick refinement o=
f
> the basic architeture.  If this is really true, then why is this document
> going ot the IESG.  If this is not true, then the scoping in above section=
s
> 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 make
> sense.
>  If you re-ordered the sections, perhaps you could provide additonal depth=

> to section 3.6.
>=20
> 4) paragraph 4.3, last sentence  "The nodes that set their M bit 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 problems
> about how long the bidding for master will take.  Is there a potential for=

> the bidding to repeat over and over.  If so, how does the operator detect
> it.  Can something drop the nodes into membership phase or re-identificati=
on
> phase
> repeated?   While the ring announcement and ring identification cycle beco=
me
> a
> denial-of-service attack on the IGPs announcing the information?  I suspec=
t
> the authors have investigated these points, but the architeture document i=
s
> 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 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 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