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

[Joe Touch]

On 2018-05-11 16:23, Brian E Carpenter wrote:

> On 12/05/2018 01:55, Joe Touch wrote: 
> 
>> Whether 6302 makes a strong recommendation or not, it is clearly aimed at 
>> policy issues.
>> 
>> I don't think we need documents to explain how to implement software that 
>> isn't focused on supporting the protocols we specify.
>> 
>> I prefer to have 6302 deprecated so it is no longer usable as justification 
>> to do otherwise (e.g., as has been done throughout this discussion).
> 
> Only by not reading the words Med quoted.

These words give a quite different impression: 

(abstract) ... this document recommends that Internet-facing servers log
   port number and accurate timestamps in addition to the incoming IP
   address.

Not "only if you're already doing it." - it makes the recommendation to
start, right there.

The motivation to do detailed logging (as recommended in Sec 2) is:

   In the past, to support abuse mitigation or
   public safety requests, ...

By the actual words, this RFC is very clearly motivated from policy, not
protocol reasons.

Joe___
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

[Brian E Carpenter]

On 12/05/2018 01:55, Joe Touch wrote:
> Whether 6302 makes a strong recommendation or not, it is clearly aimed at 
> policy issues.
> 
> I don’t think we need documents to explain how to implement software that 
> isn’t focused on supporting the protocols we specify.
> 
> I prefer to have 6302 deprecated so it is no longer usable as justification 
> to do otherwise (e.g., as has been done throughout this discussion).

Only by not reading the words Med quoted. I agree it would have been
better wordsmithed if it literally said "IF you examine and log packets
THEN this is how to do it." But logically, that's what it says.

   Brian

> 
> Joe
> 
>> On May 10, 2018, at 10:21 PM, mohamed.boucad...@orange.com wrote:
>>
>> Hi Joe,
>>  
>> This is a little bit subtle.
>>  
>> RFC6302 is about operating and protecting a server against abuses, 
>> denial-of-service, and all the issues discussed in rfc6269#section-13.1. 
>> 6302 does not ask a server to enable logging or not: 
>>  
>>The above recommendations apply to current logging practices.  They
>>do not require any changes in the way logging is performed; e.g.,
>>which packets are examined and logged.
>>  
>> Further, 6302 says explicitly:
>>  
>>Discussions about data-retention policies are out of scope for this
>>document. 
>>  
>> Cheers,
>> Med
>>  
>> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
>> Envoyé : mercredi 9 mai 2018 17:02
>> À : int-area
>> Objet : Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>>  
>>
>>
>>
>> From: Int-area <int-area-boun...@ietf.org 
>> <mailto:int-area-boun...@ietf.org>> on behalf of 
>> "mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>" 
>> <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>>
>> Date: Wednesday, May 9, 2018 at 7:26 AM
>> To: Juan Carlos Zuniga <juancarlos.zun...@sigfox.com 
>> <mailto:juancarlos.zun...@sigfox.com>>, "int-area@ietf.org 
>> <mailto:int-area@ietf.org>" <int-area@ietf.org <mailto:int-area@ietf.org>>
>> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>> Hi all, <>
>>  
>> There is no reason to revisit or deprecate RFC6302:
>> · The root technical issues as documented by intarea (RC6269) are 
>> still valid. Those issues will be experienced by more and more in the future.
>> · RFC6302 records a valid technical recommendation for servers 
>> logging IP addresses for abuse purposes.
>>  
>> I don’t think that the IETF has to mandate or preclude (IP address) logging.
>>  
>> I agree with the last sentence above, but I also think that the IETF 
>> shouldn’t be making “recommendations” in this area either (i.e., the last 
>> sentence implies to me that RFC6302 needs to be deprecated). 6302 is about 
>> identifying customers - not protocol or network diagnostics.
>>  
>> IMO:
>>  
>> - the IETF should speak to logging only when it relates to *protocol or 
>> network diagnostics*
>> - this means that the current document should not proceed
>> - this means that RFC6302 should be deprecated
>>  
>> Joe
> 
> 
> 
> 
> ___
> 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

[Joe Touch]

Whether 6302 makes a strong recommendation or not, it is clearly aimed at 
policy issues.

I don’t think we need documents to explain how to implement software that isn’t 
focused on supporting the protocols we specify.

I prefer to have 6302 deprecated so it is no longer usable as justification to 
do otherwise (e.g., as has been done throughout this discussion).

Joe

> On May 10, 2018, at 10:21 PM, mohamed.boucad...@orange.com wrote:
> 
> Hi Joe,
>  
> This is a little bit subtle.
>  
> RFC6302 is about operating and protecting a server against abuses, 
> denial-of-service, and all the issues discussed in rfc6269#section-13.1. 6302 
> does not ask a server to enable logging or not: 
>  
>The above recommendations apply to current logging practices.  They
>do not require any changes in the way logging is performed; e.g.,
>which packets are examined and logged.
>  
> Further, 6302 says explicitly:
>  
>Discussions about data-retention policies are out of scope for this
>document. 
>  
> Cheers,
> Med
>  
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
> Envoyé : mercredi 9 mai 2018 17:02
> À : int-area
> Objet : Re: [Int-area] WG adoption call: Availability of Information in 
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>  
>  
> 
> 
> 
> From: Int-area <int-area-boun...@ietf.org <mailto:int-area-boun...@ietf.org>> 
> on behalf of "mohamed.boucad...@orange.com 
> <mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com 
> <mailto:mohamed.boucad...@orange.com>>
> Date: Wednesday, May 9, 2018 at 7:26 AM
> To: Juan Carlos Zuniga <juancarlos.zun...@sigfox.com 
> <mailto:juancarlos.zun...@sigfox.com>>, "int-area@ietf.org 
> <mailto:int-area@ietf.org>" <int-area@ietf.org <mailto:int-area@ietf.org>>
> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>  
> Hi all, <>
>  
> There is no reason to revisit or deprecate RFC6302:
> · The root technical issues as documented by intarea (RC6269) are 
> still valid. Those issues will be experienced by more and more in the future.
> · RFC6302 records a valid technical recommendation for servers 
> logging IP addresses for abuse purposes.
>  
> I don’t think that the IETF has to mandate or preclude (IP address) logging.
>  
> I agree with the last sentence above, but I also think that the IETF 
> shouldn’t be making “recommendations” in this area either (i.e., the last 
> sentence implies to me that RFC6302 needs to be deprecated). 6302 is about 
> identifying customers - not protocol or network diagnostics.
>  
> IMO:
>  
> - the IETF should speak to logging only when it relates to *protocol or 
> network diagnostics*
> - this means that the current document should not proceed
> - this means that RFC6302 should be deprecated
>  
> Joe

___
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]

Hi Joe,

This is a little bit subtle.

RFC6302 is about operating and protecting a server against abuses, 
denial-of-service, and all the issues discussed in rfc6269#section-13.1. 6302 
does not ask a server to enable logging or not:


   The above recommendations apply to current logging practices.  They

   do not require any changes in the way logging is performed; e.g.,

   which packets are examined and logged.

Further, 6302 says explicitly:

   Discussions about data-retention policies are out of scope for this
   document.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
Envoyé : mercredi 9 mai 2018 17:02
À : int-area
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies





From: Int-area <int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>> on 
behalf of "mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>" 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>
Date: Wednesday, May 9, 2018 at 7:26 AM
To: Juan Carlos Zuniga 
<juancarlos.zun...@sigfox.com<mailto:juancarlos.zun...@sigfox.com>>, 
"int-area@ietf.org<mailto:int-area@ietf.org>" 
<int-area@ietf.org<mailto:int-area@ietf.org>>
Subject: Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Hi all,

There is no reason to revisit or deprecate RFC6302:
• The root technical issues as documented by intarea (RC6269) are still 
valid. Those issues will be experienced by more and more in the future.
• RFC6302 records a valid technical recommendation for servers logging 
IP addresses for abuse purposes.

I don’t think that the IETF has to mandate or preclude (IP address) logging.

I agree with the last sentence above, but I also think that the IETF shouldn’t 
be making “recommendations” in this area either (i.e., the last sentence 
implies to me that RFC6302 needs to be deprecated). 6302 is about identifying 
customers - not protocol or network diagnostics.

IMO:

- the IETF should speak to logging only when it relates to *protocol or network 
diagnostics*
- this means that the current document should not proceed
- this means that RFC6302 should be deprecated

Joe

___
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

[Christian Huitema]

On 5/9/2018 3:44 AM, Juan Carlos Zuniga wrote:

> Hello,
>
>  
>
> The call is now over and there’s been a good discussion on the list.
> Even though there is clearly no rough consensus to get the document
> adopted by the WG, many interesting points have been made.
>
>  
>
> More than the details about what/where/when/how/for-how-long to log,
> the more important question is whether IETF should say anything about
> this topic or not.
>
>  
>
> For this, we need to consider not only the technical details, but also
> the intended audience and the potential implications that the document
> could have outside the IETF.
>
>  
>
> There are three options, which could lead to different next steps:
>
>  
>
>   * Should IETF say anything at all about logging?
>   o If yes,
>   + Are we ok with RFC 6302 in its current form?
>   # If yes: Then we have nothing else to do
>   # If no: Should we amend 6302?
>   o If no,
>   + Should we deprecate/make-historical 6302?
>
>  
>
> Although this is something that may need to be addressed beyond the
> IntArea WG, any inputs people can provide here would be useful.
>

Dave's initial focus was a recommendation for logging on servers,
typically web servers. Such recommendations need to balance a variety of
requirements, from application debugging to failure and fraud
investigations. They also need to consider the inherent risks of storing
private information in logs, from risks of leakage in case of
compromises to non compliance with the GDPR in the EU. The int area
group traditionally focuses on internet level issues. If "the IETF"
wants to issue recommendations for logging on servers, would it not be a
better idea to carry that work in the ops area, or maybe the app area?

-- Christian Huitema

___
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

[Joe Touch]

> On May 9, 2018, at 4:29 PM, Brian E Carpenter  
> wrote:
> 
>> IMO:
>> 
>> - the IETF should speak to logging only when it relates to *protocol or 
>> network diagnostics*
> 
> That may be a bit narrow, which is why I prefer ...relates to *operational 
> requirements*. And yes, that could include requirements over which the 
> operator has no control, such as regulatory requirements. It's really not the 
> IETF's business *why* an operator decides to log stuff. RFC 6302 is about 
> *how* to log address information.

That’s disingenuous at best.

The RFC states:

   ...In the past, to support abuse mitigation or
   public safety requests, the knowledge of the external global IP
   address was enough to identify a subscriber of interest.  With
   address sharing technologies, only providing information about the
   external public address associated with a session to a service
   provider is no longer sufficient information to unambiguously
   identify customers.

This isn’t about how to log. This is about why merely logging the old way 
doesn’t suit a particular reason for logging.

> 
>> - this means that the current document should not proceed
> 
> A slightly different question from whether we should tackle the topic. I 
> don't think the IETF would do itself any favours by tackling the topic. That 
> doesn't mean the topic is unimportant, just that this is not the venue for it.

Granted - my reply could be suffixed with “here in the IETF”..

> 
>> - this means that RFC6302 should be deprecated
> 
> Why? It is about operational logging, and specifically says (end of section 
> 2):

It’s not about logging at all; it’s about what needs to be logged to track 
remote users behind NATs. There’s no justification given for needing to do this 
for operational purposes. The only examples given are regulatory or commercial.

Joe___
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

[Brian E Carpenter]

Joe,
On 10/05/2018 03:02, Joe Touch wrote:
> 
> 
>>
>> From: Int-area <int-area-boun...@ietf.org 
>> <mailto:int-area-boun...@ietf.org>> on behalf of 
>> "mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>" 
>> <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com>>
>> Date: Wednesday, May 9, 2018 at 7:26 AM
>> To: Juan Carlos Zuniga <juancarlos.zun...@sigfox.com 
>> <mailto:juancarlos.zun...@sigfox.com>>, "int-area@ietf.org 
>> <mailto:int-area@ietf.org>" <int-area@ietf.org <mailto:int-area@ietf.org>>
>> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
>> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>>  
>> Hi all, <>
>>  
>> There is no reason to revisit or deprecate RFC6302:
>> · The root technical issues as documented by intarea (RC6269) are 
>> still valid. Those issues will be experienced by more and more in the future.
>> · RFC6302 records a valid technical recommendation for servers 
>> logging IP addresses for abuse purposes.
>>  
>> I don’t think that the IETF has to mandate or preclude (IP address) logging.
> 
> I agree with the last sentence above, but I also think that the IETF 
> shouldn’t be making “recommendations” in this area either (i.e., the last 
> sentence implies to me that RFC6302 needs to be deprecated). 6302 is about 
> identifying customers - not protocol or network diagnostics.
> 
> IMO:
> 
> - the IETF should speak to logging only when it relates to *protocol or 
> network diagnostics*

That may be a bit narrow, which is why I prefer ...relates to *operational 
requirements*. And yes, that could include requirements over which the operator 
has no control, such as regulatory requirements. It's really not the IETF's 
business *why* an operator decides to log stuff. RFC 6302 is about *how* to log 
address information.

> - this means that the current document should not proceed

A slightly different question from whether we should tackle the topic. I don't 
think the IETF would do itself any favours by tackling the topic. That doesn't 
mean the topic is unimportant, just that this is not the venue for it.

> - this means that RFC6302 should be deprecated

Why? It is about operational logging, and specifically says (end of section 2):

>> The above recommendations apply to current logging practices.  They
>> do not require any changes in the way logging is performed; e.g.,
>> which packets are examined and logged.

Regards
   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

[Ted Lemon]

On May 9, 2018, at 11:38 AM, Dave O'Reilly  wrote:
> Indeed, I would go further and assert that the IETF is on a developmental 
> trajectory that actively seeks to eliminate evidence (and attribution of 
> online activity in particular). I cite, for example, the work that has been 
> done in the area of privacy addresses for IPv6 SLAAC. 

There's something that frustrates me about this discussion, which is not 
entirely on-topic for intarea, but which I'm going to mention anyway because 
the discussion has been happening here.

The reality is that what you are saying is sort of true, but also that a lot of 
internet crime exists because there are no consequences for network 
mismanagement.   If I set up an ISP that doesn't follow BCP 38, I will 
experience no consequences.  I will still be able to peer.  There will not even 
be BCP 38 filtering at the peering point.  There certainly need not be BCP 38 
filtering internally.  Nobody is going to ding me for not implementing SAVI.

Why is this?  Because internet regulators aren't interested in making the 
system work better.  They have a problem, and they want a narrow solution to 
that specific problem.  Rather than doing something about the systemic problems 
of the Internet, they want a point solution that makes things worse generally, 
but addresses their specific need.

So yes, I understand where you are coming from here, but in fact the IETF has 
done a pretty good job of giving network management and operations advice, 
which is generally not followed.   And governments that could be setting 
standards like "if you don't do BCP 38, you will not be permitted to continue 
operating" do not.  And people lose really large amounts of money to DDoS 
attacks because of this.

So when you hear people like me pushing back on standardizing port logging, 
part of what's going on is that we are genuinely disgusted with being asked to 
rubber-stamp point solutions when the same organizations that are asking for 
these point solutions have no interest in actually supporting systemic 
solutions to real problems.

TBH I'm not really comfortable with governments mandating BCP 38 support. But 
the fact that they don't even know about BCP 38 and never talk about it is a 
problem.  Instead we see loud engagement demanding things that aren't nearly as 
obviously beneficial, and that have clear downsides.

___
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]

Dear all,

First of all I would like to thank everyone who read, and took the time to 
contribute to the discussion of, my document. 

Obviously I think some work needs to be done to strengthen the recommendations 
of RFC6302, focussing on what should be logged (and adding additional 
recommendations to support that core point) while avoiding the issue of how 
long logs should be retained for. 

