[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Réf. : RE: Security-Requirements: alternatives?
Hi,
Just one remark in favour of ULE with regards to the other Layer 2
solutions for MPEG 2 transmission network: ULE is the only solution
providing "Hiding of layer 2 MAC/NPA address". MPE does not provide it.
Conditionnal Access (based on MPEG-2 TS scrambling) too : the destination
MAC address is scrambled, however at reception , all receivers listening to
the same PID can see the MAC address of each packet (even it is not
destined to them).
This service is an important added value of ULE, particularly for military
systems.
Regards,
Laurence Duquerroy
<H.Cruickshank@su
rrey.ac.uk> Pour : <gorry@erg.abdn.ac.uk>
Envoyé par : <ipdvb@erg.abdn.ac.uk>
owner-ipdvb@erg.a <S.Iyengar@surrey.ac.uk>
bdn.ac.uk <P.Pillai@Bradford.ac.uk>
cc :
Objet : RE: Security-Requirements: alternatives?
22/06/2006 20:08
Veuillez répondre
à ipdvb
Hi Gorry,
This issue has been addressed in the security draft. Some text has
been added to section 5.1 to this effect:
Basically, in practice there are not many L2 security systems for MPEG
transmission networks. Two major examples are:
* Conditional access for digital TV broadcasting is one example that
exists today. This system is optimised for TV broadcast services only,
and is not suitable for IP packet transmissions and difficult to
interwork with ULE.
* Some other L2 security systems are specified in standards such the MPE
for DVB system . However, MPE security incomplete and there are no
known implementations of such security system.
* For DVB-S2 Generic Streams, where IP encapsulation could be similar to
ULE. The authors believe that ULE security format can be used for
Generic Streams as well.
We would like to ask the ipdvb WG if anybody knows any other existing L2
security systems that might be suitable for ULE.
Haitham
----
Dr. Haitham S. Cruickshank
Lecturer
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK
Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: 22 June 2006 15:37
To: Cruickshank HS Dr (CCSR); ipdvb@erg.abdn.ac.uk; Iyengar S Mr (CCSR);
P.Pillai@Bradford.ac.uk
Subject: Security-Requirements: alternatives?
Haitham, I-D Authors, List,
One of the issues we need to be clear about in preparing for a WG
adoption of the security requirements I-D is the possible alternatives
that have been proposed/implemented in other standards organisations.
Could you summarise the methods that have been proposed for MPEG-2
transmission networks that provide equivalent L2 security functions, and
say which to your knowledge has actually have been implemented in
systems?
Thanks,
Gorry
RT/ST
Research Department / Advanced Telecom Satellite Systems
Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60
E-Mail : laurence.duquerroy@alcatelaleniaspace.com
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries)
shall (will) not therefore be liable for the message if modified.
Ce message et toutes les pieces jointes (ci-apres le "message") sont
etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce message non conforme a
sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
decline(nt) toute responsabilite au titre de ce message, dans l'hypothese
ou il aurait ete modifie.