Re: [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13

["Les Ginsberg (ginsberg)" <[e-mail]>]

Ben -

Inline.

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Thursday, October 18, 2018 5:27 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Yoav Nir <[e-mail]>; [e-mail]; [e-mail]; draft-ietf-idr-
> [e-mail]; [e-mail]
> Subject: Re: [secdir] Secdir early review of draft-ietf-idr-te-pm-bgp-13
> 
> On Thu, Oct 18, 2018 at 06:00:13PM +0000, Les Ginsberg (ginsberg) wrote:
> > 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.
> 
> 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.
> 

[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

> -Ben
> 
> >
> > ???
> >
> >    Les
> >
> >
> > From: Yoav Nir <[e-mail]>
> > Sent: Thursday, October 18, 2018 9:38 AM
> > To: Les Ginsberg (ginsberg) <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Re: Secdir early review of draft-ietf-idr-te-pm-bgp-13
> >
> > 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:
> >
> >   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.
> >
> > 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)
> <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > Yoav –
> >
> > I think we are converging.
> > Inline.
> >
> > From: Yoav Nir <[e-mail]<mailto:[e-mail]>>
> > Sent: Wednesday, October 17, 2018 11:14 AM
> > To: Les Ginsberg (ginsberg)
> > <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:draft-ietf-idr-te-pm-bgp.
> > [e-mail]>
> > Subject: Re: Secdir early review of draft-ietf-idr-te-pm-bgp-13
> >
> > 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.
> >
> > [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)
> <[e-mail]<mailto:[e-mail]>> 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.
> > 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 <[e-mail]<mailto:[e-mail]>>
> > > Sent: Tuesday, October 16, 2018 2:18 PM
> > > To: [e-mail]<mailto:[e-mail]>
> > > Cc: [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:draft-ietf-idr-te-pm-bg
> > > [e-mail]>
> > > Subject: Secdir early review of draft-ietf-idr-te-pm-bgp-13
> > >
> > > 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?
> > >
> >
> > [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.
> >
> > > 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.
> > >
> > [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.
> >
> > > 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.
> >
> > [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
> >
> >
> 
> > _______________________________________________
> > secdir mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdir
> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview