Hello, Gorry, Thanks so much for your response. Comments in-line... > 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. So... in this case it seems the general motivation for port randomization still applies... right? >> 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. See Figure 8 (Page 32) of RFC 793. That scenario is unlikely to happen "by chance" (as the "client" is using an ephemeral port that the server doesn't know in advance). However, if the client port numbers are predictable (or, well, he could do it brute force, too), an attacker on the server-side could fake that scenario to hijack an incoming connection. So the question in this regard wrt DCCP would be: if there's a process "listening" for incoming connections (on, say "any IP address, port X"), and an attacker on the same host is allowed to bind() a more-specific socket (say, "IP address, port number X" or "IP address, port number X, service code Y") to steal an incoming connection request? > 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. Wouldn't the app bind() the port it wishes to use, rather than simply let the kernel select a port number for it? Unless the app requests a specific ports, IMO the app would be very non-portable (i.e., can you really depend on the underlaying ephemeral port selection algorithm for your app to work properly?). That said, the hash-based port-randomization algorithms do provide port numbers that are predictable by the destination endpoint, but at the same time are not predictable by an off-path attacker. (they use a RFC1948-like scheme... therefore the properties of the "algorithm" are the same as the ones of RFC1948 for ISN generation). > 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). As mentioned above, recommending port randomization (when the port number is selected by the kernel) doesn't preclude an app from bind()ing a specific port it wishes to use. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
