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

From: <[email-masked]>
Date: Mon, 23 Apr 2018 08:38:56 +0000

Dear Amelia, 

Some comments about the main recommendations in draft-andersdotter: 

      SHOULD only store entire incoming IP addresses for as long as is
      necessary to provide the specific service requested by the user.

Med: This is implementation and deployment-specific. Not sure we can mandate a server how to service users.  

      SHOULD keep only the first two octets (of an IPv4 address) or the
      first three octets (of an IPv6 address) with remaining octets set
      to zero, when logging.

Med: A server can decide to follow this reco, but it will be difficult for the owner of the server to claim an abuse and help identifying responsibilities.  

Please note that RFC6302 ** does not recommend to log IP addresses** :.

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

which means ** IF ** a server logs source IP address, then it has to log also the source port. 

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

Med: It is out of the scope of the IETF to define the duration of logs. This is country-specific. 

      SHOULD NOT log unnecessary identifiers, such as source port
      number, time stamps, transport protocol numbers or destination
      port numbers.

Med: Not sure to understand this one. "unnecessary identifiers" is not clear. I prefer the current language in 6302 which identifies the minimum set of information. 

      SHOULD ensure adequate log access control, with suitable
      mechanisms for keeping track of which entity accesses logged
      identifiers, for what reason and at what time.

Med: I hear you, but this is out of scope of the IETF. Access rights to retention data is well known and is not altered by the IETF specification. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[email-masked]] De la part de Amelia
> Andersdotter
> Envoyé : lundi 23 avril 2018 10:11
> À : [email-masked]
> Cc : Stephen Farrell
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 23 Apr 2018 21:03:59 +0200

Dear Mohamed,
all,

> Med: This is implementation and deployment-specific. Not sure we can mandate a server how to service users.  

It's a recommendation. Cf. RFC2119 on the word SHOULD. That said, the
draft is meant to encourage good (best!) practises that can assist with
both privacy focus and regulatory compliance. The IETF cannot stop
anyone from following a poor practise, and certainly I can't.

> Med: A server can decide to follow this reco, but it will be difficult for the owner of the server to claim an abuse and help identifying responsibilities.  

The recommendation is partially inspired by web analytics
recommendations for Piwik/Matomo installations by French DPA CNIL, but
of course also enjoys support from the data minimization strategies
advanced in RFC6973.

> which means ** IF ** a server logs source IP address, then it has to log also the source port. 

Indeed, my proposal is to recommend that servers do not log IP addresses
other than to the extent recommended. If they don't log IP addresses at
all, they would be following the recommendations.

> Med: It is out of the scope of the IETF to define the duration of logs. This is country-specific. 

I'm proposing a recommendation for a best practise. Presumably if for
legal reasons one finds oneself unable to follow best practise, one
follows a worse practise instead. The fact that some people may have to
follow a worse practise is not a reason to recommend a poor practise.

> Med: Not sure to understand this one. "unnecessary identifiers" is not clear. I prefer the current language in 6302 which identifies the minimum set of information. 

The recommendation follows immediately from data minimization in
RFC6973, which is consistently adhered to in IETF drafts with a privacy
focus.

> Med: I hear you, but this is out of scope of the IETF. Access rights to retention data is well known and is not altered by the IETF specification. 

I don't understand the objection. The IETF discusses access control and
authentication in various circumstances.

If anything, the recommendation could be accused of being too inexact to
qualify as a good recommendation. The scope of it is fine and well
within IETFs mandate.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 05:25:26 +0000

Dear Amelia, 

Please see inline. 

Cheers,
Med

