Subject: Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

From: "Povl H. Pedersen" <[email-masked]>
Date: Wed, 25 Apr 2018 09:54:34 +0200

Where I work, we keep the firewall logs with port numbers completely
separate from the webserver logs.

Looking at article 25 of GDPR, it is clear that IP addresses are
pseudonymized data in the firewall logs, as there are only 2 ways to
connect the IP address to a physical person.
1. Court order to ISP etc.
2. have the web people look up the IP address in their systrem, trace
requests, and see if they can associate it with a known user identity.

So firewall logs, unless the web people have access to them, are
pseudonymized data. So secure by design (article 25). And we can keep them
for statistics, or investigation purposes.

Now, the question then is, how can we keep enough data in the webserver etc
log to be able to to actually do enough investigation ? A /16 shortening
was suggested. I think this is too large gruping. Can not even be used for
country/city statistical purposes. But of course we can enrich data with
that from the likes of MaxMind, when throwing away trailing bits.

I think we need a minimum /20-/22 and source port in the logs to, with some
degree of confidence, go from events in the webserver logs back to the
firewall log to have necesary information for investigation/authorities. If
we have a /20-/22 and GeoIP data, we might have a few candiates. Then this
is good enough to ensure we can not get back to ONE physical person.

I think, that updating RFC6302 might be a bit early, and we risk that it
has to be revised after the first court makes a decision.

If we keep RFC6302 as is, then companies can defend themself, by saying
they use best practise.

We have another obligation as dataowners/processors. We should keep enough
data to verify a suspected data breach, and judge the impact. If I can not
see if 10000 profiles was downloaded by the same IP, or from 10000
different IPs (out of 65535), I might not be able to fulfill some of the
other requirements in GDPR.

I think the big question here is how the data is stored/processed, and it
must be governed by organizational measures (policies and training). It
would likely be illegal to use to logs to profile a person.But there can be
other interests allowing us to keep the logs, disassociated from user
profiles or other things that allows us to map an IP to an individual.

---

From: <[email-masked]>
Date: Wed, 25 Apr 2018 08:20:57 +0000

Dear Povl,

Thank you for sharing your thoughts.

I have one comment and two clarification questions:

- Wouldn’t logging based /20-/22 nullify the interest to log source ports for investigations? Multiple subscribers may be assigned the same port in the /20 or /22 range.

- GeoIP (whatever that means) is broken when CGNs are in use.
      - How and under which conditions an IP address + port can be used to point to “ONE physical person” especially when address sharing is in use?

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Povl H. Pedersen
Envoyé : mercredi 25 avril 2018 09:55
À : [email-masked]
Objet : Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Where I work, we keep the firewall logs with port numbers completely separate from the webserver logs.

Looking at article 25 of GDPR, it is clear that IP addresses are pseudonymized data in the firewall logs, as there are only 2 ways to connect the IP address to a physical person.
1. Court order to ISP etc.
2. have the web people look up the IP address in their systrem, trace requests, and see if they can associate it with a known user identity.

So firewall logs, unless the web people have access to them, are pseudonymized data. So secure by design (article 25). And we can keep them for statistics, or investigation purposes.

Now, the question then is, how can we keep enough data in the webserver etc log to be able to to actually do enough investigation ? A /16 shortening was suggested. I think this is too large gruping. Can not even be used for country/city statistical purposes. But of course we can enrich data with that from the likes of MaxMind, when throwing away trailing bits.

I think we need a minimum /20-/22 and source port in the logs to, with some degree of confidence, go from events in the webserver logs back to the firewall log to have necesary information for investigation/authorities. If we have a /20-/22 and GeoIP data, we might have a few candiates. Then this is good enough to ensure we can not get back to ONE physical person.

I think, that updating RFC6302 might be a bit early, and we risk that it has to be revised after the first court makes a decision.

If we keep RFC6302 as is, then companies can defend themself, by saying they use best practise.

We have another obligation as dataowners/processors. We should keep enough data to verify a suspected data breach, and judge the impact. If I can not see if 10000 profiles was downloaded by the same IP, or from 10000 different IPs (out of 65535), I might not be able to fulfill some of the other requirements in GDPR.

I think the big question here is how the data is stored/processed, and it must be governed by organizational measures (policies and training). It would likely be illegal to use to logs to profile a person.But there can be other interests allowing us to keep the logs, disassociated from user profiles or other things that allows us to map an IP to an individual.

---

From: "Povl H. Pedersen" <[email-masked]>
Date: Wed, 25 Apr 2018 11:04:50 +0200

If we are at say a /20 or /22 (that is 2000-8000 possible IP addresses),
and we have the source port, then the ISP should be able to see which of
these addresses has the given source port to our destination IP and port.
With a timestamp, the risk of collision is low. And the police can at least
minimize number of suspects.

CGN does not break GeoIP. It still allows us to pinpoint the ISP, but might
not allow us to pinpoint the user any closer than the breakout point. If we
have an ISP, with CGN, and the police can come with a timestamp, and source
port, and a destination ip/port, the carrier can likely determine the
physical person. If he has say 255 possible external IP addresses in use,
the chance of the same source port to the same destination across these is
small.

With address sharing, we can't point to one physical person. I have a
dynamic public IP at home (changes rarely). It is diificult to pinpoint
anything to me, my wife or my children. Or any user of my open WiFi SSID.
>From a legal point of view, this is impossible.

