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, :-)
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
