Re: [v6ops] Google Alert - IPv6

Mark Andrews <marka@isc.org> Wed, 01 November 2017 07:32 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6B13FE42 for <v6ops@ietfa.amsl.com>; Wed, 1 Nov 2017 00:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uefAVQcqoSmR for <v6ops@ietfa.amsl.com>; Wed, 1 Nov 2017 00:32:36 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC17813FE40 for <v6ops@ietf.org>; Wed, 1 Nov 2017 00:32:36 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C70323AF7F4; Wed, 1 Nov 2017 07:32:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AB5F7160042; Wed, 1 Nov 2017 07:32:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 81BEE160064; Wed, 1 Nov 2017 07:32:34 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C3WlNfwJXaaB; Wed, 1 Nov 2017 07:32:34 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 14960160042; Wed, 1 Nov 2017 07:32:34 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 653A48DDFD9C; Wed, 1 Nov 2017 18:32:31 +1100 (AEDT)
To: jordi.palet@consulintel.es
Cc: v6ops list <v6ops@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <f403045ef57ac52962055bd88b84@google.com> <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <alpine.DEB.2.20.1710190655260.31961@uplift.swm.pp.se> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <alpine.DEB.2.20.1710190856530.31961@uplift.swm.pp.se> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHw9_iLWAMexrfXwsdB8duGa5ueJMofqVRqNck6DeOzA=KChqA@mail.gmail.com> <C4E37677-A2FB-49F8-B362-C29B28DFD570@daveor.com> <CE4906A4-E0CC-4C3F-A1F8-D2B5BED294D7@employees.org> <EDC5E9C7-F193-40CE-B21C-8E1D91E9E7E3@daveor.com> <C71D6C23-2720-403F-B655-D8156898A137@employees.org> <CALx6S37E9TN9SyMQfk3CSx9vWzjBM3bmuhvsyN0tFXGYFz9Mjw@mail.gmail.com> <CAO42Z2yXH0sPJYXJ6Nrq0B=UaDK4mC1R2Tds1tFQeBhuVh5meg@mail.gmail.com> <F0990C2F-0626-4416-AA5D-1AAE41C24510@gmail.com> <A9FAF661-C5DB-4EE2-8175-56FF50792B27@gmail.com> <C01E3F52-46F8-4BDC-91C8-052310673E6E@consulintel.es>
In-reply-to: Your message of "Wed, 01 Nov 2017 08:08:51 +0100." <C01E3F52-46F8-4BDC-91C8-052310673E6E@consulintel.es>
Date: Wed, 01 Nov 2017 18:32:31 +1100
Message-Id: <20171101073231.653A48DDFD9C@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jV8yV-tVB6QH25R_KLaUduico8o>
Subject: Re: [v6ops] Google Alert - IPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2017 07:32:38 -0000

In message <C01E3F52-46F8-4BDC-91C8-052310673E6E@consulintel.es>, JORDI PALET M
ARTINEZ writes:
> Totally agree, however there is a subtle situation here, when we
> associate this to the origin of the thread  CGN
>
> If an unlawful action has been done with that phone, the phone owner will
> be responsible in front of the law to identify the person who has go the
> phone. Otherwise, the courts will judge you as the author of the unlawful
> action.

Please cite the relevent law.  Phone are hacked all the time.  Phones
are shared all the time.  There is only ever a strong correlation
never absolute proof.  For proof you need other data.

> Same as if you are the owner of a car that has an accident and dont stop,
> unless you identify in and undoubtable way a third person driving the
> car, it will be your problem.

Cars get stolen all the time and sometimes the first you know about
is a knock on the door.  The owner of the vehicle is just the first
step in the investigation.  Things like a speeding fine may get
lumbered on you but failure to stop requires more that you are the
owner of the vechicle to be proven.

> So, and this is what I was trying to point to the EU article 29 working
> party many years ago, even if you identify an IP address, it is almost
> impossible to say this is personal data, you need to correlate that with
> many many many other data, and even do, unless you have a live record of
> he/she being in front of the keyboard at that specific time.
>
> However, the implications of CGN for the police is that, without a CGN,
> the owner for the phone that done that unlawful act (in EU you need to
> provide a legal ID to have a phone line) using that IP address, the
> identification is direct, no further investigation is needed and is the
> owner the responsible to identify a third party if that's the case. With
> CGN, if the IP address is shared and there are no source ports records,
> the investigation brings the police to a number of people, may be only
> 16, may be hundreds, which is a big issue.

Only if you are looking at single events.  Multiple events will
probably whittle the set down to a subscriber.  That doesn't
necessarially identify a individual.

> Regards,
> Jordi


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org