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.

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to