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

From: "Susan Hares" <[email-masked]>
Date: Tue, 4 Jun 2019 14:28:22 -0400

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:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, February 11, 2019 10:01 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 4 Jun 2019 22:38:38 -0700

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 <[email-masked]> wrote:
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 5 Jun 2019 09:49:09 -0400

Kireeti:  

If I could think of a sentence that would fix the problem, you would have had it in my response. 

I flagged it for two reasons: 
1) OPS-DIR and SEC-DIR reviews - may think of a sentence to add for operators which I could not. 
 
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. 

I'm excited to see this technology be standardized.  

Cheers, Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, June 5, 2019 1:39 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Sue,

Cheers,
Kireeti

> 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.
> 
> when you buy RMR from a vendor make sure it comes from with  control 
> plane with good security.
> 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 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/
> 
> 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),
> "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
> 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.
> 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.
> 
> 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
> 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.
> 
> While it took me to flights of fantasy where the nodes became 
> intelligent silicon
> clarifying the engineering point, the authors can rewrite the sense of 
> the text.
> 
> brief editorial nits:
> 
> While the authors first formi is current, the change makes a 
> specification clear.
>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 5 Jun 2019 15:00:41 +0000

Hi Sue, all,

From my point of view, probably this sentence could fix the point:

"The extensions proposed do not represent per-se a compromise to network security when control plane is secured, since any manipulation of the content of the messages or even the control plane misinterpretation of the semantics are avoided."

Would it be this ok from your point of view?

Best regards

Luis

-----Mensaje original-----
De: Susan Hares <[email-masked]>
Enviado el: miércoles, 5 de junio de 2019 15:49
Para: 'Kireeti Kompella' <[email-masked]>
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: RE: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Kireeti:

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.

Cheers, Sue

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, June 5, 2019 1:39 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Sue,

Cheers,
Kireeti

> 7) page 11, section 4.3, paragraph 2, sentence 2 (spelling) -

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 5 Jun 2019 12:28:33 -0400

Luis: 

This sentence captures both the original and my desired strengthening of the length to a secure control plane.  

Well done! 

Sue Hares 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Wednesday, June 5, 2019 11:01 AM
To: Susan Hares; 'Kireeti Kompella'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Hi Sue, all,

Best regards

Luis

-----Mensaje original-----
De: Susan Hares <[email-masked]>
Enviado el: miércoles, 5 de junio de 2019 15:49
Para: 'Kireeti Kompella' <[email-masked]>
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: RE: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Kireeti:

Cheers, Sue

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, June 5, 2019 1:39 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] [mpls] Rtgdir early review of draft-ietf-mpls-rmr-09

Sue,

Cheers,
Kireeti