Subject: Re: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Mar 2010 02:04:54 -0300

(added CC to tsvwg)

Hello, Alfred,

Thanks so much for your feedback! Comments inline....

> (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.
[....]
> 
> 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.

I really don't know how to proceed here. That is, I'd honor your
comment, but clearly that's not just up to me. What do the chairs and
ADs think?

> (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, ..."
[...]
> 
> Therefore, I suggest to drop the clause on RTP entirely:

FWIW, Dan Wing suggested this as one of the possible ways forward for
the RTP issue. So unless anybody disagrees I will apply your prosed change.

> (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 ..."
>    ^^^^^^^^^^^^^^^^^^^^^^^^^

Fixed.

> 
> (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.

Ok. Given that the port numbers issue has been debated recently, I'd
like Lars to comment on this proposed change.

> 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.

Your suggested change makes sense to me. But as with the previous one,
I'd like to hear what Lars thinks about this one.

> (5)  General
> 
> A few editorial nits will be reported to the authors off-list ASAP.

Looking forward to them!

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 03 Mar 2010 00:12:11 -0600

>comment, but clearly that's not just up to me. What do the chairs and

Fernando and Alfred

"randomization" in computing -- at least to me -- requires or 
necessitates a randomizer (pseudo or not), which this document 
doesn't attempt to specify or produce, so I'll have a hard time 
getting by this recommendation of yours.

FWIW -- this was a specific point of discussion within the TSVWG, and 
not just a passing comment. We discussed this at length during a 
meeting, and in email with the ADs involved.

My co-chair ought to chime in here if he feels strongly one way or the other.

James
<with my TSVWG chair hat on>

>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 03 Mar 2010 09:25:11 +0000

I'll just respond on RTP here...

On 03/03/2010 05:04, Fernando Gont wrote:

<snip>

> the RTP issue. So unless anybody disagrees I will apply your prosed change.

To me, it would seem OK to see RTP removed from the Abstract.

I would though very much prefer to see it still described in the draft, 
since it is an example of an important transport "layer" that is 
impacted by the methods described in the draft. You may like to think 
whether to break the sentence at the end of the introduction into two, 
with the final part something like:

This may also benefit protocols layered on transport protocols, such as 
RTP [RFC3550] (provided the RTP application explicitly signals the RTP 
and RTCP port numbers with e.g.[RFC3605]).

Gorry

---

From: Mark Allman <[email-masked]>
Date: Tue, 09 Mar 2010 15:59:30 -0500

> > 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.

I dunno exactly why we're still talking about this it seems a little
late in the game to worry about the nitty gritty of terminology.  The WG
had its consensus and passed this document along.  

Alfred is right that "obfuscate" is not be quite right (although I don't
think "serious misnomer" is even close to an appropriate
characterization), but "random" is not quite right either (some of these
algorithms just aren't).

I think this all comes down to the viewpoint you want to take and I
think Alfred is taking a different viewpoint than the document.  If you
are viewing this as somehow hiding the port number from all parties
outside the involved end hosts then nothing in this document obfuscates
the port number at all, as Alfred notes (its still in the clear).  On
the other hand, if you take the point of view of the document that this
offers a bit of protection against those that cannot see the packets but
can guess communication patterns and try to attack those then the
processes discussed in the document produce unpredictable ephemeral port
numbers and therefore they are in fact 'obfuscated' to such blind
attackers.

I would personally just leave the obfuscation language as I think it is
more correct than the 'random' language and this has made it through the
WG and ultimately what we call it isn't as important as people using it.
This seems a minor point.  We don't have unanimous agreement, but
OK...we live with rough consensus.

Another path might be to re-phrase everything as 'unpredictable' ports.
As I sit here I sorta wish I had thought of that long ago as that
strikes me as a bit more correct than 'obfuscate' and certainly more
than 'random'.  

But, really, its a minor point.  Lets just someone decide and be done.

allman