Réf. : Re: Encryption control of SNDU

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

Well, L3 IPsec vs L2 encryption is rather an old debate.
Any way, L2 encryption is almost always asked for by satellite providers to
allow intrinsic securtiy within the system
independantly of L3 security. IPsec is an option which is not always
applied.
How many poeple do have their DSL link secured with IPsec?
if this is not dramatic in a wired system since it is rather difficult to
snif your DSL line, a wireless system is rather vulnerable.

That is why such L2 securtiy has been provisioned for dvb-rcs systems.
Encryption at MPEG layer as suggested in the requirements ID
(draft-fair-ipdvb-req-04.txt) can not allow a per receiver keying

If such a solution is not put into ULE, it may simply turn to be
inapplicable to dvb-rcs systems :(

cheers
tarif




alain.ritoux@6wind.com@erg.abdn.ac.uk on 25/02/2004 10:36:33

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

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


Pour : IPDVB <ip-dvb@erg.abdn.ac.uk>
cc :
Objet :     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






T. Zein

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