RE: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Wed, 04 January 2023 08:59 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37C3C14CF03; Wed, 4 Jan 2023 00:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF2Xp6CqWlcW; Wed, 4 Jan 2023 00:59:06 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07B2C14F74E; Wed, 4 Jan 2023 00:59:05 -0800 (PST)
Received: from lhrpeml500002.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Nn3N05Nykz67Nc8; Wed, 4 Jan 2023 16:55:28 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 4 Jan 2023 08:59:03 +0000
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2375.034; Wed, 4 Jan 2023 08:59:03 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Dino Farinacci <farinacci@gmail.com>
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "hrpc@irtf.org" <hrpc@irtf.org>, "pearg@irtf.org" <pearg@irtf.org>, saag <saag@ietf.org>
Subject: RE: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
Thread-Topic: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
Thread-Index: AQHZH1ufkLvtCC06XE6xjs5DjZimWq6NF5nVgAAvQoCAAKEtgIAACOuA
Date: Wed, 04 Jan 2023 08:59:03 +0000
Message-ID: <3c3230f3783b4ec9a8a9e3bb87cc2a8d@huawei.com>
References: <9C9FAB23-D95D-4BB6-820C-95DA8018451B@gmail.com> <9E792EAB-29DF-4A7F-8F6B-BD5BF8041167@gmail.com>
In-Reply-To: <9E792EAB-29DF-4A7F-8F6B-BD5BF8041167@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.38]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bEaC6ZrXtrLKFZcujVlmkQ5kcaM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2023 08:59:09 -0000

Hello,

IP addresses are indeed topological. As you mentioned, the challenge with making the network layer privacy-preserving is how to route the packet without revealing the source and destination of packets. 

In the literature, there has been two approaches to this challenge: using a set of indirection elements (proxies, onion relays, private relays, you name them) in order to keep a sense of destination-based routing or using a source routing approach so that the source encodes the path to the destination using a sequentially encrypted data structure that is decrypted little by little by the elements relaying the packet. The latter approach is for example demonstrated in Sphinx or Hornet, two academic work in the area of privacy-preserving communications. I think this later approach has not been given enough attention in practical solutions, and I would be interested in working on the challenges raised by such an approach in the realm of the IETF.

If the data plane becomes anonymous, there is indeed a need to also have privacy in the control plane. In my view, this is less challenging because the timing constraints in the control plane are (a bit) less constraining, and we can use techniques studied in PPM or OHAI WG. For instance, if we adopt the source-routed approach to protect privacy at the IP layer, we need to have a privacy-preserving path computation element of some sort. This element could be developed using techniques from private information retrieval, secure multiparty computation or oblivious transfer. 

Would there be interest in the community to have a document summarizing the state of affairs and remaining challenges of IP layer anonymization? I volunteer to start such a document if there is.

Best regards,

Antoine 

-----Original Message-----
From: saag <saag-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: mercredi 4 janvier 2023 09:06
To: Dino Farinacci <farinacci@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>; ietf@ietf.org; hrpc@irtf.org; pearg@irtf.org; saag <saag@ietf.org>
Subject: Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

For all end to end communications the routing system needs to know how to deliver the packet. Obscuring the mapping between the address and the location moves the anonymisation problem from the data plane to the routing plane. This makes life harder for the observer, but I am not sure that it makes it sufficiently hard as to be worth the cost. One advantage of the topological association of addresses is the intrinsic address aggregation property which both reduces routing traffic overhead and speeds up convergence.

Stewart 

Sent from my iPad

> On 3 Jan 2023, at 22:29, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> EIDs are not topological. We have all known this for a very long time. We can make them ephemeral as well, we can make them cryptographic. 
> 
> Dino
> 
>> On Jan 3, 2023, at 11:38 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> 
>>> On 03-Jan-23 23:27, John Mattsson wrote:
>>> 
>>> IP addresses are still not only long-lived trackable identifiers, but they also reveal your location.
>> 
>> IP addressing is intrinsically topological, so this is never going to change.
>> 
>> (Temporary IPv6 addresses are not long-lived, but they remain topological.)
>> 
>>  Brian
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> 

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag