Re: [codec] [payload] Padding in draft-ietf-codec-opus-07?

Another challenge with relying on RTP padding is communicating the maximum packet size for padding from the encoder to the RTP/SRTP stack.  Of course, this could be done implicitly by having the RTP/SRTP sender maintain a "high watermark" of payload sizes seen, but that would still leak information.  Dependencies and forced "abstraction leaks" between layers increase implementation complexity, may result in subtle security bugs, and risk incompatibilities.  RTP padding is not common, so there _will_ be vendors that get it wrong when they get padded packets.

My vote is for *NOT* relying on RTP padding for conversation masking.  

--Felix

> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of
> Jean-Marc Valin
> Sent: Monday, July 25, 2011 17:12
> To: Stephen Botzko
> Cc: codec@ietf.org
> Subject: Re: [codec] [payload] Padding in draft-ietf-codec-opus-07?
> 
> On 11-07-25 01:24 PM, Stephen Botzko wrote:
> > I think RTP padding should be sufficient.
> 
> Well, it is possible for Opus to be transmitted in real-time over
> something other than RTP. Also, even for RTP, there's the issue that the
> padding bit is transmitted in the clear, which would impose padding even
> frames that would not otherwise need padding.
> 
> 	Jean-Marc
> 
> > Regards,
> > Stephen
> >
> > Sent from my Verizon Wireless Device
> >
> > Christian Hoene <hoene@uni-tuebingen.de> wrote:
> >
> >> Hello,
> >>
> >> I am wondering about a padding feature in draft-ietf-codec-opus-07.
> >> It allows you to extend the frame size by filling it up with zeros.
> >>
> >> I just spoke with the Tim, Jean-Marc and Gregory about this feature.
> >> As far as I understood, this feature is required at transcoding
> >> gateways to enforce a stream of packets having a constant size (while
> >> using UDP). Otherwise, attackers could potentially follow the
> >> conversation by observing packet sizes.
> >>
> >> To my understanding, padding is a feature that can be easily skipped
> >> from the codec specification. It violates the layering principle and
> >> is intended only for a very specific use cases. On the other side,
> >> constant sized frames can be easily supported by keeping the codec
> parameters fixed.
> >>
> >> With best regards,
> >>
> >> Christian Hoene
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -------
> >> -----
> >> Dr.-Ing. Christian Hoene, University of Tübingen, Computer Science,
> >> Chair of Communication Networks, Research Group Interactive
> >> Communication Systems
> >> (ICS)
> >> Sand 13, 72076 Tübingen, Germany, Tel +49 7071 2970532,
> >> www.net.uni-tuebingen.de
> >>
> >>
> >>
> >> _______________________________________________
> >> payload mailing list
> >> payload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/payload
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://www.ietf.org/mailman/listinfo/codec
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec