Re: [v6ops] Google Alert - IPv6

Warren Kumari <warren@kumari.net> Thu, 26 October 2017 15:01 UTC

Return-Path: <warren@kumari.net>
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 E6BC713F0A8 for <v6ops@ietfa.amsl.com>; Thu, 26 Oct 2017 08:01:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 ehfkR7KWc-hr for <v6ops@ietfa.amsl.com>; Thu, 26 Oct 2017 08:01:15 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C981E1388A9 for <v6ops@ietf.org>; Thu, 26 Oct 2017 08:01:14 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id y83so3649727wmc.4 for <v6ops@ietf.org>; Thu, 26 Oct 2017 08:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x5RJ3zPttHJCD8qIo5K8VVxjLVgUna4WYzbh6NAZkDQ=; b=nPnTfs5h5goHz7CFnYA1hzxLfgO5biZzSMJ2YqzXTmZglaykTilXDwHCmbpRlxVzbX vuXGE3HM+a4ZS1d5mvHvMZlLxNVMP7WF87Bq2ZMeW/+tkHN6Xq7eUv/nMcM7cWoYNvLP H2Bpn2YB3ttnMWi1tvPbeSI9MKKII/texasfHX5KOPRekK6mdzyEp3pRykw7kOQ0rNX9 e2mhuQiYcZpE3sJWa7G6O/1bMA8jbcyU8X5AV83j1eeC652xvE7luxeXFTkVVyCjPUU8 YS6+qYDV0CRW95KgYB7xvd5UrcIwVsCvUrdogtOinz8FgSmh4G1OYLjhXOOwgs2CnUkQ 4Njw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=x5RJ3zPttHJCD8qIo5K8VVxjLVgUna4WYzbh6NAZkDQ=; b=BDNvLZslgqvtmS3I45DXf/iSLcmI1vOORw9us33naO2We8g5FKhq2mASP/pBXC6Prc aQpO+PclQgdRTRg1qxEI+sAhyXrJFU6kdCgMeaEFJsfo0klFyIT9YrFJwnakRlC8XJsH 7f+xXhz5MLZXf6DhLXesVkO1SJCWbZKJdNWfiJcQNQrf8seiuTVO3qEjn6KgLhx0bmNp thu4BoLnOulyigLgsgeoH72m7BD2oI+IxwMpD3wrfUTEW8bNLuFAHdMYwCN1FNzE1Vis 3r6sLpyJfoHhBQ15wy4j4WEeETJVWBfko1EHlL0mWcpaBekXb9gX4E6n7At1Mq9lhw40 1x3Q==
X-Gm-Message-State: AMCzsaWiUbO+P/rjdeZ03eQa+MSD7+YoTf4zPCPqQQtbCS9LxHcGZrHg 4dfWtfvG4fCKLJVkPiAsVAiPmYnEl7vphH0ENKUYcTrI
X-Google-Smtp-Source: ABhQp+Qf/HBuJGDq3tKsr5baK4lbLeloYQ4dPexB0hBSR5jZoVZTgqbH1zKwZqvEdczcyt4Dk4b3Pk+ze5OuAAQtyMA=
X-Received: by 10.28.26.138 with SMTP id a132mr1885011wma.124.1509030073027; Thu, 26 Oct 2017 08:01:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.12 with HTTP; Thu, 26 Oct 2017 08:00:32 -0700 (PDT)
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 26 Oct 2017 11:00:32 -0400
Message-ID: <CAHw9_iLWAMexrfXwsdB8duGa5ueJMofqVRqNck6DeOzA=KChqA@mail.gmail.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, Tore Anderson <tore@fud.no>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rruoeUxtXXjJb3GSC2RaxYIaY_s>
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, 26 Oct 2017 15:01:17 -0000

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