Document: draft-ietf-avt-dtls-srtp-05
Reviewer: Ben Campbell
Review Date:  2008-09-30
IETF LC End Date: 2008-10-02


Summary:

This document is almost ready for publication as a proposed standard.  
I have a point of confusion that should be addressed prior to publication, as well as a few nits and editorial comments.

Comments:

--Substantive Comments:

I am confused on the use of DTLS "application_data". It is not clear to me if this is reader error, an issue with the explanation, or a bona-fide protocol issue.

Section 4.1 (3rd from last paragraph) says that application data is never sent in DTLS record-layer "application_data" packets. However the last paragraph says records other than "application_data" MUST use normal DTLS framing and be placed in separate datagrams from SRTP data--this sounds like an effective contradiction to me, in that since SRTP packets are not "application_data" packets than they must be "other than application_data".

Further, section 5.1.1 paragraph 1 says that "data of type 'application_data' ... is encrypted using SRTP rather than the standard TLS record encoding". I take this to mean SRTP packets _are_ sent as "application_data",  and "...delivers it to the DTLS implementation as a single write of type 'application_data'", both of which seems to conflict with the "never sent as application_data"  
assertion in section 4.1.

Finally, 5.1.2 talks about using the first byte of the packet to demux RTP, DTLS, and TURN. Is this consistent with the use of "application_data" to distinguish SRTP packets from other DTLS packets described in 5.1.1? (Maybe the RTP to be demuxed here is not SRTP
protected?)

--Nits and Editorial Comments

-Section 3, paragraph 4:

Your definition of symmetric RTP appears to assume that _both_ endpoints are behaving symmetrically, which is a stronger requirement than given in the RFC 4961. It's probably worth saying that _both_ peers must follow RFC 4961 in order to use a bi-directional session.

-Paragraph 7:

I am surprised that this is only a MAY. Would it ever make since to use DTLS-SRTP _without_ an external signaling protocol?

-Section 4.1, paragraph 1: "... data being transported is RTP and RTCP"

Should that be "RTP or RTCP", or possibly "one or both of RTP and RTCP"?

-First paragraph after the handshake flow diagram:

The server Certificate has a "*", but is not included in the list of otherwise optional parts that are always sent in DTLS-SRTP.  Do you intend the server Cert to be optional for DTLS-SRTP, or is this an error?

-section 4.1, last paragraph

It seems a bit odd to me to use a normative "MUST NOT" purely for clarification.

-4.1.2, last paragraph, first sentence.

I had trouble parsing this. I suggest something to the effect of "...  
must be defined according to the 'Specification Required' policy  as defined in RFC 5226. [RFC5226]"

--Section 9:

I've not seen normative language for IANA actions before--is this reasonable? In particular, I'm not sure how IANA will interpret a SHOULD.

References:

IDNITS reports an outdated reference for draft-ietf-tls-extractor-01.