Pasi, Fernando - here are my thoughts... but I'd also encourage emails
from others in the DCCP WG, so please do "chime-in" if you agree or
disagree!
DCCP adopted an architecture that uses ports in a way that resembles
their use in TCP, but is more flexible. As in TCP, the initial sequence
number provides the primary method to protect from off-path attacks.
On 28/01/2010 21:47, Fernando Gont wrote:
Hello, folks,
Our port randomization I-D (draft-ietf-tsvwg-port-randomization) has
been shipped to the IESG.
Lars reviewed the I-D (see the current thread on the tsvwg mailing-list:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg09679.html), and
asked a how a few specific issues would apply to transport protocols
other than TCP. So I'm posting the questions here in the hope that some
of you might know the answer and be so kind to help (see bellow).
The current Linux implementation of DCCP uses the socket API, using a
different socket type and adding support for the Service Code (RFC
5595). Section 2.1 of 5595 mentions the choice of the emphemeral port -
and suggests that DCCP can also utilise port randomisation aa a valid
way of choosing ephemeral ports.
A listening DCCP server process is bound to both a server-port AND a
service code(SC) (RFC 5595, section 3.3). As such in DCCP, an attacker
would need to guess not only the ports but also the SC. If well-known
ports are used, then I do not expect the SC mechanism to generally
provide additional protection, since this would normally make the SC
well-known.
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 to prevent an attacker from shijacking an incoming connection by
binding a port number on which a process is LISTENning for incoming
connections, and simulating a "simultaneous open" scenario). Are there
similar issues for DCCP?
The base specification of DCCP defined in RFC 4340 does not provide a
method equivalent to the simultaneous open method of TCP. An update to
DCCP, specified in RFC 5956 added support for the DCCP-Listen packet.
This assists DCCP applications to communicate through middleboxes in a
way similar to the TCP Simultaneous-Open method.
The port randomisation procedure says on paged 10:
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 [CPNI-TCP]
I think this particular attack may not apply to DCCP. If I understand
this right, the TCP attack above plays on the feature that TCP can send
an Open packet in both directions. In DCCP, this is not so. The server
and client state machines are different - at the transport level, the
client decides the ports it wishes to use, hence the need to explicitly
provide a new packet type to support simultaneous open in RFC 5596.
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].
Are there similar issues for DCCP?
I suspect the operation may be different.
Without trying to think of all possibilities, although it seems to me
that if DCCP used the same emphemeral port method as TCP, the result
would also be OK for DCCP.
Thanks so much!
Kind regards,
>
I'd like to make a note about both UDP and DCCP: There probably are
specific cases where port randomisation would interact with other specs.
Here is an example: Header compression could be a concern for DCCP
applications targeting multimedia over wireless, where predictable use
of port numbers could offer a little advantage. In some cases neither
port will be well-known and there is the case of so-called "symmetric"
RTP, where both ports are the same. I'm not saying any of these are a
show-stopper, far from it, I would have noted that earlier if I had
thought so - it is just a reminder that datagram protocols can have
different needs.
So, I think it is possible that an implementor could choose a DCCP
design at the client that uses different rules to those that will be
specified in this BCP for TCP - especially since SCs increase the
flexibility in using ports (as Pasi mentioned - this can include sharing
well-known ports between Apps).
In summary, my suggestion would be that *IF* DCCP doesn't need to do
something different, we should recommend a method that follows the
"normal" behaviour for TCP - we should not mandate a DCCP client to use
this.
Hope that helps.
Gorry
