Re: [secdir] Secdir review of draft-ietf-dccp-simul-open-07 - response

[Gorry Fairhurst <[e-mail]>]

Thanks Chris for your comments, these are really helpful.

I've updated my copy of the draft for all of these, except for one, 
which seems to not be valid - please see below, I'd love to understand 
whether I have captured this particular comment correctly.

Best wishes,

Gorry Fairhurst

Chris Newman wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Overall: This proposal provides a reasonable architecture for the 
> function the WG desires.  I support advancement after some of the issues 
> below are addressed.
> 
> Section 2.2.1:
> 
> The reference to draft-ietf-dccp-serv-codes-08 appears to be normative 
> as a "MUST" requirement is placed on a field whose meaning depends on 
> that specification.
> 
Done.

> Section 2.2.2:
> 
> The "LISTEN1" state is mentioned in the pseudocode, but not the state 
> diagram or figure label.  I suspect it should read "LISTEN'" (to match 
> the figure label) or the two should be declared equivalent.
> 
Corrected, and all have been changed to LISTEN1 - it was not good having 
a symbol that could essily be overlooked.

> Security Considerations
> 
> The stated threats seem reasonably well described.
> 
> One potentially significant threat I did not see discussed:
> 
> This creates a new way to set up a DCCP connection from a client to a
> server triggered via a SIP/SDP connection setup.  If the SIP/SDP
> connection is unencrypted, an eavesdropper could get the client IP and
> Port for the to-be-established DCCP connection and generate a
> DCCP-Listen to the client using its own server-IP/port.  So if the
> client is waiting for a DCCP-Listen from an arbitrary server-IP/port and
> responds to it, this allows an attacker to redirect the connection
> without IP spoofing.  If, however, the client is told the server-IP and
> server-port for DCCP through SDP and will only accept a DCCP-Listen from
> that endpoint, the new threat would be mitigated (leaving the existing
> DCCP IP spoofing threat).
> 
I take this to suggest:

"The method creates a new way for a client to set up a DCCP connection 
to a server using out-of-band data, carried on a signaling connection. 
If the signaling connection is not encrypted, an eavesdropper could see 
the client IP address and the port for the to-be-established DCCP 
connection and generate a DCCP-Listen packet towards the client using 
its own server-IP address and port.

This could elicit a response from a client that is waiting for a 
DCCP-Listen packet from an arbitrary server-IP/port. This would allow an 
attacker to redirect the connection without IP spoofing. If, however, 
the client is told the server-IP address and the server-port for the 
DCCP connection through the signaling connection and will only accept a 
DCCP-Listen from that endpoint, the new threat would be mitigated 
(leaving the existing DCCP IP spoofing threat)."

- It is good to think of new threats, but I am not sure this one exists. 
The second para as I write this, assumes that the client actually takes 
action on receipt of a DCCP-Listen packet. I think this only happens in 
the case of a triggered retransmission of an already sent request. I 
therefore do not understand the new threat, is it possible that this 
actually should read:

"The method creates a new way for a client to set up a DCCP connection 
to a server using out-of-band data, carried on a signaling connection. 
If the signaling connection is not encrypted, an eavesdropper could see 
the client IP address and the port for the to-be-established DCCP 
connection and generate a DCCP-Listen packet towards the client using 
its own server-IP address and port. However, a client will only respond 
to a received DCCP-Listen packet if the server-IP address and port match 
an existing DCCP connection that is in the REQUEST state (section 
2.3.2). The method therefore cannot be used to redirect the connection 
to a different IP address."

> One minor issue I noticed was not mentioned directly:
> 
> The DCCP base specification Init Cookie option lets a DCCP server avoid
> having to hold any state until the three-way connection setup handshake
> has completed.  This specification enables an out-of-band mechanism that
> forces the server to hold state for a connection that has not yet been
> established.  This is a change in the security profile of DCCP, although
> the impact is minimal and depends on the security features of the 
> out-of-band
> mechanism (SIP SDP is one such mechanism that provides sufficient security
> features).
> 
Added.

> Nit:
> 
> The statement:
>  "A DCCP server SHOULD therefore by default permit generation of
>   DCCP-Listen packets."
> seems inappropriate in a security considerations section as the
> recommendation is really unrelated to security.  Perhaps that 
> recommendation
> should be in the normative protocol description.
> 
Changed in the way you suggested.

>         - Chris
> 
>