[tsvwg] Re: draft-ietf-tsvwg-usr-exp-10 ietf last call Genart review

["[e-mail]" <[e-mail]>]

Hi, Tim,

Thank you for the review. Some comments below.

Joe

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

> On Aug 6, 2025, at 7:03 PM, Tim Evens via Datatracker <[e-mail]> wrote:
> 
> Document: draft-ietf-tsvwg-usr-exp
> Title: User Ports for Experiments
> Reviewer: Tim Evens
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
> 
> Document: draft-ietf-tsvwg-usr-exp-??
> Reviewer: Tim Evens
> Review Date: 2025-08-06
> IETF LC End Date: 2025-08-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> Overall the draft is well written and addresses an issue with developer use of
> layer 4 ports (UDP, TCP, ...) that may have otherwise been privileged or
> disallowed by security control points. The draft aims to standardize a range of
> user ports for experimental (aka developer) use, starting with two ports, that
> supports multiplexing to scale the usage of the user ports. I like the
> simplistic multiplexing approach using a single 4-byte PExID, but I am
> concerned that the simplistic method may not scale to future requirements that
> may need some flags or additional TLVs.

FWIW, the approach is an extension of the IANA ports numbers. Although additional flags or TLVs may be useful to differentiate uses of a port, they are not currently part of how transport protocols use ports, and appear to be premature to consider in this document.

> Major issues:
> None
> 
> Minor issues:
> 
> There are developer use-cases, especially within labs, that need help from the
> network infrastructure to ensure traffic does not leak out of contained
> labs/etc.  Security inspection points, such as a firewall, are used to catch a
> leak and filter it. I see this basic requirement missing for containment of
> developer/experiment user ports and PExIDs from being leaked out. There is no
> indication to the FW that it should drop or allow the packet based on PExID.

PExIDs extend the IANA port space. There is no similar indication in the port space itself. Even the distinction between System and non-System assignments has become ineffective and inaccurate, as noted in RFC 7605. Sec 7.9.

> Suggest to define a PExID range for IANA to be used where no registration will
> exist. If there is no registration, I would tend to expect that packets would
> not be allowed outside of containment (aka LAB, local, ...). In other words, no
> public internet or corporate network access allowed within this PExID range. 
> If there is a registration, maybe that should indicate scope of where these
> packets should be forwarded... Might make sense to define a range for some
> basic scopes, such as allowed within LAB only, allowed within
> local/enterprise/campus, allowed everywhere including internet.  I don't
> believe this needs to go into the weeds of authorization... There is a
> pre-established trust with the experimental user-ports and PExIDs.   These
> scopes are more of a safe guard to prevent accidental leakage of traffic that
> should have not been allowed out of an experiment/lab.

This assignment is primarily intended to reduce squatting. 

Current ports - both assigned and ’squatted - have no such capability, nor do the self-assigned ranges. This document is not intended to address that issue, nor might it even be possible to address, given the “genie is already out of the bottle” for all other cases.


> Nits/editorial comments:
> 
>