Re: [Add] ECS privacy concerns, alternatives?

Erik Nygren <erik+ietf@nygren.org> Wed, 17 April 2019 16:04 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A29120458 for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 09:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FpzbX_S_j2rb for <add@ietfa.amsl.com>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 3AD5112044D for <add@ietf.org>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
Received: by mail-wm1-f46.google.com with SMTP id z24so4265226wmi.5 for <add@ietf.org>; Wed, 17 Apr 2019 09:04:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0PM0EhlTay0qsLSntqZwXGIujD9cEMN1GXleIRTsuUk=; b=D6mnUYhW+BRtv3K3/Vvtd1ZHkd2839NRcC0RzN5uqzzJGAQ2+H2FhD7mk2J+873w3t 46BWyZqKplc9QmOWXM2lWd/LS0nrseorxF0Y0Nej5q6XnYW17tgts0/GNdiIWtMjd/zb zqizaSp4UgcqMb8L8a7U+Lkj4WeJQEhvRw2DWYKPuyjryEND7om1ivohcbMXAvk44Yc7 Y/x9kARQIn+wkfh8yeyIIPE37c/461WP+WtpPsUu1ZbkPc8ORqZz1KG5zpxv/SiJTCoS qmT14G/db/875LIEd5+XOXmEo3HaghKmeo+prSMKsiU2SsasfmOTWX5Am+1d8qca9dvE yLRg==
X-Gm-Message-State: APjAAAVlRDLols8MayQA8ovSZkyEI4LX8jt4nrmYWjeS7VbowZ0Ji/ol W7CkJrE1Hw3uB+5cWvu9H8XoG9hObaE8Cv64dBk=
X-Google-Smtp-Source: APXvYqxNW4/1InrH3ZuvR7h64YkmnYWEUucg58Q4trwWqKzo/XQMieDfogzzkAhmMIFspT2YLrysAMpofoSirzTWf6E=
X-Received: by 2002:a7b:c1cf:: with SMTP id a15mr364798wmj.44.1555517065263; Wed, 17 Apr 2019 09:04:25 -0700 (PDT)
MIME-Version: 1.0
References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <b64761dc-dfab-e4e1-4bfb-82d607efa590@riseup.net> <alpine.LRH.2.21.1904101324530.9940@bofh.nohats.ca> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <af5f5c76-0095-65a0-39d1-d29d4bb0e906@mozilla.com> <ybl36mn8b54.fsf@w7.hardakers.net> <f9d0cd98-db0c-7f42-d351-d9a5002c4765@mozilla.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <CAH1iCiqPqWCEmT0DSyzu-DRtna_p1SZXuiK15HHyTrjnX1iUaA@mail.gmail.com>
In-Reply-To: <CAH1iCiqPqWCEmT0DSyzu-DRtna_p1SZXuiK15HHyTrjnX1iUaA@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Wed, 17 Apr 2019 09:04:13 -0700
Message-ID: <CAKC-DJgmb1J281Z2j4q1NbBgf+S5PmvkJfXPDkhfX_sT6cn_PA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, "add@ietf.org" <add@ietf.org>, Peter Saint-Andre <stpeter@mozilla.com>, "Plonka, David" <dplonka@akamai.com>
Content-Type: multipart/alternative; boundary="0000000000001dff9a0586bc0a9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/mIUrHCl64Bz1QxqQ7RRatD5HM_k>
Subject: Re: [Add] ECS privacy concerns, alternatives?
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 16:04:29 -0000

On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason <
> Jason_Livingood@comcast.com> wrote:
>
>> And for ease of any replies, I have a separate question on CDN
>> localization via ECS. The 6th privacy requirement suggests that ECS cannot
>> be used unless there is encryption between the resolver and the
>> authoritative server, presumably via DoT. This suggests that the privacy
>> concern isn't that the network/geographic hint provided by ECS is
>> problematic in and of itself, but that it should not be observable along
>> the network path used in recursion.
>>
>> But if TRR-to-auth recursion is not available via DoT, I wonder what the
>> recommended mechanism is for providing a more privacy-protective
>> network-geographic hint to an authoritative server, in order for example
>> for a CDN to dynamically respond with a localized response. Maybe something
>> new needs to be standardized? What options do folks suggest?
>
>
> That's a great question. Apologies in advance for always providing long
> answers. :-)
>
> IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip.
>
> I may be oversimplifying the situation, but I believe the vast majority of
> authority DNS services (or proxy services in front of those) structure
> their internal representation of things as geo->answer mappings, and
> generally have some flavor of ip->geo mapping on their front-end(s).
>

Unfortunately, Geo is only one of the dimensions used.  At least some of
the common and heavily used CDNs and other DNS-based routing services also
need to use both ASN and in some cases the regional network location within
the ASN.  As an example, a CDN or other widely distributed service may have
"on-net" deployments located deep within ISP regional networks.  So it's
not just a matter of "hand out the London cluster for UK clients".  It's
"hand out the right cluster in the UK for the client based on the POP for
the ISP/network they are currently connected to, out of a set of well over
a hundred distinct UK clusters."

This level of locality can actually help privacy by reducing the number of
hops and network/country borders that are crossed (and therefore reducing
the chances that the service request flow traffic is crossing surveillance
points).

The purpose of doing this is for increasing user performance, but also
avoiding congested interconnect points.  Decreasing localization here would
result in substantially more traffic crossing ISP backbone and interconnect
links.

Even for country-level, the validity of "geo" is a function of the country
and works better in the US and Europe.  In Asia and South America and other
parts of the world there are many areas within countries (and also between
ISPs).

But the general point stands that the client IP is not what is needed here
by authorities.  Just enough information to know where the client is
topologically within the network.  DNS authorities would actually prefer to
have the coarsest effective granularity here as it increases DNS cache hit
rate.

In IPv6 coarser information is easier to provide via ECS.  For example, a
/48 is generally fine as nothing finer-grained typically differentiates
routing.  IPv4 is much trickier due to fragmentation of the address space.

What I'd suggest as an alternative instead is to look at a "kIP" approach.
ie, to only send information via ECS at a granularity that "makes an
individual appear indistinguishable amongst a set of [k] individuals".
For some context, see a talk from maprg:
https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf

Specifying something for TRR-to-auth recursion like "When ECS is sent to
authorities it should be at a k=100 aggregation (or coarser) level, unless
over an encrypted channel" may provide the desired property?   Having a
revision or new version of ECS that makes this easier to accomplish might
also be valuable.  Since this is generally desirable for caching
efficiency, I suspect that even once a recursive to authoritative encrypted
channel is defined it will still be preferable to send these more
aggregated ECS information.

(Note that there may be IPR in the space around sending non-client-IP
identifiers for ECS.)

Also see for background  a SIGCOMM 2015 paper from a few years back on ECS
measurements from one CDN:
https://www.akamai.com/de/de/multimedia/documents/technical-publication/end-user-mapping-next-generation-request-routing-for-content-delivery-technical-publication.pdf

     Erik