On 15/09/2013 22:08, Stephen Farrell wrote:
Hi Brian,
On 09/15/2013 08:42 PM, Brian Trammell wrote:
hi Stephen, Benoit, all,
The survey of anonymization techniques in 6235 was intended primarily
to be a complete accounting of methods one _could_ use to anonymize
fields (Information Elements) in a record, as opposed to a survey of
methods we knew to be implemented. Here the idea was to allow a
complete specification of a metadata format for specifying how
records were anonymized, as input to future analysis tasks to be done
on the data (since the anonymization method affects the set of
analyses for which the data can be used).
So we were really trying to solve a different problem: applying
anonymization (to mask irrelevant and potentially privacy-sensitive
information) while still maintaining the usefulness of the data for
specific analytical tasks. Here we'd like to get rid of absolutely
_everything_ that might be useful for analysis, just keeping around
the minimum necessary for the operation and management of the
protocol.
Which gets me back to thinking it would be very useful to have a
survey of the information radiated by protocols in common usage, then
a systematic exercise to make sure each of those bits of information
which may be identifiable serves a purpose that couldn't be done in
an anonymous or pseudonymous way.
A fine research proposal. (Really, I'd try get dosh for that:-)
But in an IETF context, maybe that'd be a thing that the lmap
wg [1] could look at? Anyone on this list active there?
The lmap charter says: "The LMAP WG will consider privacy as a core
requirement and will ensure that by default measurement and collection
mechanisms and protocols standardized operate in a privacy-sensitive
manner, for example, ensuring that measurements are not personally
identifying except where permission for such has been granted by
identified subjects. Note that this does not mean that all uses of LMAP
need to turn on all privacy features but it does mean that privacy
features do need to be at least well-defined."
(However, if I recall correctly I got that sentence shoe-horned into
their charter, so its not clear to me if the active participants are
actually keen on it or if it'll turn out to be RFC6919 fodder;-)
The issue is that it depends on the use case.
In the use case of the ISP monitoring my access device & link, the ISP
has got anyway some personally identifiable information (PII) for his
monitoring. And this is what I'm expecting as a customer .... when I
call them, complaining about _my _link quality.
However, in the regulator use case, monitoring my access link, I don't
want to share any PII.
Regards, Benoit
S.
[1] http://datatracker.ietf.org/wg/lmap/charter/
Cheers,
Brian
On Sep 15, 2013, at 7:44 PM, Stephen Farrell
<[email protected]> wrote:
Hi Benoit,
On 09/14/2013 12:02 PM, Benoit Claise wrote:
On 13/09/2013 14:37, Stephen Farrell wrote:
On 09/13/2013 05:54 AM, Moritz Bartl wrote:
Hi,
I would very much like to see servers having a minimal
logging policy by default, especially and at least when it
comes to IP addresses. I wonder if RFC 6302 is the right
document to look at or extend for this.
Or obsolete it.
It is easy to flip a switch to enable IP logging. The default
should be no IP logs, which is true for most XMPP servers,
for example, but not for web or mail servers.
The wonderfully ironically named PRISM [1] project was an EU
funded project that did some work on obfuscating IP addresses
in logs.
rfc6235
Yep, sections 4 & 5 of that are generic and not really ipfix
specific.
Do you know of implementations of that for ipfix? Or libraries that
do the various functions?
I wonder if separating those sections out into a separate RFC would
result in more people writing code that supports those kinds of
transformations. Not sure to be honest.
But that is a useful reference, regardless, Thanks, S.
Regards, Benoit
I'd love to see an RFC that described such techniques and
recommended when to use what, so we could point people at
that.
Any takers for a -00 to get that going?
S.
[1] http://www.fp7-prism.eu/
On a side node, can we do anything to get rid of sender IP
addresses in (the first) Received headers of mail?
-- Moritz _______________________________________________
perpass mailing list [email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing
list [email protected]
https://www.ietf.org/mailman/listinfo/perpass .
_______________________________________________ perpass mailing
list [email protected]
https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list
[email protected] https://www.ietf.org/mailman/listinfo/perpass
.
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
