Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

Some fairly minor comments below.  Overall I think the document provides useful mechanism to deal with tradeoff between RTP header extension encryption and RTP header
compression efficiency when we use multiple header extension.

Section 3 Encryption Mechanism
"
  To encrypt (or decrypt) an encrypted extension header, an SRTP
   participant first generates a keystream for the SRTP extension
   header.  This keystream is generated in the same manner as the
   encryption keystream for the corresponding SRTP payload, except the
   the SRTP encryption and salting keys k_e and k_s are replaced by the
   keys k_he and k_hs, respectively.
"
[Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload
to provide encryption for the payload of header extension element?
What's the benefit to choose the different keystream and crypto-suite for header extension elements?
Can we say the same keystream and  crypto-suite for SRTP payload can be applied to header extension elements?

Section 4:
"
Encrypted header extension elements are signaled in the SDP extmap
   attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt",
   followed by the URI of the header extension element being encrypted
   as well as any extensionattributes that extension normally takes.
"
[Qin]: Are you going to define new URI for Encryption of Header Extensions or use existing URI?

Section 4:

[Qin]: If one header extension has three elements, 
a) the header extension and elements header will not be encrypted, only payload of each elements need encryption 
b) or both elements header and elements payload will be encrypted?
I believe it is former.

[Qin]: If the number of header extension element included in each RTP packet changes during a stream, e.g., Firstly three header extension elements
to be encrypted carried in the first RTP packet are sent to the receiver, and then, two header extension elements carried in 
the second RTP packet are sent to the same receiver, is the receiver aware of this change and  choosing the right encryption mask? How?
based on non-encrypted header?

[Qin]: If there are no payload for header extension elements, i.e., the length of header extension elements is zero, the mechanism described in this document
does not apply to this case, right?

Regards!
-Qin
----- Original Message ----- 
From: "Jonathan Lennox" <jonathan@vidyo.com>
To: <avt@ietf.org>
Sent: Monday, March 28, 2011 5:08 PM
Subject: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

Hello, all --

I've updated my draft on encrypting RTP header extensions, targeting the draft at the AVTCore WG, in the hope that the group will find it a suitable starting point for the WG milestone.

This version of the draft has no substantial changes from draft-lennox-avt-srtp-encrypted-extension-headers-02, only the name change and some reference updates.

Begin forwarded message:

> From: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
> Date: March 28, 2011 11:00:01 AM GMT+02:00
> To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
> Subject: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> Reply-To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
> Author(s)       : J. Lennox
> Filename        : draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> Pages           : 8
> Date            : 2011-03-28
> 
> The Secure Real-Time Transport Protocol (SRTP) provides
> authentication, but not encryption, of the headers of Real-Time
> Transport Protocol (RTP) packets.  However, RTP header extensions may
> carry sensitive information for which participants in multimedia
> sessions want confidentiality.  This document provides a mechanism,
> extending the mechanisms of SRTP, to selectively encrypt RTP header
> extensions in SRTP.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

--------------------------------------------------------------------------------

> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>