On the broader issue however, I would like to offer the following observation: 

The technical decisions that are made in this forum (the IETF broadly, not the 
intarea group specifically) have real, practical consequences for the use and 
abuse of Internet services. While RFCs must have a “Security Considerations” 
section, practically none that I can find consider the implications of breach 
or misuse of services built on the specified protocols from the perspective of 
a subsequent criminal investigation. I refer by way of example to BCP72 
("Guidelines for Writing RFC Text on Security Considerations") which does a 
wonderful job of describing the types of problems that should be considered in 
an RFC “Security Considerations” section, but does not make any mention of the 
needs of an investigation in the case of a security breach or criminal misuse. 
I assert that any consideration of security must, necessarily, consider (at 
least) the implications of a breach of security.

Indeed, I would go further and assert that the IETF is on a developmental 
trajectory that actively seeks to eliminate evidence (and attribution of online 
activity in particular). I cite, for example, the work that has been done in 
the area of privacy addresses for IPv6 SLAAC. 

If the position that the IETF adopts in relation to logging (logging being just 
one example of evidence retention) is that logs should be retained only for 
protocol or network diagnostics, this effectively turns a blind eye to the 
implications that arise from architectural choices that are being made and, 
arguably, does not work towards the IETF’s stated goal to “make the Internet 
work better” - for some unspecified definition of “better” (RFC3935). 

Finally, I want to emphasise that I do not see the evidential needs of law 
enforcement and the need for individual online privacy as /necessarily/ being 
in opposition to each other. There are win-win areas where adequate privacy can 
be maintained while making sure that the information needed for criminal 
investigations is available - but people need to be thinking about this. I am 
working on a third Internet Draft where I will describe a model that I have 
developed to illustrate this concept, which I will be publishing shortly. 

daveor


> On 9 May 2018, at 11:44, Juan Carlos Zuniga <juancarlos.zun...@sigfox.com> 
> wrote:
> 
> Hello,
>  
> The call is now over and there’s been a good discussion on the list. Even 
> though there is clearly no rough consensus to get the document adopted by the 
> WG, many interesting points have been made.
>  
> More than the details about what/where/when/how/for-how-long to log, the more 
> important question is whether IETF should say anything about this topic or 
> not.
>  
> For this, we need to consider not only the technical details, but also the 
> intended audience and the potential implications that the document could have 
> outside the IETF.
>  
> There are three options, which could lead to different next steps:
>  
>   • Should IETF say anything at all about logging?
>   • If yes,
>   • Are we ok with RFC 6302 in its current form?
>   • If yes: Then we have nothing else to do
>   • If no: Should we amend 6302?
>   • If no,
>   • Should we deprecate/make-historical 6302?
>  
> Although this is something that may need to be addressed beyond the IntArea 
> WG, any inputs people can provide here would be useful.
>  
> Best,
>  
> Juan Carlos & Wassim
>  
> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Juan Carlos 
> Zuniga
> Sent: April 19, 2018 5:38 PM
> To: int-area <int-area@ietf.org>
> Subject: [Int-area] WG adoption call: Availability of Information in Criminal 
> Investigations Involving Large-Scale IP Address Sharing Technologies
>  
> Dear all,
>  
> After some discussions on the v6ops and intarea mailing lists, the author of 
> draft-daveor-cgn-logging is requesting its adoption by the IntArea WG.
>  
> Hence, we would like to start a WG adoption call for 
> draft-daveor-cgn-logging-04 
> https://tools.ietf.org/html/draft-daveor-cgn-logging-04.
>  
> Please indicate your preferences/comments on the mailing list. The deadline 
> is May the 4th.
>  
> Best,
>  
> Juan Carlos & Wassim
>  
> _

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

[Joe Touch]

> 
> From: Int-area <int-area-boun...@ietf.org <mailto:int-area-boun...@ietf.org>> 
> on behalf of "mohamed.boucad...@orange.com 
> <mailto:mohamed.boucad...@orange.com>" <mohamed.boucad...@orange.com 
> <mailto:mohamed.boucad...@orange.com>>
> Date: Wednesday, May 9, 2018 at 7:26 AM
> To: Juan Carlos Zuniga <juancarlos.zun...@sigfox.com 
> <mailto:juancarlos.zun...@sigfox.com>>, "int-area@ietf.org 
> <mailto:int-area@ietf.org>" <int-area@ietf.org <mailto:int-area@ietf.org>>
> Subject: Re: [Int-area] WG adoption call: Availability of Information in 
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
>  
> Hi all, <>
>  
> There is no reason to revisit or deprecate RFC6302:
> · The root technical issues as documented by intarea (RC6269) are 
> still valid. Those issues will be experienced by more and more in the future.
> · RFC6302 records a valid technical recommendation for servers 
> logging IP addresses for abuse purposes.
>  
> I don’t think that the IETF has to mandate or preclude (IP address) logging.

I agree with the last sentence above, but I also think that the IETF shouldn’t 
be making “recommendations” in this area either (i.e., the last sentence 
implies to me that RFC6302 needs to be deprecated). 6302 is about identifying 
customers - not protocol or network diagnostics.

IMO:

- the IETF should speak to logging only when it relates to *protocol or network 
diagnostics*
- this means that the current document should not proceed
- this means that RFC6302 should be deprecated

Joe

___
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

[Rajiv Asati (rajiva)]

I agree with Med.

--
Cheers,
Rajiv

From: Int-area <int-area-boun...@ietf.org> on behalf of 
"mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com>
Date: Wednesday, May 9, 2018 at 7:26 AM
To: Juan Carlos Zuniga <juancarlos.zun...@sigfox.com>, "int-area@ietf.org" 
<int-area@ietf.org>
Subject: Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Hi all,

There is no reason to revisit or deprecate RFC6302:

· The root technical issues as documented by intarea (RC6269) are still 
valid. Those issues will be experienced by more and more in the future.

· RFC6302 records a valid technical recommendation for servers logging 
IP addresses for abuse purposes.

I don’t think that the IETF has to mandate or preclude (IP address) logging. 
There are plenty cases where this is justified. Likewise, there are cases where 
this is not motivated at all.

Corollary, the IETF has not to provide a recommendation about “acceptable” 
duration for which logs, if recorded, have to be maintained. There are 
country-specific laws/rules for those matters.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Juan Carlos 
Zuniga
Envoyé : mercredi 9 mai 2018 12:44
À : int-area
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Hello,

The call is now over and there’s been a good discussion on the list. Even 
though there is clearly no rough consensus to get the document adopted by the 
WG, many interesting points have been made.

More than the details about what/where/when/how/for-how-long to log, the more 
important question is whether IETF should say anything about this topic or not.

For this, we need to consider not only the technical details, but also the 
intended audience and the potential implications that the document could have 
outside the IETF.

There are three options, which could lead to different next steps:

·  Should IETF say anything at all about logging?
o  If yes,
§  Are we ok with RFC 6302 in its current form?
·  If yes: Then we have nothing else to do
·  If no: Should we amend 6302?
o  If no,
§  Should we deprecate/make-historical 6302?

Although this is something that may need to be addressed beyond the IntArea WG, 
any inputs people can provide here would be useful.

Best,

Juan Carlos & Wassim

From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Juan Carlos 
Zuniga
Sent: April 19, 2018 5:38 PM
To: int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Subject: [Int-area] WG adoption call: Availability of Information in Criminal 
Investigations Involving Large-Scale IP Address Sharing Technologies


Dear all,



After some discussions on the v6ops and intarea mailing lists, the author of 
draft-daveor-cgn-logging is requesting its adoption by the IntArea WG.



Hence, we would like to start a WG adoption call for 
draft-daveor-cgn-logging-04 
https://tools.ietf.org/html/draft-daveor-cgn-logging-04.



Please indicate your preferences/comments on the mailing list. The deadline is 
May the 4th.



Best,



Juan Carlos & Wassim

___
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]

Hi all,

There is no reason to revisit or deprecate RFC6302:

· The root technical issues as documented by intarea (RC6269) are still 
valid. Those issues will be experienced by more and more in the future.

· RFC6302 records a valid technical recommendation for servers logging 
IP addresses for abuse purposes.

I don't think that the IETF has to mandate or preclude (IP address) logging.. 
There are plenty cases where this is justified. Likewise, there are cases where 
this is not motivated at all.

Corollary, the IETF has not to provide a recommendation about "acceptable" 
duration for which logs, if recorded, have to be maintained. There are 
country-specific laws/rules for those matters.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Juan Carlos 
Zuniga
Envoyé : mercredi 9 mai 2018 12:44
À : int-area
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Hello,

The call is now over and there's been a good discussion on the list. Even 
though there is clearly no rough consensus to get the document adopted by the 
WG, many interesting points have been made.

More than the details about what/where/when/how/for-how-long to log, the more 
important question is whether IETF should say anything about this topic or not.

For this, we need to consider not only the technical details, but also the 
intended audience and the potential implications that the document could have 
outside the IETF.

There are three options, which could lead to different next steps:


  *   Should IETF say anything at all about logging?

 *   If yes,

*   Are we ok with RFC 6302 in its current form?

   *   If yes: Then we have nothing else to do
   *   If no: Should we amend 6302?

 *   If no,

*   Should we deprecate/make-historical 6302?

Although this is something that may need to be addressed beyond the IntArea WG, 
any inputs people can provide here would be useful.

Best,

Juan Carlos & Wassim

From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Juan Carlos 
Zuniga
Sent: April 19, 2018 5:38 PM
To: int-area <int-area@ietf.org<mailto:int-area@ietf.org>>
Subject: [Int-area] WG adoption call: Availability of Information in Criminal 
Investigations Involving Large-Scale IP Address Sharing Technologies


Dear all,



After some discussions on the v6ops and intarea mailing lists, the author of 
draft-daveor-cgn-logging is requesting its adoption by the IntArea WG.



Hence, we would like to start a WG adoption call for 
draft-daveor-cgn-logging-04 
https://tools.ietf.org/html/draft-daveor-cgn-logging-04.



Please indicate your preferences/comments on the mailing list. The deadline is 
May the 4th.



Best,



Juan Carlos & Wassim

___
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

[Juan Carlos Zuniga]

Hello,

The call is now over and there's been a good discussion on the list. Even 
though there is clearly no rough consensus to get the document adopted by the 
WG, many interesting points have been made.

More than the details about what/where/when/how/for-how-long to log, the more 
important question is whether IETF should say anything about this topic or not.

For this, we need to consider not only the technical details, but also the 
intended audience and the potential implications that the document could have 
outside the IETF.

There are three options, which could lead to different next steps:


  *   Should IETF say anything at all about logging?
 *   If yes,
*   Are we ok with RFC 6302 in its current form?
   *   If yes: Then we have nothing else to do
   *   If no: Should we amend 6302?
 *   If no,
*   Should we deprecate/make-historical 6302?

Although this is something that may need to be addressed beyond the IntArea WG, 
any inputs people can provide here would be useful.

Best,

Juan Carlos & Wassim

From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Juan Carlos 
Zuniga
Sent: April 19, 2018 5:38 PM
To: int-area <int-area@ietf.org>
Subject: [Int-area] WG adoption call: Availability of Information in Criminal 
Investigations Involving Large-Scale IP Address Sharing Technologies


Dear all,



After some discussions on the v6ops and intarea mailing lists, the author of 
draft-daveor-cgn-logging is requesting its adoption by the IntArea WG.



Hence, we would like to start a WG adoption call for 
draft-daveor-cgn-logging-04 
https://tools.ietf.org/html/draft-daveor-cgn-logging-04.



Please indicate your preferences/comments on the mailing list. The deadline is 
May the 4th.



Best,



Juan Carlos & Wassim

___
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]

That was a minor point in my email - what about all of the rest of it?

daveor

> On 3 May 2018, at 14:26, Stephen Farrell  wrote:
> 
> 
> Dave,
> 
> On 03/05/18 14:12, Dave O'Reilly wrote:
>> I agree with you that logging source ports is not a PM threat. 
> 
> No, you do not agree with me on that because I did not
> say that. It seems the more words I type in this thread
> the more times I end up having to correct such things,
> so I'm gonna leave it to the chairs to figure out how
> they view the overall state of play and leave it at
> that for now.
> 
> S.
> 
> <0x5AB2FAF17B172BEA.asc>

___
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

[Stephen Farrell]

Dave,

On 03/05/18 14:12, Dave O'Reilly wrote:
> I agree with you that logging source ports is not a PM threat. 

No, you do not agree with me on that because I did not
say that. It seems the more words I type in this thread
the more times I end up having to correct such things,
so I'm gonna leave it to the chairs to figure out how
they view the overall state of play and leave it at
that for now.

S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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]

Stephen,

> On 3 May 2018, at 13:08, Stephen Farrell  wrote:
> 
> You asked for responses, so I'll try, but I don't expect that
> they'll satisfy you as I am not attempting to do the work of
> analysing how your draft does/doesn't affect PM (that's your
> job, not mine:-). But just in case it's useful…
> 

I agree. That’s what I’m trying to do here - argue that my draft has nothing to 
do with pervasive monitoring (I’m using your term as defined in RFC7258).

>>> 
>> 
>> I have read RFC7258 and everything that I can find on the mailing
>> list archive relating to this topic. The fact that by doing so I
>> haven’t come around to your opinion doesn’t mean I haven’t done
>> my homework. Please point out to me what specifically you think I
>> haven’t read rather than casting aspersions.
>> 
>> Maybe I didn’t make clear the point I was trying to make in my
>> email last night - I don’t know. I thought I did, but maybe not.
>> 
>> I am specifically drawing a distinction between monitoring of the
>> sort you are talking about (pervasive monitoring) and the need for
>> access to data for crime attribution. 
> 
> Those aren't commensurate things, so that's not a useful
> distinction, for this discussion.
> 

I agree they’re not commensurate - the issue of crime attribution is smaller, 
and easier to tackle.

I don’t see why the fact that the two issues are different sizes makes the 
distinction that I made made invalid. Can you explain that to me?

>> In my email from last night I
>> said, for example "How do you reconcile the existence of a
>> hypothetical database of everyone’s internet communication with
>> being stumped by CGN?” and requested "not to paint the entire
>> criminal justice system with the brush that has been dirtied by the
>> national security shenanigans that have been taking place."
> 
> - I didn't say there was a DB of everyone's comms. But there are
> lots of large DB's with lots of peoples comms, under the control
> of various actors some of whom spend *lots* of money on their
> PM attacks. So "hypothetical" doesn't help the discussion,
> as that gives the impression that you don't accept that PM is a
> real thing.
> - And I never painted any picture of any criminal justice system,
> neither a dirty one, nor a clean one.
> 

I agree “hypothetical” doesn’t help the discussion. I also acknowledge that the 
Snowdon revelations would suggest that large-scale indiscriminate monitoring of 
our data has been taking place - my question remains though - what has that got 
to do with crime attribution? 

I have already explained the difference - do you recognise that there is a 
difference between these two things?

>> 
>> Crime attribution is in some respects the opposite of monitoring -
> 
> Yet your draft is not the "opposite" of monitoring. (And just
> in case you misinterpret that, I am not saying that monitoring
> is always bad or anything like that.)
> 

My draft proposes logging sufficient information to attribute crime (in the 
presence of CGNs) in the most privacy sensitive way possible - nothing to do 
with monitoring at all.

>> pervasive monitoring is a preemptive act (at least as you appear to
>> be defining it in RFC7258 - "PM is distinguished by being
>> indiscriminate and very large-scale”) whereas crime attribution is
>> an after-the-fact, investigative action to associate known criminal
>> activity with a perpetrator. It is possible to help out in one
>> situation without making things worse in the other.
> 
> Maybe. That's where I think the onus is on you to figure out
> if that's the case or not, and to document it in such a way
> that others can (dis)agree with your analysis.
> 

