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

[Dave O'Reilly]

> On 26 Apr 2018, at 16:54, Ted Lemon  wrote:
> 
> On Apr 26, 2018, at 11:44 AM, Dave O'Reilly  wrote:
>> I don’t understand what you mean when you say "And it doesn't say what you 
>> want to say—you're talking about the other end of the connection.   So yes, 
>> it can be used as a pretext as written, but that's actually a problem, not a 
>> reason to continue doing the same thing.”
> 
> You want to talk about the server side of the connection, yes?   6302 talks 
> about the ISP side of the connection.


Sorry, you’re wrong about that. RFC6302 is about the server side of the 
connection. Here are some citations to support that assertion:

1. The title of the document is "Logging Recommendations for Internet-Facing 
Servers” - my personal server is an Internet-facing server but I am not an ISP.
2 .The abstract of RFC6302 refers to the logging of "incoming IP address” - 
from the perspective of an ISP you’d be talking about the logging of the 
outgoing IP address.
3. At the end of the introduction, RFC6302 says "   Note: This document 
provides recommendations for Internet-facing servers logging incoming 
connections.  It does not provide any recommendations about logging on 
carrier-grade NAT or other address sharing tools.” - in other words, the 
recommendations do not apply to the ISP (carrier grade NAT or otherwise) side 
of the connection.
4. Section 2 of RFC6302 states "Examples of Internet-facing servers include, 
but are not limited to, web servers and email servers.” - the authors 
explicitly stated that they are talking about the server side of the connection.

There’s more but I think that’s enough to make my point. 

So, to the extent that I “want” RFC6302 to say anything in particular, it does 
say “what I want it to say” - it makes logging recommendations for Internet 
facing servers to log source port.

Referring back to your original email: 

 
> Yes, but this is an old document that has been superseded at least in spirit 
> by more recent work.  

What work supersedes the recommendations of RFC6302? it was my intention to 
supersede (or at least update) this work with my document.

> I do not think we would publish RFC 6302 as written today.

Are you still of that opinion based on the above clarification?

daveor

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

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

[Ted Lemon]

On Apr 26, 2018, at 11:44 AM, Dave O'Reilly  wrote:
> I don’t understand what you mean when you say "And it doesn't say what you 
> want to say—you're talking about the other end of the connection.   So yes, 
> it can be used as a pretext as written, but that's actually a problem, not a 
> reason to continue doing the same thing.”

You want to talk about the server side of the connection, yes?   6302 talks 
about the ISP side of the connection.

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

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

[Dave O'Reilly]

> On 26 Apr 2018, at 16:35, Ted Lemon  wrote:
> 
> On Apr 26, 2018, at 11:18 AM, Dave O'Reilly  wrote:
>> Well, the IETF - this group in fact - is already saying this in RFC6302.
> 
> Yes, but this is an old document that has been superseded at least in spirit 
> by more recent work.   I do not think we would publish RFC 6302 as written 
> today.   And it doesn't say what you want to say—you're talking about the 
> other end of the connection.   So yes, it can be used as a pretext as 
> written, but that's actually a problem, not a reason to continue doing the 
> same thing.
> 

I don’t understand what you mean when you say "And it doesn't say what you want 
to say—you're talking about the other end of the connection.   So yes, it can 
be used as a pretext as written, but that's actually a problem, not a reason to 
continue doing the same thing.”

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

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

[Ted Lemon]

On Apr 26, 2018, at 11:18 AM, Dave O'Reilly  wrote:
> Well, the IETF - this group in fact - is already saying this in RFC6302.

Yes, but this is an old document that has been superseded at least in spirit by 
more recent work.   I do not think we would publish RFC 6302 as written today.  
 And it doesn't say what you want to say—you're talking about the other end of 
the connection.   So yes, it can be used as a pretext as written, but that's 
actually a problem, not a reason to continue doing the same thing.

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

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

[Dave O'Reilly]

Well, the IETF - this group in fact - is already saying this in RFC6302.

daveor

> On 26 Apr 2018, at 16:16, Ted Lemon  wrote:
> 
> On Apr 26, 2018, at 11:08 AM, Dave O'Reilly  wrote:
>> I thought we had already agreed that if it makes sense to log IP address, it 
>> makes sense to log source port (ref: 
>> https://www.ietf.org/mail-archive/web/int-area/current/msg06389.html)?
>> 
>> Recommendations that support that position would be a useful thing that the 
>> IETF could say, no? That’s basically what’s in my document. 
> 
> The point I'm getting at is that this is a useful thing to say, but it is not 
> clear to me that the IETF is who should be saying it.   If the IETF does say 
> something about this, it has to be done very carefully.
> 

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

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

[Ted Lemon]

On Apr 26, 2018, at 11:08 AM, Dave O'Reilly  wrote:
> I thought we had already agreed that if it makes sense to log IP address, it 
> makes sense to log source port (ref: 
> https://www.ietf.org/mail-archive/web/int-area/current/msg06389.html 
> )?
> 
> Recommendations that support that position would be a useful thing that the 
> IETF could say, no? That’s basically what’s in my document. 

The point I'm getting at is that this is a useful thing to say, but it is not 
clear to me that the IETF is who should be saying it.   If the IETF does say 
something about this, it has to be done very carefully.

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

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

[Dave O'Reilly]

I thought we had already agreed that if it makes sense to log IP address, it 
makes sense to log source port (ref: 
https://www.ietf.org/mail-archive/web/int-area/current/msg06389.html)?

Recommendations that support that position would be a useful thing that the 
IETF could say, no? That’s basically what’s in my document. 

daveor

> On 26 Apr 2018, at 16:03, Ted Lemon  wrote:
> 
> On Apr 26, 2018, at 10:50 AM, Dave O'Reilly  wrote:
>> No, you’re absolutely right about that. However I do not think that this has 
>> any bearing on the relevance of the recommendations in my document. 
> 
> I think this is the crux of the disagreement.
> 
>> In response to this point I refer back to one of my comments yesterday - the 
>> argument you’re making seems to be that as long as repressive regimes exist 
>> then privacy must trump all other considerations. The conclusion of this 
>> argument would seem to be that unless and until we all live in a democratic 
>> utopia then we can take no action to assist law enforcement. I do not except 
>> this. There is middle ground where law enforcement in democratic countries 
>> can be assisted without compromising the privacy of those who need it - I am 
>> of the opinion that my document lives in that middle ground. 
> 
> Yes, but the question is not whether your document is useful in that context, 
> but whether it is useful in the context that the IETF has to consider.   Of 
> course it makes sense to write a FIPS document or something that specifies 
> what you are trying to specify.   FIPS is specific to the U.S., and would not 
> be applicable in other jurisdictions.
> 
> The question is, is there something useful that the IETF can say about this 
> without it becoming a basis for arguments for legitimacy in repressive 
> contexts.
> 

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

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

[Ted Lemon]

On Apr 26, 2018, at 10:50 AM, Dave O'Reilly  wrote:
> No, you’re absolutely right about that. However I do not think that this has 
> any bearing on the relevance of the recommendations in my document. 

I think this is the crux of the disagreement.

> In response to this point I refer back to one of my comments yesterday - the 
> argument you’re making seems to be that as long as repressive regimes exist 
> then privacy must trump all other considerations. The conclusion of this 
> argument would seem to be that unless and until we all live in a democratic 
> utopia then we can take no action to assist law enforcement. I do not except 
> this. There is middle ground where law enforcement in democratic countries 
> can be assisted without compromising the privacy of those who need it - I am 
> of the opinion that my document lives in that middle ground. 

Yes, but the question is not whether your document is useful in that context, 
but whether it is useful in the context that the IETF has to consider.   Of 
course it makes sense to write a FIPS document or something that specifies what 
you are trying to specify.   FIPS is specific to the U.S., and would not be 
applicable in other jurisdictions.

The question is, is there something useful that the IETF can say about this 
without it becoming a basis for arguments for legitimacy in repressive contexts.

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

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

[Dave O'Reilly]

In the last paragraph I meant “I do not accept this”.

daveor

> On 26 Apr 2018, at 15:50, Dave O'Reilly  wrote:
> 
> Tom,
> 
> 
>> On 26 Apr 2018, at 15:38, Ted Lemon  wrote:
>> 
>> On Apr 26, 2018, at 10:27 AM, Dave O'Reilly  wrote:
>>> Let me clarify: I’m not saying that there are no problems with judicial 
>>> systems around the world but I was commenting, in response to your point, 
>>> that IP address will usually form part of the evidence and will not 
>>> generally be relied upon as identifying the suspect without supporting 
>>> evidence from other sources. 
>> 
>> I think what Tom is getting at, and also what I was getting at in my earlier 
>> comment, is that we simply can't make the assertion that "IP address will 
>> usually form part of the evidence and will not generally be relied upon as 
>> ... etc”.
> 
> No, you’re absolutely right about that. However I do not think that this has 
> any bearing on the relevance of the recommendations in my document. 
> 
>> 
>> One thing to bear in mind is that often the purpose of data collection under 
>> a repressive regime is to provide a pretext for prosecution, not to provide 
>> evidence in an adversarial trial.   The point is to be able to say that you 
>> did something to single out the intended victim of the prosecution, not that 
>> what you say you did actually accurately singled out that victim.
>> 
>> You've asked privately what my objection to the document is, and I haven't 
>> had time to re-review it yet (sorry—yesterday was jam-packed).   But what 
>> got me interested in the first place is that I think that it's really 
>> important to be serious about evaluating these issues and not simply think 
>> about this in terms of a particular isolated case, like Denmark's judicial 
>> system or the system in the U.S.
>> 
>> In practice, regimes where data collected will be used as a pretext probably 
>> have more total residents than countries where citizens' rights are taken 
>> seriously, either as a matter of custom or as a matter of law.   And in the 
>> U.S. it's pretty clear that rule of law doesn't apply anymore to anyone who 
>> is not a citizen, nor does it appear in practice to apply fully to citizens 
>> who are not white.   And we've seen with the recent U.K. Windrush scandal 
>> that this is also true in the U.K., and while it's great that it's creating 
>> a furor in the press, it's not clear that the situation is going to get 
>> substantially better as a result.
>> 
>> The problem with the IETF taking a position on these matters is that it 
>> grants the IETF's legitimacy not only to legitimate investigative bodies and 
>> judicial bodies, but also to illegitimate such bodies.  And so the bar for 
>> adoption of work in this area is not "this would improve public safety in 
>> situations where it's used properly," but rather "how could this be misused, 
>> and what responsibility could the IETF wind up bearing for that misuse.”
>> 
> 
> In response to this point I refer back to one of my comments yesterday - the 
> argument you’re making seems to be that as long as repressive regimes exist 
> then privacy must trump all other considerations. The conclusion of this 
> argument would seem to be that unless and until we all live in a democratic 
> utopia then we can take no action to assist law enforcement. I do not except 
> this. There is middle ground where law enforcement in democratic countries 
> can be assisted without compromising the privacy of those who need it - I am 
> of the opinion that my document lives in that middle ground. 
> 
> daveor
> 
> 
> ___
> 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] Int-area Digest, Vol 152, Issue 52

[Dave O'Reilly]

Tom,


> On 26 Apr 2018, at 15:38, Ted Lemon  wrote:
> 
> On Apr 26, 2018, at 10:27 AM, Dave O'Reilly  wrote:
>> Let me clarify: I’m not saying that there are no problems with judicial 
>> systems around the world but I was commenting, in response to your point, 
>> that IP address will usually form part of the evidence and will not 
>> generally be relied upon as identifying the suspect without supporting 
>> evidence from other sources. 
> 
> I think what Tom is getting at, and also what I was getting at in my earlier 
> comment, is that we simply can't make the assertion that "IP address will 
> usually form part of the evidence and will not generally be relied upon as 
> ... etc”.

No, you’re absolutely right about that. However I do not think that this has 
any bearing on the relevance of the recommendations in my document. 

> 
> One thing to bear in mind is that often the purpose of data collection under 
> a repressive regime is to provide a pretext for prosecution, not to provide 
> evidence in an adversarial trial.   The point is to be able to say that you 
> did something to single out the intended victim of the prosecution, not that 
> what you say you did actually accurately singled out that victim.
> 
> You've asked privately what my objection to the document is, and I haven't 
> had time to re-review it yet (sorry—yesterday was jam-packed).   But what got 
> me interested in the first place is that I think that it's really important 
> to be serious about evaluating these issues and not simply think about this 
> in terms of a particular isolated case, like Denmark's judicial system or the 
> system in the U.S.
> 
> In practice, regimes where data collected will be used as a pretext probably 
> have more total residents than countries where citizens' rights are taken 
> seriously, either as a matter of custom or as a matter of law.   And in the 
> U.S. it's pretty clear that rule of law doesn't apply anymore to anyone who 
> is not a citizen, nor does it appear in practice to apply fully to citizens 
> who are not white.   And we've seen with the recent U.K. Windrush scandal 
> that this is also true in the U.K., and while it's great that it's creating a 
> furor in the press, it's not clear that the situation is going to get 
> substantially better as a result.
> 
> The problem with the IETF taking a position on these matters is that it 
> grants the IETF's legitimacy not only to legitimate investigative bodies and 
> judicial bodies, but also to illegitimate such bodies.  And so the bar for 
> adoption of work in this area is not "this would improve public safety in 
> situations where it's used properly," but rather "how could this be misused, 
> and what responsibility could the IETF wind up bearing for that misuse.”
> 

In response to this point I refer back to one of my comments yesterday - the 
argument you’re making seems to be that as long as repressive regimes exist 
then privacy must trump all other considerations. The conclusion of this 
argument would seem to be that unless and until we all live in a democratic 
utopia then we can take no action to assist law enforcement. I do not except 
this. There is middle ground where law enforcement in democratic countries can 
be assisted without compromising the privacy of those who need it - I am of the 
opinion that my document lives in that middle ground. 

daveor


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

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

[Ted Lemon]

On Apr 26, 2018, at 10:27 AM, Dave O'Reilly  wrote:
> Let me clarify: I’m not saying that there are no problems with judicial 
> systems around the world but I was commenting, in response to your point, 
> that IP address will usually form part of the evidence and will not generally 
> be relied upon as identifying the suspect without supporting evidence from 
> other sources. 

I think what Tom is getting at, and also what I was getting at in my earlier 
comment, is that we simply can't make the assertion that "IP address will 
usually form part of the evidence and will not generally be relied upon as ... 
etc".

One thing to bear in mind is that often the purpose of data collection under a 
repressive regime is to provide a pretext for prosecution, not to provide 
evidence in an adversarial trial.   The point is to be able to say that you did 
something to single out the intended victim of the prosecution, not that what 
you say you did actually accurately singled out that victim.

You've asked privately what my objection to the document is, and I haven't had 
time to re-review it yet (sorry—yesterday was jam-packed).   But what got me 
interested in the first place is that I think that it's really important to be 
serious about evaluating these issues and not simply think about this in terms 
of a particular isolated case, like Denmark's judicial system or the system in 
the U.S.

In practice, regimes where data collected will be used as a pretext probably 
have more total residents than countries where citizens' rights are taken 
seriously, either as a matter of custom or as a matter of law.   And in the 
U.S. it's pretty clear that rule of law doesn't apply anymore to anyone who is 
not a citizen, nor does it appear in practice to apply fully to citizens who 
are not white.   And we've seen with the recent U.K. Windrush scandal that this 
is also true in the U.K., and while it's great that it's creating a furor in 
the press, it's not clear that the situation is going to get substantially 
better as a result.

The problem with the IETF taking a position on these matters is that it grants 
the IETF's legitimacy not only to legitimate investigative bodies and judicial 
bodies, but also to illegitimate such bodies.  And so the bar for adoption of 
work in this area is not "this would improve public safety in situations where 
it's used properly," but rather "how could this be misused, and what 
responsibility could the IETF wind up bearing for that misuse."

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

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

[Dave O'Reilly]

Fair point - I was over-eager in my response to this point. 

Let me clarify: I’m not saying that there are no problems with judicial systems 
around the world but I was commenting, in response to your point, that IP 
address will usually form part of the evidence and will not generally be relied 
upon as identifying the suspect without supporting evidence from other sources. 

daveor

> On 26 Apr 2018, at 15:19, Tom Herbert  wrote:
> 
> On Thu, Apr 26, 2018 at 2:16 AM, Dave O'Reilly  wrote:
>>> 
>>> In my experience it’s a pretty poor investigator that would rely on IP 
>>> address only for the purposes of identifying a real-world identity.
>> 
>> By the way, I’m not saying that there are no poor investigators out there - 
>> the judicial system has built in presumption of innocence to help to deal 
>> with this.
>> 
> What judicial system are referring to? Not all the world's population
> live under a judicial system based on the presumption of innocence--
> China and North Korea comes to mind...
> 
> Tom
> 
>> daveor
>> 
>> ___
>> 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] Int-area Digest, Vol 152, Issue 52

[Tom Herbert]

On Thu, Apr 26, 2018 at 2:16 AM, Dave O'Reilly  wrote:
>>
>> In my experience it’s a pretty poor investigator that would rely on IP 
>> address only for the purposes of identifying a real-world identity.
>
> By the way, I’m not saying that there are no poor investigators out there - 
> the judicial system has built in presumption of innocence to help to deal 
> with this.
>
What judicial system are referring to? Not all the world's population
live under a judicial system based on the presumption of innocence--
China and North Korea comes to mind...

Tom

> daveor
>
> ___
> 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] Int-area Digest, Vol 152, Issue 52

[Ted Lemon]

On Apr 26, 2018, at 5:14 AM, Dave O'Reilly  wrote:
> In my experience it’s a pretty poor investigator that would rely on IP 
> address only for the purposes of identifying a real-world identity. I mention 
> this point in both of the draft documents that I have published. Any remotely 
> experienced defence expert would have a relatively simple job stomping on a 
> prosecution case that relied on an argument that IP address equals real-world 
> person, if there were no other supporting lines of evidence. That’s not to 
> say that the IP address might not be a crucial piece of evidence, it’s just 
> that it would need to be taken in the context of the other aspects of the 
> investigation. 

It occurs to me that an IETF informational RFC that discusses this subject with 
investigators, prosecutors and defenders in mind could be useful, although also 
risky.   The problem is that yes, it's a pretty poor investigator who would do 
this, but there are lots of pretty poor investigators out there, and lots of 
courts that make really dumb decisions (the latest, for example: 
https://www.engadget.com/2018/04/25/eric-lundgren-e-waste-recycler-jail-windows-restore-disks-microsoft/
 
)

So if we do something it has to be with that in mind.  We have to assume that 
there will be Clouseaus as well as Holmses.


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

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

[Dave O'Reilly]

> 
> In my experience it’s a pretty poor investigator that would rely on IP 
> address only for the purposes of identifying a real-world identity.

By the way, I’m not saying that there are no poor investigators out there - the 
judicial system has built in presumption of innocence to help to deal with 
this. 

daveor

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

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

[Dave O'Reilly]

> On 25 Apr 2018, at 19:55, Ted Lemon  wrote:
> 
>> But an IP address is different. We can’t map it to a person. The legal 
>> system can map it to a physical location unless that location has shared 
>> WiFi, VPN or is a tor exit node. I have all 3. 
> 
> Unfortunately, although you are absolutely correct that it can't be mapped to 
> a person, that is in fact how LEOs have historically tended to treat it.   
> The person to whom it is mapped is presumed to be the subscriber.
> 

In my experience it’s a pretty poor investigator that would rely on IP address 
only for the purposes of identifying a real-world identity. I mention this 
point in both of the draft documents that I have published. Any remotely 
experienced defence expert would have a relatively simple job stomping on a 
prosecution case that relied on an argument that IP address equals real-world 
person, if there were no other supporting lines of evidence. That’s not to say 
that the IP address might not be a crucial piece of evidence, it’s just that it 
would need to be taken in the context of the other aspects of the 
investigation. 

For example, the IP address evidence suggesting that a person is involved in 
some sort of fraudulent activity might be supported by the fact that they have 
massive amounts of unexplained wealth (e.g. with no corresponding tax returns), 
evidence collected from the person’s devices (e.g. malware droppers, browsing 
history, etc.), statements from the suspect that they are the only person that 
uses those devices where evidence was found, etc. etc. 

>> We don’t send armed police in confiscating everything here in Denmark. Often 
>> it is just a friendly knock on the door and a talk/confession. 
> 
> Here in the U.S. a criminal investigation of the sort you describe, where the 
> victim is a network service provider, seems unlikely, although perhaps in 
> some jurisdictions they are catching up.   A typical consumer of this data 
> would be a DMCA complainant or a police officer investigating some 
> non-computer-fraud case that happens to involve some visible online activity 
> that, if traced, might lead in the direction of a suspect.

The evidence from service providers is important, of course, but before any 
conversation ever takes place with an ISP there needs to be some way of finding 
out which ISP needs to be talked to. A suspicious IP address (and source port!) 
needs to have been identified somehow and then a process will take place to 
identify who was using that IP address (and source port!) at a particular point 
in time. Without adequate logs from the victim or platform (which i agree is 
most likely not the service provider) it’s difficult for the investigation to 
even get started…..and from there we’re all the way back to the start of the 
discussion again so rather than repeating the whole position again, I refer to 
my document where the arguments relating to availability of the required 
information are laid out in more detail. 

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

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

[Dave O'Reilly]

Another brief contribution below:

> On 25 Apr 2018, at 19:55, Ted Lemon  wrote:
> 
>> But an IP address is different. We can’t map it to a person. The legal 
>> system can map it to a physical location unless that location has shared 
>> WiFi, VPN or is a tor exit node. I have all 3. 
> 
> Unfortunately, although you are absolutely correct that it can't be mapped to 
> a person, that is in fact how LEOs have historically tended to treat it.   
> The person to whom it is mapped is presumed to be the subscriber.
> 

In my experience it’s a pretty poor investigator that would rely on IP address 
only for the purposes of identifying a real-world identity. I mention this 
point in both of the draft documents that I have published. Any remotely 
experienced defence expert would have a relatively simple job stomping on a 
prosecution case that relied on an argument that IP address equals real-world 
person, if there were no other supporting lines of evidence. That’s not to say 
that the IP address might not be a crucial piece of evidence, it’s just that it 
would need to be taken in the context of the other aspects of the 
investigation. 

For example, the IP address evidence suggesting that a person is involved in 
some sort of fraudulent activity might be supported by the fact that they have 
massive amounts of unexplained wealth (e.g. with no corresponding tax returns), 
evidence collected from the person’s devices (e.g. malware droppers, browsing 
history, etc.), statements from the suspect that they are the only person that 
uses those devices where evidence was found, etc. etc. 

>> We don’t send armed police in confiscating everything here in Denmark. Often 
>> it is just a friendly knock on the door and a talk/confession. 
> 
> Here in the U.S. a criminal investigation of the sort you describe, where the 
> victim is a network service provider, seems unlikely, although perhaps in 
> some jurisdictions they are catching up.   A typical consumer of this data 
> would be a DMCA complainant or a police officer investigating some 
> non-computer-fraud case that happens to involve some visible online activity 
> that, if traced, might lead in the direction of a suspect.

The evidence from service providers is important, of course, but before any 
conversation ever takes place with an ISP there needs to be some way of finding 
out which ISP needs to be talked to. A suspicious IP address (and source port!) 
needs to have been identified somehow and then a process will take place to 
identify who was using that IP address (and source port!) at a particular point 
in time. Without adequate logs from the victim or platform (which i agree is 
most likely not the service provider) it’s difficult for the investigation to 
even get started…..and from there we’re all the way back to the start of the 
discussion again so rather than repeating the whole position again, I refer to 
my document where the arguments relating to availability of the required 
information are laid out in more detail. 

daveor



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

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

[Ted Lemon]

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

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

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

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

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

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

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

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

[Povl H. Pedersen]

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

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

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

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

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

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

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

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

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

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