Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Sun, 29 October 2017 16:19 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 AA18213F58B for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:19:04 -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 Ijp2icAcNYhj for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:19:03 -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 A36B913F49F for <v6ops@ietf.org>; Sun, 29 Oct 2017 09:19:03 -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=UWu7hWdHD/DxB2IpVGshFSst2j56+HQTd081yKRhyWQ=; b=rmk/XN5AhbO8ef8h9gXHCWoB6U YFGcsWc9om2x7ebH3yaQA1MmFuXC5EEOgxmbR2a8gJYhUsMfLCDiTUQIgF2KgwxNkE6pxuK7Ah5bf 8DI1p42qNFZw5Qbw0AL2DTrDyT/AnoDwIrNk168fKi/qE4AKmtE78w9EFVFa5NgAtWvg=;
Received: from 86-44-56-31-dynamic.agg7.bsn.cld-dbn.eircom.net ([86.44.56.31]:54935 helo=[192.168.1.25]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from <rfc@daveor.com>) id 1e8qIf-0001zW-O4; Sun, 29 Oct 2017 16:19:01 +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: <CE4906A4-E0CC-4C3F-A1F8-D2B5BED294D7@employees.org>
Date: Sun, 29 Oct 2017 16:19:01 +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: <EDC5E9C7-F193-40CE-B21C-8E1D91E9E7E3@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>
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/72x4P6og9wUJBTNh_5p0g3MW30g>
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: Sun, 29 Oct 2017 16:19:05 -0000

Hi Ole,

Thanks for the email.
> 
> Two minor comments.
> 
> 1) You might want to reference the other IPv4 sharing mechanisms too (RFC7598, 7599 etc). Although they don't require logging by the IPv4 sharing operator, they have the same issue with source port + timestamp required.
> 

I have included reference to these in the introduction to the -01 revision of the draft. 

> 2) I'd suggest you drop mentioned of suspects and criminal activity in general. Also it reads in places like it is written with too much of a particular jurisdiction in mind.
> 

Thanks for this comment. Could you provide a specific example of this please - I was hoping that I had adopted a reasonably international approach to the problem. Obviously I live in a specific jurisdiction, and operate/work within a particular regime (the EU), which may have coloured my thinking in a way I haven’t identified.

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

daveor