I refer you to the Council of Europe Budapest convention on cybercrime 
(https://www.coe.int/en/web/conventions/full-list/-/conventions/rms/091680081561).
 This is the most widely adopted model law on cybercrime in the world, with 
currently 56 country signatories - so its provisions are representative of the 
legal situation in 56 countries, including the United States (but ironically 
enough, not including Ireland) :-)

Article 19 describes the procedural powers relating to the search and seizure 
of stored computer data - this is the access to data for crime attribution 
aspect.

Article 20 describes the procedural powers relating to the real-time collection 
of traffic data - this is the monitoring aspect. 

Both are subject to the scope, conditions and safeguards provisions of Articles 
14 and 15, but in summary, these are different things. 

If a national security/police agency/other competent authority walks into an 
ISP with an appropriate court order and tells the ISP to perform monitoring on 
person A (or more ominously in the case of national security, attach this 
“black box” to your network), then that person (or people) is/are going to be 
monitored - otherwise the ISP will be in breach of the law. What has that got 
to do with logging source 

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

[Stephen Farrell]

Dave,

You asked for responses, so I'll try, but I don't expect that
they'll satisfy you as I am not attempting to do the work of
analysing how your draft does/doesn't affect PM (that's your
job, not mine:-). But just in case it's useful...

On 03/05/18 09:32, Dave O'Reilly wrote:
> 
>> On 2 May 2018, at 23:24, Stephen Farrell
>>  wrote:
>> 
>> 
>> On 02/05/18 23:02, Dave O'Reilly wrote:
>>> This is a very emotive topic so I request level-headed
>>> consideration of the context of these revelations,
>> 
>> Please review the long discussion that lead to RFC7258. (That's
>> the one I pointed you at the other day in an off-list discussion.)
>> You may be coming to this topic in an IETF context as a new one,
>> but it is not a new topic here. Asking that we be "level headed"
>> only gives an impression of not having done one's homework.
>> 
> 
> I have read RFC7258 and everything that I can find on the mailing
> list archive relating to this topic. The fact that by doing so I
> haven’t come around to your opinion doesn’t mean I haven’t done
> my homework. Please point out to me what specifically you think I
> haven’t read rather than casting aspersions.
> 
> Maybe I didn’t make clear the point I was trying to make in my
> email last night - I don’t know. I thought I did, but maybe not.
> 
> I am specifically drawing a distinction between monitoring of the
> sort you are talking about (pervasive monitoring) and the need for
> access to data for crime attribution. 

Those aren't commensurate things, so that's not a useful
distinction, for this discussion.

> In my email from last night I
> said, for example "How do you reconcile the existence of a
> hypothetical database of everyone’s internet communication with
> being stumped by CGN?” and requested "not to paint the entire
> criminal justice system with the brush that has been dirtied by the
> national security shenanigans that have been taking place."

- I didn't say there was a DB of everyone's comms. But there are
lots of large DB's with lots of peoples comms, under the control
of various actors some of whom spend *lots* of money on their
PM attacks. So "hypothetical" doesn't help the discussion,
as that gives the impression that you don't accept that PM is a
real thing.
- And I never painted any picture of any criminal justice system,
neither a dirty one, nor a clean one.

> 
> Crime attribution is in some respects the opposite of monitoring -

Yet your draft is not the "opposite" of monitoring. (And just
in case you misinterpret that, I am not saying that monitoring
is always bad or anything like that.)

> pervasive monitoring is a preemptive act (at least as you appear to
> be defining it in RFC7258 - "PM is distinguished by being
> indiscriminate and very large-scale”) whereas crime attribution is
> an after-the-fact, investigative action to associate known criminal
> activity with a perpetrator. It is possible to help out in one
> situation without making things worse in the other.

Maybe. That's where I think the onus is on you to figure out
if that's the case or not, and to document it in such a way
that others can (dis)agree with your analysis.

> 
> Therefore the position adopted by the IETF in RFC7258 does not seem
> to be applicable because we’re not talking about the same thing.

7258 is a BCP that says that the IETF will consider the PM threat.
You may think you've done that, but my reading of the draft (a
few weeks ago) doesn't convince me of that. Saying that "crime
attribution is not PM" is not an answer IMO. Setting HTTP cookies
is not PM, but has been abused for PM for example.

Note that I've not said that logging source ports is a huge new
PM threat. Among the many things I'm also not saying is that
logging source ports is unrelated to PM:-)

> 
>> Other than that:
>> 
>> - In terms of discussion venues within the IETF - ISTM that
>> there's little point in a document about what applications ought
>> log that isn't discussed on the art-area list (as I pointed out in
>> my original mail on this topic and also mentioned the other day).
>> 
> 
> I haven’t got the headspace to have more than one discussion like
> this at a time, so I will post in the artarea list when this
> conversation has concluded.

IMO, that's where a discussion of your draft could be much more
fruitful. That's where there are people who'd know if adding source
ports to application logs would be feasible, break things etc.
I've no clue myself if people who write the code related to such
logs would or would not want to do this. I do suspect that an
RFC recommending something that'd break logging tooling would be
pretty pointless as it'd not happen, and thus not solve the
problem you're aiming to solve.

> 
>> - Your discussion of PM totally misses the point. A lot of traffic 
>> is being stored, it doesn't matter if your preferred LEAs don't
>> have access to that. The question instead is rather whether or not
>> your 

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

[Dave O'Reilly]

Stephen,

If I have given you the impression that I haven’t “done my homework” as you 
said in your email, then please point out what you think I should have read….I 
do happen to quite like reading after all.

Either way, are you going to respond to the substance of my previous email? I 
have re-read your email, and I think my follow-up comments and requests for 
clarification are reasonable.

daveor

>  On 3 May 2018, at 10:39, Stephen Farrell  wrote:
> 
> 
> Dave,
> 
> On 03/05/18 09:32, Dave O'Reilly wrote:
>> Please point out to me what specifically you think I haven’t read
>> rather than casting aspersions.
> That's not useful. I cast no aspersions but solely pointed
> out questions that ought be asked. Please re-read my mail.
> 
> S.
> <0x5AB2FAF17B172BEA.asc>


___
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 2 May 2018, at 23:14, Ted Lemon  wrote:
> 
> On May 2, 2018, at 6:02 PM, Dave O'Reilly  wrote:
>> All of these points are addressed in the current version of the document. 
>> It’s perhaps not put in a way that refers so directly to the regulatory 
>> alternatives but they are discussed. Specifically, an entire section 
>> (Section 3) contains a discussion of the reasons why ISP connection logging 
>> is dismissed as a recommended solution to this problem. IPv6 as an ultimate 
>> solution is also mentioned in the paragraph at the end of Section 1.
> 
> While this is true, there's nothing in the document that we haven't discussed 
> on the mailing list.
> 
>> Your terminology is not very clearly defined, so I’m presuming when you say 
>> pervasive monitoring you mean the interception of the content of 
>> communication. Is that fair?
> 
> https://tools.ietf.org/html/rfc7258
> 
> Look, I'm sorry to belabor the "lazy" point, but the question isn't "is there 
> a problem."   We agree that there is a problem.   The question is, "should 
> the IETF work on it."
> 

I suppose the reason I think the IETF should work on this topic is that I don’t 
think it is acceptable that the IETF wash its hands of the consequences of its 
technical decisions on crime attribution on the internet. Whether those 
implications are “by design" (e.g. IPv6 SLAAC privacy addresses) or indirect 
(e.g. the CGN issues we are currently discussing), the consequences are real 
and are making the world less safe from a criminal investigation point of view.

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 2 May 2018, at 23:24, Stephen Farrell  wrote:
> 
> 
> On 02/05/18 23:02, Dave O'Reilly wrote:
>> This is a very emotive topic so I request level-headed consideration
>> of the context of these revelations, 
> 
> Please review the long discussion that lead to RFC7258. (That's the
> one I pointed you at the other day in an off-list discussion.) You
> may be coming to this topic in an IETF context as a new one, but it
> is not a new topic here. Asking that we be "level headed" only gives
> an impression of not having done one's homework.
> 

I have read RFC7258 and everything that I can find on the mailing list archive 
relating to this topic. The fact that by doing so I haven’t come around to your 
opinion doesn’t mean I haven’t done my homework. Please point out to me what 
specifically you think I haven’t read rather than casting aspersions.

Maybe I didn’t make clear the point I was trying to make in my email last night 
- I don’t know. I thought I did, but maybe not. 

I am specifically drawing a distinction between monitoring of the sort you are 
talking about (pervasive monitoring) and the need for access to data for crime 
attribution. In my email from last night I said, for example "How do you 
reconcile the existence of a hypothetical database of everyone’s internet 
communication with being stumped by CGN?” and requested "not to paint the 
entire criminal justice system with the brush that has been dirtied by the 
national security shenanigans that have been taking place." 

Crime attribution is in some respects the opposite of monitoring - pervasive 
monitoring is a preemptive act (at least as you appear to be defining it in 
RFC7258 - "PM is distinguished by being indiscriminate and very large-scale”) 
whereas crime attribution is an after-the-fact, investigative action to 
associate known criminal activity with a perpetrator. It is possible to help 
out in one situation without making things worse in the other. 

Therefore the position adopted by the IETF in RFC7258 does not seem to be 
applicable because we’re not talking about the same thing.
 
> Other than that:
> 
> - In terms of discussion venues within the IETF - ISTM that there's
> little point in a document about what applications ought log that
> isn't discussed on the art-area list (as I pointed out in my
> original mail on this topic and also mentioned the other day).
> 

I haven’t got the headspace to have more than one discussion like this at a 
time, so I will post in the artarea list when this conversation has concluded.

> - Your discussion of PM totally misses the point. A lot of traffic
> is being stored, it doesn't matter if your preferred LEAs don't have
> access to that. The question instead is rather whether or not your
> proposed mechanism makes PM easier/"better" or not for any of whomever
> you consider bad actors doing PM. And then generalise from that to
> realise that your (or my) classification of good/bad actors is likely
> quite different from classifications that many other people may
> find sensible. (That is not the only question to ponder related to
> your proposed mechanism, but it is one question.)
> 

Are you asserting that source port logging would make PM easier/“better”? 

If so, here you are asserting this again without providing any evidence to 
support your position - I do not accept this and I challenge you to support 
this point with some evidence to move the discussion along.

> In summary: I don't consider that the objections I raised originally
> were answered, nor do recent mails make me any happier about this
> draft. And yes, I would engage in attempts to openly discuss LEA
> requirements (*not* mechanisms, requirements) and how those can or
> cannot be reconciled with today's equally real requirements for
> openness, security and privacy. I don't actually know of a good
> IETF venue for that discussion, but I'd certainly bet a beer it is
> not this list:-)
> 

We briefly discussed this when we met and I also am happy to engage in a 
discussion about LEA requirements but, as I mentioned above, can we finish one 
discussion before moving on to something else.

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

[Stephen Farrell]

On 02/05/18 23:02, Dave O'Reilly wrote:
> This is a very emotive topic so I request level-headed consideration
> of the context of these revelations, 

Please review the long discussion that lead to RFC7258. (That's the
one I pointed you at the other day in an off-list discussion.) You
may be coming to this topic in an IETF context as a new one, but it
is not a new topic here. Asking that we be "level headed" only gives
an impression of not having done one's homework.

Other than that:

- In terms of discussion venues within the IETF - ISTM that there's
little point in a document about what applications ought log that
isn't discussed on the art-area list (as I pointed out in my
original mail on this topic and also mentioned the other day).

- Your discussion of PM totally misses the point. A lot of traffic
is being stored, it doesn't matter if your preferred LEAs don't have
access to that. The question instead is rather whether or not your
proposed mechanism makes PM easier/"better" or not for any of whomever
you consider bad actors doing PM. And then generalise from that to
realise that your (or my) classification of good/bad actors is likely
quite different from classifications that many other people may
find sensible. (That is not the only question to ponder related to
your proposed mechanism, but it is one question.)

In summary: I don't consider that the objections I raised originally
were answered, nor do recent mails make me any happier about this
draft. And yes, I would engage in attempts to openly discuss LEA
requirements (*not* mechanisms, requirements) and how those can or
cannot be reconciled with today's equally real requirements for
openness, security and privacy. I don't actually know of a good
IETF venue for that discussion, but I'd certainly bet a beer it is
not this list:-)

S.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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 May 2, 2018, at 6:02 PM, Dave O'Reilly  wrote:
> All of these points are addressed in the current version of the document. 
> It’s perhaps not put in a way that refers so directly to the regulatory 
> alternatives but they are discussed. Specifically, an entire section (Section 
> 3) contains a discussion of the reasons why ISP connection logging is 
> dismissed as a recommended solution to this problem. IPv6 as an ultimate 
> solution is also mentioned in the paragraph at the end of Section 1.

While this is true, there's nothing in the document that we haven't discussed 
on the mailing list.

> Your terminology is not very clearly defined, so I’m presuming when you say 
> pervasive monitoring you mean the interception of the content of 
> communication. Is that fair?

https://tools.ietf.org/html/rfc7258 

Look, I'm sorry to belabor the "lazy" point, but the question isn't "is there a 
problem."   We agree that there is a problem.   The question is, "should the 
IETF work on it."

___
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]

Ted,

> On 2 May 2018, at 14:02, Ted Lemon  wrote:
> 
> 
>> The only alternatives that I can see for closing the crime attribution 
>> information gap that has been opened by CGN are (a) severely limit the 
>> number of endpoints behind a given CGN IP address (a la what the Belgian 
>> ISPs are doing) or (b) require ISPs to perform connection logging (which is 
>> a privacy disaster) or (c) force migration to IPv6 (which only moves the 
>> problem around as per my other document). If there are any other options, 
>> I’d love to hear them. I can tell you all out there who work in ISPs that 
>> if/when regulators act on this, it’s going to be one of those options for 
>> you. Regulators have only power to regulate ISPs so they will find 
>> ISP-centric solutions, which are the list of options above - none of which I 
>> consider to be very attractive (apart from migration to IPv6). What I was 
>> proposing was an “Internet” solution of a sort, where if source port logging 
>> is done routinely then there is no need for regulatory intervention to close 
>> the information gap - I would like to think that what I was trying to 
>> propose was the “least worst” option for dealing with the problem.
> 
> That's a much better approach to take if you want to convince the working 
> group that this is worth doing.
> 

All of these points are addressed in the current version of the document. It’s 
perhaps not put in a way that refers so directly to the regulatory alternatives 
but they are discussed. Specifically, an entire section (Section 3) contains a 
discussion of the reasons why ISP connection logging is dismissed as a 
recommended solution to this problem. IPv6 as an ultimate solution is also 
mentioned in the paragraph at the end of Section 1.


> BTW, if you are going to take that approach, you should bear in mind that 
> most of us assume that pervasive monitoring is going on already—that is, 
> every connection is already being logged, just not by the ISP.   That may 
> sound like an extreme position to take, but we've seen buildings built in the 
> desert to house this data, so it's hard not to take it seriously.   What we 
> haven't seen, unfortunately, is that data being used for anyone's benefit in 
> terms of preventing or punishing actual online crime.   So at the moment it's 
> all stick, no carrot.


Your terminology is not very clearly defined, so I’m presuming when you say 
pervasive monitoring you mean the interception of the content of communication. 
Is that fair?
 
Connection monitoring of the type you are alluding to, were it performed by an 
ISP - without some sort of legal instruction from a competent court - would 
almost certainly put them in violation of the terms of their operating license 
and probably criminally liable as well. In every jurisdiction that I am aware 
of there is a license obligation on ISPs to maintain the privacy and 
confidentiality of subscriber communication. Maybe someone can point to a 
counterexample but if it’s not universally true I’d imagine it’s true in the 
overwhelming majority of cases.

