[tsvwg] Re: support last call for User Ports for Experiments
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Tue, 06 August 2024 13:18 UTC
Return-Path: <Michael.Scharf@hs-esslingen.de>
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 88964C1DA2F8 for <tsvwg@ietfa.amsl.com>; Tue, 6 Aug 2024 06:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=hs-esslingen.de
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 uhV9ZZ9v14M4 for <tsvwg@ietfa.amsl.com>; Tue, 6 Aug 2024 06:18:51 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2E4C169419 for <tsvwg@ietf.org>; Tue, 6 Aug 2024 06:18:50 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id C73F925A1D for <tsvwg@ietf.org>; Tue, 6 Aug 2024 15:18:48 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.1 mail.hs-esslingen.de C73F925A1D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=20240206; t=1722950328; bh=GaR2WhAUaErgRkQ31yeA/txUd9/RRS1rt16EX3gWDfk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=lHn5+VA/2sFoutiBitjXf/lb8j06QmZIr0Xa5NgOnnLm4mVb72N4aP1IdvELcNZny gLlAdW618AWI5Vx1gFQaaQqDIMHFyLPDeTCepDsOd0Oo5NZRysbZPH5CE7LaGWqfP+ kEEBEjkq3NUTc+StODiS6oCwWf4THDjIDOhsLr9p4+qOgMClzPgCbTIKigscHlascJ y5J6TArUtESpZUV96jyPAc8sPovTO9jNSMNyzThURgkL0we7W4mFfJNhP2AwVaEanZ /Cy0O6ZRtJI/pL+itnFjBVjbNKfD0jKBC2rjasQghGyy3p682faBSChg2y/KQvC6ze hA3B5qTHeWkuA==
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEdYO4OuuBUP for <tsvwg@ietf.org>; Tue, 6 Aug 2024 15:18:47 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for <tsvwg@ietf.org>; Tue, 6 Aug 2024 15:18:47 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 6 Aug 2024 15:18:47 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2507.039; Tue, 6 Aug 2024 15:18:47 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] support last call for User Ports for Experiments
Thread-Index: AQHa50CJ5MTuC1KEdk2Ks3BzxqxBZrIaC5ew
Date: Tue, 06 Aug 2024 13:18:47 +0000
Message-ID: <3573b4f88b424a428832b4b84db4254a@hs-esslingen.de>
References: <06f2434e-ed48-4b5f-8623-a567ebae9cee@mti-systems.com>
In-Reply-To: <06f2434e-ed48-4b5f-8623-a567ebae9cee@mti-systems.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.249]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: NKJPHQUQRJS67PFH6O5BQXFXT3KUHIES
X-Message-ID-Hash: NKJPHQUQRJS67PFH6O5BQXFXT3KUHIES
X-MailFrom: Michael.Scharf@hs-esslingen.de
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
X-Mailman-Version: 3.3.9rc4
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/Lfot9F7yj5fiHG4NeHEgdsMK2Cw>
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 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. >
- [tsvwg] support last call for User Ports for Expe… Wesley Eddy
- [tsvwg] Re: support last call for User Ports for … C. M. Heard
- [tsvwg] Re: support last call for User Ports for … Scharf, Michael