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@xxxxxxxxx | +------------------------+--------------------------------------------+ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf