Subject: Secdir early review of draft-ietf-idr-te-pm-bgp-13

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Oct 2018 14:18:06 -0700

Reviewer: Yoav Nir
Review result: Has Nits

This is an early review with a specific request to review the Security
Considerations section.

The draft adds a bunch of TLVs to be sent from routers regarding the link state
of the link used for IGP. The draft references RFC 7752 which defined earlier
TLVs used to carry NLRI (reachability) information.

What I found difficult about both 7752 and this draft is the vagueness about
who the consumer of this information is. The abstract of 7752 begins like this:
"In a number of environments, a component external to a network is called upon
to perform computations based on the network topology and current state of the
connections within the network, including Traffic Engineering (TE)
information." There is also a diagram with information flowing to a "consumer"
and that's it. Is it an SDN controller? Some kind of application?

OK. On to the Security Considerations section. It begins with a statement that
this does not affect the security model of BGP.  Although that is just claimed
and not supported in text, it seems reasonable. I should note that this
paragraph is copied from 7752.

The second (and last) paragraph in the security considerations section talks
about the new attributes. It mentions that security and authentication are
assumed to be used just as in RFCs 7810 and 7471. With proper authentication
this information is not sent except to the proper consumer. However, there is
an important difference that I think needs to be addressed. 7810 and 7471 are
about IS-IS and OSPF respectively. There routing protocols are typically used
in closed environments, and the Security Considerations of 7810 state that
explicitly. BGP (the subject of this document) is different in that it is
typically used all over the Internet. Without further clarity about who and
where the "consumer" is, it has to be assumed that the information might at
least leak out.

Another issue I have with this section is that the draft specifies how to send
new information (the link state TLVs) from one node to another. This is
information that was not sent before. When a change like that is made, I think
the Security Considerations section should justify why it is OK to distribute
this information. Typically you need to justify that leaking this information
(to the intended recipient or to the rest of the world) does not (1) make it
easier to attack some part of the system, or (2) distributes privacy-sensitive
information, or (3) undermines some other confidentiality interest. I think
it's fairly easy to make the argument that the information in these TLVs does
not do any of the above, but the argument should be made.  The last paragraph
in the Security Considerations section of RFC 7752 has just such an argument.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Oct 2018 23:52:04 +0000

Yoav -

Thanx for the review.

I'll preface my remarks by saying I am a big believer in modularity. If a referenced document has already covered an issue I strongly believe we are better off referencing that document than trying to repeat/restate what the referenced document has said.

There are only two things that can happen when we repeat/restate:

1)We are redundant

2)We introduce ambiguity

Neither of these is desirable.

Responses inline.

> -----Original Message-----

> From: Yoav Nir <[email-masked]>

> Sent: Tuesday, October 16, 2018 2:18 PM

> To: [email-masked]

> Cc: [email-masked]; [email-masked]; [email-masked]

> Subject: Secdir early review of draft-ietf-idr-te-pm-bgp-13

> The draft adds a bunch of TLVs to be sent from routers regarding the link

> state of the link used for IGP. The draft references RFC 7752 which defined

> earlier TLVs used to carry NLRI (reachability) information.

> "In a number of environments, a component external to a network is called

> upon to perform computations based on the network topology and current

> state of the connections within the network, including Traffic Engineering

> (TE) information." There is also a diagram with information flowing to a

> "consumer"

[Les:] The diagram you are referring to seems most likely to be in RFC 7752 since there is no such diagram in this draft.

Which leads me to say if you feel this is insufficient then it needs to be taken up in the context of RFC 7752 - not this draft.

Hopefully this makes sense to you as well.

> assumed to be used just as in RFCs 7810 and 7471. With proper

> authentication this information is not sent except to the proper consumer.

> However, there is an important difference that I think needs to be

> addressed. 7810 and 7471 are about IS-IS and OSPF respectively. There

> routing protocols are typically used in closed environments, and the Security

> Considerations of 7810 state that explicitly. BGP (the subject of this

> document) is different in that it is typically used all over the Internet. Without

> further clarity about who and where the "consumer" is, it has to be assumed

> that the information might at least leak out.

[Les:] I think you have misinterpreted this paragraph. (emphasis added below)

" The IGP

   instances originating these TLVs are assumed to have all the required

   security and authentication mechanism (as described in [RFC7810] and

   [RFC7471]) in order to prevent any security issue when propagating

   the TLVs into BGP-LS."

What we are stating here is that when the IGP advertisements are sent the security/authentication mechanisms specified in the IGP drafts applies.

This is NOT trying to apply RFC7810/RFC7471 to the new BGP advertisements.

The security issues related to the new BGP advertisements are discussed in the previous paragraph.

> information that was not sent before. When a change like that is made, I

> think the Security Considerations section should justify why it is OK to

> distribute this information. Typically you need to justify that leaking this

> information (to the intended recipient or to the rest of the world) does not

> (1) make it easier to attack some part of the system, or (2) distributes

> privacy-sensitive information, or (3) undermines some other confidentiality

> interest. I think it's fairly easy to make the argument that the information in

> these TLVs does not do any of the above, but the argument should be made.

> The last paragraph in the Security Considerations section of RFC 7752 has just

> such an argument.

[Les:] Security sections in RFC7810/RFC7471 directly address this point.

WE could repeat some of that here – but as per my “opening statement” I am reluctant to do so.

What do you think?

   Les

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Oct 2018 21:13:47 +0300

Hi, Les.

I agree that my diagram comment is directed mostly at 7752. However, the RFCs that we produce are intended to be readable by the general technical community, not just the experts in the working group. For the same reason that we are required to expand acronyms on first use, I think it makes sense for a document that describes new information being sent to identify the target. I will drop this point, though, because it is a general comment rather than a secdir issue.

I agree about not needing to repeat information that is already stated elsewhere, but you do need to point to it, as you do with the general security model of BGP (first paragraph), and as you do with the paragraph describing how the transport of attributes is secured (second paragraph). That part is fine. 

RFC 7810 and 7471 describe the new information to be sent, but they are about IS-IS and OSPF. The Security considerations section in 7810 contains the following text: "It is anticipated that in most deployments, the IS-IS protocol is used within an infrastructure entirely under control of the same operator.” and continues to discuss MITM attacks if this is not the case.  Can the same assumption be made about BGP?  That is the part that I think is missing. Either state that where BGP-LS is used the assumption can be made, or justify why there is no risk even when the information is propagated to infrastructure that is not under control of a single operator.   The difference between BGP and either IS-IS or OSPF is not part of those other documents, so IMO it should be stated here.

Yoav

> On 17 Oct 2018, at 2:52, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Yoav -
>  
> Thanx for the review.
>  
> > From: Yoav Nir <[email-masked] <mailto:[email-masked]>>
> > To: [email-masked] <mailto:[email-masked]>
> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Oct 2018 19:40:12 +0000

Yoav –

I think we are converging.
Inline.

From: Yoav Nir <[email-masked]>
Sent: Wednesday, October 17, 2018 11:14 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi, Les.

[Les:] I agree with this.
If we look at the Security section of RFC 7752 we see a number of issues discussed. If we were to add the following into this document would it suffice?

“Security considerations for acquiring and distributing BGP-LS information are discussed in RFC7752.”

