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

[Brian E Carpenter]

On 26/04/2018 04:07, Amelia Andersdotter wrote:
> On 2018-04-25 14:42, mohamed.boucad...@orange.com wrote:
>> 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.
>> [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.

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
 
> 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.
> 
>>> 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).
>> [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
> 
>>> best,
>>>
>>> A
>>>
 Cheers,

 Med



 *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk]
 *Envoyé :* mercredi 25 avril 2018 13:16
 *À :* BOUCADAIR Mohamed IMT/OLN
 *Cc :* int-a...@ietfa.amsl.com
 *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.
 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.



>>> --
>>> Amelia Andersdotter
>>> Technical Consultant, Digital Programme
>>>
>>> ARTICLE19
>>> www.article19.org
>>>
>>> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
>>>
>>> ___
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area
> 
> 

___
Int-area mailing list
Int-area@ietf.org

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

[Ted Lemon]

On Apr 25, 2018, at 2:49 PM, Povl H. Pedersen  wrote:
> If we have performance issues, a drill down might be performed when the right 
> people are involved. And in a few cases we have located some low and slow 
> attacks and ended up blocking IPs. Usually 1 or 2. So it is crucial for 
> operations to pinpoint specific IPs for say a month. 

Okay, but this won't work for the CGN case, so it's not relevant to the 
proposed work.

> But an IP address is different. We can’t map it to a person. The legal system 
> can map it to a physical location unless that location has shared WiFi, VPN 
> or is a tor exit node. I have all 3. 

Unfortunately, although you are absolutely correct that it can't be mapped to a 
person, that is in fact how LEOs have historically tended to treat it.   The 
person to whom it is mapped is presumed to be the subscriber.

> We don’t send armed police in confiscating everything here in Denmark. Often 
> it is just a friendly knock on the door and a talk/confession. 

Here in the U.S. a criminal investigation of the sort you describe, where the 
victim is a network service provider, seems unlikely, although perhaps in some 
jurisdictions they are catching up.   A typical consumer of this data would be 
a DMCA complainant or a police officer investigating some non-computer-fraud 
case that happens to involve some visible online activity that, if traced, 
might lead in the direction of a suspect.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

[Povl H. Pedersen]

I know what the web people are using the logs for. Most of the stuff they could 
likely do without an IP address. 

If we have performance issues, a drill down might be performed when the right 
people are involved. And in a few cases we have located some low and slow 
attacks and ended up blocking IPs. Usually 1 or 2. So it is crucial for 
operations to pinpoint specific IPs for say a month. 

I also know, that the Bluetooth MACs used for traffic mapping are hashed with a 
key that changes every 6 hours to provide anonymity. But here there is no need 
for the specific MAC. 

Telecoms are tracking tourists phones and selling the data. Anonymous of 
course. But selling info on hotel used, and tourist destinations visited. This 
is abuse and overstepping any privacy expectations. 

But an IP address is different. We can’t map it to a person. The legal system 
can map it to a physical location unless that location has shared WiFi, VPN or 
is a tor exit node. I have all 3. 

I see the abuse if my son surfs on Fortnite sites and I start getting fortnite 
ads. And he gets lawnmower ads. Then somebody assumes more from an IP address 
than they can do with any certainty. 

Last attack we tracked down to 2 IP addresses. Same city. Different Chrome on 
OSX. Same C net. 
We could then use these 2 IPs to find their interests. Newest iPhone. And see a 
Samsung galaxy visiting women’s fashion. This together with the IP and port 
number was something the engineer at the police where happy about. Would make 
it easier for them to talk to the criminals. 

We were not able to find any physical person or address. And we will not know 
about how the case goes before we are awarded damages after conviction. 

But the police engineer has repeated that they want as much info and background 
as we can get them. 

We don’t send armed police in confiscating everything here in Denmark. Often it 
is just a friendly knock on the door and a talk/confession. 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Amelia Andersdotter]

On 2018-04-25 13:16, Povl H. Pedersen wrote:
> 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.

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.

> Our legal department actually suggested we keep logs for 5 years, as
> 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(?)

> 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.
>

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,  > wrote:
>
> Re-,
>
>  
>
> Please see inline.
>
>  
>
> Cheers,
>
> Med
>
>  
>
> *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk
> ]
> *Envoyé :* mercredi 25 avril 2018 11:05
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* int-a...@ietfa.amsl.com 
> *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 

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

[Amelia Andersdotter]

On 2018-04-25 14:42, mohamed.boucad...@orange.com wrote:
> 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.
> [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.

>> 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).
> [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

>> best,
>>
>> A
>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk]
>>> *Envoyé :* mercredi 25 avril 2018 13:16
>>> *À :* BOUCADAIR Mohamed IMT/OLN
>>> *Cc :* int-a...@ietfa.amsl.com
>>> *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.
>>> 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.
>>>
>>>
>>>
>> --
>> Amelia Andersdotter
>> Technical Consultant, Digital Programme
>>
>> ARTICLE19
>> www.article19.org
>>
>> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
>>
>> ___
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area


-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

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


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

Well, you know where I’ll be! :-)

daveor

> On 25 Apr 2018, at 14:55, Ted Lemon  wrote:
> 
> On Apr 25, 2018, at 9:50 AM, Dave O'Reilly  wrote:
>> In that case - that’s substantially all that’s in my Internet Draft. Where 
>> do you see a difference between the content of the Internet Draft and this 
>> apparent consensus?
> 
> In order to answer this I'm going to have to re-read the draft, so it might 
> take a while, but I'll try to get to it today.
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Ted Lemon]

On Apr 25, 2018, at 9:50 AM, Dave O'Reilly  wrote:
> In that case - that’s substantially all that’s in my Internet Draft. Where do 
> you see a difference between the content of the Internet Draft and this 
> apparent consensus?

In order to answer this I'm going to have to re-read the draft, so it might 
take a while, but I'll try to get to it today.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

Oh OK! 

In that case - that’s substantially all that’s in my Internet Draft. Where do 
you see a difference between the content of the Internet Draft and this 
apparent consensus?

daveor

> On 25 Apr 2018, at 14:47, Ted Lemon  wrote:
> 
> On Apr 25, 2018, at 9:44 AM, Dave O'Reilly  wrote:
>> Sorry, I may have misread your email. Are you saying that there are times 
>> when it makes sense to log IP, but NO times in which it makes sense to log 
>> source port? Or something different?
> 
> No, I'm saying that if it makes sense to log source IP address, it makes 
> sense to log source port.
> 
> Where I think we may disagree is on how often it makes sense to log these 
> things.   But I don't think we disagree on what the technical details of the 
> log should look like.
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Ted Lemon]

On Apr 25, 2018, at 9:44 AM, Dave O'Reilly  wrote:
> Sorry, I may have misread your email. Are you saying that there are times 
> when it makes sense to log IP, but NO times in which it makes sense to log 
> source port? Or something different?

No, I'm saying that if it makes sense to log source IP address, it makes sense 
to log source port.

Where I think we may disagree is on how often it makes sense to log these 
things.   But I don't think we disagree on what the technical details of the 
log should look like.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

Sorry, I may have misread your email. Are you saying that there are times when 
it makes sense to log IP, but NO times in which it makes sense to log source 
port? Or something different?

daveor

> On 25 Apr 2018, at 14:39, Ted Lemon  wrote:
> 
> On Apr 25, 2018, at 9:36 AM, Dave O'Reilly  wrote:
>> OK, and what are the disadvantages of logging source port? Specifically, 
>> what are the differential disadvantages between logging IP address and 
>> source port versus only logging IP address?
> 
> I don't think there are times when it makes sense to log IP source address 
> but does not make sense to log source port, at least for IPv4.   For IPv6, 
> you could log /64 prefix and that would get you more information than logging 
> /32 IP address+port does in IPv4.
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Ted Lemon]

On Apr 25, 2018, at 9:36 AM, Dave O'Reilly  wrote:
> OK, and what are the disadvantages of logging source port? Specifically, what 
> are the differential disadvantages between logging IP address and source port 
> versus only logging IP address?

I don't think there are times when it makes sense to log IP source address but 
does not make sense to log source port, at least for IPv4.   For IPv6, you 
could log /64 prefix and that would get you more information than logging /32 
IP address+port does in IPv4.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Ted Lemon]

On Apr 25, 2018, at 5:47 AM, Dave O'Reilly  wrote:
> Considering the examples I provided, would you be prepared to agree that 
> there exist situations where it would be useful to have source port logged 
> alongside IP address?

I think I already agreed that that was true.   I mean, there is the problem 
that the source port/IP address could be a convenient way to deflect blame if 
you have the ability to modify the log, but perhaps that's a tale for another 
debate.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia
> Andersdotter
> Envoyé : mercredi 25 avril 2018 14:37
> À : int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> On 2018-04-25 13:27, mohamed.boucad...@orange.com wrote:
> >     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.
> >
> >
> >
> 
> 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.

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

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

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

> 
> best,
> 
> A
> 
> > Cheers,
> >
> > Med
> >
> >
> >
> > *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk]
> > *Envoyé :* mercredi 25 avril 2018 13:16
> > *À :* BOUCADAIR Mohamed IMT/OLN
> > *Cc :* int-a...@ietfa.amsl.com
> > *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.
> > 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.
> >
> >
> >
> 
> --
> Amelia Andersdotter
> Technical Consultant, Digital Programme
> 
> ARTICLE19
> www.article19.org
> 
> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Amelia Andersdotter]

On 2018-04-25 13:27, mohamed.boucad...@orange.com wrote:
>     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.
>
>  
>

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:p...@my.terminal.dk]
> *Envoyé :* mercredi 25 avril 2018 13:16
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* int-a...@ietfa.amsl.com
> *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.
> 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.
>
>  
>

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

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

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 13:16
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
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.
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, 
> wrote:
Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
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 

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

[Povl H. Pedersen]

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,  wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Povl H. Pedersen [mailto:p...@my.terminal.dk]
> *Envoyé :* mercredi 25 avril 2018 11:05
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* int-a...@ietfa.amsl.com
> *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 

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

[Dave O'Reilly]

Ted,

In response to this email, I refer you to the response I just wrote to Brian E 
Carpenter’s email. 

Considering the examples I provided, would you be prepared to agree that there 
exist situations where it would be useful to have source port logged alongside 
IP address?

daveor

> On 24 Apr 2018, at 16:44, Ted Lemon  wrote:
> 
> On Apr 24, 2018, at 11:30 AM, Dave O'Reilly  wrote:
>> Could you give me an example of when you think it would be appropriate to 
>> log source port and when it would not be?
> 
> It's not appropriate to log source port if there's no potential for abuse by 
> the connecting party, or if the potential for abuse by the connecting party 
> is small compared to the potential for abuse by the consumer of the log 
> information.   As has been mentioned previously, it may make sense to log 
> source port when accepting posts from an end user, or when taking orders, or 
> in similar situations.   But to use the example Amelia gave, if I go to 
> Wikipedia and start reading articles and clicking on links, it isn't 
> appropriate to log the source port.   If I am reading a newspaper, it is not 
> appropriate to log anything about my reading habits (although in this case 
> cookies are likely more of a problem than source port).   It's possible that 
> some government somewhere would disagree; if they do, that's fine, but it's 
> not the IETF's role to promote or enable this behavior.
> 
> To continue the Wikipedia example, Wikipedia does in fact ban IP addresses 
> when abusive behavior is exhibited by some person using that IP address.   I 
> don't think there would be a particular problem extending this to ports as 
> well, although it might not actually be all that useful if they are 
> randomized by the CGN.   I don't know if Wikipedia logs this information for 
> law enforcement use, but if they do, then logging the source port as well _in 
> these situations_ would make sense, even though logging it when the end user 
> is simply reading pages would not.
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

I think Brian has made a great point below. I’d like to provide a few more 
examples (all real) of scenarios where criminal investigations can rely heavily 
on the logs retained by the victim or the platform. 

1. A person running a content business (e.g. blog) and their platform is 
compromised and defaced. 
2. An organisation’s corporate website is compromised and used to host child 
porn (at a hidden URL).
3. Links that serve malware posted in comments of blogs, with malware hosted on 
separate (compromised) sites.
4. Email credentials of an employee in an organisation compromised, log in to 
employee’s webmail and send fake invoices to trick company to transfer money 
into wrong account (BEC fraud).
5. Compromise of email account and used to send fake invoices (same as above, 
but SMTP/POP rather than HTTP)
6. Banking credentials of customers are compromised, fraudster logs in and 
transfers funds out of customer account.
7. Purchase and sale of drugs, guns, etc. on dark web (although this is a whole 
other can of worms, Tor etc…).
8. Posting of “revenge porn” pictures.

Before the group launches into a debate about the pros and cons of the examples 
that I provided above, I wanted to say that the only point I’m making is that 
there are at least some reasons why routine source port logging would be 
advantageous in cases where CGN (or other large-scale address sharing 
technologies) are involved. 

The question of how long these logs are retained for is, as Brian also probably 
rightly points out, not likely to be something that the IETF can meaningfully 
adopt a position on.

daveor

> On 24 Apr 2018, at 23:53, Brian E Carpenter  
> wrote:
> 
> On 25/04/2018 01:25, Ted Lemon wrote:
>> On Apr 24, 2018, at 9:11 AM,  
>>  wrote:
>>> What sort of trade-offs can be added to Dave’s document? Do you have in 
>>> mind something like:
>>> (1)
>>> -Warranting that logging may be misused for tracking users?  
>>> -Logging information can be used for profiling users?
>>> -Not logging is also an option?
>> 
>> I don't think Dave's document is a good starting point.   Amelia (I think it 
>> was Amelia) already pointed out a number of things to talk about: for 
>> example, if you are going to log source ports, it should be possible to log 
>> them only when doing so is necessary, and not log them at other times.
> 
> I have trouble with that. When a user complains that "my transaction at 23:59 
> UTC
> yesterday failed", it's too late to switch on logging. So I think in 
> practice, logging
> for problem debugging needs to be switched on 24x7. Similarly for abuse 
> detection,
> since you can't predict when abuse will happen. I don't think there's a get 
> out
> of jail card here. The problem is what happens to the logged data later, and 
> that
> is a regulatory issue that the IETF can do absolutely, utterly nothing about.
> 
>Brian

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
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, 
> wrote:
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 

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

[Povl H. Pedersen]

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,  wrote:

> 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:int-area-boun...@ietf.org] *De la part de* Povl
> H. Pedersen
> *Envoyé :* mercredi 25 avril 2018 09:55
> *À :* int-a...@ietfa.amsl.com
> *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 

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

