Re: [Idr] Stephen Farrell's Discuss on draft-ietf-idr-ls-distribution-12: (with DISCUSS)

["Adrian Farrel" <[e-mail]>]

> > Just checking which recommendation you are suggesting to strengthen.
> > The one to not export information you don't want others to see?
> 
> Yes. While it may sound obvious as you state it, it seems that
> people constantly do do the wrong thing here and often accidentally,
> or not fully considering the scope in which that information will
> be visible.
> 
> If some text here can help avoid someone writing code that makes
> that happen too easily then that could be worthwhile. (But that
> general point is not blocking.)

OK.
In other news: don't run with scissors.

> >> However, noting that e.g. ALTO servers can be handling data that is
> >> privacy sensitive for specific users (e.g. see
> >> https://tools.ietf.org/html/rfc7285#section-15.3 and
> >> https://tools.ietf.org/html/rfc7285#section-15.4), I think there
> >> are two more things that need to be noted here, but that are not.
> >
> > BGP-LS is not ALTO :-) The information exchanged is specific to the
> > topology of the network and not the location of applications or user
> > resources.
> 
> Where does it say that? It may well, and I missed it, or it may
> say it in a way that's too subtle for me;-)
> 
> If that was clearly stated then that would be good.

How about "North-Bound Distribution of Link-State and TE Information using BGP" :-)

> >> (1) First is that this document does change (what I understand,
> >> perhaps imperfectly, as) the security model for BGP, in that
> >> previously we have assumed that BGP speakers are not exposing
> >> user-specific privacy sensitive information. This draft seems to me
> >> to change that. (If it does not, then a reference to where that was
> >> previously done would be needed, or an explanation of why I'm
> >> wrong:-)
> >
> > It is not that is doesn't make the change in the sense you are
> > describing it, it is that it does not expose user-specific
> > information (unless I am missing something!).
> >
> > It exposes network-specific information. Someone intercepting a
> > BGP-LS message is like someone snooping on an IGP (modulo
> > post-processing policy applied to the IGP snoop). I can't see a way
> > in which this reveals user-specific information.  Well, I suppose
> > that if you could see both the whole topology and the policy filtered
> > topology for a specific user you might be able to deduce something -
> > but I don't know what.
> >
> > On the whole, however, I think that "confidentiality" here applies to
> > the network operator's information, not to details of the user.
> 
> If the above is the case then I would agree that this is not a change.
> 
> >
> >> If you could add a strong recommendation to not do that, I think
> >> that'd be good. (I do get that that can't be an easily implemented
> >> MUST NOT statement though, so I'm not quite sure what text to
> >> suggest, but it oughtn't be too hard to figure something out.)
> >
> > I think you are asking for a strong statement recommending that
> > BGP-LS not be used to distribute information that could reveal
> > user-specific privacy information.
> >
> > I'd like not to add unfocused apple pie statements (don't use BGP-LS
> > to carry your bank details) when there is currently no intent or way
> 
> Relying on good intentions will get us where? I do think this draft
> provides a way to carry PII, should one want to do that.

Yes, but *every* protocol that allows any form of extension to carry data that is not yet defined is documented in a "draft [that] provides a way to carry PII". 

I am reminded of the lady who sued her refrigerator manufacturer because it fell on her when she stood on the open door to try to change the light bulb in her kitchen.

> For example, an ALTO server may know that it can reach an IPv6 address
> in my home. Couldn't that be passed on via this mechanism? And in some
> cases, couldn't one regard that prefix as being personally identifying?

Where did ALTO come into this? Second time you've mentioned it, but I don't understand why. I think possibly you have misunderstood Figure 3. In that picture, BGP-LS is used to provide information to the ALTO server, not (as your text seems to suggest) that information from the ALTO server is distributed using BGP-LS (see the arrow heads in the figure - or read the text ;-)

