Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Thu, 02 November 2017 16:58 UTC

Return-Path: <rfc@daveor.com>
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 B06A813B432 for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 09:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com
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 MCr5vRNHEIgl for <v6ops@ietfa.amsl.com>; Thu, 2 Nov 2017 09:58:55 -0700 (PDT)
Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (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 64AC913ACAB for <v6ops@ietf.org>; Thu, 2 Nov 2017 09:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=CKLCrZbk+AtH4+CaviptBy+eehfXCLlSBNMG8vHFANQ=; b=iGLBQcMEQvRxWgHOsKbwJJged2 A9WWLaX3cz0jC6U8/yPCqS+Ay0TatCNuCPO697/CElB50gOj+a/JAxjHZu+fIr/1s3cLHP1gtuF9m 4qCN6VQGKXYAzBvsD0x0qZB3kqvfZUctQpacX6EhLaqT1rf2Lb03YdIWsmYVLIV5B4yc=;
Received: from [83.103.212.135] (port=62244 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <rfc@daveor.com>) id 1eAIpR-0002ee-5L; Thu, 02 Nov 2017 16:58:53 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave O'Reilly <rfc@daveor.com>
In-Reply-To: <C71D6C23-2720-403F-B655-D8156898A137@employees.org>
Date: Thu, 02 Nov 2017 16:58:54 +0000
Cc: Warren Kumari <warren@kumari.net>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF9B540E-5B21-4C2B-A271-3DB156EE6069@daveor.com>
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>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - daveor.com
X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com
X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IxVtyEhKrtvnL-bFDkNjsiGPR3M>
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: Thu, 02 Nov 2017 16:58:56 -0000

Totally agree. As I mentioned in the email that I just wrote, even if the IP address identifies a device that is no indication of who was in control of that device at a particular time. Don’t forget that there are other possibilities, for example, that the device may have been remote controlled by e.g. malware - I think this point would be pretty well understood in the law enforcement community but I will review the draft and clarify this point if necessary.

Thanks,
daveor

> On 30 Oct 2017, at 09:03, Ole Troan <otroan@employees.org> wrote:
> 
> Hi Dave,
> 
>>> Major comment:
>>> 3) The document talks about identifying an individual, and in places a subscriber endpoint. What it does identify, is the _originating network_. What you get is the public interface address of the customer CPE. Which looks like a network from the inside.
>>> Make it very clear that this does not identify individual hosts. And it might be worth noting that traffic my enter the originating network from outside. E.g. through VPNs, TOR exits, shared WIFI and whatnot.
>>> 
>> 
>> Yes, I completely agree.
>> 
>> I do address this point in the -01 revision scope section:
>> 
>> "Clearly no single solution will address the problem of crime attribution on the Internet.  Load balancers, proxies and other network infrastructure may also, intentionally or as a side-effect, obfuscate the true source of Internet traffic and these problems will continue to exist with or without the presence of large-scale address sharing technologies (like Carrier-Grade NAT and A+P).”
>> 
>> I wanted to mention the point without getting dragged into details of all of the possible scenarios where an IP address does not represent an individual or subscriber endpoint (apart from CGNAT). I was of the opinion that there is a risk of trying to “boil the ocean” with a  document like this so I was trying to keep the focus as tightly as possible on the issues raised by CGNAT.
>> 
>> In light of this, do you think this needs to be more explicitly discussed or clarified?
> 
> I think that's fine.
> As long as you make it clear that:
> - the IP address _never_ identifies an individual.
> - it identifies a host, a source network, or the obfuscated result of a TOR gateway, VPN, another NAT, LB etc, etc...
> 
> But never, ever by itself an individual person.
> 
> Best regards,
> Ole