So what I assume we’re talking about here is law enforcement access to the 
content of communication. Once again, I ask is that what you meant?
 
If that is indeed what you meant, well then what I can tell you is that, as far 
as I understand, these powers cannot be exercised without the most stringent 
judicial oversight - at least not in any country where I have worked. So I 
really do not think the sort of wholesale, indiscriminate data collection of 
the type you are alluding to takes place (or is even an option) in routine 
criminal investigations. That’s to say nothing of the cost in terms of both 
equipment and manpower required to handle in any meaningful way such a volume 
of data.

Counter-terrorism (whatever that means) and national security - these are areas 
where things might be different but I have no experience with them. The Snowden 
and other revelations would certainly suggest that national security agencies 
all around the world are collecting data about all of us (hello NSA!). This is 
a very emotive topic so I request level-headed consideration of the context of 
these revelations, in particular:

1. I encourage you not to paint the entire criminal justice system with the 
brush that has been dirtied by the national security shenanigans that have been 
taking place. 
2. It’s probably fair to say that, in my experience at least, most law 
enforcement agencies neither have or want indiscriminate access to this type of 
data - these are the ones that need help with CGN. How do you reconcile the 
existence of a hypothetical database of everyone’s internet communication with 
being stumped by CGN? Surely one, if it existed and was accessible to law 
enforcement, would preclude the need for dealing with the other?

Finally, to your point about not seeing ‘"that data being used for anyone's 
benefit in terms of preventing or punishing 

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

[Dave O'Reilly]

Dear all,

On reflection, I would like to send a clarification to my previous email. 

I didn’t want to see the conversation going all the way back to the beginning 
and covering the same ground again, so I responded to this email in haste.

In particular in relation to this comment:

> 
> I don’t think even those who are most aggressively opposed to the viewpoint I 
> am espousing here would agree with you that "any logging however, if not done 
> as a temporary measure to understand and enhance a protocol would potentially 
> discourage communication”.

It is a mischaracterisation to represent those with whom I have been engaged as 
“aggressively opposed” to my viewpoint. I think we have covered a lot of ground 
here and both positions have been put forward with gusto but never 
aggressively. I would also like to say that I think that this has been a very 
worthwhile discussion. This comment subtracts from the value of the discussion 
and I apologise for that.

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]

Linus,


> On 2 May 2018, at 15:08, Linus Lüssing  wrote:
> 
> 
> Since the Internet is about communication, I would interpret
> "better" in this context as improving and encouraging communication.
> Any logging however, if not done as a temporary measure to understand
> and enhance a protocol (configuration), will potentially discourage
> communication.
> 

I don’t think even those who are most aggressively opposed to the viewpoint I 
am espousing here would agree with you that "any logging however, if not done 
as a temporary measure to understand and enhance a protocol would potentially 
discourage communication". 

>> a. “Better” will in some sense incorporate “more secure”
>> b. Security includes consideration of the implications of breaches of 
>> security
>> c. The implications of a breach of security need to take into account the 
>> risks to privacy BUT ALSO THE RIGHTS OF VICTIMS OF CRIME
> 
> To me this draft has the potential to stifle the rights of
> victims, too: A permanent IP/source-port logging could create a
> significant barrier for victims to seek help and guidance over the
> Internet. I could not find any such considerations in the current
> draft.
> 

I agree that the document does not contain this, because I do not think it is 
correct. In what way does logging IP/source port create a barrier for victims? 
Why is it any different to logging IP address, which is routine at the moment, 
in terms of creating any sort of barrier for victims?

You mention “permanent” - In case you haven’t already, I encourage you to read 
back over the rest of this thread because we’re specifically not talking about 
how long logs should be kept for, rather the advantages/disadvantages of 
logging source port whenever IP address is logged - and in the case of my 
document, what else can be done to encourage that approach.

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

[Linus Lüssing]

On Wed, May 02, 2018 at 11:15:54AM +0100, Dave O'Reilly wrote:
[...]
> Referring to the mission statement: https://tools.ietf.org/html/rfc3935
> 
> "The goal of the IETF is to make the Internet work better.”
> 
> I offer the following thoughts:
> 
> 1. Definition of the term “Internet”
> 
> RFC3935 defines “Internet” as follows:
> 
> The Internet: A large, heterogeneous collection of interconnected systems 
> that can be used for communication of many different types between any 
> interested parties connected to it.  
[...]
> 2. Definition of the term “better”
> 
> This term is undefined in the document. However, However, I put forward the 
> following argument for your consideration:

Since the Internet is about communication, I would interpret
"better" in this context as improving and encouraging communication.
Any logging however, if not done as a temporary measure to understand
and enhance a protocol (configuration), will potentially discourage
communication.

> a. “Better” will in some sense incorporate “more secure”
> b. Security includes consideration of the implications of breaches of security
> c. The implications of a breach of security need to take into account the 
> risks to privacy BUT ALSO THE RIGHTS OF VICTIMS OF CRIME

To me this draft has the potential to stifle the rights of
victims, too: A permanent IP/source-port logging could create a
significant barrier for victims to seek help and guidance over the
Internet. I could not find any such considerations in the current
draft.

Regards, Linus

___
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 May 2, 2018, at 9:02 AM, Ted Lemon  wrote:
> That's a much better approach to take if you want to convince the working 
> group that this is worth doing.

BTW, if you are going to take that approach, you should bear in mind that most 
of us assume that pervasive monitoring is going on already—that is, every 
connection is already being logged, just not by the ISP.   That may sound like 
an extreme position to take, but we've seen buildings built in the desert to 
house this data, so it's hard not to take it seriously.   What we haven't seen, 
unfortunately, is that data being used for anyone's benefit in terms of 
preventing or punishing actual online crime.   So at the moment it's all stick, 
no carrot.

___
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 May 2, 2018, at 6:14 AM, Dave O'Reilly  wrote:
> No, what you said was that “it’s not clear that the work is in scope of the 
> working group anyway”. And I was asking you, if it isn’t, where would be a 
> more appropriate place to have the discussion? 

It's possible that the IETF would be the best place to do this work if we had 
the energy to do it.   But I don't think we do.   Stephen actually said he'd be 
willing to work on something, but I don't think you took that as a genuine 
offer, or else you concluded that what he'd come up with wouldn't satisfy your 
needs.

There isn't some other working group in the IETF of which I'm aware that would 
be a better place to work on this.   That's why I've mentioned doing it in 
government standards bodies.   E.g., since I think you're in Ireland, maybe 
ETSI.

> Well what it seems to me that you’re saying is that you don’t want to work on 
> the draft, and that’s entirely up to you. So we have you on one side of the 
> opinion and me on the other. I can already see which way (at least the vocal 
> part of the) consensus is - you’d need to be intellectually blind not to - 
> but for me this conversation is as important as the eventual outcome of the 
> document per se. 

What I was exactly saying is that if you want people here to work on it, you 
need to convince us that it's worth working on, and you haven't done that.

> I could go to law enforcement agencies, regulators etc. and talk about this 
> problem - and I have - but they already know it’s a problem and recognise 
> that something needs to be done. It’s only when you present an opinion to a 
> group who have a totally different perspective that you get new arguments 
> presented and get make any sort of intellectual progress. In that regard, 
> none of this discussion has made me less convinced that source port logging 
> is the best solution to crime attribution problems arising from CGN (IPv6 
> migration comes with its own can of worms that I discuss elsewhere). In fact 
> I think I recall that even you agreed that if IP address is being logged, 
> source port should be logged as well. 

Yes.   I don't think anybody here is disagreeing with you on a technical 
level—that's why that's not what we need to talk about.

> The only alternatives that I can see for closing the crime attribution 
> information gap that has been opened by CGN are (a) severely limit the number 
> of endpoints behind a given CGN IP address (a la what the Belgian ISPs are 
> doing) or (b) require ISPs to perform connection logging (which is a privacy 
> disaster) or (c) force migration to IPv6 (which only moves the problem around 
> as per my other document). If there are any other options, I’d love to hear 
> them. I can tell you all out there who work in ISPs that if/when regulators 
> act on this, it’s going to be one of those options for you. Regulators have 
> only power to regulate ISPs so they will find ISP-centric solutions, which 
> are the list of options above - none of which I consider to be very 
> attractive (apart from migration to IPv6). What I was proposing was an 
> “Internet” solution of a sort, where if source port logging is done routinely 
> then there is no need for regulatory intervention to close the information 
> gap - I would like to think that what I was trying to propose was the “least 
> worst” option for dealing with the problem.

That's a much better approach to take if you want to convince the working group 
that this is worth doing.

___
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]

Brian,

A very interesting email. 

Referring to the mission statement: https://tools.ietf.org/html/rfc3935

"The goal of the IETF is to make the Internet work better.”

I offer the following thoughts:

1. Definition of the term “Internet”

RFC3935 defines “Internet” as follows:

The Internet: A large, heterogeneous collection of interconnected systems that 
can be used for communication of many different types between any interested 
parties connected to it.  The term includes both the "core Internet" (ISP 
networks) and "edge Internet” (corporate and private networks, often connected 
via firewalls, NAT boxes, application layer gateways and similar devices).  The 
Internet is a truly global network, reaching into just about every country in 
the world.”

Although “systems” are referenced above it seems to me that the definition is 
intended to relate to internetworking connectivity, rather than end systems. 
Nevertheless, if you look at the work of the IETF, there is clearly work going 
on in relation to the activity of endpoints on the Internet - I could provide a 
list of working groups that I think fall into this category if people disagree 
with this point but I point to the application/real time area generally.

2. Definition of the term “better”

This term is undefined in the document. However, However, I put forward the 
following argument for your consideration:

a. “Better” will in some sense incorporate “more secure”
b. Security includes consideration of the implications of breaches of security
c. The implications of a breach of security need to take into account the risks 
to privacy BUT ALSO THE RIGHTS OF VICTIMS OF CRIME

3. Once again I most also note that RFC3935 puts forward no consideration of 
the victims of crime on the Internet. 

4. On the point of the term internet governance - I agree with you that the 
term is poorly defined. I have briefly read some of your thoughts in the link 
you provided - I have some comments and would be interested in talking about 
that with you. I note you don’t want to have that discussion here but if you 
are interested in corresponding on this point further you might ping me an 
off-list email and we can start a separate discussion.

Regards,
daveor


> On 1 May 2018, at 23:42, Brian E Carpenter  
> wrote:
> 
> On 02/05/2018 04:36, Dave O'Reilly wrote:
> 
>> The IETF has a role in the governance of the Internet, 
> 
> That's news to me. I've never been completely sure what
> "governance of the Internet" actually means**, but in any case
> it isn't mentioned in the mission statement at
> https://tools.ietf.org/html/rfc3935
> 
> Both this draft and draft-andersdotter-intarea-update-to-rfc6302
> take me out of my comfort zone for IETF scope.
> 
>   Brian
> 
> ** Full disclosure: my rants on this topic can be found at
> https://www.cs.auckland.ac.nz/~brian/bits.html
> but please let's not discuss them here.
> 
> ___
> 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]

Brian,

A very interesting email. 

Referring to the mission statement: https://tools.ietf.org/html/rfc3935

"The goal of the IETF is to make the Internet work better.”

I offer the following thoughts:

1. Definition of the term “Internet”

RFC3935 defines “Internet” as follows:

The Internet: A large, heterogeneous collection of interconnected systems that 
can be used for communication of many different types between any interested 
parties connected to it.  The term includes both the "core Internet" (ISP 
networks) and "edge Internet” (corporate and private networks, often connected 
via firewalls, NAT boxes, application layer gateways and similar devices).  The 
Internet is a truly global network, reaching into just about every country in 
the world.”

Although “systems” are referenced above it seems to me that the definition is 
intended to relate to internetworking connectivity, rather than end systems. 
Nevertheless, if you look at the work of the IETF, there is clearly work going 
on in relation to the activity of endpoints on the Internet - I could provide a 
list of working groups that I think fall into this category if people disagree 
with this point but I point to the application/real time area generally.

2. Definition of the term “better”

This term is undefined in the document. However, However, I put forward the 
following argument for your consideration:

a. “Better” will in some sense incorporate “more secure”
b. Security includes consideration of the implications of breaches of security
c. The implications of a breach of security need to take into account the risks 
to privacy BUT ALSO THE RIGHTS OF VICTIMS OF CRIME

3. Once again I most also note that RFC3935 puts forward no consideration of 
the victims of crime on the Internet. 

4. On the point of the term internet governance - I agree with you that the 
term is poorly defined. I have briefly read some of your thoughts in the link 
you provided - I have some comments and would be interested in talking about 
that with you. I note you don’t want to have that discussion here but if you 
are interested in corresponding on this point further you might ping me an 
off-list email and we can start a separate discussion.

Regards,
daveor



> On 1 May 2018, at 23:42, Brian E Carpenter  
> wrote:
> 
> On 02/05/2018 04:36, Dave O'Reilly wrote:
> 
>> The IETF has a role in the governance of the Internet, 
> 
> That's news to me. I've never been completely sure what
> "governance of the Internet" actually means**, but in any case
> it isn't mentioned in the mission statement at
> https://tools.ietf.org/html/rfc3935
> 
> Both this draft and draft-andersdotter-intarea-update-to-rfc6302
> take me out of my comfort zone for IETF scope.
> 
>   Brian
> 
> ** Full disclosure: my rants on this topic can be found at
> https://www.cs.auckland.ac.nz/~brian/bits.html
> but please let's not discuss them here.
> 
> ___
> 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]

Ted,

> On 1 May 2018, at 17:55, Ted Lemon  wrote:
> 
> On May 1, 2018, at 12:36 PM, Dave O'Reilly  wrote:
>> 3. If there is a more appropriate forum for discussion, what do you think it 
>> is?
> 
> I didn't say that there was a better forum.  

No, what you said was that “it’s not clear that the work is in scope of the 
working group anyway”. And I was asking you, if it isn’t, where would be a more 
appropriate place to have the discussion? 

> I said that you haven't said anything to convince me that the IETF in 
> particular should be working on this, or that it's worth my time in 
> particular to try to help you navigate the balance between doing something 
> you think is necessary and making things worse for the online safety of 
> Internet users.
> 
> In particular, this is not an internet governance issue.   You are talking 
> about logging of A+P on servers on the internet, not the operation of the 
> internet.
> 

That depends how you define Internet governance, I suppose. I would argue 
otherwise but it’s not too important - see also the comments in the email to 
Brian. 

> Again, don't tell me what the value of this is to you.   We already 
> understand that it's valuable to you.   Try to figure out how it's valuable 
> to the IETF.  Why we should spend time working on it.   Tell us why we should 
> put the IETF's name on it, and say that it's how the IETF recommends things 
> be done.
> 
> The problem is that you've already tried to do that, and it wasn't 
> convincing.   I don't think this is something the IETF should work on, and 
> you haven't convinced me otherwise.   It seems to me more like something a 
> government standards org should work on.   That would make it applicable in 
> the right context, and would prevent it from becoming a blanket 
> recommendation, which is what it would have to be if the IETF published it.
> 

Well what it seems to me that you’re saying is that you don’t want to work on 
the draft, and that’s entirely up to you. So we have you on one side of the 
opinion and me on the other. I can already see which way (at least the vocal 
part of the) consensus is - you’d need to be intellectually blind not to - but 
for me this conversation is as important as the eventual outcome of the 
document per se. 

I could go to law enforcement agencies, regulators etc. and talk about this 
problem - and I have - but they already know it’s a problem and recognise that 
something needs to be done. It’s only when you present an opinion to a group 
who have a totally different perspective that you get new arguments presented 
and get make any sort of intellectual progress. In that regard, none of this 
discussion has made me less convinced that source port logging is the best 
solution to crime attribution problems arising from CGN (IPv6 migration comes 
with its own can of worms that I discuss elsewhere). In fact I think I recall 
that even you agreed that if IP address is being logged, source port should be 
logged as well. 