But, the privacy protection in GDPR should protect the 20 y.o. old having a
fixed public IP, living alone. And here a fixed IP is enough for an ISP to
locate a person (or rather a machine) with som certainty.

I think this is all a tradeoff between protecting individuals, while not
completely giving up investigative tools - At least to do investigation
with some statistical probability. And since you do not know which
addresses are used by CGN, you can't handle them different than other IPs.

Having the full firewall logs as a separate supplement to webserver logs
will allow you (in many cases) to use the truncated source IP + port to
find one or a few possible IP addresses. Since you need data from 2
systems, they are Pseudonymized, and our legal department would agree it is
then acceptable.

Today we keep logs for 18-24 months, and most police investigations comes
to us 12-14 months after the crime asking for more details. Sometimes for
cases we did not know existed. We are a PCI audited level 1 retailer with a
few web stores.

We do not have people at work every day to look in logs, so the 3 days
retention is impossible. It may take weeks for us to discover things. If 3
days is to cover the weekend (no 24/7), it should instead be 30 days, as
key employees might have the normal 21 days of holiday and a week to catch
up. Smaller companies might not have overlapping staff skills.

On Wed, Apr 25, 2018 at 10:20 AM, <[email-masked]> wrote:

> - Wouldn’t logging based /20-/22 nullify the interest to log source ports
> for investigations? Multiple subscribers may be assigned the same port in
> the /20 or /22 range.
>
>       - How and under which conditions an IP address + port can be used to
> point to “ONE physical person” especially when address sharing is in use?
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Int-area [mailto:[email-masked]] *De la part de* Povl
> H. Pedersen
> *Envoyé :* mercredi 25 avril 2018 09:55
> *À :* [email-masked]
> *Objet :* Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing
> Technologies
>
>
>
> Now, the question then is, how can we keep enough data in the webserver
> etc log to be able to to actually do enough investigation ? A /16
> shortening was suggested. I think this is too large gruping. Can not even
> be used for country/city statistical purposes. But of course we can enrich
> data with that from the likes of MaxMind, when throwing away trailing bits.
>
> I think we need a minimum /20-/22 and source port in the logs to, with
> some degree of confidence, go from events in the webserver logs back to the

---

From: <[email-masked]>
Date: Wed, 25 Apr 2018 09:22:12 +0000

Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:[email-masked]]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]
Objet : Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

If we are at say a /20 or /22 (that is 2000-8000 possible IP addresses), and we have the source port, then the ISP should be able to see which of these addresses has the given source port to our destination IP and port.
[Med] The assumption about destination IP at the provider side is broken. Further, logging destination IP address is not recommended. RFC6888 says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
      required to do so for administrative reasons.

   Justification:  Destination logging at the CGN creates privacy
      issues.

Note also that recent advances in optimizing logs at CGNs (e.g. port set assignment, deterministic NAT) conflicts with maintaining a track of the destination IP address.

Also, there are stateless address sharing techniques which does not even involve a CGN (MAP-E, MAP-T, …). The information about destination IP address per new session is not an option.

With a timestamp, the risk of collision is low. And the police can at least minimize number of suspects.

[Med] If the destination IP address is not logged at the provider side (which is likely), the collision probability of your proposal may be bigger for deployments which use a low address sharing ratio (1:2, 1:4).

CGN does not break GeoIP. It still allows us to pinpoint the ISP, but might not allow us to pinpoint the user any closer than the breakout point.
[Med] This is exactly what we meant by broken GeoIP in https://tools.ietf.org/html/rfc6269#section-7

If we have an ISP, with CGN, and the police can come with a timestamp, and source port, and a destination ip/port, the carrier can likely determine the physical person. If he has say 255 possible external IP addresses in use, the chance of the same source port to the same destination across these is small.

With address sharing, we can't point to one physical person.
[Med] OK.
I have a dynamic public IP at home (changes rarely). It is diificult to pinpoint anything to me, my wife or my children. Or any user of my open WiFi SSID. From a legal point of view, this is impossible.
[Med] OK.
But, the privacy protection in GDPR should protect the 20 y.o. old having a fixed public IP, living alone. And here a fixed IP is enough for an ISP to locate a person (or rather a machine) with som certainty.
[Med] ISPs operating fixed networks can locate their customers/subscribers whatever scheme used for assigning IP addresses. The identification is based on the line, not IP addresses.

I think this is all a tradeoff between protecting individuals, while not completely giving up investigative tools - At least to do investigation with some statistical probability. And since you do not know which addresses are used by CGN, you can't handle them different than other IPs.
[Med] Given that you stated above that it is difficult to track an individual user based on the IP address, then what is the value of complicating the investigation by not recording the full IP address + port (for this specific investigation purpose)?

Having the full firewall logs as a separate supplement to webserver logs will allow you (in many cases) to use the truncated source IP + port to find one or a few possible IP addresses. Since you need data from 2 systems, they are Pseudonymized, and our legal department would agree it is then acceptable.

Today we keep logs for 18-24 months, and most police investigations comes to us 12-14 months after the crime asking for more details. Sometimes for cases we did not know existed. We are a PCI audited level 1 retailer with a few web stores.

