Re: Encryption control of SNDU

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

So, I'm trying to build a list of "issues for ULE" and the questions I have
are:

(i) Does the proposed ULE base header format (4/12B of header) need to be
changed to support any required encryption/scrambling?

Possible answers include:

* Yes - because the ULE header must not be increased when
    link encryption is used.

* No - because the ULE header can specify a TYPE that could
    indicate an encrypted payload, and hence this issue
    could be solved by using an extension header of some form.

If it is YES, then this has design implications for the ULE Spec.

If it is NO, then some text on how to implement the encryption header would
be a useful input - perhaps this should be a short separate ID?
- We can discuss this more easily if we have a proposal and a short example,
I'd also be keen to get expert security advice, we don't wish to repeat any
of the mistakes made by others.  If we can find a solution that is accepted
and widely applicable, we could then either add this to the ULE Spec or as a
separate document.


(b) Whatever the result of the above question, it would be MOST beneficial
to have some security inputs to the REQUIREMENTS ID.  This document needs to
evolve to clearly express the motivations of the ipdvb protocol framework.
This is the next draft on the table for discussion....

Can anyone offer 2 or 3 paragraphs on why we need to do/not to do
encryption/scrambling at the ULE layer, and what the relationship is to
MPEG-2 scrambling and IPSEC?

Gorry Fairhurst


On 26/2/04 10:32 am, "Haitham Cruickshank" <H.Cruickshank@eim.surrey.ac.uk>
wrote:

> 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/
> 
>