Re: [v6ops] Google Alert - IPv6

Erik Nygren <erik+ietf@nygren.org> Fri, 27 October 2017 14:21 UTC

Return-Path: <nygren@gmail.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 16FF013F516 for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 07:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6n8orX5bWxYO for <v6ops@ietfa.amsl.com>; Fri, 27 Oct 2017 07:21:38 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 19FEC13F577 for <v6ops@ietf.org>; Fri, 27 Oct 2017 07:21:38 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id f20so13029192ioj.9 for <v6ops@ietf.org>; Fri, 27 Oct 2017 07:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jD8Vf7SdMFYsG0ggP2nyL3dH+ERQDbI7luIhbHs9r8M=; b=E1tq6fUmDyt2KO3+Kqf7c4CMt3ALo58nflOjCuXhorpvONqsgYU1M4bhLnbF5ThfBI Yyt0pFfArpc6o9K/qz3QxKKphNZL3evPwFs/d3y/Ts0Q/gWAwgNx9YIOY7ccZozLpIdZ Fv9YVk4BdcFA7Dso5+lzoCWmo95tLj4b3612BsSQK3lHDTnhE28B+MxPCtMS1hghS+hg xHID8kBNfVAvnd97/Lrg5+Y2yGVa7ID1utKticys7kQinH030Lyj6hPftwcvz/uSljuW hiL94dSEpAZnWOhmTVJj1CsUbNGNRHhMW2tDGWx498XAAjUEfphYeEZZU9f7SlRNVisk 4ixg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jD8Vf7SdMFYsG0ggP2nyL3dH+ERQDbI7luIhbHs9r8M=; b=StOJjNpXJ8VhS1DKHJFPALoOLD19695O4Tm4bsNRuv8zoaiW1ruEP9PQ+RFbOrV19g b7veAuVkEKiAePLCK8du7HHpz8dxamws/4oslaUOTxoTVb9vwLvXS607YB+XdXUQj1ao bqRfEcKzh+Y70CIowsVFzvxZusOuKenkTXbV53GEUXj8iceicnM9mxTdUJS1GXiUrKQp cmyrsF8Jhp6LsnumTAQGkS1B2tB84mtlFCuavdlbnvKiQPC/l/DVd2zr+Nx814oEpcIk lebztNmFJnLrqC7Q3iVmVJVx0MfK0xG8FP+t86kDcKKjHxEz0UtA5IAl2pXrU8aqAhSX etyQ==
X-Gm-Message-State: AMCzsaXCogmUE/sZGv4O5XV2jQ+khj6BRvBvAIahxeKmujGggozORTFc HGi2y7kklZkCQBl70sp8aZ5H3NtCQttxq8hb8sE=
X-Google-Smtp-Source: ABhQp+SxetbnKo3VLv5b5Ctr3WuZvkkRMpPIJVg1m8RGaaXMsDh4gEmbFS34G9YgXHcspqpzK2/nkKdFsl/Sbam7+zQ=
X-Received: by 10.107.20.203 with SMTP id 194mr852972iou.6.1509114097287; Fri, 27 Oct 2017 07:21:37 -0700 (PDT)
MIME-Version: 1.0
Sender: nygren@gmail.com
Received: by 10.79.107.134 with HTTP; Fri, 27 Oct 2017 07:21:36 -0700 (PDT)
In-Reply-To: <D618D79F.8AA1A%lee@asgard.org>
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> <D618D79F.8AA1A%lee@asgard.org>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 27 Oct 2017 10:21:36 -0400
X-Google-Sender-Auth: PIN45Q6R27QexQS16pG39CEKTwM
Message-ID: <CAKC-DJgou-wPuT9Xy-8ddp_5avnUj8mqApVJ3GWChLXQsqkeBA@mail.gmail.com>
To: Lee Howard <lee@asgard.org>
Cc: Dave O'Reilly <rfc@daveor.com>, Warren Kumari <warren@kumari.net>, "v6ops@ietf.org" <v6ops@ietf.org>, Tore Anderson <tore@fud.no>
Content-Type: multipart/alternative; boundary="001a114fa7a0b1c58a055c8801bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SJcHqdio5eWA1L0uEFooa_YYuto>
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 14:21:40 -0000

On Fri, Oct 27, 2017 at 4:51 AM, Lee Howard <lee@asgard.org> wrote:

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

I'll note that that one of the major limitations for content providers
deploying IPv6
(perhaps the #1 limitation?) has been making sure all systems that handle
IP addresses
can handle IPv6 addresses well.  This includes for logging, storing in
databases,
client reputation, ip-geo, bot detection, fraud management, authentication
cookies,
parsing to partially pseudonymize (eg, stripping off bottom N bits), and
the like.
Plumbing "port" through many of these systems (even just logging and
storage)
is a non-trivial effort in many places (perhaps larger in some places than
supporting
IPv6 as now there is a {timestamp,IP,port) tuple that must be transported
and stored
rather than just an IP.

It would be much better if we can get onto a path where IPv6 can be relied
on
enough of the time to avoid having to make a large push on source port
logging.
A worst case would be if content providers had internal budget/resources to
chose between
one of "log source port" and "enable IPv6 and support logging IPv6",
especially since
some might decide to pick just the former and then might say "I went
through a big
project to log IPv4 source port, why should I also go through the effort to
support IPv6?"
despite the other good reasons to do so...

Note that reading the report, it seems like there are two issues:  the
ability to attribute,
and the risk of misattribution.  IPv6 may not always help to attribute
(especially if some
requests still come over IPv4), but it can help reduce the risk of
misattribution (at least
for those requests coming over IPv6).  The report almost seemed more
concerned about
the former than the latter.  Regardless, there is still the inherent risk
that IP addresses
can be spoofed or be multi-tenant even absent CGNAT and thus there is
danger in soley
relying on addresses in logs.

     Erik


[thoughts/opinions here are my own and do not necessarily represent my
employer]