[tsvwg] Tommy Jensen's Discuss on draft-ietf-tsvwg-usr-exp-14: (with DISCUSS and COMMENT)

[Tommy Jensen via Datatracker <[e-mail]>]

Tommy Jensen has entered the following ballot position for
draft-ietf-tsvwg-usr-exp-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-usr-exp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting Discuss in case the overhaul I am requesting turns out to be
feasible, but right now my objections are fundamental to the current nature of
the document and its goal, and therefore my concerns likely cannot be
addressed. Should that be true and I am found in the rough, I will end up
balloting Abstain to get out of the way.

Introducing overlap avoidance as a protocol feature that applies to beta
deployments that does not apply to production is introduced complexity whose
only value is to provide a mechanism to quickly identify port collision. The
document asserts that this is problematic, but in my opinion does not
sufficiently justify that claim. For example:

> However, dynamic ports can be difficult to reserve in
> some systems or blocked from traversing some firewalls.

This is asserted but not explained or justified. In which systems are dynamic
ports difficult to reserve? As for dynamic ports being blocked over the public
Internet, an example used elsewhere in the document, this certainly isn't true
generally. In private networks where experiments are being run or the last mile
for over the Internet experiments, firewalls are likely to be under the control
of the same organization running the experiment, or are associated (such as the
IT and CS departments of a university). This can be solved with human
coordination. Host firewalls should never be a problem given computers
participating in an experiment should be administered by the experiment
conductors.

Also, if this standard is deployed, the firewall problem will be re-introduced
by any network that is willing to block dynamic ports which will certainly want
to block these ports also. Therefore, I do not see that there is any way to
make experiments easier to traverse unknown firewalls practically even with the
best of intentions. If there was a way to do that, we would consider it a
security problem (therefore I support the DISCUSS positions that mention this,
I just do not believe it can be addressed without fundamentally writing a whole
new document).

Furthermore, Section 4 has several RFC 6919 type of requirements, describing
which kinds of experiments need this versus not. This is one example:

>    PExIDs SHOULD NOT be used for classroom assignments or training-
>    related experiments; in those cases, dynamic ports are more
>    appropriate.

Why? I'm quite confident people will ask an AI how to do experiments, find this
document, and use it without caring. Per IESG guidance, SHOULDs need to explain
what the conditions for acceptable skipping of implementation are, which in
this case would explain why some experiments need this mechanism and some need
to not use it. While that would be actionable DISCUSS feedback, my response
here is that defining a mechanism for allowing experiments to share ports that
require a new type of transport channels that are only for some kinds of
experiments is destined to be misused from day one. This concern could be
addressed if the document stayed away from delineating right and wrong
experiments, but then I don't know if that's ok because I don't understand

> The creation of new ports for experiment purposes does not create
> any new security considerations.

Yes, it does. It is exactly trying to make unknown firewall traversal easier.
The document points out firewalls and other stacks do not support this and
therefore experiment implementors are responsible for implementing proper
security controls (yet more burden on experimenters unrelated to their actual
project or final production version). This won't remain true if this standards
is in use, and once these stacks do support this, one of two things is true:
(1) they do not block this, in which case the concern stands, or (2) they do
block this, and then the document failed to achieve its own goal.

I do not believe the problem is as painful as described, I do not believe the
solution can actually alleviate the pain that is there once deployed, and I do
not believe the fundamental goal of this document can be achieved in a secure
fashion. I think this is a well-intentioned idea to solve a minor problem that
over-engineers a solution that introduces new problems without adequately
solving the original minor problem.

In the spirit of DISCUSS, the changes that would help are additions of problem
justification and explanations for the normative requirements in Section 4.
However, this document also needs to address the security model in much greater
detail, as "does not create any new security considerations" definitely isn't
accurate.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support all current Discuss positions (Deb, Ketan, Mike, Med).