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

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Apr 2018 17:24:15 +0100

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Apr 2018 17:31:08 +1200

> I've read this draft and do not support adoption of a

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Apr 2018 16:50:05 +0100

Hi Brian,

On 22/04/18 06:31, Brian E Carpenter wrote:
> draft, even if the authors disagree.

I agree that you are formally correct - once adopted the WG can
change a document according to WG consensus despite an author's
disagreement etc. However, I figure in practice it's way better
if a document has the right scope before being adopted - I think
our processes work much better in that latter situation and are
prone to generating heat and not light in situations like the
former;-)

And in this case, Juan-Carlos' mail was specifically a call for
adoption of this document, (at the author's behest), so I do think
the right answer here is "no" to adoption. And to then have discussion
about whether there's a usefully scoped bit of work that includes
what this draft discusses.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 22 Apr 2018 12:10:35 -0400

FWIW I think both Brian and Stephen have raised good points here.   I don't mean to say that there isn't a problem here, but I don't think it's really the right match for the IETF in general or for IntArea in particular to be publishing a document on how to facilitate monitoring on legacy networks.

I'm not personally in favor of the working group adopting this particular proposal as it's currently being presented.   I think that if Stephen's proposal were to be taken seriously, the right next step would be to try to come up with a document that could then be presented for a new call for adoption.

To me what "the working group adopted this" means is that we agree on a problem, we think we need to work on the problem, and when we succeed in documenting a solution to that problem for which there are no unaddressed technical objections, it is presumed that we will publish it.

I don't think we agree on the problem yet, so if we were to adopt this document as it stands, there's a significant risk that the changes Stephen's suggested, with which I agree, would not actually be made, and when the last call on the document happened, we'd be told that since we adopted the document and it does basically what it said it was going to do when we adopted, it's too late to object.   Let's make sure we're all on the same page so that we aren't taking that risk.

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 22 Apr 2018 20:18:40 +0100

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

- 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)) - recommending selection of temporary addresses generated using RFC4941 over other options

I think a discussion of the broader issue requires robust and vocal representation of both sides and I am willing to adopt for the 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.

From Brian E Carpenter:

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

I agree with you that this is an IPv4 problem. I mention in the document (last paragraph of section 1) that migration to IPv6 would make this problem go away but also I would like to emphasise that this is a real problem being faced right now and it is something that can’t be put off until IPv6 migration is complete. Whether or not the IETF is the correct forum is not for me to say - all I’m trying to do is make sure that at least the conversation takes place.

Regards,
daveor

---

From: Tom Herbert <[email-masked]>
Date: Sun, 22 Apr 2018 13:29:49 -0700

> The main point people are making:
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

---

From: Amelia Andersdotter <[email-masked]>
Date: Sun, 22 Apr 2018 22:36:27 +0200

Dear all,

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

> The main point people are making:

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

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

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

---

From: Amelia Andersdotter <[email-masked]>
Date: Sun, 22 Apr 2018 22:38:26 +0200

> that have been considered in the IETF.

+ since December 2016. Typical.

ARTICLE19
www.article19.org

---

From: <[email-masked]>
Date: Mon, 23 Apr 2018 05:32:25 +0000

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:[email-masked]] De la part de Stephen
> Farrell
> Envoyé : samedi 21 avril 2018 18:24
> À : [email-masked]
> Objet : [Int-area] WG adoption call: Availability of Information in Criminal
> Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 
> Hiya,
>

---

From: <[email-masked]>
Date: Mon, 23 Apr 2018 05:43:29 +0000

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

> De : Int-area [mailto:[email-masked]] De la part de Brian E
> Carpenter
> Envoyé : dimanche 22 avril 2018 07:31
> À : [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
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Apr 2018 08:39:50 +0100

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

> 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, [email-masked] wrote:
>> DeÂ : Int-area [mailto:[email-masked]] De la part de Stephen
>> Farrell
>> EnvoyÃ©Â : samedi 21 avril 2018 18:24
>> Ã€Â : [email-masked]
>> ObjetÂ : [Int-area] WG adoption call: Availability of Information in Criminal

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Apr 2018 09:01:10 +0100

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.
> 
>  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 with no consideration of the crime attribution
> implications - RFC6742 (Default address selection for Internet
> Protocol version 6 (IPv6)) - recommending selection of temporary
> addresses generated using RFC4941 over other options
> 
> 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.

> 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'm not sure what'd be the best way to have such a discussion in
the IETF context, nor if (many) others are interested in such a
discussion.

Cheers,
S.

> 
> From Brian E Carpenter:
> 
>> 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 .
> 
> I agree with you that this is an IPv4 problem. I mention in the
> document (last paragraph of section 1) that migration to IPv6 would
> make this problem go away but also I would like to emphasise that
> this is a real problem being faced right now and it is something that
> can’t be put off until IPv6 migration is complete. Whether or not
> the IETF is the correct forum is not for me to say - all I’m trying
> to do is make sure that at least the conversation takes place.
> 
> Regards, daveor
>

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 23 Apr 2018 10:10:36 +0200

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

ARTICLE19
www.article19.org

---

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

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

> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : lundi 23 avril 2018 09:40
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > The scope of this document is aligned with what the IETF has published in
> the past in this field. A list is provided below:
> >
> > - **DOES NOT** require logging another yet information: again, it relies on
> the various schemes discussed in existing RFCs.
> >

---

From: Dave O'Reilly <[email-masked]>
Date: Mon, 23 Apr 2018 13:57:06 +0100

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

---

From: Dave O'Reilly <[email-masked]>
Date: Mon, 23 Apr 2018 14:14:12 +0100

> arguments given, there's no need to try make that sound like

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

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

> for some people who support the traditional LEA position to take

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.

> 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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Apr 2018 08:20:19 -0700

> 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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2018 11:55:10 -0400

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

---

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

Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:[email-masked]]
Envoyé : lundi 23 avril 2018 17:55
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; [email-masked]
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, [email-masked]<mailto:[email-masked]> 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.

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

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 24 Apr 2018 10:11:59 +0100

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.

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

