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

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
> -Ben
>