[perc-implementation] Re: Sergio concerns [copy]

  • From: Boris Grozev <boris@xxxxxxxxx>
  • To: perc-implementation@xxxxxxxxxxxxx
  • Date: Mon, 27 Mar 2017 15:02:44 -0500

On 27/03/2017 14:19, Sergio Garcia Murillo wrote:

Hi Boris,

Re-reading the draft-03 the X bit is handling on the receiving side:

         Insert all header extensions up to the OHB extension, but
         exclude the OHB and any header extensions that follow the OHB.
         If there are no extensions remaining, then the X bit MUST bet
         set to 0.  If there are extensions remaining, then the
         remaining extensions MUST be padded to the first 32-bit
         boundary and the overall length of the header extensions
         adjusted accordingly.


So there is no need to signal the original X bit.

I think that we need to signal at least the padding bit, as if there is
any padding on the original rtp packet, it will be converted into
payload for the double encrypted packet, which would not carry padding
by default (we could force to keep the padding bit as the original
packet and set the padding count to 0 but that will add one extra byte
anyway).

I think we need something like this if we want to have packets with payload+padding, and have the MD strip the padding from them. Otherwise,
the MD can just work without knowing the amount of padding in a packet (in which case we don't need to copy the original P bit and the padding length).


Re: padding only bit, I don't have a strong opinion. But the only thing
is that currently padding on the original packet can only be of 256, so
"padded only" encrypted packet can't be bigger than that too.

I don't understand why. The semantics that I have in mind for the "padding-only" bit are that, if it is set then the packet contains only "padding" (i.e. completely discardable data), regardless of its size. This might not be the best name, but I wanted to avoid using something like "discard" which has another meaning in the framemarking draft.


Regards,
Boris

Other related posts:

  1. Home
  2. perc-implementation
  3. Archive
  4. 03-2017