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

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/10/15 15:00, Adrian Farrel wrote:
> Morning Stephen,
> 
>> This document does recognise that there can be confidentiality or
>> privacy issues with exporting information in this way. And it
>> correctly (I think) says that just not sending that sensitive data
>> is a good way to handle this and that mechanisms for e.g.
>> aggregating to ensure privacy are out of scope. (As an aside:
>> strengthening that recommendation would be a good thing I think.)
> 
> 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.)

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

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

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?

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

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

> 
>> (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.)

Cheers,
S.

> 
> Cheers, Adrian
> 
> 
>