Re: [Apn] Further revised draft Charter

Ted Hardie <ted.ietf@gmail.com> Wed, 18 January 2023 09:16 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83122C14CF1F; Wed, 18 Jan 2023 01:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Level:
X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BDefT8D3rixS; Wed, 18 Jan 2023 01:16:34 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 E1533C14CF17; Wed, 18 Jan 2023 01:16:34 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id ud5so81675602ejc.4; Wed, 18 Jan 2023 01:16:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TUGCDVPbbOAC3OXUmc8ReG+ppDc5DPDPg//WKSYqwlY=; b=Rr8mkmZsPN3/l8stQqp3jj55LFTG2Eb1oifYdU1BHvWblU0U5J9qiq/UyyVBGGPx8P IVL3NSgr6LrIaE++KH6DLJUzKHABDYniLnIIC5BOSMj3gfOPrF8SDCoIk0bl2xqmvL4z XoYYxZMvq5Vd50ZNIV8bPqnRG7OZ1nV9+myrnVQGJkpPlUCENnQtXa0ayJ0Y+/ovd8Ak +BapdEltojFWO1ZjWeNEeSnp/b2qQyAiuVuYrHp6pi+HOGdfbSkE9jy0fE89KawfWOVB +qY/WTVBRocXGbkPg7fNBTefMfyaC8vX7pMffwCwwHQtVTXue7v4P4XDCtetp50QFjkc coDQ==
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=TUGCDVPbbOAC3OXUmc8ReG+ppDc5DPDPg//WKSYqwlY=; b=YRaXSd9vxfiXrzGMw4K0n05rkxhKiov4tD1ugWvew/YcqYZFeNn9ilTG+fGakyG9Ry OMqem/XcUy/nb0EpvMfrOXmwSJpoNXBRz9Nig9XAY+kRCSfKndcAo4sb918vWZ+4g59w /xWxVeH9dYE07Tb+TtcWx9vyXye3c8lPvS3HSTSupfOfLXLGkCRi+8SfzHWRh8KFiXv0 zHRScmCcgNN9EvoD1WcHydOiPxRokJ7IhEQWj7aGh3H+IQyZpUyv3vCwnXNcqSFdOElv xjNwRsE7aSOGtcb75WRZRzqkJutzmXY84OE0j98eFO0c4ZiKN433maAKEAjaayxMtaDD WqCQ==
X-Gm-Message-State: AFqh2kq7qw/fpkF6AKHLA5rV/N5qkyWAi0YiVhR0El6rgyKuNysXfsZs UDlpYzxWZ44d6vh5yB49M0EHhBiamYwYTWB8XXikE6hs
X-Google-Smtp-Source: AMrXdXufxChXkIhVGCXlXVszJ/KwUb6WXp1x+9ZMGaZjtsLzn10/ZhxHMT6KF/jEN9pnh/H8m7NsBC/HHu+/cS3jZiQ=
X-Received: by 2002:a17:906:7754:b0:86f:2cc2:7028 with SMTP id o20-20020a170906775400b0086f2cc27028mr435628ejn.133.1674033392667; Wed, 18 Jan 2023 01:16:32 -0800 (PST)
MIME-Version: 1.0
References: <CAF4+nEFHcKBbc7J8v3yj_b6V1==4yUBOOhdazR2yrP75Gcd0mA@mail.gmail.com>
In-Reply-To: <CAF4+nEFHcKBbc7J8v3yj_b6V1==4yUBOOhdazR2yrP75Gcd0mA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 18 Jan 2023 09:16:05 +0000
Message-ID: <CA+9kkMAqGi-RQBB=1Mh1b-r3eMc9ysrafAR+7gOUWG=V5X_Vsw@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: apn@ietf.org, apn-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b651ea05f2864502"
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/p1eBJRmwyTWBlcCXArlNS_nhEZE>
Subject: Re: [Apn] Further revised draft Charter
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2023 09:16:35 -0000

Hi Donald,

I've read the new charter, and I continue to have both privacy concerns and
architectural doubts.  On the privacy side, you note that there are a
variety of services which might be required ranging from routing to
prioritization and measurement.  The larger the number of services, the
more likely it is that a specific combination can be used to fingerprint
traffic in ways that become problematic.  I'm sure you're aware of the
literature on this from the web world relating to headers and font
selection, so I won't belabor it too much, but I feel the open-endedness of
this field is problematic.  As I read this, an APNET domain could either
put a large collection of data into the field that becomes a fingerprint, a
hash of it that would also serve as a fingerprint, or even decide to put a
customer identifier in that field and then let each router or middlebox on
the path lookup the appropriate behavior.  While you might argue that
either that the hash of that cluster or a customer identifier would be
opaque, third party attackers would get at least uniqueness data that they
would not otherwise have, contrary to efforts by the end system to use
private IP addressing or similar approaches.

On the architectural side, there are a number of fields that already do
elements of what this charter lists as desiderata (QoS, routing, etc.)--why
is creating an omnibus field for all of them going to work better than
acting on the ones that are already there?  Stepping back a bit, If you
were to look back at the OPES considerations in RFC 3238, how would you
distinguish this from that approach, and why would the considerations be
different?  That recommended at least one party consent and directly
addressed intermediaries, neither of which this seems to provide.

To put this a differently, this work seems to want flow based path signals
without trusting the endpoint and without restricting the scope of those
signals.  Neither seems to me the best approach.

regards,

Ted


On Wed, Jan 18, 2023 at 2:04 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> I've gotten some comments and I've re-read some of the AD DISCUSSES and
> comments. Based on that I've updated the draft Charter as attached.
> Comments are welcome.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
> --
> Apn mailing list
> Apn@ietf.org
> https://www.ietf.org/mailman/listinfo/apn
>