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

From: Juan Carlos Zuniga <[email-masked]>
Date: Wed, 9 May 2018 10:44:15 +0000

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:[email-masked]] On Behalf Of Juan Carlos Zuniga
Sent: April 19, 2018 5:38 PM
To: int-area <[email-masked]>
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

---

From: <[email-masked]>
Date: Wed, 9 May 2018 11:26:25 +0000

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:[email-masked]] 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,

     *   If yes,

     *   If no,

Best,

Juan Carlos & Wassim

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

Dear all,

Best,

Juan Carlos & Wassim

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 9 May 2018 16:38:08 +0100

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 May 2018 12:19:57 -0400

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

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.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 May 2018 20:05:57 -0700

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