Greetings, I'm opposed to the suggestion to define PExID ranges that are tied to forwarding scopes. It seems to me that would bring in the need for an expert review to verify that the requested range is correct for the intended use. Much better to leave the issue of containment to a particular domain as a local matter and stick with a simple first-come, first-served registration policy.
Mike Heard 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. > > 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. > > 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. > > Nits/editorial comments: > > >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
