Subject: [Gen-art] Gen-ART review of draft-ietf-dccp-problem-03

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 14 Sep 2005 16:23:49 -0700

Gen-ART review of draft-ietf-dccp-problem-03 (Informational)
------------------------------------------------------------------------------

Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e., the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected as the
GenART member to review this document.  Below is my review, which was
written specifically with an eye to the GenART process, but since I
believe that it will be useful to have these comments more widely
distributed, others outside the GenART group are included.

Summary:  Very well written; however, missing security considerations ...

I enjoyed reading the I-D immensely; as I was nearing the end, I was hoping 
to see the authors' recommendations on security protocols for a datagram 
congestion control protocol.   Unfortunately, security did not make the cut 
in Section 5 on Additional Design Considerations.  Furthermore, Section 8 
on Security Considerations says that there are no security considerations 
for this document.  I disagree!

Here are some questions the security considerations section might address:

1. I use SRTP/IPsec/DTLS for my VoIP traffic and now that a motivation for 
a DCCP being proposed, what are the implications on the existing security 
protocols.  Would they work without modifications or would there be any 
special considerations (for instance the DTLS draft has a paragraph on what 
might be different w.r.t. the DCCP vs. UDP).

2. TCP and UDP have different security considerations (e.g., reset attacks 
in TCP don't apply to UDP).  Would a DCCP be similar to TCP or UDP in 
security issues?

The answers may be obvious to folks active in this area, but not 
necessarily to an average reader.

As Russ suggested in his comments, DoS considerations and FW traversal as 
noted in other parts of the draft might be repeated in the security 
considerations section as well.

Nit: The abstract says the document is a historical record.  In that case, 
please delete the sentence starting with "The current version of DCCP 
includes no multihoming ..." in Section 5 (for future proofing this 
document in the face of changes to the DCCP specification).

Hope that is helpful!

thanks and regards,
Lakshminath

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sally Floyd <[email-masked]>
Date: Thu, 15 Sep 2005 12:05:32 -0700

Lakshminath -

>The clarification on the historical record part is welcome.  I think what I 
>meant though (and did not express properly) is that the draft mentions that 
>the motivation and design considerations apply even if the DCCP were not 
>the chosen protocol (probably written at the beginning of the DCCP work at 
>the IETF).  I was thinking perhaps this draft/RFC will stay stable while 
>the dccp-spec RFC might change in the future (and hence the request to 
>delete that one sentence in the mobility considerations part of the 
>draft).  Anyway, please revise as you feel appropriate.

Actually, the dccp spec has been approved for Proposed Standard,
and is in the RFC Editor's hands (having already passed IANA).  So
in the problem statement we can just refer to the dccp spec as RFC
XXXX, rather than as the current version of the spec, and we will
be able to fill in the actual RFC number for the dccp spec long
before the problem statement makes it to the 48-hour-last-call from
the RFC Editor.

(The problem statement was done years ago, and had been on
hold while the actual dccp spec progressed.  So the dccp
spec will appear first as an RFC, before the problem statement
does.  That is, *at this stage* the problem statement really is 
serving as a historical document.)

- Sally
http://www.icir.org/floyd/