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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 15 Oct 2015 04:37:23 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-idr-ls-distribution-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Note: This may sound like a scary discuss, and who knows but
it might lead to us recognising that some significant work is
needed in future, but I think this should be easily fixed for
this particular document... 

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

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.

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 15 Oct 2015 15:00:59 +0100

Morning Stephen,

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

> there are two more things that need to be noted here, but that

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.

> 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 you could add a strong

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

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.

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

Cheers,
Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Oct 2015 15:03:07 +0100

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

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Oct 2015 16:08:32 +0100

> general point is not blocking.)

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

> If that was clearly stated then that would be good.

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

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

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

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

> in that way to avoid ending up with BGP carrying PII up, down

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.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Oct 2015 16:26:23 +0100

On 16/10/15 16:08, Adrian Farrel wrote:
> 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 ;-)

Ah. Crap. Mea culpa.

Much as I hate to admit it to your good self, I had gotten the
direction of that arrow arse-ways. And that does mean that there
is no new issue, yes.

I've cleared.

S.