Subject: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Oct 2018 15:29:19 -0400

Les, Stefano, Qin, Jeff, and Clarence: 

This document is generally in excellent shape.   I note the following four
things need to be fixed prior to submitting this to Alvaro Retana: 

1)      Editorial:   

Page 3 states "Unidirectional Packet Loss", but section 3.4 says
"Unidirectional Link Loss TLV"

Please fix this editorial error.  It is a requirement for sending to the
IESG for publication

2)      Security Section - Consider whether you want to add additional
comments in your security section about the distribution of IGP TE
information in BGP.   Even if the node inputted the data into BGP-LS has the
appropriate permissions, BGP blindly sends this to the entire BGP
infrastructure supporting BGP-LS guided only by policy set on nodes.  Is
this what you want? 

If so, I will forward this to the security directorate for their review. 

3)      We do not have any implementations reported. 

Please put the existence of the implementation on the BGP Wiki - under
implementation reports. 

4)      An IPR statement directly from Clarence Fils on this draft.  John
approved the WG LC based on a related IPR statement, but I fear this will
not be sufficient for the current IESG.  Please as Clarence to respond to
this email with an IPR Statement. 

The Shepherd's report is online.  This document will stay in "Waiting
implementation" until John or I receive a report on 2 implementations.
Please place this on the Wiki. 

Cheerily, Susan Hares

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 5 Oct 2018 06:48:46 +0000

Sue -

Thanx for the review.
Responses inline.

From: Susan Hares <[email-masked]>
Sent: Thursday, October 04, 2018 12:29 PM
To: [email-masked]
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: Shepherd's review of draft-ietf-idr-te-pm-bgp

This document is generally in excellent shape.   I note the following four things need to be fixed prior to submitting this to Alvaro Retana:

1)      Editorial:
Page 3 states "Unidirectional Packet Loss", but section 3.4 says "Unidirectional Link Loss TLV"

Please fix this editorial error.  It is a requirement for sending to the IESG for publication

[Les:] I have changed these all to be "Link Loss' - consistent with RFC 7810.

2)      Security Section - Consider whether you want to add additional comments in your security section about the distribution of IGP TE information in BGP.   Even if the node inputted the data into BGP-LS has the appropriate permissions, BGP blindly sends this to the entire BGP infrastructure supporting BGP-LS guided only by policy set on nodes.  Is this what you want?

[Les:] I am having some trouble understanding the motivation for your comment.

IGP TE information has been distributed via BGP-LS since RFC 7752. Why do you believe that the addition of the IGP TE information defined here requires additional security comments?

Please put the existence of the implementation on the BGP Wiki - under implementation reports.

[Les:] I have an implementation report for one Cisco implementation which I will post shortly. A second Cisco implementation is currently in progress.
If other vendors have implementations that they wish to share I would appreciate it if they either contacted me or updated the wiki after I post the initial report.

4)      An IPR statement directly from Clarence Fils on this draft.  John approved the WG LC based on a related IPR statement, but I fear this will not be sufficient for the current IESG.  Please as Clarence to respond to this email with an IPR Statement.

[Les:] I have pinged Clarence on this - please expect a reply from him soon.

   Les

The Shepherd's report is online.  This document will stay in "Waiting implementation" until John or I receive a report on 2 implementations.  Please place this on the Wiki.

Cheerily, Susan Hares

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Oct 2018 09:30:29 -0400

Les:

Thank you for quickly responding to my Shepherd's report.   As far as I can
tell, we have the following item to discuss on the list: 

[Les:] I am having some trouble understanding the motivation for your
comment.

IGP TE information has been distributed via BGP-LS since RFC 7752. Why do
you believe that the addition of the IGP TE information defined here
requires additional security comments?

I would like to structure this discussion in two fashions: technical
information and shepherd's requirements.   As a BGP technical expert I have
specific concerns regarding this information.  However, as a shepherd my
technical concerns are only informational and not required to be resolved
prior to standardizing this document.  As a shepherd, all I require is that
you consider this technical information before we go forward to
standardization.  

I have requested a security directorate review for this document regarding
my concern.  Why?  The reason for requesting this security review now is
that you do not have your implementation reports completed, and I anticipate
issues with the security ADs.   I can make use of this time while we wait
for implementation report to get an early security review of this issue to
resolve any potential issues early. 

Technical information:  IGP information may provide information on places
within a network that have high or critical load.  An attacker could use
this information to launch a directed attack. 

Shepherd requirement:  Please simply consider this area and decide if you
wish to change your text.  Please send me email if you wish to change your
text so that I can review it. 

Please let me know if you have any questions regarding my response.

Cheerily, Sue  

From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 5, 2018 2:49 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp

Sue -

Thanx for the review.

Responses inline.

From: Susan Hares <[email-masked]> 
Sent: Thursday, October 04, 2018 12:29 PM
To: [email-masked]
Cc: Les Ginsberg (ginsberg) <[email-masked]>;
[email-masked]
Subject: Shepherd's review of draft-ietf-idr-te-pm-bgp

1)      Editorial:   

[Les:] I have changed these all to be "Link Loss' - consistent with RFC
7810.

[Les:] I am having some trouble understanding the motivation for your
comment.

IGP TE information has been distributed via BGP-LS since RFC 7752. Why do
you believe that the addition of the IGP TE information defined here
requires additional security comments?

[Les:] I have an implementation report for one Cisco implementation which I
will post shortly. A second Cisco implementation is currently in progress.

If other vendors have implementations that they wish to share I would
appreciate it if they either contacted me or updated the wiki after I post
the initial report.

   Les

Cheerily, Susan Hares

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 5 Oct 2018 16:13:04 +0200

