Re: Address privacy

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 26 January 2020 19:59 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45902120071 for <ipv6@ietfa.amsl.com>; Sun, 26 Jan 2020 11:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.636
X-Spam-Level:
X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 bARWTbCRn-ac for <ipv6@ietfa.amsl.com>; Sun, 26 Jan 2020 11:59:47 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 CEBB5120052 for <ipv6@ietf.org>; Sun, 26 Jan 2020 11:59:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 485NyC5WkJz1ny8w; Sun, 26 Jan 2020 11:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580068787; bh=K5ysYD5yVTFT9udwac5W6boN3jY4RC7WngDCcx3ic6Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Xf7LjEUYkGPIFQujzT8jTH9hujtKwkMaPe0cQpnUoPc0SHJGFF3LA7W2xBRs2tyw8 XOB2l3sYjPQcveOBSGcisXsVfK4NPVRxQK7fxE0ekAt8AY/X3NAc1jXd2LDslqnGGA CrxaxAl6l9ohpM2AMHlsgLwsATilAVVj0oDXqGAE=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 485NyC1PcQz1ntHw; Sun, 26 Jan 2020 11:59:47 -0800 (PST)
Subject: Re: Address privacy
To: Tom Herbert <tom@herbertland.com>
Cc: 6man WG <ipv6@ietf.org>
References: <03C832CE-7282-4320-BF1B-4CB7167FE6BE@employees.org> <MN2PR11MB3565330989D411525D30B90DD80F0@MN2PR11MB3565.namprd11.prod.outlook.com> <80207E17-AE8E-4D19-B516-D2E6AB70721E@employees.org> <8D5610EA-49D3-483E-BB7A-67D67BC89346@jisc.ac.uk> <DE7B0688-230F-4A5C-8E24-9EAED9FD9FEB@puck.nether.net> <CAO42Z2zXwVnzemRqyqy78czpHjZm0nhkCJgVrx=-fmt+C6MnSA@mail.gmail.com> <1962.1579823388@localhost> <f83ab037-9125-bb74-dbac-68850aeb1020@huitema.net> <CBB23ABE-A7A3-4208-873C-E47EE063E34B@fugue.com> <11855.1579980079@localhost> <CALx6S36V_VjaxhELYcsgDYLWsCkj20p6gtiY9T9Q=9-9Oibyjw@mail.gmail.com> <32626.1580060558@localhost> <CALx6S37prWACD0jv9c-XHD-JtPqZAcgeT2Ax0EZHkiQaDR4t=g@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <419b7c7a-e364-7951-5a44-6c39e1da65fb@joelhalpern.com>
Date: Sun, 26 Jan 2020 14:59:46 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CALx6S37prWACD0jv9c-XHD-JtPqZAcgeT2Ax0EZHkiQaDR4t=g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4FGbPMCtaoF0MLjSRfukkWEkLqI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 19:59:49 -0000

Tom, your description is somewhat misleading.

On the one hand, LISP replies on per-flow state only in the mapping 
entity.  Not at arbitrary places in the network.

Secondly, if hosts work in terms of identifiers, and the network works 
in temrs of locators, someone has to map them.  You can cache (including 
caching the whole thing), you can ask the host to hold the cache itself. 
  There are other tradeoffs you can make, moving things around.  But you 
can't just magically make the problem disappear.

Yours,
Joel

On 1/26/2020 2:51 PM, Tom Herbert wrote:
> On Sun, Jan 26, 2020 at 9:42 AM Michael Richardson
> <mcr+ietf@sandelman.ca> wrote:
>>
>>
>> Tom Herbert <tom@herbertland.com> wrote:
>>      >> Except that instead of doing it at layer 4, you do it with IPsec, and extrude
>>      >> that /128 to your machine.  This is already a thing :-)
>>      >>
>>      >> > Another solution I’ve considered is to have a giant anonymity mesh,
>>      >> > with every ISP’s user participating, and forward flows through this
>>      >> > mesh, treating each customer as an anonymity server.   I think this is
>>      >>
>>      >> This is also a thing called Tor.
>>      >>
>>      > Michael,
>>
>>      > Doesn't that require that the users must explicitly configure when
>>      > they want privacy? I think a general solution should be transparent to
>>
>> Yes, I agree, it requires explicit configuration.
>> I agree that this is not a good thing.
>>
>>      > the user and "just works" to ensure their privacy. That in fact is one
>>      > of the arguments for NAT. If there is a significantly large enough
>>      > pool of users behind a NAT device, then the obfuscation is transparent
>>      > to the use and seems to be pretty good privacy (good enough that law
>>      > enforcement is concerned about NAT). I suppose a similar effect could
>>      > be achieved with a transparent proxy.
>>
>> Yes, and I think that more and more LEA will grow ever concerned about this
>> situation, and it *is* pushing IPv6 adoption.  So, how can we find a happy medium?
>>
>>      > You might want to take a look at draft-herbert-ipv6-prefix-address-privacy-00.
>>
>> An interesting read. I'm not sure where it goes.
>>
>> I would like Locator/Identifier separation.
>> I wanted SHIM6. LISP would work, I think.
>> Then privacy needs don't need to screw up efficient routing at the edge.
>>
> Hi Michael,
> 
> The problem of LISP is that it potentially includes a cache in the
> operator network that can be driven by downstream untrusted users--
> hence there is possibility of DOS attack on the cache (this is the
> primary reason why LISP hasn't been accepted into Linux).
> 
> What we really want is Identifier/Locator routing that neither
> requires per flow state to be maintained in the network nor relies on
> caches to get reasonable performance.
> draft-herbert-ipv6-prefix-address-privacy suggests crypto functions to
> map identifiers to locators at the edge.
> 
> Tom
> 
> 
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>   -= IPv6 IoT consulting =-
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>