We do not have people at work every day to look in logs, so the 3 days retention is impossible. It may take weeks for us to discover things. If 3 days is to cover the weekend (no 24/7), it should instead be 30 days, as key employees might have the normal 21 days of holiday and a week to catch up. Smaller companies might not have overlapping staff skills.

On Wed, Apr 25, 2018 at 10:20 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Povl,

Cheers,
Med

De : Int-area [mailto:[email-masked]<mailto:[email-masked]>] De la part de Povl H. Pedersen
Envoyé : mercredi 25 avril 2018 09:55
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

---

From: "Povl H. Pedersen" <[email-masked]>
Date: Wed, 25 Apr 2018 13:16:19 +0200

I would keep full IP address + port info in my firewall log. Separate from
the webserver log. This to help the webguys not abusing collected data.
Having talked to the webguys, they use the logfiles in daily operations,
and they see them as necesary to provide continous delivery of the services
to the end user.That is another obligation we have.
Our legal department actually suggested we keep logs for 5 years, as some
data must be kept that long.

The big privacy issue here is more about abuse and losing the data (move
them away from the internet facing server within 3 days would be a good
recommendation). This must be controlled by internal company rules. Not
this RFC that says we must cripple data after 3 days. And 3 days is a
stupid limit if there is a longer weekened/holidays etc. Easter is an
example, Thursday to monday are non-working days. That is 5 days + the
extra. So the 3 days should be 6 days without even accounting for holidays.

On Wed, Apr 25, 2018 at 11:22 AM, <[email-masked]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Povl H. Pedersen [mailto:[email-masked]]
> *Envoyé :* mercredi 25 avril 2018 11:05
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* [email-masked]
> [Med] The assumption about destination IP at the provider side is broken.
> Further, logging destination IP address is not recommended. RFC6888 says
> the following:
>
>
>
> Note also that recent advances in optimizing logs at CGNs (e.g. port set
> assignment, deterministic NAT) conflicts with maintaining a track of the
> destination IP address.
>
>
>
> Also, there are stateless address sharing techniques which does not even
> involve a CGN (MAP-E, MAP-T, …). The information about destination IP
> address per new session is not an option.
>
>
>
>
>
> [Med] If the destination IP address is not logged at the provider side
> (which is likely), the collision probability of your proposal may be bigger
> for deployments which use a low address sharing ratio (1:2, 1:4).
>
> CGN does not break GeoIP. It still allows us to pinpoint the ISP, but
> might not allow us to pinpoint the user any closer than the breakout point.
>
> [Med] This is exactly what we meant by broken GeoIP in
> https://tools.ietf.org/html/rfc6269#section-7
>
>
>
> If we have an ISP, with CGN, and the police can come with a timestamp, and
> source port, and a destination ip/port, the carrier can likely determine
> the physical person. If he has say 255 possible external IP addresses in
> use, the chance of the same source port to the same destination across
> these is small.
>
>
> I have a dynamic public IP at home (changes rarely). It is diificult to
> pinpoint anything to me, my wife or my children. Or any user of my open
> WiFi SSID. From a legal point of view, this is impossible.
>
> [Med] OK.
>
> But, the privacy protection in GDPR should protect the 20 y.o. old having
> a fixed public IP, living alone. And here a fixed IP is enough for an ISP
> to locate a person (or rather a machine) with som certainty.
>
> [Med] ISPs operating fixed networks can locate their customers/subscribers
> whatever scheme used for assigning IP addresses. The identification is
> based on the line, not IP addresses.
>
> [Med] Given that you stated above that it is difficult to track an
> individual user based on the IP address, then what is the value of
> complicating the investigation by not recording the full IP address + port
> (for this specific investigation purpose)?
>
>

---

From: <[email-masked]>
Date: Wed, 25 Apr 2018 11:27:42 +0000

Re-,

I think we are in agreement.

Please note there is ** NO RFC ** which mandates logs to be kept 3 days.

I guess you are referring to this text from Amelia’s I-D (which reflects the author’s opinion):

      SHOULD NOT store logs of incoming IP addresses from inbound
      traffic for longer than three days.

The above proposed text does not make sense to me. The IETF does not have to make a call on such matters.

Cheers,
Med

Envoyé : mercredi 25 avril 2018 13:16

I would keep full IP address + port info in my firewall log. Separate from the webserver log. This to help the webguys not abusing collected data.
Having talked to the webguys, they use the logfiles in daily operations, and they see them as necesary to provide continous delivery of the services to the end user.That is another obligation we have.
Our legal department actually suggested we keep logs for 5 years, as some data must be kept that long.

The big privacy issue here is more about abuse and losing the data (move them away from the internet facing server within 3 days would be a good recommendation). This must be controlled by internal company rules. Not this RFC that says we must cripple data after 3 days. And 3 days is a stupid limit if there is a longer weekened/holidays etc. Easter is an example, Thursday to monday are non-working days. That is 5 days + the extra. So the 3 days should be 6 days without even accounting for holidays.

On Wed, Apr 25, 2018 at 11:22 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 25 Apr 2018 14:36:43 +0200

> have to make a call on such matters.

You could have two different objections to the draft:

1. The IETF does not, in general, recommend grace periods or time
periods for logging, caching, etc. That's just wrong - I find loads of
examples in old and new RFCs of recommended time-periods for data
storage by googling.