I’d like to point out that this document is just one of many (existing and yet to be written) extensions to RFC 7752. Given the way BGP-LS has been defined, every time we define new information to be advertised by an IGP we have to write a BGP-LS draft defining how that information is to be advertised in BGP-LS. So this issue is going to come up over and over. I hope what we are doing in this document is a good model for Security Considerations in all of these types of drafts ie.,

1)Reference RFC 7752 Security discussion.
2)Reference the relevant IGP RFC Security discussion to cover security issues specific to the class of information covered by the draft

What we lack at the moment is #1 above.

Does this work?

   Les

Yoav

On 17 Oct 2018, at 2:52, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Yoav -

Thanx for the review.

1)We are redundant
2)We introduce ambiguity

Responses inline.

> From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

" The IGP

What do you think?

   Les

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Oct 2018 19:38:21 +0300

Hi, Les.

I think we are converging, but haven’t converged yet. 

Here’s what is still missing for me: You are adding some new TLVs to pass into BGP-LS. Let’s pick one at random —  the Unidirectional Utilized Bandwidth — as an example.  You are claiming two things about this TLV:
That RFC 7752 already has text about sending other TLVs in BGP-LS.
That RFC 7810 and 7471 have text about sending Unidirectional Utilized Bandwidth in IS-IS and OSPF.

Both of these are true, but I claim that even taken together they are not enough. BGP runs in different environments than OSPF, so a statement that sending Unidirectional Utilized Bandwidth in OSPF is safe is not sufficient for proving it safe in BGP-LS.  Similarly, the fact that the “Prefix Metric” TLV is safe to send over BGP-LS is no proof that sending Unidirectional Utilized Bandwidth is safe.

I’m missing a paragraph making the claim that distributing Unidirectional Utilized Bandwidth (and the other TLVs) over BGP-LS is safe. 

Hope this helps

Yoav

> On 17 Oct 2018, at 22:40, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Yoav –
>  
> To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 17 Oct 2018, at 2:52, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Yoav -
>  
> Thanx for the review.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Oct 2018 18:00:13 +0000

Yoav –

In regards to the risks associated with advertising the specific information covered in this draft we have a statement in the IGP drafts:

From RFC7810

“The sub-TLVs introduced in this document allow an operator to
   advertise state information of links (bandwidth, delay) that could be
   sensitive and that an operator may not want to disclose.”

In regards to the risks associated with sending information via BGP-LS we have a number of statements in RFC 7752 – most relevant is:

“Additionally, it may be considered that the export of link-state and
   TE information as described in this document constitutes a risk to
   confidentiality of mission-critical or commercially sensitive
   information about the network.”

So long as there are references to both the IGP RFCs and RFC 7752 I am therefore hard pressed to understand what else could be usefully said.
Certainly the risks associated with the BGP-LS transport mechanism are not altered by adding some new TLVs – and since the IGP RFCs have already covered risks associated with the specific class of information (not simply the risks associated with the transport mechanism) you are going to have to provide more specifics on what can meaningfully be said that is not already covered in the references.

???

   Les

Sent: Thursday, October 18, 2018 9:38 AM

Hi, Les.

  1.  That RFC 7752 already has text about sending other TLVs in BGP-LS.
  2.  That RFC 7810 and 7471 have text about sending Unidirectional Utilized Bandwidth in IS-IS and OSPF.

Hope this helps

Yoav

On 17 Oct 2018, at 22:40, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Yoav –

From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 17, 2018 11:14 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi, Les.

Does this work?

   Les

Yoav

Yoav -

Thanx for the review.

1)We are redundant
2)We introduce ambiguity

Responses inline.

" The IGP

What do you think?

   Les

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Oct 2018 19:26:42 -0500

> Certainly the risks associated with the BGP-LS transport mechanism are not altered by adding some new TLVs – and since the IGP RFCs have already covered risks associated with the specific class of…

My apologies for jumping in in the middle, but IIUC the IGP RFCs have
covered the risks associated with a specific class of information, *under
the assumption that the transport mechanism is within a single AS and
administrative domain*.  Yoav is pointing out that the risks for that
information may change when the distribution is over a broader domain than
the one for which the previous analysis was performed.

-Ben

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 00:40:51 +0000

Ben -

Inline.

