[tsvwg] Paul Wouters' Abstain on draft-ietf-tsvwg-usr-exp-12: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-tsvwg-usr-exp-12: Abstain

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/



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

I have balloted Abstain, as I would prefer that the multiplexer
defined in this document not be deployed.

The entire Introduction seems at odds with the last paragraph that
updates RFC 4727 which makes it unclear what problem is really being
solved. The update text talks about "short term or need more than one
port during development" while the rest of Section one talks about the
need for unprivileged ports that are not like dynamic ports by introducing
some port multiplexing system using IDs.

I am not convinced that running experiments requiring a demuxer that the
final protocol would not have is a good idea. Especially, if such a
protocol would also use (D)TLS. The document also lists STUN interactions.

Grabbing a "privileged port" on a Linux system or VM/container is also
not that hard anymore as it used to be when we all have logins on shared
unix servers. Grabbing a "user port" that is not a "system port" will
affect other common security mechanisms, for example SElinux, which might
allow a daemon to grab < 1024 but not > 1024, or allow things based on
policy labels, eg http_port_t. Expressing things like SElinux labels based
on multiplexing port numbers seems much harder to do and prone to failure.

I am not aware of large scale experiments that accidentally overlapped
with other large scale experiments. Having a group of say 10 consecutive
port numbers reserved for experiments sounds good. Doing hacks with
multiplexing over two ports does not seem like a solution people would
prefer over using some hardcoded set of ports - even if that technically
risks clashing with other experiments.