Gen-ART LC review of draft-ietf-avt-dtls-srtp-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


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.



_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]