> From: Benjamin Kaduk <[email-masked]>
> Sent: Thursday, October 18, 2018 5:27 PM
> Cc: Yoav Nir <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-idr-
> [email-masked]; [email-masked]
> Subject: Re: [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
> 
> > In regards to the risks associated with advertising the specific information
> covered in this draft we have a statement in the IGP drafts:
> >
> > From RFC7810
> >
> > In regards to the risks associated with sending information via BGP-LS we
> have a number of statements in RFC 7752 – most relevant is:
> >
> > So long as there are references to both the IGP RFCs and RFC 7752 I am
> therefore hard pressed to understand what else could be usefully said.
> > Certainly the risks associated with the BGP-LS transport mechanism are not
> altered by adding some new TLVs – and since the IGP RFCs have already
> covered risks associated with the specific class of information (not simply the
> risks associated with the transport mechanism) you are going to have to
> provide more specifics on what can meaningfully be said that is not already
> covered in the references.
> 
> covered the risks associated with a specific class of information, *under the
> assumption that the transport mechanism is within a single AS and

[Les:] IGP RFCs talk both about the risks associated with the transport (which are indeed bound to a single AS)  and the risks associated with the particular class of information.

RFC 7752 talks about the risks associated with distribution using BGP-LS as the transport and the risks associated with the class of information.

Please read https://tools.ietf.org/html/rfc7810#section-11 and https://tools.ietf.org/html/rfc7752#section-8 in their entirety.

Unless you want to argue that the risk associated with distributing the information defined in this document is qualitatively different than the risk associated with (for example) "Unreserved Bandwidth" defined in https://tools.ietf.org/html/rfc7752#section-3.3.2  I have no idea what to say. You are going to have to help me here.

   Les

> > Here’s what is still missing for me: You are adding some new TLVs to pass
> into BGP-LS. Let’s pick one at random —  the Unidirectional Utilized
> Bandwidth — as an example.  You are claiming two things about this TLV:
> >
> > Both of these are true, but I claim that even taken together they are not
> enough. BGP runs in different environments than OSPF, so a statement that
> sending Unidirectional Utilized Bandwidth in OSPF is safe is not sufficient for
> proving it safe in BGP-LS.  Similarly, the fact that the “Prefix Metric” TLV is
> safe to send over BGP-LS is no proof that sending Unidirectional Utilized
> Bandwidth is safe.
> >
> > I’m missing a paragraph making the claim that distributing Unidirectional
> Utilized Bandwidth (and the other TLVs) over BGP-LS is safe.
> >
> > Hope this helps
> >
> > Yoav
> >
> >
> > On 17 Oct 2018, at 22:40, Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Yoav –
> >
> > To: Les Ginsberg (ginsberg)
> > <[email-masked]<mailto:[email-masked]>>
> > Cc: [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:[email-masked]>;
> > [email-masked]<mailto:draft-ietf-idr-te-pm-bgp.
> > [email-masked]>
> > I agree that my diagram comment is directed mostly at 7752. However, the
> RFCs that we produce are intended to be readable by the general technical
> community, not just the experts in the working group. For the same reason
> that we are required to expand acronyms on first use, I think it makes sense
> for a document that describes new information being sent to identify the
> target. I will drop this point, though, because it is a general comment rather
> than a secdir issue.
> >
> > I agree about not needing to repeat information that is already stated
> elsewhere, but you do need to point to it, as you do with the general security
> model of BGP (first paragraph), and as you do with the paragraph describing
> how the transport of attributes is secured (second paragraph). That part is
> fine.
> >
> > RFC 7810 and 7471 describe the new information to be sent, but they are
> about IS-IS and OSPF. The Security considerations section in 7810 contains
> the following text: "It is anticipated that in most deployments, the IS-IS
> protocol is used within an infrastructure entirely under control of the same
> operator.” and continues to discuss MITM attacks if this is not the case.  Can
> the same assumption be made about BGP?  That is the part that I think is
> missing. Either state that where BGP-LS is used the assumption can be made,
> or justify why there is no risk even when the information is propagated to
> infrastructure that is not under control of a single operator.   The difference
> between BGP and either IS-IS or OSPF is not part of those other documents,
> so IMO it should be stated here.
> >
> > If we look at the Security section of RFC 7752 we see a number of issues
> discussed. If we were to add the following into this document would it
> suffice?
> >
> > I’d like to point out that this document is just one of many (existing
> > and yet to be written) extensions to RFC 7752. Given the way BGP-LS
> > has been defined, every time we define new information to be
> > advertised by an IGP we have to write a BGP-LS draft defining how that
> > information is to be advertised in BGP-LS. So this issue is going to
> > come up over and over. I hope what we are doing in this document is a
> > good model for Security Considerations in all of these types of drafts
> > ie.,
> >
> > 2)Reference the relevant IGP RFC Security discussion to cover security
> > issues specific to the class of information covered by the draft
> >
> > On 17 Oct 2018, at 2:52, Les Ginsberg (ginsberg)
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Yoav -
> >
> > Thanx for the review.
> >
> > I'll preface my remarks by saying I am a big believer in modularity. If a
> referenced document has already covered an issue I strongly believe we are
> better off referencing that document than trying to repeat/restate what the
> referenced document has said.
> > > Cc: [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:draft-ietf-idr-te-pm-bg
> > > [email-masked]>
> > > This is an early review with a specific request to review the
> > > Security Considerations section.
> > >
> > > The draft adds a bunch of TLVs to be sent from routers regarding the
> > > link state of the link used for IGP. The draft references RFC 7752
> > > which defined earlier TLVs used to carry NLRI (reachability) information.
> > >
> > > What I found difficult about both 7752 and this draft is the
> > > vagueness about who the consumer of this information is. The abstract of
> 7752 begins like this:
> > > "In a number of environments, a component external to a network is
> > > called upon to perform computations based on the network topology
> > > and current state of the connections within the network, including
> > > Traffic Engineering
> > > (TE) information." There is also a diagram with information flowing
> > > to a "consumer"
> > [Les:] The diagram you are referring to seems most likely to be in RFC 7752
> since there is no such diagram in this draft.
> > Which leads me to say if you feel this is insufficient then it needs to be
> taken up in the context of RFC 7752 - not this draft.
> >
> > > OK. On to the Security Considerations section. It begins with a
> > > statement that this does not affect the security model of BGP.
> > > Although that is just claimed and not supported in text, it seems
> > > reasonable. I should note that this paragraph is copied from 7752.
> > >
> > > The second (and last) paragraph in the security considerations
> > > section talks about the new attributes. It mentions that security
> > > and authentication are assumed to be used just as in RFCs 7810 and
> > > 7471. With proper authentication this information is not sent except to
> the proper consumer.
> > > addressed. 7810 and 7471 are about IS-IS and OSPF respectively.
> > > There routing protocols are typically used in closed environments,
> > > and the Security Considerations of 7810 state that explicitly. BGP
> > > (the subject of this
> > > document) is different in that it is typically used all over the
> > > Internet. Without further clarity about who and where the "consumer"
> > > is, it has to be assumed that the information might at least leak out.
> > >
> > What we are stating here is that when the IGP advertisements are sent the
> security/authentication mechanisms specified in the IGP drafts applies.
> > > Another issue I have with this section is that the draft specifies
> > > how to send new information (the link state TLVs) from one node to
> > > another. This is information that was not sent before. When a change
> > > like that is made, I think the Security Considerations section
> > > should justify why it is OK to distribute this information.
> > > Typically you need to justify that leaking this information (to the
> > > intended recipient or to the rest of the world) does not
> > > (1) make it easier to attack some part of the system, or (2)
> > > distributes privacy-sensitive information, or (3) undermines some
> > > other confidentiality interest. I think it's fairly easy to make the
> > > argument that the information in these TLVs does not do any of the
> above, but the argument should be made.
> > > The last paragraph in the Security Considerations section of RFC
> > > 7752 has just such an argument.
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 18 Oct 2018 19:58:51 -0500

> Unless you want to argue that the risk associated with distributing the information defined in this document is qualitatively different than the risk associated with (for example) "Unreserved Bandw…

I'm not sure I can commit to that reading list until the document gets on a
telechat (this week's is a pretty big one), but hopefully Yoav can work on
a faster scale than me.  Thank you for the specific references; it does
seem like we can converge pretty quickly.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Oct 2018 21:18:00 -0400

Ben:

Thank you for helping this discussion. 

Sue Hares 
IDR co-chair

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, October 18, 2018 8:59 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; [email-masked]; Yoav Nir; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

On Fri, Oct 19, 2018 at 12:40:51AM +0000, Les Ginsberg (ginsberg) wrote:
> > Cc: Yoav Nir <[email-masked]>; [email-masked]; [email-masked]; 
> > draft-ietf-idr- [email-masked]; [email-masked]
> > altered by adding some new TLVs – and since the IGP RFCs have 
> > already covered risks associated with the specific class of 
> > information (not simply the risks associated with the transport 
> > mechanism) you are going to have to provide more specifics on what 
> > can meaningfully be said that is not already covered in the references.
> > 
> > My apologies for jumping in in the middle, but IIUC the IGP RFCs 
> > have covered the risks associated with a specific class of 
> > information, *under the assumption that the transport mechanism is 
> > within a single AS and administrative domain*.  Yoav is pointing out 
> > that the risks for that information may change when the distribution 
> > is over a broader domain than the one for which the previous analysis was performed.
> > 
> 

I'm not sure I can commit to that reading list until the document gets on a telechat (this week's is a pretty big one), but hopefully Yoav can work on a faster scale than me.  Thank you for the specific references; it does seem like we can converge pretty quickly.

-Ben

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Oct 2018 08:51:46 +0200

Hello Benjamin,

Not sure if you have spotted similar comment made to IDR regarding this
topic, but your comment seems to indicate that here we are about to define
ways to carry nicely scoped IGP information into BGP. Well that has already
happened with RFC7752 and your comment or for that matter Yoav's remarks
are indeed spot on but to the security discussion on RFC7752 and IMO not
any follow up extensions of it.

Sure - as observed by Sue - one may argue that providing more information
about the network to the potential attacker makes the network weaker, but
the cure for that is to prevent the leaks and reduce probability of
intercepting new information by unauthorized parties.

BGP-LS is already defined in a new SAFI what by itself does provide nice
level of isolation. RFC7752 is pretty clear on that too and says:

"BGP peerings are not automatic and require configuration; thus, it is the
responsibility of the network operator to ensure that only trusted
consumers are configured to receive such information."

If someone would be still concerned about configuration mistakes and
negotiating SAFI 71 or 72 to those who should not get this data I recommend
we reissue the RFC7752 as -bis version and restrict the scope of the
distribution even further by mandating default use of NO-EXPORT community
with ability to overwrite it for the selective eBGP peers. Or perhaps we
could progress Jim's One Administrative Domain draft
(draft-uttaro-idr-oad-01).

In either case while both of your comments are great they seems a bit late
in the game here or at least targeting wrong document.

Kind regards,
Robert.

On Fri, Oct 19, 2018 at 2:27 AM Benjamin Kaduk <[email-masked]> wrote:

> > In regards to the risks associated with advertising the specific
> information covered in this draft we have a statement in the IGP drafts:
> >
> > From RFC7810
> >
> > In regards to the risks associated with sending information via BGP-LS
> we have a number of statements in RFC 7752 – most relevant is:
> >
> > Certainly the risks associated with the BGP-LS transport mechanism are
> not altered by adding some new TLVs – and since the IGP RFCs have already
> covered risks associated with the specific class of information (not simply
> the risks associated with the transport mechanism) you are going to have to

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 09:25:42 -0400

Robert, Benjamin, and Yoav: 

I agree these context of these issues are not specific to this draft.  However, traffic engineering information does provide information which is a tempting attack vector. 

The original RFC7752 described a different purpose with restricted usage that SR routing extensions do not adhere to in BGP.   Since Spring WG shows that operators are interested in the extended use, it may be time to examine the RFC7752bis or other solutions that takes care of these security issues.  

My job as a shepherd is to point out these issues per draft for the IESG and security directorate in order to obtain the correct feedback.  As a WG chair, I have pointed out these issues, but the WG has these drafts on WG LC without the extra security.

Without RFC7752bis with additional security in the base document, I am working as a shepherd make the manageability and security sections as clear as possible.  

If the feedback from the security directorate review or the IESG is that we need to obtain a solution for RFC7752bis that describes and handles these security issues, I will be glad to support fast-tracking this issue within the WG. 

If an offline discussion with Benjamin, Yoav, the IDR chairs, and Alvaro would speed this along, I can set this up early next week.  It would be helpful to have this offline discussion before the IDR interim session on 10/26. 

Thank you for all your comments. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 19, 2018 2:52 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Benjamin,

Not sure if you have spotted similar comment made to IDR regarding this topic, but your comment seems to indicate that here we are about to define ways to carry nicely scoped IGP information into BGP. Well that has already happened with RFC7752 and your comment or for that matter Yoav's remarks are indeed spot on but to the security discussion on RFC7752 and IMO not any follow up extensions of it. 

Sure - as observed by Sue - one may argue that providing more information about the network to the potential attacker makes the network weaker, but the cure for that is to prevent the leaks and reduce probability of intercepting new information by unauthorized parties. 

BGP-LS is already defined in a new SAFI what by itself does provide nice level of isolation. RFC7752 is pretty clear on that too and says: 

"BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information."

If someone would be still concerned about configuration mistakes and negotiating SAFI 71 or 72 to those who should not get this data I recommend we reissue the RFC7752 as -bis version and restrict the scope of the distribution even further by mandating default use of NO-EXPORT community with ability to overwrite it for the selective eBGP peers. Or perhaps we could progress Jim's One Administrative Domain draft (draft-uttaro-idr-oad-01). 

In either case while both of your comments are great they seems a bit late in the game here or at least targeting wrong document. 

Kind regards,

Robert.

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:51:35 +0000

Robert’s post addresses points I also want to make.

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

In theory, we could have simply updated RFC 7752 rather writing a separate draft, but practically this would be a poor strategy as it would incorrectly suggest that some change was being made to the existing text in RFC 7752.

I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752. The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion.

I think it is important that you note this relationship, because the nature of BGP-LS is that whenever IGP extensions are defined to advertise new information it is necessary to define corresponding BGP-LS codepoints. This is not the first such BGP-LS extension document – and it is safe to say it won’t be the last. It would be helpful to all if we reached a common understanding or this discussion will take place every time a BGP-LS extension document is being reviewed – which will cost us all time needlessly.

   Les

From: Robert Raszuk <[email-masked]>
Sent: Thursday, October 18, 2018 11:52 PM
To: [email-masked]
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Benjamin,

Kind regards,
Robert.

On Fri, Oct 19, 2018 at 2:27 AM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:57:48 +0000

Sue –

One of us is confused. ☺

draft-ietf-idr-te-pm-bgp is not related to Segment Routing. Those words do not appear anywhere in the document. Nor is there a reference to any SR document.

Further, RFC 7752 includes traffic engineering information (see https://tools.ietf.org/html/rfc7752#section-3.3.2 ) so the suggestion that we are introducing a new attack vector by defining some additional(sic) TE codepoints does not make sense to me.

I appreciate that there are other drafts on your mind which are SR related – but this is not one of them.

Could you please update your response with these points in mind?

Thanx.

   Les

From: Susan Hares <[email-masked]>
Sent: Friday, October 19, 2018 6:26 AM
To: 'Robert Raszuk' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, October 19, 2018 2:52 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 11:32:44 -0400

Les:

Thank you for responding to Robert’s post.  

Your argument that this information would have added to RFC7752 is on “thin ice” as the IESG in their approval of RFC7752 was concerned about the scope of the information.   The extension of the scope beyond its stated scope might have trigger the current discussions at that time.  The authors indicated to the IDR chairs the RFC7752 scope would not grow.   

As shepherd I requested this draft to be reviewed by the security directorate because we are going beyond the original scope of RFC7752 with this draft.  As Shepherd, I do not agree with you that security issues Yoav raises are specified in RFC7752.   I

You are correct that there are many drafts (just BGP-LS extensions and segment routing extensions that use BGP-LS).   This draft is just the first of a wave of drafts.      It is appropriate to have a solution for the security issues that covers all the drafts rather than go through drafts one at a time. I suggest that a revision to RFC7752 that addresses these issues is appropriate. 

If you are interested in discuss this topic with Yoav, Benjamin, and the IDR WG – shall we start a thread on this topic? 

Susan Hares 

 

 

From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 10:52 AM
To: Robert Raszuk; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

   Les

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 15:56:53 +0000

Sue –

I was not an author of RFC 7752 and have no idea what promises the authors might have made. I will say that it seems very late in the game for you to suggest that this document should not be allowed to progress because it  exceeds some agreement on the scope of RFC 7752. Why weren’t these concerns expressed long before?

If you feel that RFC 7752 security needs revision I would appreciate it if you state so clearly (to the WG – not just to me) and in the right context. Such work is clearly not in the scope of draft-ietf-idr-te-pm-bgp.

   Les

From: Susan Hares <[email-masked]>
Sent: Friday, October 19, 2018 8:33 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; 'Robert Raszuk' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Les:

Susan Hares

From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 10:52 AM
To: Robert Raszuk; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

   Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 18, 2018 11:52 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Oct 2018 17:57:22 +0200

Hi Sue,

RFC7752 title is: North-Bound Distribution of Link-State and Traffic
Engineering (TE) Information Using BGP

+ section 1:

1 <https://tools.ietf.org/html/rfc7752#section-1>.  Introduction

   The contents of a Link-State Database (LSDB) or of an IGP's Traffic
   Engineering Database (TED) describe only the links and nodes within
   an IGP area.

So assuming that RFC7752 was read with some level of understading on
what LSDB or TED mean there should be no surprise and also no content
today that as LSDB or TED are continue to be extended in their
respected WGs you will see new extensions of information to be added
to RFC7752 vehicle in the forms of new TLV.

Of course we would not have any of this discussions or need for new
drafts if RFC7752 would simply zip and carry those two databases in
binary chunks. Well for some reason authors decided to involve BGP in
that process of carried data validation - but this alone should also
be well understood by approvers of RFC7752.

Kind regards,
R.

On Fri, Oct 19, 2018 at 5:32 PM Susan Hares <[email-masked]> wrote:

> Your argument that this information would have added to RFC7752 is on
> “thin ice” as the IESG in their approval of RFC7752 was concerned about the
> scope of the information.   The extension of the scope beyond its stated
> scope might have trigger the current discussions at that time.  The authors
> indicated to the IDR chairs the RFC7752 scope would not grow.
>
>
>
> As shepherd I requested this draft to be reviewed by the security
> directorate because we are going beyond the original scope of RFC7752 with
> this draft.  As Shepherd, I do not agree with you that security issues Yoav
> raises are specified in RFC7752.   I
>
>
>
> You are correct that there are many drafts (just BGP-LS extensions and
> segment routing extensions that use BGP-LS).   This draft is just the first
> of a wave of drafts.      It is appropriate to have a solution for the
> security issues that covers all the drafts rather than go through drafts
> one at a time. I suggest that a revision to RFC7752 that addresses these
> issues is appropriate.
>
>
>
> If you are interested in discuss this topic with Yoav, Benjamin, and the
> IDR WG – shall we start a thread on this topic?
>
>
>
> Susan Hares
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Les Ginsberg
> (ginsberg)
> *Sent:* Friday, October 19, 2018 10:52 AM
> *To:* Robert Raszuk; [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [Idr] [secdir] Secdir early review of
> draft-ietf-idr-te-pm-bgp-13
>
>
>
> What is being done here is to add additional BGP-LS codepoints to
> advertise IGP information that was not defined at the time RFC 7752 was
> written. We haven’t changed the  BGP-LS transport mechanism – nor is the
> information being advertised here (some additional TE related link
> attribute information) qualitatively different than a number of existing
> TLVs defined in RFC 7752 (see
> https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information
> had already been defined in the IGPs at the time RFC 7752 was written it
> would simply have been included as a section of RFC 7752 and no additional
> changes to RFC 7752 would have been required.
>
>
>
> In theory, we could have simply updated RFC 7752 rather writing a separate
> draft, but practically this would be a poor strategy as it would
> incorrectly suggest that some change was being made to the existing text in
> RFC 7752.
>
>
>
> I appreciate that from the POV of the Security Area you folks are not as
> intimately familiar with the routing drafts and the relationship between
> them. It is therefore understandable that you start looking at the new
> draft as a standalone document – and in that context your comments are
> absolutely correct. But the document you are reviewing is most accurately
> seen as an “addendum” to RFC 7752. The issues you raise have already been
> addressed in RFC 7752 and it is therefore very appropriate that we address
> your concerns by including a reference to the RFC 7752 security discussion.
>
>
>
> I think it is important that you note this relationship, because the
> nature of BGP-LS is that whenever IGP extensions are defined to advertise
> new information it is necessary to define corresponding BGP-LS codepoints.
> This is not the first such BGP-LS extension document – and it is safe to
> say it won’t be the last. It would be helpful to all if we reached a common
> understanding or this discussion will take place every time a BGP-LS
> extension document is being reviewed – which will cost us all time
> needlessly.
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Thursday, October 18, 2018 11:52 PM
> *To:* [email-masked]
> *Cc:* Les Ginsberg (ginsberg) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [Idr] [secdir] Secdir early review of
> draft-ietf-idr-te-pm-bgp-13
>
>
>
> Hello Benjamin,
>
>
>

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Oct 2018 16:26:47 +0000

Hi,

I was a co-author of RFC 7471 and  RFC 7810, which introduce a handful of new TE metrics into the existing OSPF and IS-IS TE infrastructures.  The subject draft does exactly the same thing for the existing BGP-LS TE infrastructure defined in RFC 7752.

As Les correctly points out, if there are security issues with the existing BGP-LS TE infrastructure or more generally with RFC 7752, then those issues need to be addressed with a revision of that RFC and not with this draft.  I.e., this draft does not change the scope of RFC 7752 in any way.

Yours Irrespectively,

John

From: Idr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 11:57 AM
To: Susan Hares <[email-masked]>; 'Robert Raszuk' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue –

   Les

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 19, 2018 8:33 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Les:

Susan Hares

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7752-23section-2D3.3.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=npn_gYm6dQhrzturGfvoWX6l7yj98L8B3REypoIHJKs&s=8nwBVMh50NAXY6ST8HOYQs4XY-lPCJC5n3k8uKFlW4w&e=> ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

   Les

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 12:27:58 -0400

Les:

The discussion was not with specifically with me, but with both IDR chairs, the AD for routing, and the IESG.  I am simply reporting what happened during the approval process.   

Perhaps you have not been active in IDR for a while.  I stated these concerns during the original RFC7752 discussion, but agreed that a limited scope would limit my concerns.  As we have expanded these drafts,   I have repeated these concerns and in person to the authors who discussed these issues with me at IETF IDR meetings.   You have not been at any of the in-person author discussions at IETF.  Please see my comments on the list regarding BGP-LS additions and SR routing drafts. 

You felt that RFC7752 was sufficient to cover these drafts.  I stated clearly to you as a shepherd of your draft that you might wish to upgrade your security section.  You felt it was sufficient.   Therefore, I sent the draft to the security directorate for an impartial review.  

You are in this discussion because security directorate reviewer, Yoav, pointed this issue regarding RFC7752 security.  You feel it is sufficient and my understanding of the discussion is that they do not feel it is sufficient.    

I do agree that the IDR WG should engage in a general solution is to the queries from the security directorate on RFC7752 security.  It is not specifically an issue specific to the draft-ietf-te-pm-bgp draft.  I have made the same suggestion for a revision to RFC7752 security to the draft-ietf-idr-bgpls-segment-routing-epe and draft-ietf-idr-bgpls-segment-routing-ext.  

If you agree that the RFC7752 needs a revision with improved security, you can put that statement in your draft.  I will be glad to help “fast-track” an RFC7752bis with the security issues resolved.  If this issue of critical importance to deployed code that is important to operators, the IDR WG can move within 6-8 weeks.  The next IESG meeting this document can reach approval will be after IETF 103 (~6 weeks).    

Shall we take the approach of adding a reference of RFC7752bis with security issues to draft-ietf-idr-te-pm-bgp-13 or do you wish to engage in a discussion thread where you prove a revision to RFC7752bis is not required?   

Cheerily, Sue 

From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 11:57 AM
To: Susan Hares; 'Robert Raszuk'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue –

   Les

Les:

Susan Hares 

 

 

   Les

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 12:33:17 -0400

John: 

I agree with you that this issue is not specific to draft-ietf-idr-te-pm-bgp-13.txt, but should be taken up as a revision to RFC7752.   

I disagree with you on the change of scope for RFC7752.  This draft (draft-ietf-idr-te-pm-bgp-13.txt) does add additional risk for the scope of the attack surface on RFC7752 as it adds to the traffic engineering information passed.  

Shall we agree on creating RFC7752bis that expands the security section?  I am glad to sponsor a “fast-track” action on an RFC7752bis. 

Yours respectfully, 

Sue 

From: John E Drake [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 12:27 PM
To: Les Ginsberg (ginsberg); Susan Hares; 'Robert Raszuk'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi,

Yours Irrespectively,

John

Sue –

   Les

Les:

Susan Hares 

 

 

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7752-23section-2D3.3.2&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=npn_gYm6dQhrzturGfvoWX6l7yj98L8B3REypoIHJKs&s=8nwBVMh50NAXY6ST8HOYQs4XY-lPCJC5n3k8uKFlW4w&e=>  ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

   Les

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Oct 2018 16:52:33 +0000

Sue,

Comments inline.

Yours Irrespectively,

John

From: Susan Hares <[email-masked]>
Sent: Friday, October 19, 2018 12:33 PM
To: John E Drake <[email-masked]>; 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Robert Raszuk' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

John:

[JD]  Fine w/ me

[JD]  That sounds suspiciously like an assertion

[JD]  Fine w/ me

Yours respectfully,
Sue

From: John E Drake [mailto:[email-masked]]
Sent: Friday, October 19, 2018 12:27 PM
To: Les Ginsberg (ginsberg); Susan Hares; 'Robert Raszuk'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi,

Yours Irrespectively,

John

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 11:57 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue –

   Les

Les:

Susan Hares

   Les

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 12:55:25 -0400

John:

I believe we are aligned on the next steps.    Thanks for the input. 

Cheerily, Sue 

From: John E Drake [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 12:53 PM
To: Susan Hares; 'Les Ginsberg (ginsberg)'; 'Robert Raszuk'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue,

Comments inline.

Yours Irrespectively,

John

John: 

[JD]  Fine w/ me 

[Sue2] Yes – this is my assertion.  If you wish to have this assertion reviewed by security directorate, I can ask.  However, we agree on the solution. 

[JD]  Fine w/ me 

Yours respectfully, 

Sue 

Hi,

Yours Irrespectively,

John

Sue –

   Les

Les:

Susan Hares 

 

 

   Les

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 13:07:42 -0400

Les:

I apologize if my email message was unclear.   We both agree that your draft is not related to SR routing.   SR routing is related to BGP-LS as a transport mechanism for information.  

I agree that RFC7752 had traffic engineering information.  However, that traffic engineering information almost got that draft rejected by the IESG at the time.  As my previous message to this list indicated, we got agreement on RFC7752 based on limiting that information and the assurance that BGP-LS nodes were deployed on a separate set of nodes.  Expanding the traffic engineering information beyond RFC7752 re-opens all the security issues and questions from RFC7752’s original review.  

The security directorate reviewer is asking these security questions.  The security directorate does have people with both routing and security experts.   

SR routing is also expanding the information past the original RFC7752.   The expansions requested by SR routing also re-open those original security questions and issues.  

One way to answer these questions is to provide a  RFC7752bis with an updated security section.  If you agree with this approach, I suggest simply referring to a RFC7752bis that in your security section.   If you disagree that an update to the RFC7752bis is required, we can start a thread on that point. 

Did this message clarify my earlier brief message?  Do you want to continue to discuss the need for RFC7752bis? 

Cheerily, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 10:58 AM
To: Susan Hares; 'Robert Raszuk'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue –

One of us is confused. J

Thanx.

   Les

Sue 

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 17:28:54 +0000

Sue –

Inline.

Sent: Friday, October 19, 2018 10:08 AM

Les:

[Les:] So far, you are the only person who seems aware of this. I am not saying you are wrong – I am just saying my private attempts to get more context for this have thus far failed – and you have not provided any documentation of this.
If your statement is accurate (again – not saying it isn’t) – it also seems most unfortunate (and I am being “kind” here) that this was not mentioned in the course of the four years that draft-ietf-idr-te-pm-bgp has taken to progress to this point.

[Les:] I do not know why you mention SR here since we both agree this draft is not SR related.

[Les:] There is no RFC7752bis draft. ☺  So you are asking me to reference a non-existent document?

I understand that you (at least) would like to have one – which is perfectly legitimate – though you should go through the normal WG process to take this work on – correct?

But this dodges the question as to whether draft-ietf-idr-te-pm-bgp has a dependency on enhanced security. So far, you are the only person making this claim – and several folks (including myself) have expressed a different POV. I think you at least have to provide a justification for this dependency before we introduce it and get some support for your position – since this will mean draft-ietf-idr-te-pm-bgp would be stuck in MISSREF state until this currently non-existent draft becomes an RFC.

   Les

Cheerily, Sue

From: Idr [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, October 19, 2018 10:58 AM
To: Susan Hares; 'Robert Raszuk'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Sue –

One of us is confused. ☺

Thanx.

   Les

To: 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Sue

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 17:31:59 -0400

Les:

I will respond to this information point by point after I have responded to Ketan who sent me messages regarding his draft prior to yours.   However, I would like your feedback on whether you believe RFC7752 has security that is equivalent to, less than, or greater than a trusted domain? 

The spring routing architecture (RFC8402) indicates that be default SR operates within a trusted domain.   It says further: 

“Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important.  Such practices are discussed in [RFC4381 <https://tools.ietf.org/html/rfc4381> ] and are applicable to both SR-MPLS and SRv6.” 

If you believe that RFC7752 describes a trusted domain [per RFC4381], 

RFC7762 does not state that it is a trusted domain. 

If you believe the RFC7752 has stronger security 

than a trusted domain, can you let me know 

why you think it is stronger than a trusted domain.  

If you believe that RFC7752 describes security which 

is less than a trusted domain, please let me how it is less. 

The RFC7752 text is below for ease of the IDR and secdir readers. 

Thank you for providing this feedback, 

Sue

------------

RFC7752 security section (section 8.)  

8.  Security Considerations

   Procedures and protocol extensions defined in this document do not

   affect the BGP security model.  See the Security Considerations

   section of [RFC4271] for a discussion of BGP security.  Also refer to

   [RFC4272] and [RFC6952] for analysis of security issues for BGP

   In the context of the BGP peerings associated with this document, a

   BGP speaker MUST NOT accept updates from a consumer peer.  That is, a

   participating BGP speaker should be aware of the nature of its

   relationships for link-state relationships and should protect itself

   from peers sending updates that either represent erroneous

   information feedback loops or are false input.  Such protection can

   be achieved by manual configuration of consumer peers at the BGP

   speaker.

    An operator SHOULD employ a mechanism to protect a BGP speaker

   against DDoS attacks from consumers.  The principal attack a consumer

   may apply is to attempt to start multiple sessions either

   sequentially or simultaneously.  Protection can be applied by

   imposing rate limits.

   Additionally, it may be considered that the export of link-state and

   information about the network.  BGP peerings are not automatic and

   require configuration; thus, it is the responsibility of the network

   operator to ensure that only trusted consumers are configured to

   receive such information.

Sent: Friday, October 19, 2018 1:29 PM

Sue –

Inline.

Les:

[Les:] There is no RFC7752bis draft. J  So you are asking me to reference a non-existent document?

   Les

Cheerily, Sue 

Sue –

One of us is confused. J

Thanx.

   Les

Sue 

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 19 Oct 2018 22:00:37 +0000

Sue –

I will not reinforce your inappropriate insertion of the discussion of possible RFC 7752 deficiencies into a thread which is reviewing draft-ietf-idr-te-pm-bgp. This is wrong – please stop it.

You want to discuss issues with RFC 7752 – please start a separate thread – directed at the WG (of course) – and state your position as a WG member as to what you feel needs to be done. Then others can comment and the WG can decide whether they agree work needs to be done.

Also - and for the third time - draft-ietf-idr-te-pm-bgp is NOT SR related – please also stop inserting a discussion of SR/BGP-LS into the review of this draft.

(Apologies for the harsh tone – but it is becoming increasingly frustrating to watch this thread being misdirected.)

   Les

Sent: Friday, October 19, 2018 2:32 PM

Les:

“Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important.  Such practices are discussed in [RFC4381<https://tools.ietf.org/html/rfc4381>] and are applicable to both SR-MPLS and SRv6.”

Sue

------------

Sue –

Inline.

Les:

   Les

Cheerily, Sue

Sue –

One of us is confused. ☺

Thanx.

   Les

Sue

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 20 Oct 2018 00:27:41 +0200

Hello Sue,

However, I would like your feedback on whether you believe RFC7752 has
> security that is equivalent to, less than, or greater than a trusted
> domain?
>
>
>
> The spring routing architecture (RFC8402) indicates that be default SR
> operates within a trusted domain.
>
>
>
> “Traffic MUST be filtered at the domain boundaries. The use of best
> practices to reduce the risk of tampering within the trusted domain is
> important.  Such practices are discussed in [RFC4381
> <https://tools.ietf.org/html/rfc4381>] and are applicable to both SR-MPLS
> and SRv6.”
>

Reading your comments I am also similarly to Les's feelings quite not sure
what the point here is.

SR Architecture while completely irrelevant to this thread talks about
trusted domain in the context of data plane. Bringing in L3VPNs out of the
sudden only because some SR document referred to it's security analysis is
also quite a bizarre maneuver.

With control plane and especially with BGP the notion of trusted vs
untrusted domain is not something anyone can just pick or state on what his
or her believe is.

The short answer is that BGP operates on a per AFI/SAFI basis and level of
trust is directly related to the actual configuration applied including
level of policy inserted when using such apparatus to distribute various
forms of information.

Same SAFI can be configured by one operator quite strictly limiting it to
one AS and someone else will like to share his information with entire
world publishing it to a looking glass. Are we here to restrict this ? What
means of control is there to enforce such restrictions other then perhaps
stating simple recommendation in an advisory fashion that one should be a
bit careful when publishing content of his LSDB or TED beyond devices he
trusts ? **

** Note that even if TE infrastructure addresses or other information are
accidentally leaked - there should be no great immediate harm - since well
managed network prevents on ingress to the domain any flows which would aim
at internal infrastructure address space.

Thx,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 18:31:38 -0400

Les:

I politely asked for viewpoint on RFC7752’s security since your draft depends on RFC7752.  You have impolitely and harshly refused to comment on these points.  

I am focused on finding a resolution to the security directorates comments on this draft on this thread.   One resolution was to suggest a general resolution by revising the RFC7752 draft.   I have spent time today providing background and reasons why this might be a good resolution.  I see from your comments that you are rejecting this potential resolution.  

Propose a resolution to the secdir comments.    Please note as your shepherd and WG chair, stating  “security directorate does not understand BGP” is not a resolution.   

IMHO as shepherd for your document Yoav has a valid point that on vagueness of RFC7752 and the addition of new information.   Please continue to work with Yoav, Benjamin and the secdir to resolve their concerns since my resolution has been rejected by you.  

Sue Hares

Sent: Friday, October 19, 2018 6:01 PM

Sue –

   Les

Les:

Sue

------------

   speaker.

   imposing rate limits.

 

Sue –

Inline.

Les:

   Les

Cheerily, Sue 

Sue –

One of us is confused. J

Thanx.

   Les

Sue 

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Oct 2018 22:40:57 +0000

Hi,

Comments inline

Yours Irrespectively,

John

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Friday, October 19, 2018 6:32 PM
To: 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Robert Raszuk' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Les:

[JD]  What part of “this draft has nothing to do with segment routing” do you not understand”?

[JD]  From whom did that direct quote come?  I don’t recall seeing it on the email thread.

[JD]  I just re-read the entire email thread on this draft and it appears to me that that the above is exactly what Les was doing and that he was quite close to a resolution before you injected RFC 7752bis and segment routing into the conversation.

Sue Hares

Sue –

   Les

Les:

“Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important.  Such practices are discussed in [RFC4381<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4381&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=nSYW85l7_rYWox4dgWJmIPDGtX17whuzGQ0GFgNsWnU&e=>] and are applicable to both SR-MPLS and SRv6.”

Sue

------------

Sue –

Inline.

Les:

   Les

Cheerily, Sue

Sue –

One of us is confused. ☺

Further, RFC 7752 includes traffic engineering information (see https://tools.ietf.org/html/rfc7752#section-3.3.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7752-23section-2D3.3.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=RXx7h2EP_TUmNFxdSk6_WgQ27JsdivA22bqO3xxj63E&e=> ) so the suggestion that we are introducing a new attack vector by defining some additional(sic) TE codepoints does not make sense to me.

Thanx.

   Les

Sue

Hello Benjamin,

Kind regards,
Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 19:01:21 -0400

Les: 

I am only going to respond to your many misconceptions inline.  

Most of the text below are comments which harshly personalizes the discussion rather than consider that Yoav indicates some of the same concern regarding the information that I had as your shepherd.   

You have rejected my suggested resolution of a RFC7752bis as a way to resolve the security directorates concerns.  I will add this fact to shepherd’s report so that Alvaro and the IESG knows you have rejected any resolution that involves revising RFC5572’s security section.  

It is now up to you to propose a solution that will satisfy SEC-DIR review.  

Cheerily, Sue 

Sue –

Inline.

Les:

[Sue]: You are repeatedly making this a personal issue.  As I have stated in previous messages you were not at in-person authors meetings. I cannot help if you do not attend IETF discussions with your shepherd or your co-authors do not relay my concerns.  I would ask that you stop any further personal comments. 

[sue]:  Why am I mentioning it?  They have a reasonable solution to the security consideration by considering everything as a trusted domain (see RFC8402), and defining who the BGP peers are.   Due to deployments, I am trying to help you resolve this issue quickly. . 

[Sue]: I am looking for a solution that will technically resolve the security concerns.  After you agree in principle, I would go to Alvaro and the IESG and see if we could get a fast-track for the solution.  

[Sue]:  I am willing to take this through a fast track IDR document since it is for the security considerations only.  I am willing to go the extra mile and talk to Routing ADs and the security ADs about a quick resolution. 

But this dodges the question as to whether draft-ietf-idr-te-pm-bgp has a dependency on enhanced security. So far, you are the only person making this claim – and several folks (including myself) have expressed a different POV. 

[Sue]: Yoav had the same point of view on the potential security issues in his original review so I am not the only person that believes there is a problem.   As I mentioned as a shepherd, I would let the SEC-DIR provide an independent review on whether your security considerations sections was sufficient.  Yoav ruled “not sufficient”.   

At this point,  please do not repeat this comment again as it is not true.  Restating it over and over does not make it true.  Using words like “dodges the issue” are not words that progress a consensus decision forward.   

I think you at least have to provide a justification for this dependency before we introduce it and get some support for your position – since this will mean draft-ietf-idr-te-pm-bgp would be stuck in MISSREF state until this currently non-existent draft becomes an RFC.

[Sue]:  The solution could be easy – but you are not willing to listen regarding the proposed resolution.  RFC8402 considers the BGP-LS for Segment routing to be a trusted domain and provides some additional comments on BGP peers.  My suggestion would have been to revise RFC7752 to be a trusted domain with some of the same wording.   

   Les

Cheerily, Sue 

Sue –

One of us is confused. J

Thanx.

   Les

Sue 

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 19:21:50 -0400

John: 

Per Les’s request we are trimming any discussion of my suggested solution to let him focus on resolving the issues with the sec-dir people.     

IMHO I do not think Les was close to resolving the issue main issue, but we both can watch and read as he continues to discuss this point with the secdir people.   As WG chair, I will continue to support resolution of secdir comments. 

Respectfully, Sue 

PS - Your personal comments regarding my email on SR or RFC7752 miss the point that RFC8402 resolves many issues by declaring the SR area a trusted domain. 

From: Idr [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, October 19, 2018 6:41 PM
To: Susan Hares; 'Les Ginsberg (ginsberg)'; 'Robert Raszuk'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hi,

Comments inline

Yours Irrespectively,

John

Les:

Sue Hares

Sue –

   Les

Les:

“Traffic MUST be filtered at the domain boundaries. The use of best practices to reduce the risk of tampering within the trusted domain is important.  Such practices are discussed in [RFC4381 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4381&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=nSYW85l7_rYWox4dgWJmIPDGtX17whuzGQ0GFgNsWnU&e=> ] and are applicable to both SR-MPLS and SRv6.” 

Sue

------------

   speaker.

   imposing rate limits.

 

Sue –

Inline.

Les:

   Les

Cheerily, Sue 

Sue –

One of us is confused. J

Further, RFC 7752 includes traffic engineering information (see https://tools.ietf.org/html/rfc7752#section-3.3.2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7752-23section-2D3.3.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=WBOa24L-SPSPc89aL0B8JgnbdISmCygL5WDqT1642Zg&s=RXx7h2EP_TUmNFxdSk6_WgQ27JsdivA22bqO3xxj63E&e=>  ) so the suggestion that we are introducing a new attack vector by defining some additional(sic) TE codepoints does not make sense to me.

Thanx.

   Les

Sue 

Hello Benjamin,

Kind regards,

Robert.

-Ben

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Oct 2018 19:54:06 -0400

Robert: 

I disagree with many of your comment below.  However,  a discussion of these points is no longer appropriate on this thread. Les has indicated my suggested resolution of a revision to RFC7752 is not an acceptable alternative.   He wishes to focus on directly resolving these issues with the secdir.  This thread is closed to any further discussions on a revision of RFC7752.  

If you wish to discuss these offline, you can send me email.   If you wish to discuss these on a different thread, please start that specific thread.   

Sue

PS – The point of my questions were to explore if recasting the web of RFC7752 BGP peers as a trusted domain with the restrictions in RFC8402 would resolve security concerns related to RFC7752.  

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, October 19, 2018 6:28 PM
To: [email-masked]
Cc: Les Ginsberg (ginsberg); [email-masked]; [email-masked]; [email-masked]; [email-masked]; Yoav Nir; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

Hello Sue,

However, I would like your feedback on whether you believe RFC7752 has security that is equivalent to, less than, or greater than a trusted domain? 

The spring routing architecture (RFC8402) indicates that be default SR operates within a trusted domain. 

 

Reading your comments I am also similarly to Les's feelings quite not sure what the point here is. 

SR Architecture while completely irrelevant to this thread talks about trusted domain in the context of data plane. Bringing in L3VPNs out of the sudden only because some SR document referred to it's security analysis is also quite a bizarre maneuver. 

With control plane and especially with BGP the notion of trusted vs untrusted domain is not something anyone can just pick or state on what his or her believe is. 

The short answer is that BGP operates on a per AFI/SAFI basis and level of trust is directly related to the actual configuration applied including level of policy inserted when using such apparatus to distribute various forms of information. 

Same SAFI can be configured by one operator quite strictly limiting it to one AS and someone else will like to share his information with entire world publishing it to a looking glass. Are we here to restrict this ? What means of control is there to enforce such restrictions other then perhaps stating simple recommendation in an advisory fashion that one should be a bit careful when publishing content of his LSDB or TED beyond devices he trusts ? **

** Note that even if TE infrastructure addresses or other information are accidentally leaked - there should be no great immediate harm - since well managed network prevents on ingress to the domain any flows which would aim at internal infrastructure address space. 

Thx,
R.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 21 Oct 2018 20:44:39 +0300

See inline.

> On 19 Oct 2018, at 17:51, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2 <https://tools.ietf.org/html/rfc7752#section-3.3.2> ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.
>  
> I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752.

[YN] Right, and as such, I believe that this document should address the part that it adds to RFC 7752. IOW it should state that the new IGP information that will now be sent through BGP does not present new/different risk to the information already defined in 7752. This is information that has up until now only been sent in IS-IS and OSPF and will not be sent in BGP, so we need a statement that it’s OK to send these attributes in BGP as well. Of course, such a statement could be challenged in WGLC or IETF LC, but it should be made.

> The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 21 Oct 2018 20:33:03 +0000

Yoav –

Thanx for the suggestion. I have just posted V14 of the draft which I believe addresses your concerns – please review and confirm.

   Les

From: Yoav Nir <[email-masked]>
Sent: Sunday, October 21, 2018 10:45 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

See inline.

On 19 Oct 2018, at 17:51, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

   Les

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 21 Oct 2018 19:26:40 -0400

Yoav:

Thank you providing suggested text to resolve your concerns and coming to a resolution with the security issues with Les. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, October 21, 2018 1:45 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; [email-masked]; Robert Raszuk; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

See inline.

What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the  BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see  <https://tools.ietf.org/html/rfc7752#section-3.3.2> https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required.

   Les

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Oct 2018 01:26:41 +0000

Thanks Yoav for proposed change,:-)
发件人: Yoav Nir [mailto:[email-masked]]
发送时间: 2018年10月22日 1:45
收件人: Les Ginsberg (ginsberg)
抄送: Robert Raszuk; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Idr] [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

See inline.

   Les