AW: Réf. : Re: Encryption control of SNDU

["Fritsche Wolfgang" <Fritsche@iabg.de>]

Scrambling and FEC are first examples for possible future extensions of ULE, which have not been foreseen during the original design. Certainly these will not be the last ones. 

Therefore I don't think using space from the length field is a good way to serve these future needs, and would agree with Alains proposal that a cleaner, more flexible and more efficient way to allow extensibility of ULE is the specification of an optional extension header. Like for IPv6 this keeps the basic header slim for efficient processing and allows the introduction of new functionality while keeping backward compatibility (older ULE versions simply can skip new functionality).

Cheers,

Wolfgang


> -----Ursprüngliche Nachricht-----
> Von: owner-ip-dvb@erg.abdn.ac.uk 
> [mailto:owner-ip-dvb@erg.abdn.ac.uk] Im Auftrag von Bernhard 
> Collini-Nocker
> Gesendet: Mittwoch, 25. Februar 2004 13:39
> An: ip-dvb@erg.abdn.ac.uk
> Betreff: RE: Réf. : Re: Encryption control of SNDU
> 
> 
> Dear Tarif,
> 
> since I am not an expert on scrambling could you please 
> elaborate a little bit on how the receivers do obtain the two 
> keys. Is there a key distribution mechanism or are those keys 
> permanently set in the receiver hardware? Still my personal 
> opinion is that scrambling control should be in a separate 
> standard track. Where to put the 2 necessary bits is a good 
> question, adding another header byte seems too much overhead 
> to me. An potential alternative, provided the MTU of the 
> SNDUs is small enough, which might be the case for DVB-RCS 
> anyhow, could be to limit the Length field and insert those 2 
> bits after the D bit. That would lead to a 8 K maximum size of SNDUs.
> 
> Any other ideas and arguments?
> 
> Regards,
> Bernhard
> 
> > 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
> >
> >
> >
> >
> 
>