2. The time-period as suggested is wrong. For instance, as Povl
proposed, 3 days is reasonable if it's just about shifting the log from
the internet-facing server as such to somewhere else, and for storing
logs at end-destination a longer period of time is necessary.

I think you're aiming for objection 1). I don't see the historical
precedent for this assertion, and it seems to be rather about what the
IETF would feel like. I'm open for discussion on objection 2).

best,

A

> Cheers,
>
> Med
>
>  
>
> *De :*Povl H. Pedersen [mailto:[email-masked]]
> *Envoyé :* mercredi 25 avril 2018 13:16
> *Objet :* Re: [Int-area] WG adoption call: Availability of Information
> in Criminal Investigations Involving Large-Scale IP Address Sharing
> Technologies
>
>  
>
> I would keep full IP address + port info in my firewall log. Separate
> from the webserver log. This to help the webguys not abusing collected
> data. 
>
> Having talked to the webguys, they use the logfiles in daily
> operations, and they see them as necesary to provide continous
> delivery of the services to the end user.That is another obligation we
> have.
> The big privacy issue here is more about abuse and losing the data
> (move them away from the internet facing server within 3 days would be
> a good recommendation). This must be controlled by internal company
> rules. Not this RFC that says we must cripple data after 3 days. And 3
> days is a stupid limit if there is a longer weekened/holidays etc.
> Easter is an example, Thursday to monday are non-working days. That is
> 5 days + the extra. So the 3 days should be 6 days without even
> accounting for holidays.
>
>  
>

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: <[email-masked]>
Date: Wed, 25 Apr 2018 12:42:58 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[email-masked]] De la part de Amelia
> Andersdotter
> Envoyé : mercredi 25 avril 2018 14:37
> À : [email-masked]
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 

[Med] AFAIK, there is no such IETF reco for address sharing specifications. 

> IETF would feel like. I'm open for discussion on objection 2).

[Med] Hmm. Please check https://mailarchive.ietf.org/arch/msg/behave/GzY46_zyxVDeKv10nGzGWM8FA34 

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

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 25 Apr 2018 18:07:18 +0200

> [Med] AFAIK, there is no such IETF reco for address sharing specifications. 

The IETF has made recommendations against a backdrop of highlighted
regulatory requirements mandating storage of data (for 6-12 months), cf
RFC7768, RFC6269. So the time-limits are there, just not decided on
technical merits, but by reference to legal merits.

But the examples I mentioned are for other types of identifiers that are
logged, cached or stored. RFC2308 Section 7.1 and 7.2, for example.
RFC5988 section 6.3. In general, the IETF could decide to recommend data
minimization in terms of storage duration, was what I meant, and it
wouldn't be a complete break from tradition.

> [Med] Hmm. Please check https://mailarchive.ietf.org/arch/msg/behave/GzY46_zyxVDeKv10nGzGWM8FA34 

Not sure I see the relevance? Neither RFC6269 nor RFC7768 should have
been adopted by workgroups or become RFCs if that 2011 e-mail had
established an IETF praxis.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 25 Apr 2018 18:34:46 +0200

> delivery of the services to the end user.That is another obligation we

I'm assuming that subscribers (end users, data subjects, individuals)
are informed of your web analytics practises and consent to it somehow.
Web analytics people use a lot of data for a lot of things that aren't
*technically* required for a service to work. That's why Section 6.2
User involvement of RFC6973 and "It is RECOMMENDED that deviations from
the above practices are carefully documented and communicated to
subscribers," in my draft.

> some data must be kept that long.

I find that difficult to believe. Under accounting/tax law you would
sometimes have to keep track of sales, money received, etc. but surely
your company doesn't do that through IP and source port logs from
Internet-Facing Servers/firewalls(?)

> 5 days + the extra. So the 3 days should be 6 days without even

Earlier you said 30 days, in case someone needs to be on their entire
holidays (three weeks) and another week to work through backlogs,
because they start processing the potential identity of a perpetrator in
a security-related incident from 30 days prior. With DDOS as an example:
if you were DDOS:ed 30 days ago, and only now you're going over the logs
from that event, you should probably just get better at incident
response - so that you could freeze the specific logs relating to that
event in the three-day period that the logs were recommended to be
stored (assuming there's some way of initiating retention of data for a
longer period than three days if necessary, but not as a default).

/a

