Re: [secdir] secdir review of draft-ietf-avt-rfc3047-bis-08.txt

"Roni Even" <ron.even.tlv@gmail.com> Wed, 25 February 2009 14:21 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=wDgqcxAvBKDti5AO1b0vdanBO73oRKVHKWp++TgU+fBqM43CgelGPE21Xms+T+3Dg3 AKEJBcB7zS99YC+697cMpr6jFw6rhZktNRAqz8leS/lIdoWUtVdhkg9cM+RHm961EGnz p9fZeQKBJl7QsCDsvB00jjtyfny3TgCwwuIFE=
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Alexey Melnikov' <alexey.melnikov@isode.com>, secdir@ietf.org, draft-ietf-avt-rfc3047-bis@tools.ietf.org
References: <49920C4C.50907@isode.com>
In-Reply-To: <49920C4C.50907@isode.com>
Date: Wed, 25 Feb 2009 16:19:52 +0200
Message-ID: <49a55402.06e2660a.114b.ffffaa53@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcmL1pLdp903pf8vRKqWXgq7aIXhgwLfTEpQ
Content-Language: en-us
Cc: iesg@ietf.org, avt-chairs@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-avt-rfc3047-bis-08.txt
Precedence: list

Hi,
I agree with the proposed change.
Regards
Roni Even
As editor of rfc3047-bis

-----Original Message-----
From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] 
Sent: Wednesday, February 11, 2009 1:23 AM
To: secdir@ietf.org; draft-ietf-avt-rfc3047-bis@tools.ietf.org
Cc: avt-chairs@tools.ietf.org; iesg@ietf.org
Subject: secdir review of draft-ietf-avt-rfc3047-bis-08.txt

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 document describes the payload format for including G.722.1
generated bit streams (audio) within an RTP packet. The Security
Considerations
section is nearly the same as in RFC 3047, with some obsoleted text deleted
(good).

I would suggest replacing the first paragraph
   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550], and any appropriate RTP profile.  This
   implies that confidentiality of the media streams is achieved by
   encryption.

with (for example) the text found in RFC 5404:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550] and in any applicable RTP profile.  The main
   security considerations for the RTP packet carrying the RTP payload
   format defined within this memo are confidentiality, integrity, and
   source authenticity.  Confidentiality is achieved by encryption of
   the RTP payload.  Integrity of the RTP packets is achieved through a
   suitable cryptographic integrity protection mechanism.  Such a
   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.

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this memo may vary.  It is dependent on the
   application, the transport, and the signaling protocol employed.
   Therefore, a single mechanism is not sufficient, although if
   suitable, usage of the Secure Real-time Transport Protocol (SRTP)
   [RFC3711] is recommended.  Other mechanisms that may be used are
   IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP
   over TCP); other alternatives may exist.

as it provides more background to a reader unfamiliar with RTP
on possible security mechanisms that can be used.

Apart from that I found the document to be well written and being quite
clear
on which data is valid and which is invalid.

[secdir] secdir review of draft-ietf-avt-rfc3047-… Alexey Melnikov
Re: [secdir] secdir review of draft-ietf-avt-rfc3… Roni Even