However, it *is* true that you could choose to run BGP-LS to distribute information about what addresses are reachable in a specific network. That seems to be the point of a routing protocol! I hope you are not going to say that BGP needs a health warning because it leaks reachability information from within one network to make it visible in another network. The whole point of routing is that it knows what addresses exist in your home - without that knowledge, it is pretty tough to route packets there.  (And if you decide to "hide" behind a NAT or some such, then obviously you have no intention of facilitating external influencing of TE within your network, so not only would you not use BGP-LS to advertise which addresses are in your network, you wouldn't use BGP-LS at all.)

> > to carry that information. So, can you clarify what user-specific
> > information you think this document is proposing should be carried in
> > BGP-LS.
> >
> > Or are you saying we should add something like:
> >
> > It should be noted that BGP-LS is a change in paradigm because it is
> > used to export information from a network where previously the
> > information was retained within that network. Not only should
> > deployments be aware of this and consider the confidentiality and
> > security implications of distributing routing and topology
> > information about a network to nodes outside that network, but future
> > protocol extensions defining further information that can be exported
> > northbound using BGP-LS should consider carefully whether
> > interception of such information could have a negative impact on the
> > confidentiality of users of the network.
> >
> > It's a bit vague!
> 
> Yep. That change is a good start though.

If it is a "start" then we need to work on it more?
Please suggest changes.
Please don't suggest "Future extensions to BGP-LS SHOULD NOT be used to distribute the marital status or sexual orientation of any user of a network."

> > Furthermore, it is precisely what BGP already does east-west. That
> > is, the purpose of BGP is to leak routing information 9at some level
> > of detail and aggregation) from inside a routing domain to nodes
> > outside that domain.
> 
> Well perhaps it's not too late to (start to) recognise the
> increasing security, and now perhaps privacy, implications of
> constantly extending BGP to carry more and more stuff? And
> in that way to avoid ending up with BGP carrying PII up, down
> or sideways.

Who is "constantly extending BGP to carry more and more stuff"?

But on this point, please ask for a slot on the IDR agenda to explain the issues to them or write a draft on the dangers. While you are having a Discussion (which is the point of a Discuss) I don't think you are Discussing this document.

> >> (2) Second, I wonder if the above change means that we need to
> >> seriously consider confidentiality for BGP. The RPKI does not, but
> >> then neither did DNSSEC for years until we belatedly realised that
> >> that was a real issue. I'm not asking that this draft provide a
> >> mechanism for confidentiality for BGP, but that at least
> >> recognising the issue as real (if it is) seems to be required. (And
> >> nor am I asking that a confidentiality system as complex as the
> >> rpki be developed, I think that if anything is needed here beyond
> >> data minimisation, then transport layer security would be as good
> >> as it'd get.) The change here would be to simply recognise this
> >> consequence, if it is real, and that could be a simple sentennce in
> >> the draft, e.g. saying that these changes to BGP might result in
> >> PII being emitted, and hence might cause a real need for
> >> confidentiality for BGP.
> >
> > Please consider as much as you can! I think the key is to build the
> > threat analysis : what confidential information might be leaked?;
> > whose information is it?; who might be able to access it?; what might
> > they be able to do with it? If you, or someone you know who has spare
> > cycles brings this to IDR or GROW then I am sure it will be
> > discussed.
> >
> > Wrt this document, can you convince me that the consequence is real?
> > What PII might be emitted using BGP-LS as described here? What more
> > than is already stated needs to be added?
> 
> See above. If I'm wrong that PII available to an ALTO server or to
> another BGP speaker could be passed on in this way, then I'll just
> clear. If not, then adding your text suggested above could be enough
> for me to clear. (We might want to try improve it of course.)

For "we" read "you" :-)

Where I am at the moment is that I don't have any concrete changes to make to the document to address your discuss. I do have a woolly paragraph that would not be harmful to add (but that would, IMHO, be pointless), but that you say is a "start" and you "might want to improve". That means I am stuck for a way to advance this document.

Alvaro, can you help?

Thanks,
Adrian