Subject: Re: [tsvwg] AD review: draft-ietf-tsvwg-port-randomization-05

From: Fernando Gont <[email-masked]>
Date: Tue, 05 Jan 2010 10:41:38 -0300

Hello, Lars,

> any progress on this?

I have already applied all the nits you found, and have also asked a
couple of people to comment on the SCTP-specific stuff. Have almost
finished my follow-up to your e-mail.

Sorry it has taken me a while to respond -- Seasons delayed my work on
this more than expected.

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 Jan 2010 21:55:38 -0300

Hello, Lars,

Thanks for your review. Comments in-line (I have omitted the nits, which
have been fixed).

> It would be good to find a more precise title. Maybe "Transport 
> Protocol Port Randomization Recommendations" or something along those
>  lines?

I have no issues with your proposed title. Unless I receive any
objections or alternative proposals for the title, I will apply the one
you have suggested.

FWIW, how about "Recommendations for selecting ephemeral ports in
transport protocols"?

> Section 1., paragraph 1:
>> Recently, awareness has been raised about a number of "blind" 
>> attacks (i.e., attacks that can be performed without the need to 
>> sniff the packets that correspond to the transport protocol 
>> instance to be
> 
> By "instance" you mean "connection"? I'd mildly prefer to use 
> connection, esp. since you don't use the term "instance" consistently
>  in the document anyway.

"instance" is more generic ("connection" implies connection-oriented
protocol)... and port randomization has been relevant for connectionless
protocols, too, . e.g., it has received its share of attention as a
result of the Kaminsky vulnerabilities found a couple of years ago.
That's why, if possible, I'd prefer to try to use the term "instance"
consistently.

> Section 1., paragraph 6:
>> This document describes a number of algorithms for the selection of
>>  the ephemeral ports, such that the possibility of an off-path
> 
> Wording. s/the ephemeral ports/an ephemeral port number for a 
> connection instance/

I changed it to "of algorithms for the selection of ephemeral port
numbers"  ("connection" is a CO-protocol specificl... )

> Section 1., paragraph 8:
>> The mechanisms described in this document are local modifications
> 
> Nit: s/local/local, sender-side/

Sender-side sounds a little bit confusing to me. One might change it to
"*client* side"... but then some protocols (notably FTP) use ephemeral
ports on the server side. So I left this one "as is" (please yell if you
feel strongly about this change).

> Section 2., paragraph 0:
>> 2.  Ephemeral Ports
> 
> I don't really understand the purpose of Section 2. Almost all 
> content is again covered in Section 3.

It provides an introduction to ephemeral port selection algorithms. It
describes the traditional BSD ephemeral port selection algorithm, a
number of issues (e.g., collisions of connection-id's that are relevant
for any ephemeral port selection algorithm (even non-random ones))

> Section 2.1., paragraph 5:
>> The range for assigned ports managed by the IANA is 0-1023, with 
>> the remainder being registered by IANA but not assigned.
> 
> This is from the IANA web page, but I think it's actually incorrect. 
> IANA manages the entire range 0-65536, and makes assignments in the 
> 0-49151 range, with the 49152-65536 range being unassignable.

IIRC, ports in the range 1024-49151 are not assigned. IANA just
registers their use (i.e., what port is being used, and what for).

> Section 2.1., paragraph 6:
>> The ephemeral port range defined by IANA has traditionally 
>> consisted of the 49152-65535 range.
> 
> Not only "traditionally" - it is still defined to be that range.

Isn't this implied in the sentence? (i.e., the text says "has..." rather
than "was...").

Anyway... how about something along the lines of "IANA defines the
'dynamic ports', consisting of the range 49152-65535, which is meant for
the selection of ephemeral ports".

> Section 2.2., paragraph 6:
>> if (five-tuple is unique) return port;
> 
> This syntax doesn't really make it clear that the "five-tuple is 
> unique" check uses is done with "port" as the candidate ephemeral 
> port. (Also elsewhere.)

I couldn't parse your comment. Do you mean we should clarify what we
mean by "five-tuple", or what?

> Section 2.3., paragraph 0:
>> 2.3.  Collision of connection-id's
> 
> What is a connection-id? Hasn't been defined so far and isn't defined
>  in this section either.

It's a short-hand for "five-tuple"... But now I realize that
"connection-ID" would imply "connections" (i.e., CO protocols). So...
maybe I should change this to "instance-id"? (as a short-hand... and
provided I have defined the term first, of course).

