[tsvwg] Re: support last call for User Ports for Experiments

"touch@strayalpha.com" <touch@strayalpha.com> Tue, 28 January 2025 04:30 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E19C15106A for <tsvwg@ietfa.amsl.com>; Mon, 27 Jan 2025 20:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 1pKenR7r7XuK for <tsvwg@ietfa.amsl.com>; Mon, 27 Jan 2025 20:30:33 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA0EC151062 for <tsvwg@ietf.org>; Mon, 27 Jan 2025 20:30:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GrYLtSKVD0ZlViumUuIm4G6fpXvCren1tTkgR98cqwE=; b=aA+i5NLoxnZeCiv3etXnEpr7KX 26kMeQrATM/ESgfKfgq+8tcd0er8KfixuUT1MMvG1UNC4MVAuzN4gBA/r2vWk1eFgx249V/o+rlek GL0N9DtOEVitdtwxV6HaVdqvlT5vJ7bUOkhcf6FM6FAo0nuCp+N+LAcptQVVilfcdrFJ7iwoTjOvB nNOA55trcu3PxXmePCgDzKTqF7rA/tK732+Fuyfk86TBcE10tRCFQ/HzSkPIFu5YcXNOjlSq/S2wx MmpkBnCrAB0M5bKdG5yy/sgce8hK5qNL04bvRzFnsLw96fk6uJzjLIpmjPsv+zYXj4n+JwixDXxU5 7EIoqWJQ==;
Received: from [172.58.208.178] (port=24829 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <touch@strayalpha.com>) id 1tcdF9-00ERUS-14; Mon, 27 Jan 2025 23:30:31 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B15D88B7-FA0D-4198-9AE3-29ABD23562B1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <3573b4f88b424a428832b4b84db4254a@hs-esslingen.de>
Date: Mon, 27 Jan 2025 20:30:19 -0800
Message-Id: <AC1A37F5-CCF1-47A8-A664-D7757F80266D@strayalpha.com>
References: <06f2434e-ed48-4b5f-8623-a567ebae9cee@mti-systems.com> <3573b4f88b424a428832b4b84db4254a@hs-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3826.300.87.4.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Message-ID-Hash: Y7GSPY2QLG2272P6IEJNCIUEZQETIXHL
X-Message-ID-Hash: Y7GSPY2QLG2272P6IEJNCIUEZQETIXHL
X-MailFrom: touch@strayalpha.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [tsvwg] Re: support last call for User Ports for Experiments
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tdrBLXs3zfHpxhEhpSwjZrW20zY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

HI, Michael,

Thanks for your comments - I addressed them just now in -04.

Note that I did find that both QUIC and TLS/DTLS have mechanisms for extension negotiation, just as would TCP, but that I felt it was outside the scope of the document to request such code points.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Aug 6, 2024, at 6:18 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> Hi all,
> 
> I have read this document as well. Basically, I agree that it makes sense to have an "official solution" for experiments on user ports. Section 3 of the document looks good to me.
> 
> Regarding section 4, I wonder if some additional suggestions or examples could make sense to explain how PExIDs could be used. PExIDs are optional, and experiments may or may not be able to use it. But the document could possibly discuss a bit more how this mechanism could be used in typical cases. For instance:
> 
> - How PExIDs could be used if the TCP connection uses TLS. For instance, one potential alternative design would be to send PExIDs at the beginning of the application-byte-stream encrypted by TLS. Maybe there could also be ways to encode the PExID inside TLS (I am not a TLS expert). These potential alternatives may have downsides. But, for instance, maybe sending a PExID this way could be a better alternative to not sending a PExID at all?
> 
> - A similar question is if a PExID could be embedded somewhere in the application protocol itself, but not at the beginning (say, some optional application protocol option or the like). It means to achieve this would obviously be outside the scope of this document. 
> 
> - Another similar questions may apply to QUIC.
> 
> Section 6 does not discuss security implications of PExIDs. Even if the document focuses on experiments, it could be reasonable to discuss potential security and/or privacy issues, such as:
> 
> - Whether PExIDs could be used by Deep Packet Inspection (DPI), e.g., to detect protocols, and whether that differs to port numbers.
> 
> - Whether implementing PExIDs has any impact on other security protocols. For instance, are there any implications whenf PExIDs are sent before a TLS handshake? This usage pattern may be similar to STARTTLS, so maybe it just works fine? Or not? Anyway, it could make sense to expand on that, even if implementations are not required to use PExIDs.
> 
> Best regards
> 
> Michael
> 
> 
>> -----Original Message-----
>> From: Wesley Eddy <wes@mti-systems.com>
>> Sent: Monday, August 5, 2024 4:05 PM
>> To: tsvwg@ietf.org
>> Subject: [tsvwg] support last call for User Ports for Experiments
>> 
>> In the last meetings, the chairs asked for inputs on next steps for
>> draft-ietf-tsvwg-usr-exp (User Ports for Experiments).
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-usr-exp/
>> 
>> I've read this.  It is ready for working group last call, in my
>> opinion.  It seems useful to me to progress this, based on experiences
>> serving as an IANA ports reviewer.  I think it would likely make some of
>> our responses to port applicants simpler, as well as give those
>> applicants a clear direction forward, in cases where it makes sense.
>> 
>