Réf. : Re: Encryption control of SNDU

[Tarif.Zein-Alabedeen@space.alcatel.fr]

Thanks bernhard for your answer,

In fact, even if we use a secure ULE session mechanism, rekeying is
required during a session.
PSI/SI is not real time and could not allow synchronized rekeying on the
fly without SNDU (or MPE section) loss.
The receiver still needs a flag indicating from which SNDU the new key
applies.

The requirement for such a control field is specified in the dvb-rcs
standard (EN 301790) and in EN 301192.
In EN 301790 section 6.4.6.3, the exact wording for this is as follows :

DVB Multiprotocol Encapsulation sections, according to EN 301 192 [5], the 2-bit
payload_scrambling_control field in the section header is used:
- 00: not encrypted;
- 01: reserved;
- 10: encrypted using session key 0;
- 11: encrypted using session key 1.

Regards







Bernhard Nocker <bnocker@cosy.sbg.ac.at>@erg.abdn.ac.uk on 24/02/2004
21:25:15

Veuillez répondre à ip-dvb@erg.abdn.ac.uk

Envoyé par :      owner-ip-dvb@erg.abdn.ac.uk


Pour : <ip-dvb@erg.abdn.ac.uk>
cc :
Objet :     Re: Encryption control of SNDU


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
>
>
>






T. Zein

ALCATEL SPACE
DRT/RST  --  Ingénieur Systèmes
Tel : 0534356918  /  Fax : 0534355560
Porte : W.220