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

From: Moritz Bartl <[email-masked]>
Date: Fri, 13 Sep 2013 06:54:18 +0200

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.

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.

On a side node, can we do anything to get rid of sender IP addresses in
(the first) Received headers of mail?

-- Moritz

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Sep 2013 13:37:38 +0100

> if RFC 6302 is the right document to look at or extend for this.

Or obsolete it.

> no IP logs, which is true for most XMPP servers, for example, but not

The wonderfully ironically named PRISM [1] project was an EU funded
project that did some work on obfuscating IP addresses in logs.

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/

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

---

From: manning bill <[email-masked]>
Date: Fri, 13 Sep 2013 21:12:37 -0700

is there a good reason to remove support for address literals?
are you _really_ forcing a critical dependence on the DNS?

/bill

---

From: manning bill <[email-masked]>
Date: Fri, 13 Sep 2013 21:14:29 -0700

sure,  i'm sure this will be complex and difficult…

/bill

---

From: Benoit Claise <[email-masked]>
Date: Sat, 14 Sep 2013 13:02:02 +0200

> project that did some work on obfuscating IP addresses in logs.
rfc6235

Regards, Benoit
> .

---

From: SM <[email-masked]>
Date: Sat, 14 Sep 2013 07:31:12 -0700

Hi Moritz,
>(the first) Received headers of mail?

Yes.  Someone can write an Internet-Draft which recommends that such 
information should not be included.

Regards,
-sm

---

From: Moritz Bartl <[email-masked]>
Date: Sun, 15 Sep 2013 03:11:22 +0200

> are you _really_ forcing a critical dependence on the DNS?

Sorry. What I meant to say was "get rid of sender addresses", as in
client addresses. Both hostname and IP. Today, where most people use
SMTP relays, the relay should not include sender address from
authenticated senders in mail headers. They can keep a local mapping,
say of Message-ID to sender, as long as necessary, but I don't see any
reason to include that data as "world readable" in the mail headers.
Gmail doesn't do it, for example, and rightly so. As a counter-example,
Postfix makes it artificially hard, and it should be its default.

--Mo

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Sep 2013 18:44:35 +0100

Hi Benoit,

>> project that did some work on obfuscating IP addresses in logs.

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.

---

From: Brian Trammell <[email-masked]>
Date: Sun, 15 Sep 2013 21:42:08 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Sep 2013 21:08:24 +0100

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;-)

S.

[1] http://datatracker.ietf.org/wg/lmap/charter/

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 16 Sep 2013 23:02:53 +0200

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Sep 2013 22:08:59 +0100

> call them, complaining about _my _link quality.

Fair enough. OTOH, large organisations do tend to leak out information
once enough people need access (cf. NSA and Snowden:-) so one might
argue that having a well defined way to keep that PII private as you
send it to and then have it stored/processed in the ISP may well be
worthwhile. (And granting special access to some customer support
applications.)

> However, in the regulator use case, monitoring my access link, I don't

More promising:-) So, I guess there ought be an argument for applying
some of the Good-PRISM/RFC6325 techniques in lmap? If so that's good
to hear. (If not, or probably not, be interested in that too.)

Cheers,
S.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 16 Sep 2013 23:23:17 +0200

On 16/09/2013 23:08, Stephen Farrell wrote:
> some of the Good-PRISM/RFC6325 techniques in lmap?
For sure.

Regards, Benoit
> If so that's good

---

From: Scott Brim <[email-masked]>
Date: Mon, 16 Sep 2013 17:42:44 -0400

> to hear. (If not, or probably not, be interested in that too.)

The PII your ISP needs for access management is rather different from what
IMAP needs :-) but yes that would be good in IMAP.

Scott