>
> On Wed, Apr 25, 2018 at 11:22 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Re-,
>
>      
>
>     Please see inline.
>
>      
>
>     Cheers,
>
>     Med
>
>      
>
>     *De :*Povl H. Pedersen [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc :* [email-masked] <mailto:[email-masked]>
>     *Objet :* Re: [Int-area] WG adoption call: Availability of
>     Information in Criminal Investigations Involving Large-Scale IP
>     Address Sharing Technologies
>
>      
>
>     If we are at say a /20 or /22 (that is 2000-8000 possible IP
>     addresses), and we have the source port, then the ISP should be
>     able to see which of these addresses has the given source port to
>     our destination IP and port.
>
>     [Med] The assumption about destination IP at the provider side is
>     broken. Further, logging destination IP address is not
>     recommended. RFC6888 says the following:
>
>      
>
>     Note also that recent advances in optimizing logs at CGNs (e.g.
>     port set assignment, deterministic NAT) conflicts with maintaining
>     a track of the destination IP address.  
>
>      
>
>     Also, there are stateless address sharing techniques which does
>     not even involve a CGN (MAP-E, MAP-T, …). The information about
>     destination IP address per new session is not an option.
>
>      
>
>      
>
>     [Med] If the destination IP address is not logged at the provider
>     side (which is likely), the collision probability of your proposal
>     may be bigger for deployments which use a low address sharing
>     ratio (1:2, 1:4).
>
>     CGN does not break GeoIP. It still allows us to pinpoint the ISP,
>     but might not allow us to pinpoint the user any closer than the
>     breakout point.
>
>     <https://tools.ietf.org/html/rfc6269#section-7>
>
>      
>
>     If we have an ISP, with CGN, and the police can come with a
>     timestamp, and source port, and a destination ip/port, the carrier
>     can likely determine the physical person. If he has say 255
>     possible external IP addresses in use, the chance of the same
>     source port to the same destination across these is small.
>
>
>     I have a dynamic public IP at home (changes rarely). It is
>     diificult to pinpoint anything to me, my wife or my children. Or
>     any user of my open WiFi SSID. From a legal point of view, this is
>     impossible.
>
>     [Med] OK..
>
>     But, the privacy protection in GDPR should protect the 20 y.o. old
>     having a fixed public IP, living alone. And here a fixed IP is
>     enough for an ISP to locate a person (or rather a machine) with
>     som certainty.
>
>     [Med] ISPs operating fixed networks can locate their
>     customers/subscribers whatever scheme used for assigning IP
>     addresses. The identification is based on the line, not IP addresses.
>
>     I think this is all a tradeoff between protecting individuals,
>     while not completely giving up investigative tools - At least to
>     do investigation with some statistical probability. And since you
>     do not know which addresses are used by CGN, you can't handle them
>     different than other IPs.
>
>     complicating the investigation by not recording the full IP
>     address + port (for this specific investigation purpose)?  
>
>
>
>     Having the full firewall logs as a separate supplement to
>     webserver logs will allow you (in many cases) to use the truncated
>     source IP + port to find one or a few possible IP addresses. Since
>     you need data from 2 systems, they are Pseudonymized, and our
>     legal department would agree it is then acceptable.
>
>     Today we keep logs for 18-24 months, and most police
>     investigations comes to us 12-14 months after the crime asking for
>     more details. Sometimes for cases we did not know existed. We are
>     a PCI audited level 1 retailer with a few web stores. 
>
>     We do not have people at work every day to look in logs, so the 3
>     days retention is impossible. It may take weeks for us to discover
>     things. If 3 days is to cover the weekend (no 24/7), it should
>     instead be 30 days, as key employees might have the normal 21 days
>     of holiday and a week to catch up. Smaller companies might not
>     have overlapping staff skills.
>
>      
>
>     On Wed, Apr 25, 2018 at 10:20 AM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     Dear Povl,
>
>      
>
>     - Wouldn’t logging based /20-/22 nullify the interest to log
>     source ports for investigations? Multiple subscribers may be
>     assigned the same port in the /20 or /22 range.
>
>           - How and under which conditions an IP address + port can be
>     used to point to “ONE physical person” especially when address
>     sharing is in use?
>
>      
>
>     Cheers,
>
>     Med
>
>      
>
>     *De :*Int-area [mailto:[email-masked]
>     <mailto:[email-masked]>] *De la part de* Povl H. Pedersen
>     *À :* [email-masked] <mailto:[email-masked]>
>     *Objet :* Re: [Int-area] WG adoption call: Availability of
>     Information in Criminal Investigations Involving Large-Scale IP
>     Address Sharing Technologies
>
>      
>
>     Where I work, we keep the firewall logs with port numbers
>     completely separate from the webserver logs.
>
>     pseudonymized data in the firewall logs, as there are only 2 ways
>     to connect the IP address to a physical person.
>     2. have the web people look up the IP address in their systrem,
>     trace requests, and see if they can associate it with a known user
>     identity.
>
>     pseudonymized data. So secure by design (article 25). And we can
>     keep them for statistics, or investigation purposes.
>
>     Now, the question then is, how can we keep enough data in the
>     webserver etc log to be able to to actually do enough
>     investigation ? A /16 shortening was suggested. I think this is
>     too large gruping. Can not even be used for country/city
>     statistical purposes. But of course we can enrich data with that
>     from the likes of MaxMind, when throwing away trailing bits.
>
>     I think we need a minimum /20-/22 and source port in the logs to,
>     with some degree of confidence, go from events in the webserver
>     logs back to the firewall log to have necesary information for
>     investigation/authorities. If we have a /20-/22 and GeoIP data, we
>     might have a few candiates. Then this is good enough to ensure we
>     can not get back to ONE physical person.
>
>     I think, that updating RFC6302 might be a bit early, and we risk
>     that it has to be revised after the first court makes a decision.
>
>     We have another obligation as dataowners/processors. We should
>     keep enough data to verify a suspected data breach, and judge the
>     impact. If I can not see if 10000 profiles was downloaded by the
>     same IP, or from 10000 different IPs (out of 65535), I might not
>     be able to fulfill some of the other requirements in GDPR.
>
>     I think the big question here is how the data is stored/processed,
>     and it must be governed by organizational measures (policies and
>     training). It would likely be illegal to use to logs to profile a
>     person.But there can be other interests allowing us to keep the
>     logs, disassociated from user profiles or other things that allows
>     us to map an IP to an individual.
>
>      
>
>
>
>

ARTICLE19
www.article19.org

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Apr 2018 16:29:22 +1200

> technical merits, but by reference to legal merits.

We can recommend what we like, but the fact of life is that products will
be designed to support the most stringent regulatory requirement in the
world market, and if there are conflicting requirements in different
jurisdictions there will be corresponding configuration options in the
products. So even if we put privacy-protecting SHOULDs in our RFCs,
the regulators decide what actually happens. I'm not against putting
those SHOULDs but I try to be realistic about their impact.

RFC6269 is Informational, describing issues. So it doesn't matter
what it says, really. It doesn't recommend anything. RFC7768 is
also Informational, only offers "A Suggested Solution", and is not
an IETF document anyway. So again, it doesn't matter what it says.

IMHO we should say nothing that appears to be a recommendation
about the duration of logging. We can say as a factual matter that
logging is useful for operational purposes (fault diagnosis, abuse
detection, and statistical analysis) and may be legally required.
We can say that the logs SHOULD be stored securely, and SHOULD NOT
be retained any longer than is needed for these purposes.

   Brian

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 26 Apr 2018 09:41:26 +0100

Brian,

> On 26 Apr 2018, at 05:29, Brian E Carpenter <[email-masked]> wrote:
> 

[snip]

> detection, and statistical analysis) and may be legally required.