The only alternatives that I can see for closing the crime attribution 
information gap that has been opened by CGN are (a) severely limit the number 
of endpoints behind a given CGN IP address (a la what the Belgian ISPs are 
doing) or (b) require ISPs to perform connection logging (which is a privacy 
disaster) or (c) force migration to IPv6 (which only moves the problem around 
as per my other document). If there are any other options, I’d love to hear 
them. I can tell you all out there who work in ISPs that if/when regulators act 
on this, it’s going to be one of those options for you. Regulators have only 
power to regulate ISPs so they will find ISP-centric solutions, which are the 
list of options above - none of which I consider to be very attractive (apart 
from migration to IPv6). What I was proposing was an “Internet” solution of a 
sort, where if source port logging is done routinely then there is no need for 
regulatory intervention to close the information gap - I would like to think 
that what I was trying to propose was the “least worst” option for dealing with 
the problem.

Whether the IETF is going to do anything about the problem - and I think it 
should - is incidental, but as you have pointed out I am only once voice. The 
problem is real and someone needs to do something. 

Finally, I’d also like to point out that one of the recommendations that I made 
in my document is that awareness of this issue needs to be raised and perhaps 
there’s someone who is reading this thread who might now be aware of this 
problem who wasn’t already and it might, in some small way, shape future 
thinking.

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

[Brian E Carpenter]

On 02/05/2018 04:36, Dave O'Reilly wrote:

> The IETF has a role in the governance of the Internet, 

That's news to me. I've never been completely sure what
"governance of the Internet" actually means**, but in any case
it isn't mentioned in the mission statement at
https://tools.ietf.org/html/rfc3935

Both this draft and draft-andersdotter-intarea-update-to-rfc6302
take me out of my comfort zone for IETF scope.

   Brian

** Full disclosure: my rants on this topic can be found at
https://www.cs.auckland.ac.nz/~brian/bits.html
but please let's not discuss them here.

___
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 May 1, 2018, at 12:36 PM, Dave O'Reilly  wrote:
> 3. If there is a more appropriate forum for discussion, what do you think it 
> is?

I didn't say that there was a better forum.   I said that you haven't said 
anything to convince me that the IETF in particular should be working on this, 
or that it's worth my time in particular to try to help you navigate the 
balance between doing something you think is necessary and making things worse 
for the online safety of Internet users.

In particular, this is not an internet governance issue.   You are talking 
about logging of A+P on servers on the internet, not the operation of the 
internet.

Again, don't tell me what the value of this is to you.   We already understand 
that it's valuable to you.   Try to figure out how it's valuable to the IETF.  
Why we should spend time working on it.   Tell us why we should put the IETF's 
name on it, and say that it's how the IETF recommends things be done.

The problem is that you've already tried to do that, and it wasn't convincing.  
 I don't think this is something the IETF should work on, and you haven't 
convinced me otherwise.   It seems to me more like something a government 
standards org should work on.   That would make it applicable in the right 
context, and would prevent it from becoming a blanket recommendation, which is 
what it would have to be if the IETF published it.

___
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]

Thanks Juan Carlos,

My response to Teds email is below:

> Again, Dave, that is not the conversation we are having here.   The way that 
> a document is adopted is not "we adopt it unless nobody objects."   It is "we 
> see if there is consensus to adopt it, and if it's in scope for the work we 
> are chartered to do, and if both of these are true, and if there is energy in 
> the working group to work on it, then we work on it.”
>  

I’m aware of this and, to be honest, it’s clear to me that there is no 
consensus (at least no vocal consensus in this discussion so far) for the 
adoption of the document. Nevertheless, all I can do is present my arguments as 
robustly as I can and to the best of my ability.

> The problems you have are:
>  
>   • There are quite a few participants here who think this is not a good 
> idea for the IETF to work on

That is apparent to me :-)

>   • It's not clear that the work is in scope for the working group anyway

Well, three things there:

1. It was Suresh Krishnan (the intarea director) that referred me to the 
intarea group with my draft in the first place.
2. If I look at the charter for the intarea group 
(https://datatracker.ietf.org/doc/charter-ietf-intarea/) I noted the following 
scope item in particular seems applicable: "The Internet Area receives 
occasional proposals for the development and publication of RFCs that are not 
in scope of an existing working group and do not justify the formation of a new 
working group. The INTAREA WG has a secondary role to serve as the forum for 
developing such workitems in the IETF."
3. If there is a more appropriate forum for discussion, what do you think it is?

>   • For me at least, this is work that I can't get paid to do, and so I 
> don't want to do it.   So if I'm going to participate, I have to be convinced 
> that there's a really serious problem here that is urgent enough that the 
> working group must work on it or there will be some bad outcome.  

Same here.

> And you haven't made that case at all—it's pretty clear that there are some 
> benefits to doing the work, but there are also some drawbacks, and figuring 
> out the right balance will be a lot of work.   Not doing the work is less 
> work.   So if you want the working group to work on this, you need to explain 
> to us why it's worth it to us to spend our resources on this, rather than 
> saying "no, let's not do this.”

How can I make it more clear? 

In the document I refer to law enforcement publications that state that the 
crime attribution challenges presented by carrier grade NAT are serious 
internet governance challenges 
(https://www.europol.europa.eu/sites/default/files/documents/europol_iocta_web_2016.pdf).
 Also this document refers to an EU survey (reference no. 186) that indicates 
that 90% of respondents (cybercrime units in EU member states) regularly 
encounter carrier grade NAT in their investigations.

intarea has already published RFC6302 and all I’m trying to do is enhance the 
effectiveness of the recommendations already published in that document.

>  
> "No, let's not do this" is the default, and it's my personal preference, 
> since I'm pretty sure there are other, more valuable things I could do with 
> the time I'd spend trying to get this document to do as little harm as 
> possible.   Unfortunately, it's pretty clear to me that if the working group 
> adopts this document, I will have to do that work, so that's why I'm pushing 
> back on adoption.
>  
> If this seems like a pretty high bar to get over, that's because it is.   The 
> IETF should not work on a document just because some IETF participant thinks 
> it's worth working on.   The reason you want to do this in the IETF is that 
> there's value to you in the IETF having published the document, and not some 
> other organization, and not you personally.   What's the value to the IETF in 
> publishing this document?

I suppose I can see how it would appear that way to you. There’s value to me in 
the sense that I think the world (and the Internet in particular) would be a 
better place if more cybercriminals were caught. 

The IETF has a role in the governance of the Internet, I am pointing out a 
governance problem along with a proposal for some recommendations - that’s the 
value to the IETF. 

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]

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  
> wrote:
> 
> On 27/04/2018 21:15, Amelia Andersdotter wrote:
>> On 2018-04-27 04:00, Brian E Carpenter wrote:
> 
> 
>> i would have been slightly less annoyed had this not been the case. For
>> this reason:
>> 
>>> This is not an area where anybody in authority gives a fig about what
>>> the IETF says.
>> 
>> This is not reflective of my experience. The details are tedious, but
>> 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
> 
> ___
> 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

[Brian E Carpenter]

On 27/04/2018 21:15, Amelia Andersdotter wrote:
> On 2018-04-27 04:00, Brian E Carpenter wrote:


> i would have been slightly less annoyed had this not been the case. For
> this reason:
> 
>> This is not an area where anybody in authority gives a fig about what
>> the IETF says.
> 
> This is not reflective of my experience. The details are tedious, but
> 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

___
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]

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  wrote:
> 
> On 2018-04-27 11:30, Dave O'Reilly wrote:
>>> 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.
>> 
>> 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. 
>> 
> 
> It's not a problem /that/, but /how/ and /where/. In the particular case
> of these logging proposals, also /when/.
> 
> best,
> 
> -- 
> 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

[Amelia Andersdotter]

On 2018-04-27 11:30, Dave O'Reilly wrote:
>> 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.
>
> 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. 
>

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

best,

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

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia
> Andersdotter
> Envoyé : vendredi 27 avril 2018 11:16
> À : Brian E Carpenter; Dave O'Reilly
> Cc : 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-27 04:00, Brian E Carpenter wrote:
> > On 27/04/2018 09:09, Amelia Andersdotter wrote:
> >> On 2018-04-26 17:41, Dave O'Reilly wrote:
> >>> 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.
> > 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.
> 
> 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 reason:
> 
> > This is not an area where anybody in authority gives a fig about what
> > the IETF says.
> 
> 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
> 
> > Brian
> >
> > **
> https://www.ag.gov.au/NationalSecurity/DataRetention/Pages/Frequentlyaskedque
> stions.aspx
> >
> 
> 
> --
> 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

[mohamed.boucadair]

Dave, 

Your affiliation has nothing to do with this discussion. 

We all are contributing as individuals. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Dave O'Reilly
> Envoyé : vendredi 27 avril 2018 11:31
> À : Amelia Andersdotter
> Cc : int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> > 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.
> 
> 
> 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
> 
> 
> > On 27 Apr 2018, at 10:15, Amelia Andersdotter <ame...@article19.org> wrote:
> >
> > On 2018-04-27 04:00, Brian E Carpenter wrote:
> >> On 27/04/2018 09:09, Amelia Andersdotter wrote:
> >>> On 2018-04-26 17:41, Dave O'Reilly wrote:
> >>>> 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.
> >> 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.
> >
> > 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 reason:
> >
> >> This is not an area where anybody in authority gives a fig about what
> >> the IETF says.
> >
> > 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
> >
> >>Brian
> >>
> >> **
> https://www.ag.gov.au/NationalSecurity/DataRetention/Pages/Frequentlyaskedque
> stions.aspx
> >>
> >
> >
> > --
> > 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
___
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-27 04:00, Brian E Carpenter wrote:
> On 27/04/2018 09:09, Amelia Andersdotter wrote:
>> On 2018-04-26 17:41, Dave O'Reilly wrote:
>>> 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.
> 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.

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 reason:

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

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

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


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

> On 26 Apr 2018, at 22:09, Amelia Andersdotter  wrote:
> 
> On 2018-04-26 17:41, Dave O'Reilly wrote:
>> 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.
> 

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

> -Message d'origine-
> De : Amelia Andersdotter [mailto:ame...@article19.org]
> Envoyé : jeudi 26 avril 2018 17:27
> À : Dave O'Reilly
> Cc : Brian E Carpenter; BOUCADAIR Mohamed IMT/OLN; 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-26 15:59, Dave O'Reilly wrote:
> > 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.
> 
> 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
> 
> > daveor
> >
> >
> 
> --
> 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

[Brian E Carpenter]

(Bundling answers to two messages)
On 26/04/2018 20:40, Dave O'Reilly wrote:
...
>> 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.
> 
> 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. 

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:
...
>> We can say that the logs SHOULD be stored securely, and SHOULD NOT
>> 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.

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

___
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-26 17:41, Dave O'Reilly wrote:
> 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.

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

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  wrote:
> 
> On 2018-04-26 15:59, Dave O'Reilly wrote:
>> 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.
> 
> 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
> 
>> daveor
>> 
>> 
> 
> -- 
> 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-26 15:59, Dave O'Reilly wrote:
> 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.

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

> daveor
>  
>

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

> 
> On 26 Apr 2018, at 12:42, Amelia Andersdotter  wrote:
> 
> 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.
> 

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. 

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

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
___
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-26 06:29, Brian E Carpenter wrote:
> 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.
>

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.

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

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

>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

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