[Dave O'Reilly]

> On 25 Apr 2018, at 05:59, Amelia Andersdotter  wrote:
> 
> On 2018-04-25 03:22, Ted Lemon wrote:
>> On Apr 24, 2018, at 7:57 PM, Brian E Carpenter
>> > wrote:
>>> Clearly not, but operations people are much more likely to apply a "log
>>> everything we can store" approach than to be selective in advance. I
>>> think
>>> it's privacy law, not IETF BCPs, that will make them think more
>>> carefully.
>> 
>> That would be an argument for not doing this work, then.
>> 
> 
> It will also be very challenging for lots of smaller operations (I've
> interacted a lot with Swedish municipalities, some varities of Swedish
> NGOs) to know what good practises are, when something is *technically
> necessary* or just *convenient*, when they need to start considering
> privacy terms (basically one it's convenience rather than technology
> that's at play).
> 
> I think these are things that would be helpful if the IETF weeds out.

I agree with the assertion that the IETF has an important role to play here.. 

The point I’m trying to make is that logging less is not a priori the best 
solution, because logging less does not have zero negative consequences. 

daveor
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

> On 24 Apr 2018, at 16:41, Tom Herbert  wrote:
>> 
>> Although not explicitly stated, your message is certainly implying that the 
>> conclusion of your argument is … and therefore we should do nothing.
>> 
>> I agree with you that the world is not perfect - when I’m in an optimistic 
>> state of mind (which is most of the time!) I like to think of it as a work 
>> in progress. However, the position that as long as there are repressive 
>> regimes out there where freedom of speech is not respected we should do 
>> nothing, is one that I think needs to be challenged. What about the rights 
>> of the rest of us in the meantime?
>> 
>> This is the point I’m trying to make: the situation is more nuanced than a 
>> simplistic privacy is good, more privacy is better, total privacy is best 
>> position - this being, at least as it appears to me, the prevailing opinion 
>> within the IETF. All I’m trying to do here is find an appropriate forum 
>> within which to stimulate this discussion.
>> 
>> Part of the problem that I have noticed is that the discussions of privacy 
>> vs. law enforcement access to data are very ideologically motivated - on 
>> both sides - with neither side apparently willing to accept that the other 
>> side has any validity to their position. Not the first time in the history 
>> of humanity that we’ve had that problem. As with all of the most interesting 
>> problems, there isn’t a right or wrong answer, when considering the conflict 
>> between individual right to privacy and law enforcement access to data - the 
>> solution is not one or the other, but much more likely to be somewhere in 
>> the middle.
>> 
> Dave,
> 
> Sure, then propose a solution for that. As others have pointed out
> this current draft is one sided and although acknowledges the fact
> that a balanced approach is warranted, it does nothing to try to find
> a balance. I'd also ask that you be a little more careful in framing
> this as a "privacy" versus "law enforcement" issue. They are not
> mutually exclusive. Many of us believe that privacy is a necessity for
> liberty, security, and crime prevention.
> 

Tom,

Challenge excepted!

I have just finished the document I was working on and it was my intention to 
begin working on a document that might help consideration of this issue next. 
It will take me some time but I will be back to the group when that is finished.

daveor

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

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:int-area-boun...@ietf.org] De la part de Povl H. Pedersen
Envoyé : mercredi 25 avril 2018 09:55
À : int-a...@ietfa.amsl.com
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 
1 profiles was downloaded by the same IP, or from 1 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.
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Povl H. Pedersen]

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 1 profiles was downloaded by the same IP, or from 1
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.
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area