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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 04 January 2023 16:16 UTC

Return-Path: <hallam@gmail.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 EA4DDC15271F; Wed, 4 Jan 2023 08:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Slv9IAxf5_8H; Wed, 4 Jan 2023 08:16:50 -0800 (PST)
Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5009AC1522B1; Wed, 4 Jan 2023 08:16:50 -0800 (PST)
Received: by mail-oi1-f176.google.com with SMTP id r130so29912532oih.2; Wed, 04 Jan 2023 08:16:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tmllMx97F1PUCyfOzs/CwyU9Wwo+SYJdgKUrzGzTB5Q=; b=MS0z4oar1U19QyacWdWdGklB3tupuHr+RdLt2M5NeEb9/up0+bUCzp1gx/K8EhXLA8 EB2SdC+p87RFC3rKcJxiqC3hFjjFgr9WpdTBVVqv41YsMgLCbMFGh16EZ/HTS8aMXark nIUdCU3LaIbeM/3lPMep8oRmBkwwJ8pibCs16vlQqmpguX3gCOK+rLQiwgh3maZhGt5L 9NHTBX4l0YNmBXQurUkoYnsyk+oD+mqUyoqUroK4yQ+mxcTCwaaAl/IvPQ11fY7C4wMm zxLI5/WWtgnRCZbdeuCQpT/sKRqVie4G76aO4UQvYTvLTz96JFfi67LuABOH4NTfexwc mm2w==
X-Gm-Message-State: AFqh2kqoz1pZcszJhImGXK9qJA9F0sFasct2aedrW3KMKl7hRFWwXsoW qe8yWDIW7+5+0KArdeJ2oBg1xNVPlPBiVijToqE=
X-Google-Smtp-Source: AMrXdXtMVm+Y/9wqVw3AUOQMsB7ROUUHYjW8fDerWTdGNtJwPYc7DtxxoG2Tj68oOT+VYV5tomvuJFdUz9pcuzMLRaU=
X-Received: by 2002:a54:4583:0:b0:35b:88ce:f191 with SMTP id z3-20020a544583000000b0035b88cef191mr3326762oib.108.1672849009572; Wed, 04 Jan 2023 08:16:49 -0800 (PST)
MIME-Version: 1.0
References: <3c3230f3783b4ec9a8a9e3bb87cc2a8d@huawei.com> <08C49067-DB4C-41AB-A6F3-B96BDBE0A4BC@yahoo.co.uk>
In-Reply-To: <08C49067-DB4C-41AB-A6F3-B96BDBE0A4BC@yahoo.co.uk>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 04 Jan 2023 11:16:38 -0500
Message-ID: <CAMm+LwjvOz3FZZJ4P4K1qk8XYustnYUFf8sVDiBfNSFXYwbdZw@mail.gmail.com>
Subject: Re: [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
To: Lloyd W <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>
Cc: Antoine FRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org>, ietf@ietf.org, pearg@irtf.org, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, saag <saag@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, hrpc@irtf.org
Content-Type: multipart/alternative; boundary="000000000000fa810505f1728291"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SjpXCOrVjZlTQzt2zYUEQxlyv5E>
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 16:16:51 -0000

On Wed, Jan 4, 2023 at 4:20 AM Lloyd W <lloyd.wood=
40yahoo.co.uk@dmarc.ietf.org> wrote:

> There has been no mention of NAT in this thread as an obscuring technique.
>
> There's probably scope for a 'best practices for preserving privacy for
> carrier grade NATs' or somesuch document  -- I doubt much can be done at
> the low end for a NATted residential 192.168.1.1 network, but CGNAT for
> millions of users is a very different beast.
>

I don't think it is a useful term to use in this context.

Since London, I have completed a prototype of a transport layer which
arguably provides the ultimate in traffic analysis protection and then
backed it out as far too complex for most developers to tolerate at this
point. I will try to get round to a write up.

It does look a bit like NAT if you squint. But only a very little bit.

Thing with NAT is that all packets are going through one ingress/egress
point. If you are doing traffic analysis protection you want a nice fat
branching tree. So all your outbound packets go to a single node but your
inbound packets are coming from multiple exit nodes.

Another thing about NAT is that it is passive and in my scheme, every
connection is brokered through an external service.

The only thing that it really has in common with NAT is that it has the
same effect of allowing more efficient use of the IPv4 address space.