Re: Encryption control of SNDU

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

Thanks Alain for the example "extension format"

- I like the idea you put forward of extension headers for optional items,
the the Receiver *may* wish to use to enhance processing - this can be very
powerful, particularly with unidirectional and/or multipoint feeds, and
avoids explicit configuration for each Receiver.

- But I think the encryption information is mandatory to processing the
SNDU, so an alternate way to extend the header would be to assign one (or a
block of several contiguous) codepoints from the TYPE field. This could be
more efficient to implement, and would carry the same semantics as other
packet types - i.e. The type field indicates how to demultiplex the PDU. An
example could be:

< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | ENC |ETYPE |                PDU              | CRC-32 |
+-+-------------------------------------------------------+--------+
       
Where ENC = a predefined 2B TYPE  value, and ETYPE is the 2B type field
Corresponding to the PDU. Several ENC values could be specified.
Additional overhead = 2B.

If necessary, one or more bytes could be added between ENC and ETYPE,
It would be useful to think if these were desirable i.e. could assist
security decoding (or not).

So, I'm saying is:

(i) We now have two ways to extend ULE, we need to see which is most
appropriate, and for what.

(ii) The part of the text that I cut is equally important, we need inputs on
*WHY* and *HOW* the encryption should be done.

Gorry Fairhurst.


On 26/2/04 2:25 pm, "Alain RITOUX" <alain.ritoux@6wind.com> wrote:

> 
> 
> Gorry Fairhurst wrote:
> 
>> 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:
> Anyway, I may have missed something, so :
> 
> II) Etxension Header for Encryption
> ====================================
> *IF* an ULE encryption is needed, then some extension header can be
> defined to provide it, so the SNDU would be like :
> 
> -  [ULE_Header] [DVB_MAC*] [SEC_Header] [xxx SNDU Payload xxx]
>        |
>        +--> Type = sec_header
>   (*) if MAC addres bit is '0'
> 
> 
> -  The SEC_Header would be
>   +---+---+---+--//  ..... // ----+
>   |   NH  | L |  security params  |
>   +---+---+---+--//  ..... // ----+
> 
>   with NH = Type of SNDU payload (IP, IPv6, ...)
>        L  = Length of SEC_Header
> 
>   security params will define key material, type of security
>   (encryption, authentication, ....), algo, whatever ...
> 
>   In the extension headers I proposed, the SEC_Header would be one
>   of the "drop packets if unknown"  type.
> 
> - The SNDU payload woul be clear/encrypt/padded accordingly to what
>   params will be found in SEC_Header.
> 
> With that approach, the only thing needed is to include the Extension
> Headers mechanism definition in the ULE base specs. Then ALL that
> SEC_Header stuff can be described in a separate doc, and good luck with
> the (re)keying framework/protocols, security analysis ...
> 
> Regards.
> Alain.