Re: [v6ops] Google Alert - IPv6
Lee Howard <lee@asgard.org> Fri, 27 October 2017 08:51 UTC
Return-Path: <lee@asgard.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 B80C413ADD2 for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 01:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ZASK8ty3TDLo for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 01:51:29 -0700 (PDT)
Received: from atl4mhob04.registeredsite.com (atl4mhob04.registeredsite.com [209.17.115.42]) (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 545EB138103 for <v6ops@ietf.org>; Fri, 27 Oct 2017 01:51:29 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id v9R8pQ8I022106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 27 Oct 2017 04:51:26 -0400
Received: (qmail 14415 invoked by uid 0); 27 Oct 2017 08:51:26 -0000
X-TCPREMOTEIP: 86.98.5.7
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.10.61?) (lee@asgard.org@86.98.5.7) by 0 with ESMTPA; 27 Oct 2017 08:51:25 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Fri, 27 Oct 2017 12:51:15 +0400
From: Lee Howard <lee@asgard.org>
To: Dave O'Reilly <rfc@daveor.com>, Warren Kumari <warren@kumari.net>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Message-ID: <D618D79F.8AA1A%lee@asgard.org>
Thread-Topic: [v6ops] Google Alert - IPv6
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>
In-Reply-To: <C4E37677-A2FB-49F8-B362-C29B28DFD570@daveor.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DB1NCqfJx1hEPwlqSAfQ49Yw9PY>
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: Fri, 27 Oct 2017 08:51:32 -0000
Without any IETF hat on. . . On 10/27/17, 12:15 AM, "v6ops on behalf of Dave O'Reilly" <v6ops-bounces@ietf.org on behalf of rfc@daveor.com> wrote: >Can we regulate our way out of this problem? >—————————————————————————————— Probably not. Countries with the highest IPv6 deployment have had either no government influence, or little more than government talking with industry about their IPv6 deployment plans. Countries with IPv6 mandates on industry seem to have very low actual deployment. > >Considering regulation as a way to adjust economic incentives, there is >indeed an opportunity to help to shift things along in one or more >countries through regulation, but to what extent will this help with the >global issue of crime attribution? To the degree that IPv6 and/or proper port/timestamp logging is adopted. Either will work, but this is becoming much more of a content operator problem than an ISP or mobile carrier problem. >It is clear that if the number of subscribers that can be simultaneously >behind a CGNAT is limited, the deployment of IPv6 increases, and the IPv6 >adoption in Belgium bears that out. Yes, and I think you’re right, but the Belgian interpretation that address sharing must not exceed 16:1 may not be generalizable. That is: Belgium is one country, and we don’t know if their rule would work everywhere. > > >However, the obvious question to ask is - are the Belgian authorities >catching any more criminals now that they have such a high adoption rate >of IPv6? Has the problem of crime attribution due to CGNAT gone away for >them, or does it actually require global adoption of IPv6? The question is more like, “Are Belgian authorities catching more criminals than other countries in proportion to their IPv6 deployment?” They’re probably not catching more bad guys than they were before CGN, they’re just trying not to lose ground. And the answer is probably not good, because although Belgium has great numbers on eyeballs, their IPv6 deployment on content sites is still weak (https://www.vyncke.org/ipv6status/detailed.php?country=be ). > >One possible solution frequently cited to the problem of CGNAT is >migration to IPv6.However, does migration to IPv6 ACTUALLY solve the >problem of crime attribution due to large-scale address sharing? Only if content providers deploy IPv6, including logging. >The problem is that law enforcement agencies do not have the required >information to be able to ask the ISP for the subscriber identity - >because source ports are required and not logged anywhere. > >So the question becomes how to address this information gap. One >possibility is that ISPs must record all destination IP addresses for all >TCP connections, If the problem is that content providers are not logging enough information to identify users reaching their content, why in the world would this gap become the ISPs' problem? Regulate the content providers if they’re the ones providing insufficient information. > >The role of the IETF in this >—————————————————————————————— > >Right from the front page of the IETF website: "The mission of the IETF >is to make the Internet work better by producing high quality, relevant >technical documents that influence the way people design, use, and manage >the Internet.” > >Large scale address sharing technologies present a challenge to the >management of the Internet so that seems to fit right within the remit of >the IETF to me. Correct me if I’m wrong... Not entirely, but this seems more operational to me, and might be better targeted as a recommendation for how to manage servers. Lee > > > > >> On 26 Oct 2017, at 16:00, Warren Kumari <warren@kumari.net> wrote: >> >> On Thu, Oct 19, 2017 at 5:23 AM, <mohamed.boucadair@orange.com> wrote: >>> Hi Mikael, Tore, all, >>> >>> You may want read: >>>https://tools.ietf.org/html/draft-daveor-cgn-logging-00 which relies on >>>the Europol threat assessment report >>>(https://www.europol.europa.eu/sites/default/files/documents/europol_ioc >>>ta_web_2016.pdf) >>> >> >> I'm somewhat hijacking an old thread, but it would be great if we >> could get some more review of draft-daveor-cgn-logging -- I know Dave >> would really appreciate comments / review. >> >> W >> >> >>> As far as the IETF is concerned, I do believe that we have done our >>>part of the job: >>> >>> 1. Identify logging as an issue in address sharing: RFC 6269 >>> >>> 2. Require address sharing to enable a logging function: RFC 6269 >>> and RFC 6888 >>> >>> 3. Identify a minimal set of information to be logged: RFC 6269, >>> RFC 6888, and RFC 6908 >>> >>> 4. Identify and discuss trade-offs of solutions to achieve logging: >>> RFC 6269, RFC 6908 >>> >>> 5. Specify means to optimize logging (port range allocation, >>> deterministic NAT): draft-ietf-softwire-stateless- >>> 4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and >>> RFC7422 >>> >>> 6. Recommend servers to log source port: RFC 6302 >>> >>> 7. An initial survey of servers supporting source port logging: RFC >>> 7768 >>> >>> 8. Retrieve NAT session loggings: draft-ietf-behave-syslog-nat- >>> logging, draft-ietf-behave-ipfix-nat-logging >>> >>> 9. Enable address sharing logging function by means of NETCONF: >>> draft-ietf-opsawg-nat-yang >>> >>> 10. CPU and memory issues: RFC 6908 >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de Mikael >>>> Abrahamsson >>>> Envoyé : jeudi 19 octobre 2017 09:03 >>>> À : Tore Anderson >>>> Cc : v6ops@ietf.org >>>> Objet : Re: [v6ops] Google Alert - IPv6 >>>> >>>> On Thu, 19 Oct 2017, Tore Anderson wrote: >>>> >>>>> * Mikael Abrahamsson <swmike@swm.pp.se> >>>>> >>>>>> If they do have a port, then LEA can have a single subscriber. >>>>> >>>>> Reading the original article (linked below) I am left with the >>>>>feeling >>>>> that the problem is that they generally *don't* know the source port, >>>>> and therefore end up, quote, «[unable] to identify internet >>>>>subscribers >>>>> on the basis of an IP address». >>>>> >>>>> https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip- >>>> >>>>address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn- >>>>to- >>>> increase-accountability-online >>>>> >>>>> The article proceeds to define «CGN» as «technologies which allow >>>>> sharing of IPv4 addresses with multiple internet users». In that >>>>> context, MAP, even though it is not technically CGNAT, is just as >>>>> problematic (to answer Rajiv). >>>>> >>>>> C'est la vie! If Europol don't like IP address sharing, I think the >>>>> only thing they actually could do about it would be to put pressure >>>>>on >>>>> regulators and/or lawmakers to accelerate IPv6 adoption. I understand >>>>> that's what already happened in Belgium with impressive results. >>>> >>>> So I have no idea what's really going on here, but I can imagine >>>>someone >>>> doing CGN and just NATing people left and right, and not logging >>>>anything. >>>> Then it's near impossible to find who did what. >>>> >>>> At least when I looked into this issue, the message I got back was >>>>that >>>> narrowing down the user list to a few tens of subscribers was still >>>>vastly >>>> better than no information at all. Of course LEAs don't like it, but >>>>it's >>>> a lot better than nothing. >>>> >>>> Also, services who are typically involved in being targeted for crimes >>>> should start logging the source port of whoever is talking to them. >>>>This >>>> option is available in most web servers and has been for a >>>>considerable >>>> amount of time. >>>> >>>> Mandating IPv6 is a hard sell. Mandating ISPs to log what subscriber >>>> accounts was behind an IPv4 address at a given point in time including >>>> port used by what account, that's less far fetched. >>>> >>>> -- >>>> Mikael Abrahamsson email: swmike@swm.pp.se >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> >> >> --===============7090974386904564375==-- >> >> --===============4172498714441195205== >> Content-Type: text/plain; charset="us-ascii" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Content-Description: Digest Footer >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops
- Re: [v6ops] Google Alert - IPv6 Paul Marks
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Brian E Carpenter
- Re: [v6ops] Google Alert - IPv6 Rajiv Asati (rajiva)
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Erik Kline
- Re: [v6ops] Google Alert - IPv6 Mikael Abrahamsson
- Re: [v6ops] Google Alert - IPv6 Tore Anderson
- Re: [v6ops] Google Alert - IPv6 Mikael Abrahamsson
- Re: [v6ops] Google Alert - IPv6 mohamed.boucadair
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Lorenzo Colitti
- Re: [v6ops] Google Alert - IPv6 Alexandre Petrescu
- Re: [v6ops] Google Alert - IPv6 Warren Kumari
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ca By
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 mohamed.boucadair
- Re: [v6ops] [SUSPECTED SPAM] RE: Google Alert - I… Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] RE: Google Alert - I… mohamed.boucadair
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] Google Alert - IPv6 Erik Nygren
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 Fernando Gont
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Gert Doering
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Mark Smith
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Fred Baker
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] Google Alert - IPv6 Mark Smith
- Re: [v6ops] Google Alert - IPv6 DY Kim
- Re: [v6ops] Google Alert - IPv6 Fred Baker
- Re: [v6ops] Google Alert - IPv6 DY Kim
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Mark Andrews
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Lee Howard
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 JORDI PALET MARTINEZ
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 t.petch
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Dave O'Reilly
- Re: [v6ops] Google Alert - IPv6 Tom Herbert
- Re: [v6ops] Google Alert - IPv6 Ole Troan
- Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 Mark Smith