> Section 2.3., paragraph 3:
>> Another possible approach to minimize the rate of collisions of 
>> connection-id's would be for both end-points of a TCP connection to
>>  keep state about recent connections (e.g., have both end-points 
>> end up in the TIME-WAIT state).
> 
> I wouldn't call this a "possible" approach. It has significant 
> drawbacks that make it unsuitable for real deployments (state 
> explosion at servers). It's at best a strawman.

Completely agree with your pov. -- I just added this one in response to
wg feeedback/request. However, this approach *is* implented by Cisco IOS.

> Section 3.1., paragraph 10:
>> Port numbers that are currently in use by a TCP in the LISTEN state
>>  should not be allowed for use as ephemeral ports.
> 
> This policy is TCP-specific. Can we broaden this to other transport 
> protocols?

I'm working on text on SCTP.... (Short answer: SCTP does not allow an
app to bind() an already-bound port number, unless a specific socket
option is previously issued). TCP does not preclude this (its API
specification is much more abstract).

> Section 3.1., paragraph 13:
>> It should be noted that most applications based on popular 
>> implementations of TCP API (such as the Sockets API) perform 
>> "passive opens" in three steps.  Firstly, the application obtains a
>>  file descriptor to be used for inter-process communication (e.g.,
>>  by issuing a socket() call).  Secondly, the application binds the
>>  file descriptor to a local TCP port number (e.g., by issuing a 
>> bind() call), thus creating a TCP in the fictional CLOSED state. 
>> Thirdly, the aforementioned TCP is put in the LISTEN state (e.g., 
>> by issuing a listen() call).  As a result, with such an 
>> implementation of the TCP API, even if port numbers in use for TCPs
>>  in the LISTEN state were not allowed for use as ephemeral ports, 
>> there is a window of time between the second and the third steps in
>>  which an attacker could be allowed to select a port number that 
>> would be later used for listening to incoming connections. 
>> Therefore, these implementations of the TCP API should enforce a 
>> stricter requirement for the allocation of port numbers: port 
>> numbers that are in use by a TCP in the LISTEN or CLOSED states 
>> should not be allowed for allocation as ephemeral ports [CPNI-TCP]
>>  [I-D.gont-tcp-security].
> 
> This is again entirely about TCP. Do similar issues not exist for 
> other transport protocols?

Same as above (working on text, and same "short answer").

> Section 3.2., paragraph 1:
>> As mentioned in Section 2.1, the ephemeral port range has 
>> traditionally consisted of the 49152-65535 range.
> 
> It *still* consists only of that range.

How about "the port range defined by IANA to be used for the ephemeral
ports consists..."?

> Section 3.2., paragraph 2:
>> However, it should also include the range 1024-49151 range.
> 
> You're mixing two things here: (1) the ranges for which IANA has 
> different allocation rules for and (2) which range the host should 
> randomize over. I understand that you want to say that (2) should be 
> larger than the ephemeral range in (1), but that is *not* the same as
> making the ephemeral range larger.

Well, IIRC, IANA does not use the term "ephemeral ports". So, if that's
the case, the "dynamic port range" is the rannge for which IANA has
"different allocation rules", while "ephemeral port range" is the range
that's actually used for outgoing connections. (even with this reasoning
in mind, I realize the text should be tweaked).

> Section 3.2., paragraph 3:
>> Since this range includes user-specific server ports, this may not 
>> always be possible, though.
> 
> It doesn't just include "user specific server ports" - it includes 
> ports that IANA has assigned.

Would rephrasing the text as "... it includes user-specific ports and
port numbers registered by IANA..." address the issue you have raised?
(note my s/assigned/registered/)

Anyway, I don't think one should care about a port number that has been
registered by IANA, but rather about services that are expected to be
run by the system in question. e.g., my OpenSolaris system should
probably not care about the fact that some specific port has been
registered/assigned_to a MS-Windows-specific service.

> Section 3.2., paragraph 5:
>> Transport protocols SHOULD use the largest possible port range, 
>> since this improves the obfuscation provided by the ephemeral port 
>> selection algorithms.
> 
> s/Transport protocols SHOULD use/Port randomization algorithms SHOULD
>  randomize over/ and remove the redundant part after "obfuscation."

I have changed the text to "Ephemeral port selection algorithms SHOULD
use the largest possible port range, since this improves the obfuscation
when proper obfuscation algorithms are employed". Please let me know if
this is good enough.

