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

From: Chris Newman <[email-masked]>
Date: Tue, 21 Apr 2009 18:25:01 -0700

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.

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.

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).

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).

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.

		- Chris

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 28 Apr 2009 08:23:19 +0100

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:
> 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.

> 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.

> 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."

> mechanism (SIP SDP is one such mechanism that provides sufficient security
Added.

> should be in the normative protocol description.
Changed in the way you suggested.