Re: Encryption control of SNDU

[Bernhard Nocker <bnocker@cosy.sbg.ac.at>]

Hi,

if it is really required to notify a receiver about scrambled SNDUs I
would prefer to use another type field value for that purpose instead of
adding new header fields. But it might be as appropriate to start a S-ULE
(secure ULE) draft just for that purpose?! Another alternative would be to
announce the scrambled ULE in the PSI/SI instead of the encapsulation
header fields.

Kind regards,
Bernhard

On Tue, 24 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote:

>
>
> Hi every body
>
> The current ULE draft does not address the issue of SNDU encryption which
> we think is important.
> In fact, a requirement has been identified in IP/MPE/MPEG to allow, when
> necessary, data encryption at MPE level. Some IP/MPE/MPEG products already
> implement this capability (e.g. Alcatel 9780)
> Encryption is controlled using the 'payload scrambling control' field (2
> bits) in the MPE header.
>
> Consequently, it would be necessary to provision an "encryption-control"
> field (2 bits) in the SNDU header.
> This could also facilitate the transition from MPE to ULE
> Here is a proposal for its definition :
>    bit 1 : indicates if the SNDU is encrypted or not
>    bit 2 : indicating the type of encryption (when active) odd/even (to
>    allow key shift on the fly)
>
> Adding 2 bits would require to add a complete byte to the SNDU header in
> order that the header still an integer number of bytes. If this is not
> acceptable from a performance point of view, we can envisage to shorten the
> 'length' field from 15 bits down to 13 bits (note that in MPE, the length
> field is 12 bits).
>
> waiting for your feedback
> regards
>
> T. Zein
>
> ALCATEL SPACE
> DRT/RST  --  Ingénieur Systèmes
> Tel : 0534356918  /  Fax : 0534355560
> Porte : W.220
>
>
>