> Section 3.3.1., paragraph 2:
>> next_ephemeral = min_ephemeral + (random() % num_ephemeral);
> 
> You need to say somewhere what you expect random() to return.

I used random() as C's random() function. Please let me know if you
still think I should clarify this.

> Section 3.3.1., paragraph 14:
>> This algorithm selects ephemeral port numbers randomly and thus 
>> reduces the chances of an attacker of guessing the ephemeral port 
>> selected for a target connection.  Additionally, it prevents 
>> attackers from obtaining the number of outgoing connections 
>> established by the client in some period of time.
> 
> It sounds like you should move this paragraph up to the beginning of 
> this discussion.

Each section provides this "summary at the end of the section" (that's
just how we have structured the document). Unless you feel strongly
about this, I'd leave the text as is (just to avoid shuffling the
document at this point in time).

> Section 3.3.3., paragraph 1:
>> We would like to achieve the port reuse properties of the 
>> traditional
> 
> When you say "we would like <x>" a number of times in this section, 
> it's not clear if you mean "it could be beneficial to have one 
> algorithm with property <x>" or "we would like <x> for all 
> algorithms." I assume the former, but it's not clear and can be 
> better phrased.

I think that that depends on the context. e.g.:

> We would like to achieve the port reuse properties of the traditional
>  BSD port selection algorithm (described in Section 2.2), while at
> the same time achieve the obfuscation properties of Algorithm 1 and 
> Algorithm 2.

means that those properties would be beneficial in every obfuscation
algorithm.

OTOH,

> Ideally, we would like a 'next_ephemeral' value for each set of 
> (local IP address, remote IP addresses, remote port), so that the 
> port reuse frequency is the lowest possible.

discusses how those properties could possibly be achieved by tweaking
the traditional BSD ephemeral-port selection algorithm.

Nevertheless, I will try to tweak the text to address this issue you
have raised.

> Section 3.3.3., paragraph 15:
>> The local IP address and remote port may in some cases be constant
>>  and not improve the connection separation, however, they should 
>> also be included in the offset calculation.
> 
> What do you mean by "separation"?

I s/connection/ephemeral port space/

Separation means that while the port range is still the same,
connections to different endpoints make independent use of that range
(the idea of "separation" was already described in RFC1948)

> Section 3.5., paragraph 5:
>> The algorithm sketched in Figure 1 is the traditional ephemeral 
>> port
> 
> It's a bit confusing to refer to one algorithm by "Figure 1" and to 
> another *different* one as "Algorithm 1". I suggest to remove the 
> "Figure X" title from all figures and instead refer to all algorithms
>  by a unique number.

I kept the titles, but replaced any references made using figure numbers
(I replaced them with references to the relevant *section* numbers).

> Section 3.5., paragraph 7:
>> Algorithm 1 and Algorithm 2 have the advantage that they provide 
>> complete randomization.
> 
> Don't understand what you mean by "complete randomization".

I changed that sentence to "Algorithm 1 and Algorithm 2 have the
advantage that they provide actual randomization of the ephemeral ports."

With "actual randomization" we were meaning that these two algorithms
actually randomizae the ephemeral pots, whereas other algorithms
obfuscate the port numbers, but do not actually "randomize" the sequences.

> Section 3.5., paragraph 9:
>> Algorithm 3 provides complete separation in local and remote IP 
>> addresses and remote port space, and only limited separation in 
>> other dimensions (see Section 3.4).
> 
> Don't understand what you mean by complete and limited "separation".

Complete separation: both in terms of the destination-endpoint and the
increments.

Partial separation: only in terms of the destination-endpoints. But all
connections share the same counter variable for providing the increments.

> Section 4., paragraph 1:
>> Network Address Port Translation (NAPT) translate both the network 
>> address and transport-protocol port number, thus allowing the
> 
> *source* address and *source* port

mmm... I think that would be misleading: that depends on the direction
of the packets.

> Appendix A., paragraph 0:
>> Appendix A.  Survey of the algorithms in use by some popular 
>> implementations
> 
> It would be useful to add which *version* of the operating systems 
> below you looked at.

-current, at the time of writing. But will update the document as suggested.

Hope we can close this issues soon to move the document forward.

Thanks so much for your detailed review!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 10 Jan 2010 21:55:38 -0300

Hello, Lars,

OTOH,

Kind regards,