Subject: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Sep 2013 10:46:59 +0200

Dear all,

FYI. Some LMAP related comments on the <[email-masked]> mailing list.

Regards, Benoit

-------- Original Message --------
Subject: 	Re: [perpass] RFC 6302 Logging Recommendations for 
Internet-Facing Servers
Date: 	Mon, 16 Sep 2013 23:02:53 +0200
From: 	Benoit Claise <[email-masked]>
To: 	Stephen Farrell <[email-masked]>
CC: 	<[email-masked]>, Brian Trammell <[email-masked]>

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-masked]>  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 [email-masked]  
>>>>>> https://www.ietf.org/mailman/listinfo/perpass
>>>>>>
>>>>> _______________________________________________ perpass mailing
>>>>> [email-masked]  
>>>>> https://www.ietf.org/mailman/listinfo/perpass  .
>>>>>
>>> _______________________________________________ perpass mailing
>>> [email-masked]  
>>> https://www.ietf.org/mailman/listinfo/perpass
>>
>> _______________________________________________ perpass mailing list
>> [email-masked]  https://www.ietf.org/mailman/listinfo/perpass
>>
> .
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 18 Sep 2013 11:36:50 -0400

Benoit and Stephen,
watch for the next lmap framework draft,
it will be non-compliant with RFC6919.
Al

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, September 18, 2013 4:47 AM
To: [email-masked]
Subject: [lmap] Fwd: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers

Dear all,

FYI. Some LMAP related comments on the <[email-masked]><mailto:[email-masked]> mailing list.

Regards, Benoit

-------- Original Message --------
Subject:

Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers

Date:

Mon, 16 Sep 2013 23:02:53 +0200

From:

Benoit Claise <[email-masked]><mailto:[email-masked]>

To:

Stephen Farrell <[email-masked]><mailto:[email-masked]>

CC:

<[email-masked]><mailto:[email-masked]>, Brian Trammell <[email-masked]><mailto:[email-masked]>

Hi Brian,

hi Stephen, Benoit, all,

protocol.

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

<[email-masked]><mailto:[email-masked]> wrote:

Hi Benoit,

Hi,

Or obsolete it.

in logs.

rfc6235

specific.

Regards, Benoit

that.

S.

[1] http://www.fp7-prism.eu/

perpass mailing list [email-masked]<mailto:[email-masked]>

list [email-masked]<mailto:[email-masked]>

list [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/perpass

.