Re: [v6ops] Google Alert - IPv6

Ole Troan <otroan@employees.org> Mon, 30 October 2017 09:03 UTC

Return-Path: <otroan@employees.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 7E0B913F8EA for <v6ops@ietfa.amsl.com>; Mon, 30 Oct 2017 02:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 EX0fbugEdQje for <v6ops@ietfa.amsl.com>; Mon, 30 Oct 2017 02:03:48 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC84713F8DA for <v6ops@ietf.org>; Mon, 30 Oct 2017 02:03:44 -0700 (PDT)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 23A352D5113; Mon, 30 Oct 2017 09:03:44 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4343C2007EF9BE; Mon, 30 Oct 2017 10:03:42 +0100 (CET)
From: Ole Troan <otroan@employees.org>
Message-Id: <C71D6C23-2720-403F-B655-D8156898A137@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F9E3C752-B456-4548-8C44-1129D6F406F6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Mon, 30 Oct 2017 10:03:41 +0100
In-Reply-To: <EDC5E9C7-F193-40CE-B21C-8E1D91E9E7E3@daveor.com>
Cc: Warren Kumari <warren@kumari.net>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
To: Dave O'Reilly <rfc@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>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wbdmxcIPU7NqcR4eSB-HHpBJqZ4>
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: Mon, 30 Oct 2017 09:03:50 -0000

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