Hi Stephen,

Many thanks for the text suggestion:

> Anyway, if it works, I'd suggest adding something simple like:
> 
> "NVEs and NVAs need to collect performance and other data in
> order to carry out their functions. This data can sometimes be
> unexpectedly sensitive, for example, allowing non-obvious
> inferences as to activity within a VM. This provides a reason
> to minimise the data collected so as to be cautious not to
> create such potential vulnerabilities. As noted briefly in
> RFC6973 and RFC7258 there is an inevitable tension between
> being privacy sensitive and network operations that needs to
> be taken into account in nvo3 protocol development."

> Of course that's offered modulo whatever wordsmithing
> makes sense.

I can work with that text, with wordsmithing applied to one sentence:

OLD
   This provides a reason to minimise the data collected
   so as to be cautious not to create such potential vulnerabilities.
NEW
   This provides a reason to minimise the data collected in some
   environments in order to limit potential exposure of sensitive
   information.

I want to add "in some environments" as there are environments
in which this is not a concern, e.g., a data center environment in
which all the tenants, the data center operator and the network
operator are one and the same organization/entity.

Determination of which environments should minimize data
collection would be left as an exercise for the reader.

Beyond that, the word "vulnerabilities" seems susceptible to
misreading - "exposure of sensitive information" is the risk to
be managed.

Thanks, --David

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Sent: Tuesday, September 20, 2016 2:17 AM
> To: Black, David; The IESG
> Cc: draft-ietf-nvo3-a...@ietf.org; Matthew Bocci; nvo3-cha...@ietf.org;
> matthew.bo...@alcatel-lucent.com; nvo3@ietf.org
> Subject: Re: Stephen Farrell's No Objection on draft-ietf-nvo3-arch-07: (with
> COMMENT)
> 
> 
> Hi David,
> 
> Just on this point...
> 
> On 20/09/16 02:06, Black, David wrote:
> >> > - section 16: I think it might be worth noting here that
> >> > meta-data and operational data could be unexpectedly
> >> > sensitive, for example performance statistics could be used
> >> > to infer what's being done in a VM or VN. So in addition to
> >> > encrypting data in transit or storage, one might also want to
> >> > consider minimising the types of data that NVEs/NVAs collect.
> > I believe that's generally the case for operational data, e.g.,
> > performance stats.  If you or the OPS ADs have a reference
> > to suggest, I'd be happy to cite it on this concern, but would
> > prefer not to add a from-scratch discussion, as covering  this:
> >
> >> > That could have an impact on protocols defined later so may
> >> > well be worth noting here too. If you do add text on that you
> >> > may also want to recognise the tension between such data
> >> > minimisation and the operational need to detect misbehaviours
> >> > or errors happening within VNs.
> > is likely to entail a discussion of trust models between a network
> > operator (landlord) and tenants using that network infrastructure.
> > I suspect that discussion will be neither simple nor short, and
> > moreover, it has much broader IETF applicability than just NVO3.
> 
> I do understand your reluctance to open cans of worms, however
> the topic does seem quite relevant to this architecture document,
> even if there is a generic concern as you note, so I'd say it
> would be right to ack the issue here, so that those doing later
> protocol development work don't trip over it at the end of their
> work.
> 
> I don't have a great reference though - this issue is noted in
> RFC7258 of course, but without any real detail. RFC 6973 is also
> relevant I guess.
> 
> Anyway, if it works, I'd suggest adding something simple like:
> 
> "NVEs and NVAs need to collect performance and other data in
> order to carry out their functions. This data can sometimes be
> unexpectedly sensitive, for example, allowing non-obvious
> inferences as to activity within a VM. This provides a reason
> to minimise the data collected so as to be cautious not to
> create such potential vulnerabilities. As noted briefly in
> RFC6973 and RFC7258 there is an inevitable tension between
> being privacy sensitive and network operations that needs to
> be taken into account in nvo3 protocol development."
> 
> Of course that's offered modulo whatever wordsmithing
> makes sense.
> 
> Cheers,
> S.
> 
> 
> 
> >
> > Thanks, --David
> >

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to