Re: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

[Kireeti Kompella <[e-mail]>]

Sue,

I hear you.  But this is not an RMR issue — _networking_ is by nature distributed.  “IS-IS + open linux without security” or “BGP + open linux without security” or ... would all be bad ideas.  That said, do you have a suggested change/addition?  I’ll be happy to amend the sentence.

Thanks for pointing out the superfluous comma.  Will delete. 

Cheers,
Kireeti

> On Jun 4, 2019, at 11:28, Susan Hares <[e-mail]> wrote:
> 
> Draft-ietf-mpls-rmr-10.txt resolves 98% of my specific comments.  
> 
> Remaining Item: Security section
> Change status: optional.  
> 
> Problem: 
> The security section has been improved, but the following sentence in the
> second paragraph of section 9 still could be strengthened. 
>  This sentence is: 
> 
> Current: /One can also ask whether the semantic content of these 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 messages."
> / 
> 
> Discussion: 
> The authors are precise in this sentence, the import of this sentence may be
> lost
> on individuals or companies deploying this technology. 
> 
> Routing control plane do get compromised.  And when they get 
> compromised with a network using RMR, they may have network 
> wide problems.    Therefore, the authors assume that 
> when you buy RMR from a vendor make sure
> it comes from with  control plane with good security. 
> For example,  RMR + open linux without security - is probably a bad idea.  
> 
> This is an acceptable choice for routing  but not self-evident from the
> text. 
> I pose the question to the authors, do you think most people will understand
> that
> this is the requirement you are placing for the "outside the scope option"?
> 
> If not, will it help to provide additional text? 
> 
> Why mention it now?:  
> If either the security directorate or OPS-DIR reviewer has strong routing
> clue, 
> the person will probably also notice the issue.  By stating it up front, I
> hope to save
> the security reviewers time.  
> 
> 
> Editorial on -10.txt 
> 
> Page 3, section 1, paragraph 3, sentence 
> 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./ 
> New: The intent is not to construct rings in a mess network and use the
> rings in the mess network for protection/
> 
> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Susan Hares
> Sent: Monday, February 11, 2019 10:01 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09
> 
> Reviewer: Susan Hares
> Review result: Not Ready
> 
> This is a routing directorate review.  As such, it should be considered the
> same as other later WG LC review.
> 
> overall-comment: Well-written and an exciting new direction.  I appreciate
> Kireeti and Luis work on this topic.
> 
> 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.
> 
> 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.
> 
> Major concerns
> =======
> 
> 1) Section 8 - Security considerations.
> 
> "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."
> 
> 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. 
> Surely, these authors have considered or tried these issues.
> 
> 2) Long-term stability of document - in the face of repeated statements of a
> future version of this document.
> 
> If this is just an interim document, then why is it being standardized.  In
> 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.
> 
> I agree with the concept of deployment and then refinement of the 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 scoping in above sections
> needs to be refined.
> 
> 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.
> 
> 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".
> 
> 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-identification
> phase
> repeated?   While the ring announcement and ring identification cycle become
> a
> denial-of-service attack on the IGPs announcing the information?  I suspect
> the authors have investigated these points, but the architeture document is
> the place to indicate why the architecture prevents these problems.
> 
> 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.
> 
> brief editorial nits:
> 
> 1) page 4, node index linke
> /upto/ to /up to/
> 
> 2) page 5 (Q_jk): - not define earlier, please define it.
> 
> 3) page 5, section 3 paragraph 2, sentence file
> 
> sentence:
> current: /The default is to send traffic along the shortest path./
> new:  /The default policy is to send traffic along the shortest path./
> 
> 4) page 6, section 3.3 sentences 2
> 
> current:/ The last attribute means/
> new: /The "auto-bundled" attribute means/
> 
> While the authors first formi is current, the change makes a specification
> clear.
> 
> 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) -
> 
> old/exaclty one;/
> new/exactly one/
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>