Last Call Review of draft-ietf-avt-rtp-h264-rcdo-
review-ietf-avt-rtp-h264-rcdo-secdir-lc-kelly-2010-11-12-00

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.

This draft describes a new RTP payload format, extending existing RTP
capabilities. Based on my limited understanding of RTP, this introduces no new
security considerations.

The security considerations section starts off by saying this, but then goes on
to talk about various security properties that could be added by various means.
I found the text to be a little confusing, especially when it makes
recommendations without detailing any particular threats.

I would suggest simplifying the security considerations. Here is the current
text:

  "RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [6], and in any applicable RTP profile.  The main
   security considerations for the RTP packet carrying the RTP payload
   format defined within this document are confidentiality, integrity
   and source authenticity.  Confidentiality is achieved by encryption
   of the RTP payload.  Integrity of the RTP packets through suitable
   cryptographic integrity protection mechanism.  Cryptographic system
   may also allow the authentication of the source of the payload.  A
   suitable security mechanism for this RTP payload format should
   provide confidentiality, integrity protection and at least source
   authentication capable of determining if an RTP packet is from a
   member of the RTP session or not.

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this document may vary.  It is dependent on the
   application, the transport, and the signalling protocol employed.
   Therefore a single mechanism is not sufficient.  Usage of data origin
   authentication and data integrity protection of at least the RTP
   packet is RECOMMENDED, for example by use of the Secure Real-time
   Transport Protocol (SRTP) [12].  Other mechanisms that may be used
   are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
   TCP), but other alternatives may exist.

   Refer also to section 9 of RFC YYYY [3], as no reasons for separate
   considerations are introduced in this document."

I would suggest the following simplified text:

  "RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [6], and in any applicable RTP profile.  No additional
   security considerations are introduced by this specification."

(or something like this).

--Scott