RE: Encryption control of SNDU

["Allison, Art" <AAllison@nab.org>]

I add my voice to those saying keep this ULE recommendation free from
security complications.

It seems to me that whatever security that anyone feels is needed can happen
above (or below) this transport recommendations place in the stack of
protocols.

The entire payload of all packets identified by a PID can be scrambled at
the MPEG-2 layer, with what ever CA standard is appropriate.  At the IP
layer (and/or higher) there are tools available, such as IPSEC.

With respect to traffic analysis protection, that too does not seem to need
definition at this layer. However, my difficulty in understanding what
traffic analysis means or could yield to an attacker in a one-way broadcast
environment may be affecting this assessment.  

Regards,
Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Haitham Cruickshank [mailto:H.Cruickshank@eim.surrey.ac.uk]
Sent: Thursday, February 26, 2004 5:32 AM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: Encryption control of SNDU


Hi Alain and All,

I like to add my voice to Alain's, regarding keeping ULE simple and free
from
security complications.  Also using IPSEC mean closer integration with
terrestrial IP networks.

However, Bernhard mentioned a good point: "I do see reasons for scrambling
e.g.
for the case to prevent from traffic analysis".  I think this problem can be
solved using IPSEC between satellite nodes (before ULE encapsulation) in two
ways:

1. Using IPSEC ESP in transparent mode.  This means the IP header is sent in
the
clear and IP payload is encrypted.  This solution is efficient but might not
prevent traffic analysis using IP addresses.
2. Using IPSEC ESP in tunnel mode.  This means IP header and payload are
encrypted.  This solution is better against traffic analysis, but there is
the
extra overhead of IPSEC tunnelling.

Regards.
Haitham

alain.ritoux@6wind.com wrote:

> 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

--
Dr. Haitham S. Cruickshank

Senior Research Fellow
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/