[Dave O'Reilly]

Brian,

> On 26 Apr 2018, at 05:29, Brian E Carpenter  
> wrote:
> 

[snip]

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

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. 

> We can say that the logs SHOULD be stored securely, and SHOULD NOT
> be retained any longer than is needed for these purposes.

Perfectly reasonable.

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

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

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

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, 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote:
Re-,

Please see inline.

Cheers,
Med

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

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, <mohamed.boucad...@orange.com> 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

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, 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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<

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, <mohamed.boucad...@orange.com> 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 physica

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

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

[Ted Lemon]

On Apr 24, 2018, at 6:53 PM, Brian E Carpenter  
wrote:
> 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.


Except that if the user doesn't have a login and wasn't authenticated to the 
site, it's very unlikely that a conversation of this sort could occur.   So I 
don't think that's a valid use case for what we are talking about.

___
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

[Brian E Carpenter]

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

>   This is a meaningful technical point that would have clear implications in 
> the code that got written.   It's not just a platitude to put in the privacy 
> considerations section.   That's what I have in mind too.
> 
> So yes, of course we should say "there are problems with logging source 
> ports, and these are some examples of the problems doing so can cause."
> 
> TBH, if I were an open source implementor, I would just ignore any advice 
> about logging source ports, so if you want the document to have any relevance 
> in that space, you have to give such people a reason for doing it and a basis 
> for doing as little harm as possible.
> 
> 
> 
> 
> ___
> 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

[Brian E Carpenter]

On 25/04/2018 00:49, Dave O'Reilly wrote:
> Amelia,
> 
> I have read this draft now and, once again, it seems there has been no 
> consideration of the implications for law enforcement of these 
> recommendations. A further example of the "privacy is good, more privacy is 
> better" philosophy. 
> 
> I also reviewed RFC6973 and the exact same problem is present there. The 
> privacy threats highlighted in RFC6973 are reasonable from a privacy 
> advocate’s perspective and worthy of consideration, and the mitigants listed 
> also make sense in the context of the listed threats. However, to intimate 
> that the representations of RFC6973 are the only possible perspective, or in 
> some objective sense the “right” perspective, or indeed in any way a complete 
> perspective, misses out important societal issues such as those that are 
> being discussed in this thread.
> 
> The considerations that appear to be foremost in RFC6973 are the issues 
> relating to the collection and use of personal data for commercial purposes 
> and the impact of data breaches

These days we would add "political purposes", and that is interesting because
it has both societal and possible criminal implications. But those issues are
much wider than IP addresses and ports. 

> - the crime attribution characteristics are hardly considered at all. Only 
> surveillance is mentioned and this category, crime attribution per se is not 
> considered at all.

For a reason. A tool that can be used by the authorities for tracing crime to 
its
source can be used by authorities for tracing political activity to its source,
which in many countries is considered to be abuse of power. And if the tool 
itself
is vulnerable, it can be mis-used by non-government actors for bad purposes.
This is the argument behind RFC 2804 of course, and I don't see this discussion
as anything different in principle.

RFC 6302 is a bit different. Server logs are sometimes essential for problem
debugging, rather than for penetrating privacy.

   Brian

> It is also sort of implied that surveillance is always a bad thing (it is, 
> after all, listed in the privacy threats section with no consideration of if, 
> or why, there might be a legitimate use for surveillance, subject to 
> appropriate legal safeguards of course) - another point that should be 
> debated and not automatically accepted.
> 
> The only trade-offs that are suggested for consideration are (ref. section 
> 4.a)  "privacy and usability, privacy and efficiency, privacy and 
> implementability, or privacy and other design goals”. What about, for 
> example, privacy and potential for misuse, privacy and potential for 
> concealing criminal activity, etc. etc.?
> 
> Coming back to the Internet Draft for a moment, there are other points that I 
> could raise but I only want to draw out one rather glaring misrepresentation 
> for now:
> 
> "Earlier recommendations contained in [RFC6302] relied heavily on 
> observations made in Section 12 of [RFC6269] that regulatory requirements 
> could imply a broad obligation to log identifiers.”
> 
> RFC6302 has nothing to do with regulatory requirements to log anything. 
> RFC6302 relates to recommendations that Internet-facing servers log source 
> port information alongside IP address. The overwhelming majority of 
> Internet-facing servers are subject to no form of regulation at all. The fact 
> that RFC6269 highlights a regulatory requirement to maintain subscriber 
> identity, and the subsequent striking down of the data retention directive, 
> is immaterial to the substance of RFC6302 and RFC6302 does not rely on it in 
> any way. Attempting to throw out the existing recommendations in RFC6302 
> because of the ECJ ruling on data retention directive is disingenuous. 
> 
> daveor
> 
>> On 23 Apr 2018, at 09:10, Amelia Andersdotter  wrote:
>>
>> I've tabled a similar draft but with a different scope. Happy to discuss
>> with members on the list:
>>
>> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-rfc6302/
>>
>> -- 
>>
>> 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-24 17: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.

Christian Huitema gave this example(!) but his e-mail reflects concerns
that I would also raise, and want to be taken into account when drafting
any logging recommendations.

best,

A

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


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

[Ted Lemon]

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

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

[Tom Herbert]

On Tue, Apr 24, 2018 at 2:11 AM, Dave O'Reilly  wrote:
> Tom,
>
> I think the points you raise below need to be challenged because (a) they are 
> not a priori true and (b) they oversimplify a much more nuanced situation. 
> See below.
>
>>>
>>> However, I agree with you that a broader discussion within the IETF of the 
>>> balance between privacy and the societal need for law enforcement access to 
>>> data is certainly required. From what I can see in my research so far, the 
>>> philosophy within the IETF appears to heavily favour privacy over other 
>>> issues (such as societal rights or rights of victims of crime - represented 
>>> in this case by law enforcement access to data). I cite as just two 
>>> examples of this (and believe me I can provide many more):
>>>
>>
>> I think the term "societal need for law enforcement" is euphemistic.
>
> Not euphemistic at all. The sense in which I meant it was as follows:
>
> Suppose a member of my family was murdered. Nobody would expect me to conduct 
> my own investigation into the murder, find the murderer and exact my own 
> justice. Why not? Two reasons - Firstly because I am in a country that is 
> governed by the principle of the rule of law and secondly because in such an 
> environment we (societally) delegate responsibility for the investigation, 
> prosecution, adjudication and punishment of unlawful acts to the criminal 
> justice system. There is a tradeoff in this societal deal; I, as an 
> individual, give up my right to get together a vigilante group and avenge the 
> murder of my family member but in exchange I have an expectation that the 
> criminal justice system will look after my rights as a victim of crime (or in 
> my example, the rights of my dead family member).
>
> So, I put it to you that in this sense, which is the sense in which I 
> intended, there is a societal need for law enforcement…unless you’d rather 
> vigilante justice?
>
> Out of curiosity, what did you think I was using it as a euphemism for?
>
>> That seems to presume that the laws are universally just in the first
>> place, and that access to the information is always controlled by a
>> reasonable legal process like warrants. That is not reality. There are
>> hundreds of legal jurisdictions in the world each with their own
>> concept of what constitutes a crime. Yes, there are clearly cases
>> where the information is warranted when a serious crime has been
>> committed for which a reasonable person would say the law enforcement
>> access to the information is warranted. However, we've also seen many
>> case where the information is be used to investigate "crimes" that
>> many reasonable people would not consider meritable to allow access.
>> For example, in many regions of the world it is considered a crime
>> speaking out against an unjust government. To a lot of people that is
>> considered a violation of human rights and such laws are considered
>> unjust. I would expect that any proposal that enables governments to
>> crack down on freedom of speech, even if the proposal is otherwise
>> beneficial, will get a lot of push back in IETF!
>>
>>
>
> 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 

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

[Dave O'Reilly]

Ted,

Could you give me an example of when you think it would be appropriate to log 
source port and when it would not be?

Thanks,
daveor

> On 24 Apr 2018, at 16:26, Ted Lemon  wrote:
> 
> On Apr 24, 2018, at 9:53 AM,  
>  wrote:
>> [Med] Sure, if the intent was to discuss logging in general. But, when it 
>> comes to source ports in the context of address sharing, I’m adopting a 
>> distinct approach: whenever a server decides to log the IP address for 
>> abuse, it has to maintain a record of the source. Because otherwise, its 
>> records won’t be useful in case an important address ratio is used.  
>>  
>> In other words, I don’t think we can mandate to a server if and when it has 
>> to log source IP address.
> 
> That's correct.   But we can say "there are cases where it may be necessary 
> for servers to log source ports; servers that support this functionality must 
> be able to log source port in some cases and not log it in others," and then 
> talk about when it's appropriate to log it and when it's not.   N'est ce pa?
> 
> ___
> 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

[mohamed.boucadair]

Thank you Ted for clarifying.

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : mardi 24 avril 2018 15:26
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; 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 Apr 24, 2018, at 9:11 AM, 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 
<mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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.

[Med] Sure, if the intent was to discuss logging in general. But, when it comes 
to source ports in the context of address sharing, I’m adopting a distinct 
approach: whenever a server decides to log the IP address for abuse, it has to 
maintain a record of the source. Because otherwise, its records won’t be useful 
in case an important address ratio is used.

In other words, I don’t think we can mandate to a server if and when it has to 
log source IP address.

  This is a meaningful technical point that would have clear implications in 
the code that got written.

[Med] Isn’t the code for logging source IP address already there?

  It's not just a platitude to put in the privacy considerations section.   
That's what I have in mind too.

[Med] Fair.

So yes, of course we should say "there are problems with logging source ports, 
and these are some examples of the problems doing so can cause."

TBH, if I were an open source implementor, I would just ignore any advice about 
logging source ports, so if you want the document to have any relevance in that 
space, you have to give such people a reason for doing it and a basis for doing 
as little harm as possible.

[Med] IMHO, that part is already in 
https://tools.ietf.org/html/rfc6269#section-13.1 (Abuse Logging and Penalty 
Boxes)

___
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-24 15: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.   This is a meaningful technical point that would have
> clear implications in the code that got written. 

+1

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

[Ted Lemon]

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.   This is a 
meaningful technical point that would have clear implications in the code that 
got written.   It's not just a platitude to put in the privacy considerations 
section.   That's what I have in mind too.

So yes, of course we should say "there are problems with logging source ports, 
and these are some examples of the problems doing so can cause."

TBH, if I were an open source implementor, I would just ignore any advice about 
logging source ports, so if you want the document to have any relevance in that 
space, you have to give such people a reason for doing it and a basis for doing 
as little harm as possible.

___
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]

Amelia,

I have read this draft now and, once again, it seems there has been no 
consideration of the implications for law enforcement of these recommendations. 
A further example of the "privacy is good, more privacy is better" philosophy. 

I also reviewed RFC6973 and the exact same problem is present there. The 
privacy threats highlighted in RFC6973 are reasonable from a privacy advocate’s 
perspective and worthy of consideration, and the mitigants listed also make 
sense in the context of the listed threats. However, to intimate that the 
representations of RFC6973 are the only possible perspective, or in some 
objective sense the “right” perspective, or indeed in any way a complete 
perspective, misses out important societal issues such as those that are being 
discussed in this thread.

The considerations that appear to be foremost in RFC6973 are the issues 
relating to the collection and use of personal data for commercial purposes and 
the impact of data breaches - the crime attribution characteristics are hardly 
considered at all. Only surveillance is mentioned and this category, crime 
attribution per se is not considered at all. It is also sort of implied that 
surveillance is always a bad thing (it is, after all, listed in the privacy 
threats section with no consideration of if, or why, there might be a 
legitimate use for surveillance, subject to appropriate legal safeguards of 
course) - another point that should be debated and not automatically accepted.

The only trade-offs that are suggested for consideration are (ref. section 4.a) 
 "privacy and usability, privacy and efficiency, privacy and implementability, 
or privacy and other design goals”. What about, for example, privacy and 
potential for misuse, privacy and potential for concealing criminal activity, 
etc. etc.?

Coming back to the Internet Draft for a moment, there are other points that I 
could raise but I only want to draw out one rather glaring misrepresentation 
for now:

"Earlier recommendations contained in [RFC6302] relied heavily on observations 
made in Section 12 of [RFC6269] that regulatory requirements could imply a 
broad obligation to log identifiers.”

RFC6302 has nothing to do with regulatory requirements to log anything. RFC6302 
relates to recommendations that Internet-facing servers log source port 
information alongside IP address. The overwhelming majority of Internet-facing 
servers are subject to no form of regulation at all. The fact that RFC6269 
highlights a regulatory requirement to maintain subscriber identity, and the 
subsequent striking down of the data retention directive, is immaterial to the 
substance of RFC6302 and RFC6302 does not rely on it in any way. Attempting to 
throw out the existing recommendations in RFC6302 because of the ECJ ruling on 
data retention directive is disingenuous. 

daveor

> On 23 Apr 2018, at 09:10, Amelia Andersdotter  wrote:
> 
> I've tabled a similar draft but with a different scope. Happy to discuss
> with members on the list:
> 
> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-rfc6302/
> 
> -- 
> 
> 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]

All I can say in response to your email is that I appeal to the fair-mindedness 
of the other readers of this thread to decide for themselves whether my 
conclusion does a disservice to the discussion that has taken place here. 

In the quote from my email below what I’m saying is that there are parties on 
both sides of the argument that are ideologically motivated and coming at the 
argument from that position makes one disinclined to listen to, and 
acknowledge, the points that the other side is making. I finish up by saying 
that seeking mutually beneficial middle ground allows us all to make progress. 

daveor

> On 24 Apr 2018, at 13:18, Ted Lemon  wrote:
> 
> On Apr 24, 2018, at 5:11 AM, Dave O'Reilly  wrote:
>> 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. 
> 
> This statement does a huge disservice to the actual comments that have been 
> submitted so far, which have been far more nuanced than you are suggesting.   
> For example, the point was raised that the ability to track which wikipedia 
> articles were read by whom is very different than seeing what article was 
> posted by whom.
> 
> In your example of a murder investigation, I'm sure it's possible that 
> knowing what wiki article someone read could have some bearing on the 
> investigation.   But there's a pretty obvious tradeoff here: the wiki article 
> info might by some remote chance be useful for that purpose, but having a 
> list of who read what is definitely useful for repression, whether that is 
> done by the police or by some other agency.
> 
> So painting this as a matter of ideology, as if the actual conclusion we drew 
> were somewhat academic, is simply incorrect.   If you are not willing to 
> consider this problem in any other terms, I think that bodes ill for this 
> effort.
> 

___
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 24, 2018, at 5:11 AM, Dave O'Reilly  wrote:
> 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. 

This statement does a huge disservice to the actual comments that have been 
submitted so far, which have been far more nuanced than you are suggesting.   
For example, the point was raised that the ability to track which wikipedia 
articles were read by whom is very different than seeing what article was 
posted by whom.

In your example of a murder investigation, I'm sure it's possible that knowing 
what wiki article someone read could have some bearing on the investigation.   
But there's a pretty obvious tradeoff here: the wiki article info might by some 
remote chance be useful for that purpose, but having a list of who read what is 
definitely useful for repression, whether that is done by the police or by some 
other agency.

So painting this as a matter of ideology, as if the actual conclusion we drew 
were somewhat academic, is simply incorrect.   If you are not willing to 
consider this problem in any other terms, I think that bodes ill for this 
effort.

___
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 24, 2018, at 1:58 AM,  
 wrote:
> [Med] I confirm that Dave’s I-D does not define a new behavior. It has the 
> merit to discuss issues related to source ports. I do agree this is a minor 
> contribution, but I like it because it is comprehensive.  

I don't disagree that there is value in talking about requirements, but if the 
discussion is incomplete, the impression of the reader can be that, for 
example, there is no tradeoff in logging source ports, and it's just something 
everybody should do all the time for every connection.

My goal in asking you about Stephen's suggestion was to know whether you would 
object to that scope of work as opposed to the more narrow scope that this 
document addresses.   Whether or not work happens is always chancy, but if we 
set out with a smaller scope, we can be fairly sure that the additional work 
will not be done.

As far as I'm concerned, if the larger scope of work isn't done, the document 
will cause more harm than good.  My question to you is whether, if the scope 
were enlarged as Stephen has proposed, you would object to doing that work.   I 
understand your skepticism about it being done, but that's not what I'm asking.

___
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]

Tom,

I think the points you raise below need to be challenged because (a) they are 
not a priori true and (b) they oversimplify a much more nuanced situation. See 
below.

>> 
>> However, I agree with you that a broader discussion within the IETF of the 
>> balance between privacy and the societal need for law enforcement access to 
>> data is certainly required. From what I can see in my research so far, the 
>> philosophy within the IETF appears to heavily favour privacy over other 
>> issues (such as societal rights or rights of victims of crime - represented 
>> in this case by law enforcement access to data). I cite as just two examples 
>> of this (and believe me I can provide many more):
>> 
> 
> I think the term "societal need for law enforcement" is euphemistic.

Not euphemistic at all. The sense in which I meant it was as follows:

Suppose a member of my family was murdered. Nobody would expect me to conduct 
my own investigation into the murder, find the murderer and exact my own 
justice. Why not? Two reasons - Firstly because I am in a country that is 
governed by the principle of the rule of law and secondly because in such an 
environment we (societally) delegate responsibility for the investigation, 
prosecution, adjudication and punishment of unlawful acts to the criminal 
justice system. There is a tradeoff in this societal deal; I, as an individual, 
give up my right to get together a vigilante group and avenge the murder of my 
family member but in exchange I have an expectation that the criminal justice 
system will look after my rights as a victim of crime (or in my example, the 
rights of my dead family member). 

So, I put it to you that in this sense, which is the sense in which I intended, 
there is a societal need for law enforcement…unless you’d rather vigilante 
justice?

Out of curiosity, what did you think I was using it as a euphemism for?

> That seems to presume that the laws are universally just in the first
> place, and that access to the information is always controlled by a
> reasonable legal process like warrants. That is not reality. There are
> hundreds of legal jurisdictions in the world each with their own
> concept of what constitutes a crime. Yes, there are clearly cases
> where the information is warranted when a serious crime has been
> committed for which a reasonable person would say the law enforcement
> access to the information is warranted. However, we've also seen many
> case where the information is be used to investigate "crimes" that
> many reasonable people would not consider meritable to allow access.
> For example, in many regions of the world it is considered a crime
> speaking out against an unjust government. To a lot of people that is
> considered a violation of human rights and such laws are considered
> unjust. I would expect that any proposal that enables governments to
> crack down on freedom of speech, even if the proposal is otherwise
> beneficial, will get a lot of push back in IETF!
> 
> 

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. 

I don’t expect that I’ll change the mind of most people who have decided that 
privacy is the best, boo for law enforcement, and that’s the end of the 
discussion - but maybe there are a few people out there who are reading this, 
hadn’t thought of this position before, and will think “good point”. That would 
be progress of a sort!

Coming back to my draft document for a moment - it is not intended to address 
any of these bigger privacy vs. law 

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

[mohamed.boucadair]

Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : lundi 23 avril 2018 17:55
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; 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 Apr 23, 2018, at 1:32 AM, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:
- **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
- **DOES NOT** require logging another yet information: again, it relies on the 
various schemes discussed in existing RFCs.

If it doesn't define new behavior, why do we need it?

[Med] I confirm that Dave's I-D does not define a new behavior. It has the 
merit to discuss issues related to source ports. I do agree this is a minor 
contribution, but I like it because it is comprehensive.

