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.
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:
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
