Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 12 Dec 2004 12:34:35 +0200

The short poll run a few days ago was indicating that the RFC 3611 packets seem to be the only ones candidates right now for selective encryption. There also were concerns about making a negotiation mechanism too complex. To keep things simple by now, but flexible for the future I would suggest that the document does not include the list of the to the candidate payload types that have a demand for running non-encrypted in a SRTP deployment, but rather refer to a list external to the document and maintained by IANA. This list will include only XR to begin with, and can be extended later without changing this document, or creating new ones. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Alan Clark
> Sent: 11 December, 2004 4:50 PM
> To: Mark Baugher; Colin Perkins; Magnus Westerlund
> Cc: [email-masked]
> Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> 
> It would seem that an additional draft needs to state roughly 
> the following:
> 
> (i) Scope - provides method for selective encryption/ unencryption of
> certain RTCP payload types
> 
> (ii) Approach - allow for SRTCP encryption to be set ON by default but
> overridden for certain payload types
> 
> (iii) New parameter
> 
> SELECTIVE_SRTCP_UNENCRYPTED means that by default RTCP frames 
> are encrypted
> with the exception of the listed payload types
> 
> List of RTCP payload types .. SDES, BYE, RR, SR, XR, 
> XR_VOIPMETRICS, XR_...
> 
> Some compound types (for convenience) .. ALL_INFORMATIONAL_TYPES
> where ALL_INFORMATIONAL_TYPES = SR, RR as defined in RFC3550 
> and XR payloads
> as defined in RFC3611
> 
> (iv) Examples
> 
>  ....., SELECTIVE_SRTCP_UNENCRYPTED:ALL_INFORMATIONAL_TYPES
> 
> or
> 
>  ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR_VOIPMETRICS
> 
> Any comments on the general approach?
> 
> Regards
> 
> Alan
> 
> 
> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]]
> Sent: Friday, December 10, 2004 6:39 PM
> To: Alan Clark
> Cc: [email-masked]; Colin Perkins
> Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> 
> 
> Alan,
>    I'm finishing sdescriptions-08 without any change to accommodate XR
> packets to use the E bit.  I don't yet know who is going to 
> do the work
> on the I-D that Colin suggested to address Magnus' issues with E-bit
> usage.  As it stands now, UNENCRYPTED_SRTCP will need to be 
> signaled in
> order to keep XR packets in the clear.
> 
> Mark
> On Dec 10, 2004, at 1:05 PM, Alan Clark wrote:
> 
> > Mark, Colin
> >
> > Where does this leave the issue?  Some sizeable network and telecom
> > equipment vendors are in the process of integrating support for the
> > RFC3611
> > VoIP metrics, due in a large part to service provider and enterprise
> > customer demand.  The demand exists because customers need to manage
> > their
> > VoIP deployments, hence they see RFC3611 as a key element in their
> > management infrastructure.  The accessibility of RFC3611 
> VoIP metrics
> > is
> > therefore an issue of concern today.
> >
> > If it's proposed to deal with this in a separate draft then 
> what is the
> > expected timeframe - going through the regular I-D, WG draft, IESG
> > process
> > seem to take a year or so. Is there some mechanism by which 
> this can be
> > accelerated?
> >
> > If the proposal is to address the issue in the draft currently being
> > finalized then my apologies if this has caused any last 
> minute delays
> > however the issue is important enough to warrant this (at 
> least in my
> > view).
> > We hoped that the comment in the security considerations section of
> > RFC3611
> > was strong enough to address the issue however it appears 
> not to have
> > been.
> >
> > Regards
> >
> > Alan
> >
> >
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> > Of Mark Baugher
> > Sent: Friday, December 10, 2004 11:03 AM
> > To: Colin Perkins
> > Cc: [email-masked]
> > Subject: Re: [MMUSIC] RE: [AVT] RFC 3711 and RTCP
> >
> >
> > Colin,
> >
> > On Dec 10, 2004, at 3:47 AM, Colin Perkins wrote:
> >
> >> Mark,
> >>
> >> On 8 Dec 2004, at 00:43, Mark Baugher wrote:
> >>>   Do we know of any other applications besides RFC 3611 that might
> >>> need to selectively encrypt SRTCP packets?
> >>
> >> I don't, but I can imagine future RTCP extensions which 
> might require
> >> this feature (and applications that might want to encrypt various
> >> subsets of the RFC 3611 data).
> >
> > I don't see a large downside in waiting until we see such extensions
> > for real.
> >>
> >>>   I am okay with putting this requirement aside pending a separate
> >>> document.  But before someone goes to the trouble of 
> writing the new
> >>> draft, it might be good to consider if it's needed or not.
> >>
> >> Even if RTCP XR is the only driver, it might be appropriate to make
> >> that a separate short draft. There's been enough discussion on the
> >> list that I'm not entirely comfortable slotting it into 
> sdescriptions
> >> this late in the process.
> >
> > Ok.  If there are no objections, I'll generate a new 
> version and post
> > it early next week.
> >
> > Mark
> >>
> >> Colin
> >>
> >
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> >
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Alan Clark" <[email-masked]>
Date: Sun, 12 Dec 2004 18:41:33 -0500

There is already an IANA numbering system for the various report types and
presumably we should just use this

IANA already knows about:-

   FIR        full INTRA-frame request 192      [RFC2032]
   NACK       negative acknowledgement 193      [RFC2032]
   SR         sender report            200      [RFC3551]
   RR         receiver report          201      [RFC3551]
   SDES       source description       202      [RFC3551]
   BYE        goodbye                  203      [RFC3551]
   APP        application-defined      204      [RFC3551]
   XR         extended report          207      [RFC3611]

and for RTCP XR

      BT  name
      --  ----
       1  Loss RLE Report Block
       2  Duplicate RLE Report Block
       3  Packet Receipt Times Report Block
       4  Receiver Reference Time Report Block
       5  DLRR Report Block
       6  Statistics Summary Report Block
       7  VoIP Metrics Report Block

This would result in syntax along the lines of

  ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[7],BYE

or

  ....., SELECTIVE_SRTCP_UNENCRYPTED:RR,SR,XR[6,7]

or presumably

  ....., SELECTIVE_SRTCP_UNENCRYPTED:200,201,207[6,7]

This looks like quite a short draft!!!!!  We only need to add one new
parameter to the sdescriptions to give much more flexibility.

Regards

Alan

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Sunday, December 12, 2004 5:35 AM
To: Alan Clark; Mark Baugher; Colin Perkins; Magnus Westerlund
Cc: [email-masked]
Subject: RE: [MMUSIC] RE: [AVT] RFC 3711 and RTCP

The short poll run a few days ago was indicating that the RFC 3611 packets
seem to be the only ones candidates right now for selective encryption.
There also were concerns about making a negotiation mechanism too complex.
To keep things simple by now, but flexible for the future I would suggest
that the document does not include the list of the to the candidate payload
types that have a demand for running non-encrypted in a SRTP deployment, but
rather refer to a list external to the document and maintained by IANA. This
list will include only XR to begin with, and can be extended later without
changing this document, or creating new ones.

Regards,

Dan