Also, some of the documents you cite predate the rather extensive and evolving 
discussions that the IETF has since had on the issue of privacy.
[Med] Please note that we did already have that discussion in the past. Stephen 
suggested at that time (2014) to have a document 
(https://mailarchive.ietf.org/arch/msg/ietf-privacy/Xy0SZvTH_iU9ktlGyp8SpJZNDdQ),
 but unless I'm mistaken there is not such document.

Would you object to a new proposal that incorporated privacy issues as Stephen 
suggested in his first response on this topic?
[Med] Having a document is always welcome to assess whether what we claim is an 
issue or not. I recommend reading existing RFCs and consider carefully the 
language used; some of them was motivated by privacy considerations.

___
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 23, 2018, at 1:32 AM, mohamed.boucad...@orange.com wrote:
> - **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
> - **DOES NOT** require logging another yet information: again, it relies on 
> the various schemes discussed in existing RFCs.

If it doesn't define new behavior, why do we need it?

Also, some of the documents you cite predate the rather extensive and evolving 
discussions that the IETF has since had on the issue of privacy.   Would you 
object to a new proposal that incorporated privacy issues as Stephen suggested 
in his first response on this topic?

___
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

[Christian Huitema]

On 4/23/2018 6:14 AM, Dave O'Reilly wrote:

> Briefly, I summarise the position laid out in the document as follows:
>
> Problem: there is an information gap between records maintained by CGNAT 
> operators and internet-facing server operators. How to close that gap?
> Options: (a) CGNAT operators keep connection logs, (b) internet-facing server 
> operators keep source port records.
> Privacy considerations: 
>   connection logs are bad (greater impact of data breach, significant 
> implications for ISPs, etc. etc.)
>   source port logging has minimal additional privacy impact over and 
> above recording of IP address in logs, which is already routine
> Conclusion: of the available options to close the information gap, source 
> port logging is the most privacy sensitive way to achieve this
>
> I’d be interested in hearing why you think this argument is not adequate?

Dave, I think that your argumentation is missing a big conditional.
Detailed logging may be needed when there is a good reason to conduct
inquiries about past abuses. It does not follow that detailed logging is
needed all the time, by all servers.

Take the example of a site like Wikipedia. There may be a need for
detailed logs of who was editing a controversial page, in order for
example to defend against vandalism. But it does not follow that there
is a need for detailed logging of who accesses what page. That kind of
log would invite all kinds of abuses, such as tracking the location of
people or their reading habits.

Logs are dangerous, because they become a target for nuisance lawsuits,
hackers, advertisers, data brokers and many more. The simplest way to
avoid the issue is to only log the information that is strictly needed.
That may include great details in the case of financial transactions,
which was your example. It may require way fewer detail in a
run-of-the-mill server. It may sometime be useful to log IP addresses,
and it may sometimes be a better idea to not log them, or to anonymize
the data before logging it.

When people speak of balance, they are speaking about that, balancing
the usefulness of logs for inquiries versus the dangers of logs in
general. I think that balance should be explicitly stated in any kind of
"logging requirement".

-- Christian Huitema

___
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]

> 
>> 
>> However, if people are irreconcilably opposed to the scope of the
> 
> "irreconcilably" is just rhetoric - I am opposed based on the
> arguments given, there's no need to try make that sound like
> it's unreasonable.
> 

Point taken. I’ll clarify my original email by asking that you please 
substitute "if people are irreconcilably opposed to the scope of the current 
document ..” with "if the outcome of the call to adopt the document is rejected 
for reasons that the scope is not acceptable…” 

>> current document, then I propose as follows:
>> 
>> a. Reject the call for adoption by the working group and move the
>> document back to the independent submission stream. I believe the
>> conflict review comments have already been adequately addressed in
>> draft -04 and publication will hopefully be possible there. b. Begin
>> a discussion here (or in whatever forum might be more appropriate) on
>> what would be an appropriate scope for a separate document to
>> consider the broader issues that are being raised by the various
>> commenters and see what sort of consensus can be reached. I offer to
>> contribute my opinion to that discussion.
> 
> That's up to you, the ISE and the IESG and doesn't need any WG
> action.
> 
> But I'm not clear - are you saying you no longer want the draft
> to be adopted? If that's the case, we're done with this thread.
> 

What I’m saying is that I judge that the sentiment in the group may be more 
amenable to development of a new scope and beginning work from there, rather 
than adopting the current document.

I don’t see that the rejection of the document needs to bring an end to the 
discussion of scope. However, how might such a discussion meaningfully proceed?

>> I do
>> address in section 9 the privacy implications of the specific
>> proposal 
> 
> I disagree with the above assertion. "mention" != “address"

Well, I’m not sure exactly what else needs to be said on the topic addressed by 
the document. Can you indicate to me how you think the treatment of the privacy 
implications is insufficient? 

Briefly, I summarise the position laid out in the document as follows:

Problem: there is an information gap between records maintained by CGNAT 
operators and internet-facing server operators. How to close that gap?
Options: (a) CGNAT operators keep connection logs, (b) internet-facing server 
operators keep source port records.
Privacy considerations: 
connection logs are bad (greater impact of data breach, significant 
implications for ISPs, etc. etc.)
source port logging has minimal additional privacy impact over and 
above recording of IP address in logs, which is already routine
Conclusion: of the available options to close the information gap, source port 
logging is the most privacy sensitive way to achieve this

I’d be interested in hearing why you think this argument is not adequate?

> 
>> 
>> I think a discussion of the broader issue requires robust and vocal
>> representation of both sides and I am willing to adopt for the
> 
> We don't do "representation" here - which I agree makes it hard
> for some people who support the traditional LEA position to take
> part in discussion.
> 

I’m not adopting a “traditional LEA position” - all I’m saying is that more 
consideration needs to be given to the counterbalancing arguments against total 
privacy.

>> purposes of such a discussion the, apparently unpopular, position
>> that while the right to privacy is very important it is not the only
>> right and a more nuanced consideration of the situation might be
>> worthwhile.
> 
> I'd love to see a discussion of requirements (not mechanisms) in
> this space. IMO the "record it all just in case" type of requirement
> is no longer appropriate when logging related to Internet protocols,
> given current and likely future uses for Internet protocols.
> 

I completely agree that “record it all just in case” is not a priori the best 
solution but there is certainly an under-represented need. I also agree that 
it’s better to start with the actual requirements and work forward to 
considering how those requirements can be achieved in a privacy sensitive way. 

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]

I would like to clarify, in response to the email below, that the document is 
not about logging of records at CGNATs which is usually defined by regulatory 
requirements. It is about the fact that there is an information gap between the 
records being maintained by ISPs and the operators of internet-facing servers. 

How should that information gap be addressed? The most privacy sensitive way to 
achieve this is for internet-facing server operators to maintain source port 
records. In fact, in the document I specifically indicate that centralised 
logging of additional information is not a good response to this problem (ref. 
section 3 and section 9).

Regards,
daveor


> On 22 Apr 2018, at 21:36, Amelia Andersdotter  wrote:
> 
> Dear all,
> 
> I have read this draft and I do not support adoption.
> 
> On 2018-04-22 21:18, Dave O'Reilly wrote:
>> Dear all,
>> 
>> I hope it’s not inappropriate for me to step into this discussion, but I 
>> would like to respond to a few of the points that have been raised so far. 
>> For brevity I will incorporate my responses to the various emails into a 
>> single email.
>> 
>> The main point people are making:
>> ———
>> 
>> There are several objections to the document scope (by Stephen Farrell, 
>> Brian E Carpenter and Ted Lemon - quotations are not necessary, I trust). 
>> 
>> In response I only point out that the intarea working group has already 
>> adopted a document making recommendations that logging of source port should 
>> be done (RFC6302/BCP162). The point I’m making in this document is that:
> 
> The working group adopted other documents back in 2011 relating to
> CG-NAT och logging requirements, that to me look inspired by woes
> brought on by regulatory requirements in some jurisdictions (which are
> extensively referenced in those same documents, cf. Section 12 of
> RFC6269). There have been a few drafts on NAT logging over the years
> that reference these regulatory requirements (in the BEHAVE working
> group, for instance). But the regulatory requirements that were likely
> referenced expired in December 2016, when the European Union Court of
> Justice kind of chucked out generalised data retention requirements in
> favour of targetted surveillance practises. I have been able to find no
> drafts referencing regulatory requirements to log or retain data in NATs
> that have been considered in the IETF.
> 
> The scope of the draft therefore doesn't sit well with me.
> 
> I'm also reminded of other regulatory requirements entering into effect
> soon that go in a completely different direction. The proposal by
> Stephen to look at a differently scoped document about logging seems
> more reasonable under present circumstances.
> 
> best regards,
> 
> Amelia
> 
>> Regards,
>> daveor
>> 
>> ___
>> 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

[mohamed.boucadair]

Stephen, 

"I hope that we've learned that we need to do more thorough analyses
of the privacy implications of our work."

The discussion about privacy implications for 6302 occurred in the past either 
in intarea list or ietf-privacy: 

* https://mailarchive.ietf.org/arch/msg/int-area/uIvwbV0W4r8QhMfq1n5f5m32gO0 

Unfortunately, there is no such document that you asked for in 
https://mailarchive.ietf.org/arch/msg/ietf-privacy/Xy0SZvTH_iU9ktlGyp8SpJZNDdQ 
so that we can have something concrete to discuss. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Envoyé : lundi 23 avril 2018 09:40
> À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 
> Hiya,
> 
> We could trade references to existing BCPs and RFCs but I don't
> think we need to - I did not claim that the IETF had never done
> work in this space, nor that we ought not - my point was that
> such work being done at this point in time needs to take a
> broader perspective than the document concerned. (If for some
> reason it is helpful to trade references to existing BCPs and
> RFCs that argue for different approaches to privacy, I'm fine
> with doing that, but I hope it's not needed;-)
> 
> Below you say:
> 
> > The I-D inherits the same privacy implications of existing RFCs.
> 
> That would be a significant reason to not adopt the current document!
> 
> I hope that we've learned that we need to do more thorough analyses
> of the privacy implications of our work.
> 
> Cheers,
> S.
> 
> On 23/04/18 06:32, mohamed.boucad...@orange.com wrote:
> > Hi Stephen,
> >
> > The scope of this document is aligned with what the IETF has published in
> the past in this field. A list is provided below:
> >
> >1.   Identify logging as an issue in address sharing: RFC 6269
> >
> >2.   Require address sharing to enable a logging function: RFC 6269
> > and RFC 6888
> >
> >3.   Identify a minimal set of information to be logged: RFC 6269,
> > RFC 6888, and RFC 6908
> >
> >4.   Identify and discuss trade-offs of solutions to achieve logging:
> > RFC 6269, RFC 6908
> >
> >5.   Specify means to optimize logging (port range allocation,
> > deterministic NAT): draft-ietf-softwire-stateless-
> > 4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
> > RFC7422
> >
> >6.   Recommend servers to log source port: RFC 6302
> >
> >7.   An initial survey of servers supporting source port logging: RFC
> > 7768 (ISE)
> >
> >8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
> > logging, RFC 8158
> >
> >9.  CPU and memory issues: RFC 6908
> >
> > As such, this I-D:
> > - **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
> > - **DOES NOT** require logging another yet information: again, it relies on
> the various schemes discussed in existing RFCs.
> >
> > The I-D inherits the same privacy implications of existing RFCs.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Stephen
> >> Farrell
> >> Envoyé : samedi 21 avril 2018 18:24
> >> À : int-area@ietf.org
> >> Objet : [Int-area] WG adoption call: Availability of Information in
> Criminal
> >> Investigations Involving Large-Scale IP Address Sharing Technologies
> >>
> >>
> >> Hiya,
> >>
> >> I've read this draft and do not support adoption of a
> >> draft with this scope.
> >>
> >> I do support consideration of how law enforcement
> >> investigations can be carried out, but not without a
> >> similar level of consideration of the real trade-offs
> >> between assisting law enforcement and commercial or
> >> other surveillance. At present, the draft is nowhere
> >> near sufficient in this respect. (Despite saying that
> >> "Clearly a balance needs to be struck between individual
> >> right to privacy and law enforcement access to data
> >> during criminal investigations" the draft is anything
> >> but balanced in that respect.)
> >>
> >> I don't think that this problem is a thing that'd be
> >> reasonable to try fix after WG adoption, but needs to be
> >> handled beforehand as it's a fundamental scope issue.

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

[Amelia Andersdotter]

I've tabled a similar draft but with a different scope. Happy to discuss
with members on the list:

https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-rfc6302/

-- 

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

[Stephen Farrell]

Hiya,

On 22/04/18 20:18, Dave O'Reilly wrote:
> Dear all,
> 
> I hope it’s not inappropriate for me to step into this discussion,
> 
On the contrary, it's entirely appropriate!

> but I would like to respond to a few of the points that have been
> raised so far. For brevity I will incorporate my responses to the
> various emails into a single email.
> 
> The main point people are making: 
> ———————————————————————
>
>  There are several objections to the document scope (by Stephen
> Farrell, Brian E Carpenter and Ted Lemon - quotations are not
> necessary, I trust).
> 
> In response I only point out that the intarea working group has
> already adopted a document making recommendations that logging of
> source port should be done (RFC6302/BCP162). The point I’m making
> in this document is that:
> 
> 1. source port logging is not routine, despite publication of RFC6302
> in 2011 - in other words the document has not had the hoped for
> impact 2. what are the reasons for this 3. what additional
> recommendations can be made to move this along
> 
> Therefore I’m a little surprised by this response to a relatively
> minor movement in an already published intarea position.

See my answer to Med.

> 
> However, if people are irreconcilably opposed to the scope of the

"irreconcilably" is just rhetoric - I am opposed based on the
arguments given, there's no need to try make that sound like
it's unreasonable.

> current document, then I propose as follows:
> 
> a. Reject the call for adoption by the working group and move the
> document back to the independent submission stream. I believe the
> conflict review comments have already been adequately addressed in
> draft -04 and publication will hopefully be possible there. b. Begin
> a discussion here (or in whatever forum might be more appropriate) on
> what would be an appropriate scope for a separate document to
> consider the broader issues that are being raised by the various
> commenters and see what sort of consensus can be reached. I offer to
> contribute my opinion to that discussion.

That's up to you, the ISE and the IESG and doesn't need any WG
action.

But I'm not clear - are you saying you no longer want the draft
to be adopted? If that's the case, we're done with this thread.

> 
> Other additional points: 
> ———————————————
> 
> From Stephen Farrell:
> 
>> I do support consideration of how law enforcement investigations
>> can be carried out, but not without a similar level of
>> consideration of the real trade-offs between assisting law
>> enforcement and commercial or other surveillance. At present, the
>> draft is nowhere near sufficient in this respect. (Despite saying
>> that "Clearly a balance needs to be struck between individual right
>> to privacy and law enforcement access to data during criminal
>> investigations" the draft is anything but balanced in that
>> respect.)
> 
> The document is not supposed to be an analysis of the privacy
> implications of law enforcement access to data in general and, by the
> way, nobody is talking about “assisting law enforcement and
> commercial or other surveillance” - that’s a straw man.

Sorry it is not a straw man. If the mechanism has that effect
then it has that effect regardless of your intentions as an author.
So it doesn't matter what the draft is "supposed to be" but
rather what matters is what the draft says.

> I do
> address in section 9 the privacy implications of the specific
> proposal 

I disagree with the above assertion. "mention" != "address"

> (source port logging) as a solution to a specific problem
> (carrier grade NAT and similar technologies) - a proposal that has
> already been accepted by the intarea group in RFC6302/BCP162.
> 
> However, I agree with you that a broader discussion within the IETF
> of the balance between privacy and the societal need for law
> enforcement access to data is certainly required. 

Expanding on a point Tom Herbert made - there are actually maybe
O(10,000) in the set of LEAs worldwide - most countries have more
than one entity that sets policy for such things even if there
are national laws/guidelines. IMO if the IETF tried to enable
access to all the data that all tens of thousands of LEAs would
like, then we'd be doing a disservice and engineering Internet
protocols that can't serve the privacy needs of users. There is
a real conflict in requirements from different perspectives.

> From what I can see
> in my research so far, the philosophy within the IETF appears to
> heavily favour privacy over other issues (such as societal rights or
> rights of victims of crime - represented in this case by law
> enforcement access to data). I cite as just two examples of this (and
> believe me I can provide many more):
> 
> - RFC4941 (Privacy extensions for stateless address auto
> configuration in IPv6) - “by design” obfuscation of the source of
> network traffic 

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

[Stephen Farrell]

Hiya,

We could trade references to existing BCPs and RFCs but I don't
think we need to - I did not claim that the IETF had never done
work in this space, nor that we ought not - my point was that
such work being done at this point in time needs to take a
broader perspective than the document concerned. (If for some
reason it is helpful to trade references to existing BCPs and
RFCs that argue for different approaches to privacy, I'm fine
with doing that, but I hope it's not needed;-)

Below you say:

> The I-D inherits the same privacy implications of existing RFCs.

That would be a significant reason to not adopt the current document!

I hope that we've learned that we need to do more thorough analyses
of the privacy implications of our work.

Cheers,
S.

On 23/04/18 06:32, mohamed.boucad...@orange.com wrote:
> Hi Stephen,
> 
> The scope of this document is aligned with what the IETF has published in the 
> past in this field. A list is provided below:
> 
>1.   Identify logging as an issue in address sharing: RFC 6269
> 
>2.   Require address sharing to enable a logging function: RFC 6269
> and RFC 6888
> 
>3.   Identify a minimal set of information to be logged: RFC 6269,
> RFC 6888, and RFC 6908
> 
>4.   Identify and discuss trade-offs of solutions to achieve logging:
> RFC 6269, RFC 6908
> 
>5.   Specify means to optimize logging (port range allocation,
> deterministic NAT): draft-ietf-softwire-stateless-
> 4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
> RFC7422
> 
>6.   Recommend servers to log source port: RFC 6302
> 
>7.   An initial survey of servers supporting source port logging: RFC
> 7768 (ISE)
> 
>8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
> logging, RFC 8158
> 
>9.  CPU and memory issues: RFC 6908
> 
> As such, this I-D:
> - **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
> - **DOES NOT** require logging another yet information: again, it relies on 
> the various schemes discussed in existing RFCs.
> 
> The I-D inherits the same privacy implications of existing RFCs. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Stephen
>> Farrell
>> Envoyé : samedi 21 avril 2018 18:24
>> À : int-area@ietf.org
>> Objet : [Int-area] WG adoption call: Availability of Information in Criminal
>> Investigations Involving Large-Scale IP Address Sharing Technologies
>>
>>
>> Hiya,
>>
>> I've read this draft and do not support adoption of a
>> draft with this scope.
>>
>> I do support consideration of how law enforcement
>> investigations can be carried out, but not without a
>> similar level of consideration of the real trade-offs
>> between assisting law enforcement and commercial or
>> other surveillance. At present, the draft is nowhere
>> near sufficient in this respect. (Despite saying that
>> "Clearly a balance needs to be struck between individual
>> right to privacy and law enforcement access to data
>> during criminal investigations" the draft is anything
>> but balanced in that respect.)
>>
>> I don't think that this problem is a thing that'd be
>> reasonable to try fix after WG adoption, but needs to be
>> handled beforehand as it's a fundamental scope issue.
>>
>> In other words, I believe this draft just has the wrong
>> scope, and if adopted would be likely quite controversial
>> before publication. In contrast, a draft that really does
>> consider the trade-offs related to logging could be quite
>> valuable and if it provided a balanced approach might even
>> not be controversial.
>>
>> (FWIW, I might be willing to try help out a bit on a draft
>> that did have what I think is an appropriate scope, as I do
>> think more appropriate logging is a reasonable goal. But
>> before accepting that offer be aware that IMO sometimes
>> "more appropriate" ought mean only logging minimal data for
>> a very short period and then thoroughly scrubbing all of
>> that:-)
>>
>> Separately, if a document on this topic is to be adopted
>> by any IETF WG, I think the adoption call ought be widely
>> circulated (esp to saag, and art-area lists) as this is a
>> topic that is likely to attract interest from various folks
>> in other areas, and it'd be much better to figure out early
>> and not late if others also see problems with this draft.
>>
>> Cheers,
>> S.
>>
>> PS: I'm not subscribed to the int-area list so please do
>> cc' me on any follow ups.
>>
>>
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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]

Hi Brian, 

The issue discussed in this I-D applies each time you have to share an IPv4 
address. This covers IPv4 service continuity mechanism with IPv6-only 
connectivity such as: NAT64, DS-Lite, MAP-E, MAP-T and lw4o6. 

There is IMHO a value in socializing the IETF BCP and help 
servers/implementation fixing this.  

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian E
> Carpenter
> Envoyé : dimanche 22 avril 2018 07:31
> À : int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> On 22/04/2018 04:24, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > I've read this draft and do not support adoption of a
> > draft with this scope.
> 
> I see that this draft started its life as a submission to
> the Independent Submissions editor:
> https://datatracker.ietf.org/doc/conflict-review-daveor-cgn-logging/
> The IESG is probably correct about the overlap, but I think I agree
> with Stephen that the draft is scoped as if port logging is always
> OK. That's a possible scope for an Independent Submission to
> choose, but clearly getting IETF consensus on it is another question.
> 
> However, WG adoption doesn't imply accepting the contents, only
> the topic. Actually it transforms the authors from independent actors
> into servants of the WG. So from a formal viewpoint Stephen is wrong:
> the WG can decide to completely change the scope and viewpoint of the
> draft, even if the authors disagree. I certainly think a discussion
> of the downsides is needed, and the cross-WG reviews that Stephen
> mentions.
> 
> I do have another comment about adoption. This is an IPv4 technology.
> Do we really want to spent IETF cycles on it? I'd prefer that we
> adopt https://tools.ietf.org/html/draft-george-ipv6-support-03 .
> 
>Brian
> 
> >
> > I do support consideration of how law enforcement
> > investigations can be carried out, but not without a
> > similar level of consideration of the real trade-offs
> > between assisting law enforcement and commercial or
> > other surveillance. At present, the draft is nowhere
> > near sufficient in this respect. (Despite saying that
> > "Clearly a balance needs to be struck between individual
> > right to privacy and law enforcement access to data
> > during criminal investigations" the draft is anything
> > but balanced in that respect.)
> >
> > I don't think that this problem is a thing that'd be
> > reasonable to try fix after WG adoption, but needs to be
> > handled beforehand as it's a fundamental scope issue.
> >
> > In other words, I believe this draft just has the wrong
> > scope, and if adopted would be likely quite controversial
> > before publication. In contrast, a draft that really does
> > consider the trade-offs related to logging could be quite
> > valuable and if it provided a balanced approach might even
> > not be controversial.
> >
> > (FWIW, I might be willing to try help out a bit on a draft
> > that did have what I think is an appropriate scope, as I do
> > think more appropriate logging is a reasonable goal. But
> > before accepting that offer be aware that IMO sometimes
> > "more appropriate" ought mean only logging minimal data for
> > a very short period and then thoroughly scrubbing all of
> > that:-)
> >
> > Separately, if a document on this topic is to be adopted
> > by any IETF WG, I think the adoption call ought be widely
> > circulated (esp to saag, and art-area lists) as this is a
> > topic that is likely to attract interest from various folks
> > in other areas, and it'd be much better to figure out early
> > and not late if others also see problems with this draft.
> >
> > Cheers,
> > S.
> >
> > PS: I'm not subscribed to the int-area list so please do
> > cc' me on any follow ups.
> >
> >
> >
> >
> >
> > ___
> > 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

___
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]

