I agree with Eddie's note that the API and user guidelines have not been
specified for DCCP - this is probably one reason for the small number of
responses.
I also agree that the difference between server and client functions in
DCCP make port randomization less important/undesirable for the DCCP server.
I looked at the new text in rev -06 looks like it may be appropriate. I
note that you used "should not" rather than "SHOULD NOT" - was that
intentional, and if so, why.
Gorry
I've looked at the new
Fernando Gont wrote:
Hello, folks,
I'm trying to finish a rev of the port-randomization I-D. The only
remaining bit is the DCCP-specific text. It'd be great if any you could
help me with closing these remaining bits...
Comments in-line...
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 think this could be possible for DCCP - but one also needs to be aware
of the role of service codes here. Two or more server apps could use a
different DCCP Service Code value and also be bound to the same server
port(s). See also section 3.3.1 of RFC 5595.
Question: If I understand the DCCP text, port-numbers are kinda a first
level of demultiplexing. Once you demultiplex an incoming based on the
DCCP destination port, you demultiplex it according to the service code.
Is this correct?
Now, assuming the above is correct:
Say an app binds {IP: INADDR_ANY, Port: X, SC: Y}.
Is it possible for another socket to bind() {IP: Z, Port: X, SC: Y}?
Does the spec prevent this? (e.g., is the first socket required to
setsockopt() something like SO_REUSE_PORT for the socket layer to allow
a another socket to re-bind() the same Port and SC?
And, if all this is possible, does the second (more specific) socket get
an incomming connection if the destination socket is {IP: Z, Port: X,
SC: Y)?
If all this is true, then the "requirement" for port randomization would
be that pair {Port number, SC} that is in use (no matter whether it's in
use with a specific IP address or with INADDR_ANY) SHOULD NOT be
considered for ephemeral port selection.
Last question: Is there anything like a "catch-all" for service codes?
(e.g., an app binds port X, and want to accept any incomming connections
to Port X, no matter what the service code is).
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.
Good.
Do you think I should add any text to clarify this, or would it be okay
to leave the doc "as is"? (I'd argue the later, as all these algorithms
assume that the client has not explicitly selected any port number, but....)
Thanks so much, :-)
--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.
