RE: Encryption control of SNDU

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

Hello,

I do see reasons for scrambling e.g. for the case to prevent from traffic
analysis. Whether this or other reasons are taking into account is in my
view a question of community demand.
But again, I am not in favour of new header fields/flags. Scrambling has
too little to do with encapsulation.

One other issue, which has not been discussed yet, is how to announce ULE
streams in PSI/SI at all. Does someone have a preferred strategy on how to
proceed with this issue? It is certainly a side-issue, but without having
a god-idea (in advance or by stream analysis) what stream type
(encapsulation)
is used on a specific PID receivers are somehow left in the dark.

Best regards,
Bernhard

> -----Original Message-----
> From: owner-ip-dvb@erg.abdn.ac.uk [mailto:owner-ip-dvb@erg.abdn.ac.uk]On
> Behalf Of alain.ritoux@6wind.com
> Sent: Mittwoch, 25. Februar 2004 10:37
> To: IPDVB
> Subject: Re: Encryption control of SNDU
>
>
>
>
> 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.
>
> I fail to see why we would need an L2 encryption to carry IP/IPv6
> traffic, when IPsec/IKE is already defined including encryption,
> authentication, key distribution and all that kind of stuff.
> Would it not be re-inventing the (rather complex) wheel ?
>
> Regards.
> Alain.
> --
> Alain RITOUX
> Tel +33-1-39-30-92-32
> Fax +33-1-39-30-92-11
> visit our web http://www.6wind.com
>