Hi Stephen,

The scope of this document is aligned with what the IETF has published in the 
past in this field. A list is provided below:

   1.   Identify logging as an issue in address sharing: RFC 6269

   2.   Require address sharing to enable a logging function: RFC 6269
and RFC 6888

   3.   Identify a minimal set of information to be logged: RFC 6269,
RFC 6888, and RFC 6908

   4.   Identify and discuss trade-offs of solutions to achieve logging:
RFC 6269, RFC 6908

   5.   Specify means to optimize logging (port range allocation,
deterministic NAT): draft-ietf-softwire-stateless-
4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
RFC7422

   6.   Recommend servers to log source port: RFC 6302

   7.   An initial survey of servers supporting source port logging: RFC
7768 (ISE)

   8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
logging, RFC 8158

   9.  CPU and memory issues: RFC 6908

As such, this I-D:
- **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
- **DOES NOT** require logging another yet information: again, it relies on the 
various schemes discussed in existing RFCs.

The I-D inherits the same privacy implications of existing RFCs. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Stephen
> Farrell
> Envoyé : samedi 21 avril 2018 18:24
> À : int-area@ietf.org
> Objet : [Int-area] WG adoption call: Availability of Information in Criminal
> Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 
> Hiya,
> 
> I've read this draft and do not support adoption of a
> draft with this scope.
> 
> I do support consideration of how law enforcement
> investigations can be carried out, but not without a
> similar level of consideration of the real trade-offs
> between assisting law enforcement and commercial or
> other surveillance. At present, the draft is nowhere
> near sufficient in this respect. (Despite saying that
> "Clearly a balance needs to be struck between individual
> right to privacy and law enforcement access to data
> during criminal investigations" the draft is anything
> but balanced in that respect.)
> 
> I don't think that this problem is a thing that'd be
> reasonable to try fix after WG adoption, but needs to be
> handled beforehand as it's a fundamental scope issue.
> 
> In other words, I believe this draft just has the wrong
> scope, and if adopted would be likely quite controversial
> before publication. In contrast, a draft that really does
> consider the trade-offs related to logging could be quite
> valuable and if it provided a balanced approach might even
> not be controversial.
> 
> (FWIW, I might be willing to try help out a bit on a draft
> that did have what I think is an appropriate scope, as I do
> think more appropriate logging is a reasonable goal. But
> before accepting that offer be aware that IMO sometimes
> "more appropriate" ought mean only logging minimal data for
> a very short period and then thoroughly scrubbing all of
> that:-)
> 
> Separately, if a document on this topic is to be adopted
> by any IETF WG, I think the adoption call ought be widely
> circulated (esp to saag, and art-area lists) as this is a
> topic that is likely to attract interest from various folks
> in other areas, and it'd be much better to figure out early
> and not late if others also see problems with this draft.
> 
> Cheers,
> S.
> 
> PS: I'm not subscribed to the int-area list so please do
> cc' me on any follow ups.
> 
> 

___
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-22 22:36, Amelia Andersdotter wrote:
>
> that have been considered in the IETF.
>

+ since December 2016. Typical.

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

[Amelia Andersdotter]

Dear all,

I have read this draft and I do not support adoption.

On 2018-04-22 21:18, Dave O'Reilly wrote:
> Dear all,
>
> I hope it’s not inappropriate for me to step into this discussion, but I 
> would like to respond to a few of the points that have been raised so far. 
> For brevity I will incorporate my responses to the various emails into a 
> single email.
>
> The main point people are making:
> ———
>
> There are several objections to the document scope (by Stephen Farrell, Brian 
> E Carpenter and Ted Lemon - quotations are not necessary, I trust). 
>
> In response I only point out that the intarea working group has already 
> adopted a document making recommendations that logging of source port should 
> be done (RFC6302/BCP162). The point I’m making in this document is that:

The working group adopted other documents back in 2011 relating to
CG-NAT och logging requirements, that to me look inspired by woes
brought on by regulatory requirements in some jurisdictions (which are
extensively referenced in those same documents, cf. Section 12 of
RFC6269). There have been a few drafts on NAT logging over the years
that reference these regulatory requirements (in the BEHAVE working
group, for instance). But the regulatory requirements that were likely
referenced expired in December 2016, when the European Union Court of
Justice kind of chucked out generalised data retention requirements in
favour of targetted surveillance practises. I have been able to find no
drafts referencing regulatory requirements to log or retain data in NATs
that have been considered in the IETF.

The scope of the draft therefore doesn't sit well with me.

I'm also reminded of other regulatory requirements entering into effect
soon that go in a completely different direction. The proposal by
Stephen to look at a differently scoped document about logging seems
more reasonable under present circumstances.

best regards,

Amelia

> Regards,
> daveor
>
> ___
> 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

[Tom Herbert]

On Sun, Apr 22, 2018 at 12:18 PM, Dave O'Reilly  wrote:
> Dear all,
>
> I hope it’s not inappropriate for me to step into this discussion, but I 
> would like to respond to a few of the points that have been raised so far. 
> For brevity I will incorporate my responses to the various emails into a 
> single email.
>
> The main point people are making:
> ———
>
> There are several objections to the document scope (by Stephen Farrell, Brian 
> E Carpenter and Ted Lemon - quotations are not necessary, I trust).
>
> In response I only point out that the intarea working group has already 
> adopted a document making recommendations that logging of source port should 
> be done (RFC6302/BCP162). The point I’m making in this document is that:
>
> 1. source port logging is not routine, despite publication of RFC6302 in 2011 
> - in other words the document has not had the hoped for impact
> 2. what are the reasons for this
> 3. what additional recommendations can be made to move this along
>
> Therefore I’m a little surprised by this response to a relatively minor 
> movement in an already published intarea position.
>
> However, if people are irreconcilably opposed to the scope of the current 
> document, then I propose as follows:
>
> a. Reject the call for adoption by the working group and move the document 
> back to the independent submission stream. I believe the conflict review 
> comments have already been adequately addressed in draft -04 and publication 
> will hopefully be possible there.
> b. Begin a discussion here (or in whatever forum might be more appropriate) 
> on what would be an appropriate scope for a separate document to consider the 
> broader issues that are being raised by the various commenters and see what 
> sort of consensus can be reached. I offer to contribute my opinion to that 
> discussion.
>
> Other additional points:
> ———
>
> From Stephen Farrell:
>
>> I do support consideration of how law enforcement investigations can be 
>> carried out, but not without a similar level of consideration of the real 
>> trade-offs between assisting law enforcement and commercial or other 
>> surveillance. At present, the draft is nowhere near sufficient in this 
>> respect. (Despite saying that "Clearly a balance needs to be struck between 
>> individual right to privacy and law enforcement access to data during 
>> criminal investigations" the draft is anything but balanced in that respect.)
>
> The document is not supposed to be an analysis of the privacy implications of 
> law enforcement access to data in general and, by the way, nobody is talking 
> about “assisting law enforcement and commercial or other surveillance” - 
> that’s a straw man. I do address in section 9 the privacy implications of the 
> specific proposal (source port logging) as a solution to a specific problem 
> (carrier grade NAT and similar technologies) - a proposal that has already 
> been accepted by the intarea group in RFC6302/BCP162.
>
> However, I agree with you that a broader discussion within the IETF of the 
> balance between privacy and the societal need for law enforcement access to 
> data is certainly required. From what I can see in my research so far, the 
> philosophy within the IETF appears to heavily favour privacy over other 
> issues (such as societal rights or rights of victims of crime - represented 
> in this case by law enforcement access to data). I cite as just two examples 
> of this (and believe me I can provide many more):
>
Dave,

I think the term "societal need for law enforcement" is euphemistic.
That seems to presume that the laws are universally just in the first
place, and that access to the information is always controlled by a
reasonable legal process like warrants. That is not reality. There are
hundreds of legal jurisdictions in the world each with their own
concept of what constitutes a crime. Yes, there are clearly cases
where the information is warranted when a serious crime has been
committed for which a reasonable person would say the law enforcement
access to the information is warranted. However, we've also seen many
case where the information is be used to investigate "crimes" that
many reasonable people would not consider meritable to allow access.
For example, in many regions of the world it is considered a crime
speaking out against an unjust government. To a lot of people that is
considered a violation of human rights and such laws are considered
unjust. I would expect that any proposal that enables governments to
crack down on freedom of speech, even if the proposal is otherwise
beneficial, will get a lot of push back in IETF!

Tom


> - RFC4941 (Privacy extensions for stateless address auto configuration in 
> IPv6) - “by design” obfuscation of the source of network traffic with no 
> consideration of the crime attribution implications
> - RFC6742 (Default address selection for Internet Protocol version 6 (IPv6)) 
> -