Gorry Fairhurst
Sat, 30 Jan 2010 03:33:01 -0800
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:
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.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).
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.
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.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 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