> De : Amelia Andersdotter [mailto:[email-masked]]
> Envoyé : lundi 23 avril 2018 21:04
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : Stephen Farrell
> Objet : Re: draft-andersdotter (was RE: [Int-area] WG adoption call:
> Availability of Information in Criminal Investigations Involving Large-Scale
> IP Address Sharing Technologies
> 
> Dear Mohamed,
> all,
> 

[Med] It is a not a problem with the language of the reco, but its implementation. The IETF cannot dictate which information is required to provide a service and whether an IP address is needed. This is really implementation-specific. 

> > Med: A server can decide to follow this reco, but it will be difficult for
> the owner of the server to claim an abuse and help identifying
> responsibilities.
> 

[Med] I don't have a problem with the general intent of your text, my concern is that you link those explicitly with RFC6302 which is misleading. RFC6302 has a very clear focus: address sharing. 

> all, they would be following the recommendations.

[Med] How those servers will react to DDoS attacks or other abuses? 

> I'm proposing a recommendation for a best practise.

[Med] But there are laws out of there. I don't think that we need to interfere with those. 

 Presumably if for
> > Med: Not sure to understand this one. "unnecessary identifiers" is not
> clear. I prefer the current language in 6302 which identifies the minimum set
> of information.
> 

[Med] But how this is related to RFC6302 context? 

> > Med: I hear you, but this is out of scope of the IETF. Access rights to
> retention data is well known and is not altered by the IETF specification.
> 

[Med] Rules to access regulatory data are well known.

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 24 Apr 2018 08:08:48 +0200

Dear Mohamed,

See below:

> [Med] But how this is related to RFC6302 context? 

RFC6302 is hopelessly out of date. It was specifically justified by a
regulatory framework which no longer exists(!) and it takes into account
none of the privacy guidances given by RFC6973. If we mean to say the
privacy guidelines of RFC6973 should not be applied specifically in our
recommendations for logging to internet-facing servers, then fine. If,
however, we believe privacy guidelines apply also when we make
recommendations to internet-facing servers (as we have done), then
RFC6302 needs updating.

I think this is the primary thing to establish. I'll provide more
comments later.

best,

A

ARTICLE19
www.article19.org

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 06:31:02 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 24 avril 2018 08:09
> > [Med] I don't have a problem with the general intent of your text, my
> concern is that you link those explicitly with RFC6302 which is misleading.
> RFC6302 has a very clear focus: address sharing.
> >
> regulatory framework which no longer exists(!)

[Med] Hmm, 6302 says the following: 

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

Further, if we suppose an extreme case where regulatory forbids logging source addresses, then 6302 won't contradict with those. 

 and it takes into account
> recommendations for logging to internet-facing servers, then fine.

[Med] This is subtle, 6302 is motivated by address sharing. 6302 does not recommend logging IP addresses per se, but if a server logs IP addresses for whatever reason (regulatory, prevent abuses, etc.), then it should consider the source port too. More discussion can be found in RFC6269. 

 If,
> recommendations to internet-facing servers (as we have done), then

[Med] It is completely fine to have such analysis/discussion for logging in general, but as I said earlier 6302 has a clear scope: address sharing complications.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Apr 2018 10:26:33 +1200

On 24/04/2018 18:08, Amelia Andersdotter wrote:
> none of the privacy guidances given by RFC6973.

I can't find any reference to regulatory matters in RFC 6302,
but I did find this:
  "In the absence of the source port number and accurate timestamp
   information, operators deploying any address sharing techniques will
   not be able to identify unambiguously customers when dealing with
   abuse or public safety queries."
Has that changed since 2011?

RFC6973 adds this:
  "When requiring or recommending that information
   about initiators or their communications be stored or logged by end
   systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
   the potential for that information to be compromised and for that
   potential to be weighed against the benefits of data storage."
Indeed. But since that's a general requirement, not specific to port
logging, what is obsolete in RFC6302 itself? It's what happens to the data
*after* it's been collected that matters, and that affects everything
the server collects, not just addr+port.

Regards
   Brian

> If we mean to say the

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 23:37:56 +0000

Brian, does the server *have* to collect everything?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Apr 2018 11:57:48 +1200

> Brian, does the server *have* to collect everything?

Clearly not, but operations people are much more likely to apply a "log
everything we can store" approach than to be selective in advance. I think
it's privacy law, not IETF BCPs, that will make them think more carefully.

http://www.waitrose.com/privacynotice is worth a read, I found. It makes
IP addresses look very uninteresting.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 21:22:47 -0400

> it's privacy law, not IETF BCPs, that will make them think more carefully.

That would be an argument for not doing this work, then.

> http://www.waitrose.com/privacynotice <http://www.waitrose.com/privacynotice> is worth a read, I found. It makes

True.   However, one can in principle configure the not to send this sort of information.   IP address and port are unavoidable.

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 25 Apr 2018 06:59:01 +0200

On 2018-04-25 03:22, Ted Lemon wrote:
> On Apr 24, 2018, at 7:57 PM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:

It will also be very challenging for lots of smaller operations (I've
interacted a lot with Swedish municipalities, some varities of Swedish
NGOs) to know what good practises are, when something is *technically
necessary* or just *convenient*, when they need to start considering
privacy terms (basically one it's convenience rather than technology
that's at play).

I think these are things that would be helpful if the IETF weeds out.

best regards,

A

> True.   However, one can in principle configure the not to send this
> sort of information.   IP address and port are unavoidable.
>

ARTICLE19
www.article19.org

---

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

> Has that changed since 2011?

The reference is to RFC6269 in the introduction, which claims (section
12) that the need for traceability is regulatorily motivated. When one
makes a recommendation starting from the assumption of some regulatory
need or other, and that regulatory need subsequently changes, I think
that's "outdated".

best,

A

ARTICLE19
www.article19.org

---

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

Dear Amelia,

I disagree with your comment. 

Section 12 of RFC6269 is about logging at the network side not the server. Server matters are discussed in Section 13.1 "Abuse Logging and Penalty Boxes".

Section 12 is prudent in its language, it starts with " In many jurisdictions, service providers are legally obliged to..". I don't think that you claim that all jurisdiction over the world require operators to maintain some records.

Even for the network side, the IETF is prudent in its language and does not include an explicit logging requirement for CGNs, for example. Please given a read to RFC6888. 

Cheers,
Med

> Envoyé : mercredi 25 avril 2018 07:01
> À : Brian E Carpenter; BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : Stephen Farrell
> Objet : Re: [Int-area] draft-andersdotter (was RE: WG adoption call:

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 25 Apr 2018 10:04:16 +0100

> On 25 Apr 2018, at 05:59, Amelia Andersdotter <[email-masked]> wrote:
> 

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

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

daveor

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 25 Apr 2018 11:26:47 +0200

> Section 12 is prudent in its language, it starts with " In many jurisdictions, service providers are legally obliged to..". I don't think that you claim that all jurisdiction over the world require…

The way I read RFC6302, is that it tries to solve the problems mentioned
in Section 12 of RFC6269 in a way that does not create too onerously
sized logs (cf. also RFC7768 NATx4 Log Reduction).

But it's also a bit obvious that RFC6302 isn't really used, because it
doesn't solve any problems for Internet-facing servers that
Internet-facing servers have. It appears to want to solve problems for
internet service providers/electronic communications providers instead.

So what I propose is to make RFC6302 into something which is useful for
those of operate Internet-facing servers, and to provide a base-line set
of assumptions: from where do we start when deciding on a logging
practise? Indeed, deviations from the base-line recommendations were
taken into account by a final recommendation to document and make
accessible to subscribers the policy under which logging occurs. An
administrative cop-out, perhaps, but which hopefully serves to remind
server operators to be intentional and clear to subscribers about what
they're doing and what the policies are on their server.

I would happily take on suggestions for how to improve my draft.

best regards,

ARTICLE19
www.article19.org