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:[email protected]] > Sent: Tuesday, September 20, 2016 2:17 AM > To: Black, David; The IESG > Cc: [email protected]; Matthew Bocci; [email protected]; > [email protected]; [email protected] > 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