Hi Sue,

> this information to launch a directed attack.

Seems like we have been through this topic already, but it seems to come
back :)

Your point is very valid however it applies to base RFC7752 not to few
add-on extensions as proposed here by Les at other co-authors.

All they are doing here are just defining and loading few additional bags
on the plane which do not make it any more vulnerable. Entire plane which
seems to be already in operation is a problem ..

During time of standardization the promise has been made that it will
operate separate from any other BGP traffic even including different and
separate infrastructure (ex. separate RRs). Well the reality is that this
is not something anyone can control and in practice this promise is not
met.

So IMO we should not put any obstacles into draft-ietf-idr-te-pm-bgp and
allow it to progress.

But if you have solid evidence then base RFC7752 should undergo real
security review and if decided so should be recalled or transport of it
should be clearly decoupled from port 179.

As example as a trivial start the following draft could be used to decouple
it from routing BGP: https://goo.gl/FC9qda

If we want to go further that that we could also move transport of RFC7752
to a message bus (ZMQ, RabbitMQ, NATS or Kafka etc ...to just name a few
options). I am sure there would be many more "stuff" in current BGP which
would gladly jump over to such new transport model - as example even number
of SAFIs could use customized RT based distribution instead of struggling
with pushing RTC like filters around to get tiny subset of entire load
carried in specific SAFIs. Sure it will not happen overnight - but until we
start it will never happen.

Thx,
Robert.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Oct 2018 10:59:05 -0400

Robert: 

I agree that 

“So IMO we should not put any obstacles into draft-ietf-idr-te-pm-bgp and allow it to progress”. 

I also agree we should consider the problem at large. 

Part of the progression, is to ask the question of the security directorate before we go to actual AD and IESG review. Then the shepherd, authors, and security directorate have been considered it.   Hopefully, this early consideration will allow the security ADs quickly review prior to publication.  

Susan Hares 

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, October 5, 2018 10:13 AM
To: [email-masked]
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp

Hi Sue,

Technical information:  IGP information may provide information on places within a network that have high or critical load.  An attacker could use this information to launch a directed attack.

Seems like we have been through this topic already, but it seems to come back :) 

Your point is very valid however it applies to base RFC7752 not to few add-on extensions as proposed here by Les at other co-authors. 

All they are doing here are just defining and loading few additional bags on the plane which do not make it any more vulnerable. Entire plane which seems to be already in operation is a problem .. 

During time of standardization the promise has been made that it will operate separate from any other BGP traffic even including different and separate infrastructure (ex. separate RRs). Well the reality is that this is not something anyone can control and in practice this promise is not met. 

So IMO we should not put any obstacles into draft-ietf-idr-te-pm-bgp and allow it to progress. 

But if you have solid evidence then base RFC7752 should undergo real security review and if decided so should be recalled or transport of it should be clearly decoupled from port 179. 

As example as a trivial start the following draft could be used to decouple it from routing BGP: https://goo.gl/FC9qda 

If we want to go further that that we could also move transport of RFC7752 to a message bus (ZMQ, RabbitMQ, NATS or Kafka etc ...to just name a few options). I am sure there would be many more "stuff" in current BGP which would gladly jump over to such new transport model - as example even number of SAFIs could use customized RT based distribution instead of struggling with pushing RTC like filters around to get tiny subset of entire load carried in specific SAFIs. Sure it will not happen overnight - but until we start it will never happen.

Thx,
Robert.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 6 Oct 2018 19:07:17 +0000

I have uploaded V12 of the document which addresses the Editorial issue (#1 below).

I have also uploaded an implementation report - currently specifying the one known implementation.

   Les

> -----Original Message-----
> From: Les Ginsberg (ginsberg)
> Sent: Thursday, October 04, 2018 11:49 PM
> To: Susan Hares <[email-masked]>; [email-masked]
> Subject: RE: Shepherd's review of draft-ietf-idr-te-pm-bgp
> 
> Sue -
> 
> Thanx for the review.
> Responses inline.
> 
> infrastructure supporting BGP-LS guided only by policy set on nodes.  Is this
> what you want?
> 
> you believe that the addition of the IGP TE information defined here requires
> additional security comments?
> 
> 
> 
> appreciate it if they either contacted me or updated the wiki after I post the
> initial report.
> 
> 
> approved the WG LC based on a related IPR statement, but I fear this will not
> be sufficient for the current IESG.  Please as Clarence to respond to this email
> with an IPR Statement.
> 
> [Les:] I have pinged Clarence on this - please expect a reply from him soon

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 8 Oct 2018 05:04:28 +0000

Implementation report has been updated to show two implementations.

   Les

> Sent: Saturday, October 06, 2018 12:07 PM
> > draft-ietf-idr-te-pm- [email-masked]
> > infrastructure supporting BGP-LS guided only by policy set on nodes.
> > Is this what you want?
> >
> > IGP TE information has been distributed via BGP-LS since RFC 7752. Why
> > do you believe that the addition of the IGP TE information defined
> > here requires additional security comments?
> >
> >
> >
> > [Les:] I have an implementation report for one Cisco implementation
> > which I will post shortly. A second Cisco implementation is currently in
> progress

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 9 Oct 2018 13:43:16 -0400

Les:

Thank you for the 2 implementation report.  Based on the implementation
report, this draft has been sent to the IESG for publication. 

Cheerily, Susan Hares 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, October 8, 2018 1:04 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] Shepherd's review of draft-ietf-idr-te-pm-bgp

   Les

7810.
> > IGP TE information has been distributed via BGP-LS since RFC 7752. 
> > Why do you believe that the addition of the IGP TE information 
> > defined here requires additional security comments?
> >
> >
> >

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr