Here are the most important LC comments I have to make for
draft-ietf-tsvwg-port-randomization-06 .
This document seems almost ready for publication, and I full-heartedly
support its publication.
(1) Fundamental, general issue: Terminology
A few voices have caused the authors to adopt a rather questionable
terminology throughout the draft, during its last few revisions.
- "Randomization" : My 5-vol. Dictionary of Mathematics defines
(translated into English): Randomization; Randomized Algorithm:
The introduction of randomness into mathematical algorithms.
In practice, pseudo-random numbers are used.
- "Obfuscation" denotes a kind of camouflage, or in communications,
"the poor man's" cryptography.
ROT13 is a famous obfuscation method operating on the latin alphabet.
In military and diplomatic communications, written or spoken language
has been obfuscated for decades or centuries (or even more) by the
use of 'dictionary' tables to replace "important" word (nouns, verbs,
adjectives) by apparently nonsensical other words that the recipient
decoded by use of the inverted dictionary table he kept secret;
for instance "acre" might have been used for "weather forecast",
"copper" for "rainy weather", and "Ibiza" for "snowfall".
In general, in the history of secret communications, the term
obfuscation has been used to indicate a transformation from a given
(source) domain, an "source alphabet", into another domain (target
alphabet) that can be easily inverted -- typically by a human --
by means of a small portion of additional knowledge (decoding rule,
dictionary).
Accordingly, in Government and Military environment, authorization
and access to obfuscation techniques and encryption apparatus
traditionally has been based on *different* clearance levels.
This draft clearly deals with the random selection of (client) port
numbers, i.e. the randomization of port numbers.
These port numbers are transmitted unchanged (in the clear) over the
wire; no transformation is needed to make use of them at the recipient.
Hence, the phrase "obfuscation of port numbers" is extremely misleading.
The draft describes 'cheap' methods for achieving almost perfect
randomization (more precisely: having almost the same impact on the
capability of off-path attackers as a perfect random-choice algorithm),
without having to use a costly (and slow) crypto-grade random number
generator at every request to allocate an ephemeral port number.
The most important task of such algorithms is to make it nearly
impossible for attackers that can observe (potentially large)
samples of this random port number generator's output by getting in
direct communication with the target system to infer future port
number use in communications of the target system with another system,
i.e. to ensure that predictability based on partial knowledge is
minimized.
Therefore, the only context where the term "obfuscation" might be
justified in this draft is where it is not directly tied to data
communication, for instance where it is used to denote properties
of the node behavior that make it unfeasible to infer the detailed
operation (state) of the port number generator, i.e. measures to
"obfuscate" the details of the algorithm and its internal state for
the external observer; that is: "obfuscation of the algorithm"
seems acceptable.
I therefore request that these inappropriate changes in terminology be
backed out again. "Port number obfuscation" is a serious misnomer;
port numbers still are transmitted in the clear under the methods
presented in this draft; so "port number randomization" or, for short,
"port randomization" is the proper term -- and it is widely adopted
by the community since several years.
(2) Abstract, last sentence
The new elaborations on RTP seem to be inappropriate.
RTP isn't a "classical" transport protocol.
RFC 3550 says (Section 11, 2nd para):
"RTP relies on the underlying protocol(s) to provide demultiplexing of
RTP data and RTCP control streams. For UDP and similar protocols, ..."
The SDP 'proto' registry at http://www.iana.org/assignments/sdp-parameters
currently list roughly 20 transport profiles for RTP, with (mostly)
UDP, TCP, and DCCP as the underlying transport protocol.
(RFC-to-be 5762 for RTP/DCCP is expected to be published soon.)
Further, RFC 3550 and the various RTP profiles entail rules for coupling
the port pairs used for RTP and RTCP; RTP ports are almost *always*
signaled (using SDP), and traditionally only one of the ports in an
even/odd port pair (according to RFC 3550) has been signalled.
RFC 3605 is needed for decoupling the RTCP port numbers from the RTP
port numbers and signal these independently using SDP.
RFC 4961 is needed for "full-duplex" (symmetrical) use of the transport
(thus converting the any-port-to-receiver-port model of RFC 3550 to a
local-port-to-remote-port model for both RTP and RTCP transport).
Mostly recently, RFC-to-be 5761 specifies the use of a shared port number
(on each side) for RTP and RTCP.
Thus, the note on RTP port usage seems to misrepresent RTP as a transport
protocol using port numbers of its own and overly simplifies the rather
complicated situation regarding transport protocol port number usage.
Therefore, I suggest to drop the clause on RTP entirely:
[...]. The
algorithms described in this document are local policies that may be
incrementally deployed, and that do not violate the specifications of
any of the transport protocols that may benefit from them, such as
| TCP, UDP, UDP-lite, SCTP, DCCP, and RTP (provided the RTP application
| explicitly signals the RTP and RTCP port numbers).
---
[...]. The
algorithms described in this document are local policies that may be
incrementally deployed, and that do not violate the specifications of
any of the transport protocols that may benefit from them, such as
| TCP, UDP, UDP-lite, SCTP, and DCCP.
^^^^^ ^^^
(3) Abstract and Section 1 (1st para)
"Recently, awareness has been raised ..."
^^^^^^^^
The same words had been written in the first draft version in 2006.
For not overstressing the word "recent" too much, I suggest to change
that to:
"During the last few years, awareness has been raised ..."
^^^^^^^^^^^^^^^^^^^^^^^^^
(4) Section 2.1
There is ongoing confusion on the role of the IANA managed port number
range. This is caused by the lack of distinguishing between the roles
of ports -- server ports ((semi-)static port numbers used to 'listen')
vs. client ports (ephemeral choice for activating a transport session
with a 'listening' peer). In certain 'symmetric' protocols (peer-to-
peer applications) without out-of-band agreement on port numbers,
both communicating parties are to be regarded as taking the 'server'
role, and for these the document is not applicable.
To avoid the above confusion, I strongly suggest to clarify that the
IANA registry *only* deals with *server port numbers*.
First paragraph of 2.1:
The Internet Assigned Numbers Authority (IANA) assigns the unique
parameters and values used in protocols developed by the Internet
| Engineering Task Force (IETF), including well-known ports [IANA].
[...]
---
The Internet Assigned Numbers Authority (IANA) assigns the unique
parameters and values used in protocols developed by the Internet
| Engineering Task Force (IETF), including well-known server ports
[IANA]. [...]
^^^^^^
With this clarification, it should become evident that the use of
arbitrary port numbers as ephemeral port numbers on a particular node
does not conflict with the IANA registry, unless the same port number
is in use by a (listening) server application on the same node.
The last paragraph of 2.1 is not backed by RFC 1122 (cf. sect. 4.2.2.1).
Wrt the IANA Port number registry, Dynamic / Private Ports are simply
those ports that are recommended for *server* programs that want to
dynamically bind to a port they are listening on afterwards.
Neither the TCP standard nor STD 3 contains verbiage to globally
constrain port usage as ephemeral (client) ports.
Therefore, IMO the last paragraph of 2.1 should be deleted or changed
as follows:
The dynamic port range defined by IANA consists of the 49152-65535
| range, and is meant for the selection of ephemeral ports.
---
The dynamic port range defined by IANA consists of the 49152-65535
| range; it is meant for the dynamic selection of server ports and is
| unrelated to ephemeral port selection, although this interpretation
| has been promoted in the past.
Long-standing practice of major operating systems (in particular the
use of 'low' port numbers as ephemeral port numbers, on all BSD-derived
systems and others) has shown that this interpretation makes sense and
has been assumed since the early days of TCP/IP, and that it did not
incur any trouble for TCP/IP based networks. Thus, the recommendation
stated later in the draft, to make the effective port range used for
ephemeral port number selection as large as possible, does not collide
with previous art.
(5) General
A few editorial nits will be reported to the authors off-list ASAP.
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf