Re: [v6ops] Google Alert - IPv6

Dave O'Reilly <rfc@daveor.com> Sun, 29 October 2017 16:11 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 3959A13F56A for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:11:03 -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 mUBz0aAmM2LW for <v6ops@ietfa.amsl.com>; Sun, 29 Oct 2017 09:11:01 -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 F127B1386DE for <v6ops@ietf.org>; Sun, 29 Oct 2017 09:11:00 -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=uhcoQ9ee/BnaQDke89mzIJm2fF+3pYXzioCEAZunIcY=; b=KF/Ssa9EZCsDngUERm8E5dP043 aLiD1fcfkSWz9gWiAMdXTAKdG8sdOhNO/4JjHSdaOKAL0bIJxUcL9M2dlaDfkoKzUze1DcAuyN6D0 DoUZIgWo/X6haSmbqFK0cLnm4x2Xp7UnTtibiyj39r7W4p5AshCD7XF208UuML3FXlQk=;
Received: from 86-44-56-31-dynamic.agg7.bsn.cld-dbn.eircom.net ([86.44.56.31]:54890 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 1e8qAs-0001t6-3m; Sun, 29 Oct 2017 16:10:58 +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: <CALx6S36XKOptW9h_d9HdRX6mKdZAiWgtNxS0b35BOAEb-Q+j6w@mail.gmail.com>
Date: Sun, 29 Oct 2017 16:10:57 +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: <A824C77E-084D-4293-86F4-F0DBF82EB833@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> <CALx6S36XKOptW9h_d9HdRX6mKdZAiWgtNxS0b35BOAEb-Q+j6w@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
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/HWtFYQBu1Kv9ByAxSMrl9atb6v4>
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:11:03 -0000

Hi Tom,

Thanks for your mail. 

I’m delighted to see that there have been a few replies to this thread. I am working through them now and yours is the first! 

> On 26 Oct 2017, at 21:42, Tom Herbert <tom@herbertland.com> wrote:
> 
>> 
>> 
>> On the topic of “CGNAT is a bad idea”
>> ——————————————————————————————
>> 
>> I am not too sure how much mileage there is getting caught up in this point. CGNAT is out there in the world, along with a suite of other large-scale address sharing technologies, and although the transition to IPv6 is ongoing, it is painfully slow and transitionary arrangements will be required for the foreseeable future.
>> 
>> It would be, in my opinion, remiss of the criminal justice system not to consider this issue. The argument that the CGNAT problem will go away if we were all to just move to IPv6 doesn’t help solve the murder that happened today or catch the person distributing child pornography on the Internet.
>> 
> Dave,
> 
> The flip side to this coin is that if good guys are able to track IPv6
> addresses more easily, then that means the bad guys will be able to
> also. Today it may be the case that CGNAT inadvertently offers better
> privacy for users that IPv6 would (without any consideration why users
> want privacy). So there should be a concern about the privacy of IPv6.
> The likely solution is to allow hosts to use untrackable IP addresses,
> maybe they would want to use a different IP address for each
> connection. There are proposals for this.
> 
> If hosts use untrackable addresses, then privacy properties of IPv6
> and CGNAT should be nearly equivalent. So the solution to assist law
> enforcement ends up being the the same as that for CGNAT. A provider
> maintains a log of mappings from the IP addresses to users and
> releases information to authorities under warrant. It seems like this
> is a logical extension to your draft.
> 

I agree with you that the choice of CGNAT vs. IPv6 doesn’t, and cannot possibly, address the issue of crime attribution on the Internet. I also agree that there is a balance to be struck between crime attribution (in general) and individual right to privacy. 

It has been my experience that the general approach that has been adopted to date is that:

1. ISPs are obliged through regulation to keep sufficient information to be able to identify their subscribers from their online activity
2. Law enforcement send requests for subscriber information to the ISPs concerned, with appropriate legal safeguards (whatever that means in any particular jurisdiction!!)

All of this might change (within the EU at least) due to the ECJ ruling on the invalidity of the data retention directive (the basis upon which ISPs are required to keep subscriber identity), but I don’t know how that’s going to work out.

You raise a very interesting point about how all of this will work in the case of IPv6 and I have made a note in my list of research ideas to investigate how crime attribution/subscriber identification might work in an IPv6 world. It’s a little beyond the scope of the problem I’m thinking about right now (CGNAT), but definitely worthy of consideration in due course, so thanks for that suggestion.

Regarding your comments on the use of untraceable addresses, I’m not a law enforcement officer, but I don’t think you would find a law enforcement officer anywhere in the world that would tell you that they think they could possibly catch every criminal (particularly in the cybercrime world). There are plenty of techniques and technologies out there that obfuscate the source of communication beyond the point of attribution, but this is not a reason for doing nothing - and I think this is the point I was making in my original email. CGNAT is out there, it’s a problem right now, and it’s a problem that is amenable to a solving, to a greater or lesser extent. 

I see the problem as basically an information gap problem - there is a gap between the information being retained by the ISPs and the information being logged by victims/platforms/hosting providers. There are, as far as I can tell three solutions to the problem:

1. Oblige ISPs retain more information (e.g. logging of all destination IP addresses for each subscriber)
2. Oblige ISPs to move to IPv6 either directly or indirectly
3. Victims/platforms/hosting providers look out for themselves and log the information required

Option 1, in my opinion, has horrendous privacy implications. Option 2 is also very difficult to recommend as an approach because regulation regimes vary so much across the world, and criminals tend to seek out favourable regulatory/legal regimes in which to operate (see, for example the problem of bulletproof hosting). Without regulatory pressure, IPv6 transition is only likely to happen at the slow, shall we say organic rate, that it has been taking place at until now. 

This leaves only the “self help” approach of people looking after themselves to address the immediate problem presented by CGNAT. This was the line of thinking that led to me drafting up the document for consideration of all of you good people in the IETF! 

Interested in any thoughts you might have on the above,
daveor