Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02

[Fernando Gont <[e-mail]>]

On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <[e-mail]> wrote:

>>   The Port Number registry is heavily constrained by the 16-bit
>>   namespace available, with the additional pressure resulting
>>   from the security critical need for client port randomization
>>   to only assign as few as possible additional port numbers.
>
> Randomization doesn't come into play here, because it's used for the source
> ports, whereas the registry is for destination ports.

Ephemeral ports (and randomization) do come into play.

See Section 10.2 of the d. ocument "Security Assessment of the
Transmission Control Protocol (TCP)" (available at:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf)
published by UK CPNI (or its IETF I-D counterpart
draft-gont-tcp-security).

This is an excerpt of the aforementioned document, for your convenience:

---- begin excerpt ----
10.2. Active opens and binding sockets

As discussed in Section 10.1, the “OPEN” command specified in Section
3.8 of RFC 793
[Postel, 1981c] can be used to perform active opens. In case of active
opens, the parameter
“local port” will contain a so-called “ephemeral port”. While the only
requirement for such an
ephemeral port is that the resulting connection-id is unique, port
numbers that are currently in
use by a TCP in the LISTEN state should not be allowed for use as
ephemeral ports. If this
rule is not complied, an attacker could potentially steal” an incoming
connection to a local
server application by issuing a connection request to the victim
client at roughly the same time
the client tries to connect to the victim server application. If the
SYN segment corresponding to
the attacker's connection request and the SYN segment corresponding to
the victim client
“cross each other in the network”, and provided the attacker is able
to know or guess the
ephemeral port used by the client, a TCP simultaneous open scenario
would take place, and
the incoming connection request sent by the client would be matched
with the attacker's
socket rather than with the victim server application's socket.
As already noted, in order for this attack to succeed, the attacker
should be able to guess or
know (in advance) the ephemeral port selected by the victim client,
and be able to know the
right moment to issue a connection request to the victim client. While
in many scenarios this
may prove to be a difficult task, some factors such as an inadequate
ephemeral port selection
policy at the victim client could make this attack feasible.
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.
An implementation might choose to relax the aforementioned restriction
when the process or
system user requesting allocation of such a port number is the same
that the process or
system user controlling the TCP in the CLOSED or LISTEN states with
the same port number.
---- end excerpt ----

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1