> 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 enforcement issues. There is a specific challenge with crime attribution and carrier grade nat that can (perhaps) be addressed to some extent, in a reasonably privacy sensitive way, with a minor refinement of existing best practice. The privacy implications of the proposed solution are already discussed in the document and compared to the alternative of centralised connection logging.

Regards,
daveor

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 08:12:27 -0400

On Apr 24, 2018, at 1:58 AM, <[email-masked]> <[email-masked]> 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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 08:18:16 -0400

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

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.

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 24 Apr 2018 13:46:42 +0100

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

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 24 Apr 2018 13:49:26 +0100

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

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 13:11:32 +0000

Ted,

At this stage, I don’t know if what Stephen said makes sense in the context of Dave’s I-D/RFC6302.

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?

Or (2):

-    To what extent logging source port numbers create new privacy breaches vs. only source IP address is logged?

(2) is already discussed in Dave’s I-D.

Cheers,
Med

Envoyé : mardi 24 avril 2018 14:12

On Apr 24, 2018, at 1:58 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> 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.

---

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

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

Be careful what you ask for.   The people who you consider to be ideologically opposed to you have actually tried to engage constructively with you to figure out if there's a middle ground where you get what you need without us losing what we need.   If you want to make this about ideology, it's pretty clear that there is no consensus to adopt this work.   So if this work matters to you, you need to figure out how to make it not about ideology.   A good start would be to stop accusing the people who disagree with your current approach of being ideologues.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 09:25:49 -0400

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

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 24 Apr 2018 15:30:47 +0200

On 2018-04-24 15:25, Ted Lemon wrote:
> On Apr 24, 2018, at 9:11 AM, <[email-masked]
> <mailto:[email-masked]>> <[email-masked]
> <mailto:[email-masked]>> wrote:
> 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

ARTICLE19
www.article19.org

---

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

Thank you Ted for clarifying.

Please see inline.

Cheers,
Med

Envoyé : mardi 24 avril 2018 15:26

On Apr 24, 2018, at 9:11 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

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.

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 11:26:30 -0400

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

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 24 Apr 2018 16:36:19 +0100

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Apr 2018 08:41:46 -0700

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Apr 2018 11:44:39 -0400

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

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 24 Apr 2018 18:40:16 +0200

On 2018-04-24 17:44, Ted Lemon wrote:
> On Apr 24, 2018, at 11:30 AM, Dave O'Reilly <[email-masked]
> <mailto:[email-masked]>> 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.
>
>
>

ARTICLE19
www.article19.org

---

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

On 25/04/2018 00:49, Dave O'Reilly wrote:
> 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.
>

---

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

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

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

---

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

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

---

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

Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:[email-masked]]
Envoyé : mardi 24 avril 2018 17:45
À : Dave O'Reilly
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]; Stephen Farrell
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 11:30 AM, Dave O'Reilly <[email-masked]<mailto:[email-masked]>> 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.

[Med] Agree if s/source port/source IP address [+ source port]. Please note that logging source port is likely to be **useless** for local correlation purposes.

The situation is different for abuse claims, because the source IP address AND source port are supplied via authorities to the provider who can then check its data retention files (can fed by DHCP assignments, CGN records, deterministic NAT configuration, etc...).

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

[Med] Yes.

  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.

[Med] Fully agree.

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.

[Med] Sure. Intarea published this RFC to cover this particular problem: https://tools.ietf.org/html/rfc6967 (look for Wikimedia in that RFC). Please note this is not about logging, but more blacklisting/whitelisting.

  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.

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 25 Apr 2018 09:55:51 +0100

> On 24 Apr 2018, at 16:41, Tom Herbert <[email-masked]> wrote:
>> 

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

---

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

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

---

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Apr 2018 09:31:15 -0400

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

---

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

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?

Regards,
daveor

> On 25 Apr 2018, at 14:31, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Apr 2018 09:39:51 -0400

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

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 25 Apr 2018 14:42:17 +0100

Two things:

1. We just agreed that there are some times when it would be good to log source port.

2. Re IPv6 see https://tools.ietf.org/html/draft-daveor-ipv6-crime-attribution-00, which I just published today. I would be interested in your thoughts on this.

daveor

> On 25 Apr 2018, at 14:39, Ted Lemon <[email-masked]> wrote:
>

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 25 Apr 2018 14:44:12 +0100

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Apr 2018 09:47:57 -0400

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

---

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Apr 2018 09:55:15 -0400

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

---

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

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

daveor

> On 25 Apr 2018, at 14:55, Ted Lemon <[email-masked]> wrote:
>