Hi David, That all looks fine to me.
Cheers, S. On 20/09/16 15:47, Black, David wrote: > 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 >>> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3