As I mentioned earlier in this discussion, logging is also useful with respect to the societal need for law enforcement (which is not a euphemism for anything!) and also with respect to the rights of victims of crime. 

I mention this again because these two items are always left of the list of reasons why logging is useful, just like you did in your email, but they’re really important ones despite their unpopularity. 

> be retained any longer than is needed for these purposes.

Perfectly reasonable.

daveor

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 26 Apr 2018 13:42:04 +0200

> those SHOULDs but I try to be realistic about their impact.

I think Povl already touched upon the interactions between RFCs and
regulators. It's a question of taste whether one wants to legal system
to hash out what is reasonable or have a technical recommendation. To
me, it seems preferable to have a technically motivated/scrutinized
recommendation. The worst thing that could happen is that we'd have to
revise RFC6302 again.

> be retained any longer than is needed for these purposes.

The risk is then that it's not practically useful for people in
organisations that lack large legal teams. A typical difficult case in
Sweden is municipalities, municipality-owned corporations, civil-society
organisations (I know my affiliation is an CSO for IETF purposes, but
plenty of CSOs don't work in tech standards groups at all) or similar:
they may have a lot of staff, but the vast majority don't have more than
one or two IT staff, and they may have access to lawyers only as needed.
It's a consultant field-day where reliable recommendations are hard to
come by, but they still all have internet-facing servers in one way or
the other.

For that kind of use-case, saying "it depends" is not really helpful.
Also the current RFC6302 is not helpful for this group, since it
provides recommendations that prima facie are shaky against a background
analysis that is also shaky.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 26 Apr 2018 15:01:34 +0100

> 
> On 26 Apr 2018, at 12:42, Amelia Andersdotter <[email-masked]> wrote:
> 

I doubt that the worst thing that could happen is to "have to revise RFC6302 again”. 

If the IETF holds itself to standards of reason, logic and rationality, which I hope it does, then all knowledge is only ever provisional and should be held up to repeated scrutiny. 

Contrary to your position, I would encourage the repeated revision of RFCs whenever new evidence identifies a shortcoming in a published document. 

> analysis that is also shaky.

The absence of recommendations about log retention periods does not mean that recommendations about what to log are not useful. There are technical reasons why logging source port (and supporting recommendations) is a useful thing to do and this recommendation can be made without needing to give any consideration to the period for which those logs are retained. This question can be left to organisations to decide for themselves in the context of their national data protection obligations.

daveor

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 26 Apr 2018 17:26:53 +0200

> The absence of recommendations about log retention periods does not mean that recommendations about what to log are not useful. There are technical reasons why logging source port (and supporting r…

I disagree for a similar reason to that which Povl brought up.

A recommendation to log source ports risks being construed by
implementors, operators and regulators as a technical necessity to log
source ports, including for a long time (in fact, about 12-24 months as
we've heard, or, as stated in the informational RFCs, at least 6 months).

Practises which were already rejected by courts once (general data
retention) could therefore be perpetuated through the technical route.
The only way for a court to re-establish its authority would be to
basically re-draft RFCs itself, or go into a level of technical detail
in its decisions that isn't appropriate. I don't think that's a useful
job for a court to do at all, and I'm not very keen on the working group
working on recommendations that contravene privacy decisions arisen from
the careful assessment of courts over close to a decade on the merits of
logging identifiers. It'd be backdoor politicking.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 26 Apr 2018 16:42:28 +0100

As I mentioned yesterday, I think you are misrepresenting the scope of the ECJ judgement. 

Directive 2006/24/EC (data retention directive) relates to the “retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks”. It was the retention of data in this context that was found to be inappropriate by the ECJ - it does not apply to the retention of data by every website, organisation or person. 

Your argument is not applicable in the context of RFC6302, and in particular in the context of my document, because it (my document) specifically excludes from scope both logging by service providers (ref. section 2) and dismisses centralised connection logging entirely as a solution (ref. section 3).

daveor

> On 26 Apr 2018, at 16:26, Amelia Andersdotter <[email-masked]> wrote:
>

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 26 Apr 2018 23:09:13 +0200

> As I mentioned yesterday, I think you are misrepresenting the scope of the ECJ judgement. 
what it boils down to is that the extensive, long-term logging side of
the argument lost (legally anyway). deal with it, instead of going
around lobbying SDOs.

ARTICLE19
www.article19.org

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2018 13:45:21 +1200

(Bundling answers to two messages)
On 26/04/2018 20:40, Dave O'Reilly wrote:
...
> I mention this again because these two items are always left of the list of reasons why logging is useful, just like you did in your email, but they’re really important ones despite their unpopular…

Then the wisest course for the IETF, which writes technical documents,
is probably to miss out the use cases completely, and simply say
"is useful for operational purposes and may be legally required".

On 26/04/2018 23:42, Amelia Andersdotter wrote:
...
> organisations that lack large legal teams.

That is somebody's problem, but the IETF writes technical specs, and
we don't do well at governance issues. If we make it our problem,
I'm not sure the discussion will ever end. Writing guidance that will
apply equally to (say) Sweden, Burkina Faso and China is probably
impossible anyway.

...
> (I know my affiliation is an CSO for IETF purposes, but
> plenty of CSOs don't work in tech standards groups at all)

To be a little picky, your affiliation doesn't matter here...
we all participate as individuals in the IETF. To be clear,
you raise important issues - for me the question is whether
the IETF is competent to solve them, beyond the narrow technical
aspect.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2018 14:00:29 +1200

> the argument lost (legally anyway). deal with it, instead of going

In Australia, deal with the fact the extensive, long-term logging side of
the argument won** (long term = 2 years). If you're selling products, that means
support logging and retention, with config options.

This is not an area where anybody in authority gives a fig about what
the IETF says.

    Brian

** https://www.ag.gov.au/NationalSecurity/DataRetention/Pages/Frequentlyaskedquestions.aspx

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 05:20:28 +0000

Dear Amelia, 

I reiterate there is no RFC which asks a ***server*** to log IP address for a given time. 

All what we have is a simple recommendation, saying if you log IP address (for whatever reason), then consider logging source port too to ease investigation in case of abuse, etc. 

Source port in its own does not reveal or add another yet set of privacy concerns. 

Cheers,
Med

> De : Amelia Andersdotter [mailto:[email-masked]]
> Envoyé : jeudi 26 avril 2018 17:27
> À : Dave O'Reilly
> Cc : Brian E Carpenter; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > The absence of recommendations about log retention periods does not mean
> that recommendations about what to log are not useful. There are technical
> reasons why logging source port (and supporting recommendations) is a useful
> thing to do and this recommendation can be made without needing to give any
> consideration to the period for which those logs are retained. This question
> can be left to organisations to decide for themselves in the context of their
> national data protection obligations.
>

---

From: Dave O'Reilly <[email-masked]>
Date: Fri, 27 Apr 2018 09:33:21 +0100

> On 26 Apr 2018, at 22:09, Amelia Andersdotter <[email-masked]> wrote:
> 

This is yet another misrepresentation of my position:

extensive: I am suggesting only that source port is logged in addition to IP address (which is already in RFC6302)
long-term: Never once in this discussion have I taken a position on how long logs should be retained. In fact I agreed with others that this is not something the IETF should adopt a position on.
SDO: I don’t even know what an SDO is.

You appear to be fairly entrenched in your position - is there anything I could say, or any evidence I could offer that would be able to influence you? Do you acknowledge at all the validity of the position I am putting forward?

More for the benefit of those that have not read the document and are somewhat distracted by the vocal disagreement with the document, here is what I am recommending (briefly summarised):

1. Vendors who support source port logging should include in their deployment guidance the reasons why source port logging is important.
2. Server software should support logging of source port and, further, should do so in a way that does not substantially impact production performance.
3. Vendors should include at least a sample log configuration that contains source port, preferably log source port by default.
4. Log timestamps should be recorded consistently and with sufficient granularity (one second granularity is adequate)
5. In cases where source port is translated by endpoint infrastructure (e.g. load balancers) the original (before translation) source port should be passed through to the server endpoint for logging, if possible.

RFC6302 already recommends logging of source port for Internet facing servers -  after conducting an analysis of the reasons why source port logging is no routine (despite the publication of RFC6032 in 2011) all I’m trying to do is come up with some further recommendations to make that recommendation more effective.

daveor

---

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 27 Apr 2018 11:15:57 +0200

> support logging and retention, with config options.

The proposer of more mandatory logging recommendations appears to be
from my jurisdiction. Cf
https://www.linkedin.com/in/dave-o-reilly-b373226/ One of his main
supporters in this e-mailing thread also appears to be working for a
company based in my jurisdiction.

i would have been slightly less annoyed had this not been the case. For

> This is not an area where anybody in authority gives a fig about what

This is not reflective of my experience. The details are tedious, but
RFC6302 in its current form, and even more so in the form proposed by
Dave, contains language reflective of objections to the law in my
jurisdiction as propagated by law enforcement officials. The irony of
that situation does not escape me, but neither does the gravity of the
risk that the IETF would aggravate the problem.

It sits poorly with me, but a different way of solving it is simply
withdrawing RFC6302 all together.

best,

A

ARTICLE19
www.article19.org

---

From: Dave O'Reilly <[email-masked]>
Date: Fri, 27 Apr 2018 10:27:09 +0100

I’m not sure what you’re trying to insinuate with your comment about where I’m from and how annoyed that makes you feel. The country where I live has absolutely nothing to do with the substance of the argument - crime attribution arising from the use of carrier grade NAT and other large-scale address sharing technologies is a worldwide problem.

> risk that the IETF would aggravate the problem.

Can you please point out to me something in either RFC6302 or in my document that is contrary to the law in your, or if you prefer our, jurisdiction.

daveor

> On 27 Apr 2018, at 10:15, Amelia Andersdotter <[email-masked]> wrote:
>

---

From: Dave O'Reilly <[email-masked]>
Date: Fri, 27 Apr 2018 10:30:39 +0100

> risk that the IETF would aggravate the problem.

Also, what’s the problem with a position being put forward by law enforcement officials? Do you not think they have a valid perspective on crime attribution? You might not agree with it, but that doesn’t mean there isn’t a point to be made. 

NOTE: anyone who cares to look at my linkedin profile, kindly provided by Amelia, will see that I am not a law enforcement official by the way.  

daveor

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 09:33:01 +0000

Re-,

I don't parse well the comments from you, Amelia. 

For example, when you say:
"The proposer of more mandatory logging recommendations appears"

With all due respect, this is a pure fallacy. 

Dave's document DOES NOT propose anything new to be logged. He is relaying on existing RFCs. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 11:16
> À : Brian E Carpenter; Dave O'Reilly
> Cc : [email-masked]
> > **
> https://www.ag.gov.au/NationalSecurity/DataRetention/Pages/Frequentlyaskedque
> stions.aspx
> >
> 
> 
> --
> Amelia Andersdotter

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 09:34:32 +0000

Dave, 

Your affiliation has nothing to do with this discussion. 

We all are contributing as individuals. 

Cheers,
Med

> De : Int-area [mailto:[email-masked]] De la part de Dave O'Reilly
> Envoyé : vendredi 27 avril 2018 11:31
> À : Amelia Andersdotter
> Cc : [email-masked]
> Also, what’s the problem with a position being put forward by law enforcement
> officials? Do you not think they have a valid perspective on crime
> attribution? You might not agree with it, but that doesn’t mean there isn’t a
> point to be made.
> 
> NOTE: anyone who cares to look at my linkedin profile, kindly provided by
> Amelia, will see that I am not a law enforcement official by the way.
> 
> daveor
> 
>

---

From: Amelia Andersdotter <[email-masked]>
Date: Fri, 27 Apr 2018 11:36:48 +0200

> Also, what’s the problem with a position being put forward by law enforcement officials? Do you not think they have a valid perspective on crime attribution? You might not agree with it, but that d…

It's not a problem /that/, but /how/ and /where/. In the particular case
of these logging proposals, also /when/.

best,

ARTICLE19
www.article19.org

---

From: Dave O'Reilly <[email-masked]>
Date: Fri, 27 Apr 2018 11:11:52 +0100

And so what is the problem with how, where and when I am proposing the adoption of my document?

daveor

> On 27 Apr 2018, at 10:36, Amelia Andersdotter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Apr 2018 09:01:13 +1200

...
> RFC6302 in its current form, 

We need to look at one of those details. RFC6302 starts out by saying:

  "It is RECOMMENDED as best current practice that Internet-facing
   servers logging incoming IP addresses from inbound IP traffic also
   log:

   o  The source port number..."

Therefore, the whole recommendation applies *only* to servers that
happen to log incoming IP addresses. In effect, the document says:

IF you operate an Internet facing server AND you log incoming IP addresses
THEN you should also log the source port numbers (etc.).

That is a purely technical statement, because with address sharing
in use, there is no point in logging addresses without ports.

The document does *not* say:

IF you operate an Internet facing server
THEN you should log incoming IP addresses, source port numbers (etc.).

That would be a completely inappropriate thing for the IETF to say,
because it's outside our technical remit.

If draft-daveor-cgn-logging was adopted as an IETF document, it
should IMHO be subject to the same test: is it describing how to
do something correctly, if you're doing it at all? At least some
of the language in section 7 would need tuning for that. Other
parts seem OK, like "In cases where a software package has
support for logging of incoming source port,..."

Regards
   Brian

---

From: Amelia Andersdotter <[email-masked]>
Date: Sat, 28 Apr 2018 10:02:01 +0200

On 2018-04-27 23:01, Brian E Carpenter wrote:
> We need to look at one of those details. 
/snip/
> happen to log incoming IP addresses. In effect, the document says:

I was trying to clarify that I meant semantics inside of the IETF have
consequences outside of the IETF.

Therefore the response that semantics inside the IETF could
*technically* be construed as being merely semantic isn't satisfying my
concern.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Dave O'Reilly <[email-masked]>
Date: Sat, 28 Apr 2018 09:41:33 +0100

Brian,

You make a perfectly reasonable point in my opinion, which argues for the adoption of the document by the working group (again only in my opinion - I don’t want to put words in your mouth) so that such a discussion of the wording of the recommendations could take place.

daveor

> On 27 Apr 2018, at 22:01, Brian E Carpenter <[email-masked]> wrote:
> 
> ....