Re: Encryption control of SNDU

[Alain RITOUX <alain.ritoux@6wind.com>]

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:
>
> * 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.

I would say No, because :
  - I don't really understand the need for ULE level encryption
    see point I)
  - If needed, it can be separated from ULE base specs. see point II)

I) Why ULE level encryption ?
=============================
I still don't sse the need for an ULE-level encryption, because
I see 3 possibilities of encryption
1) At MPEG-2 level, i.e. same encryption for whole content of a PID
2) At ULE level, i.e. encryption on a per SNDU basis for the case as
 Tarif said, where PID is mutli-receiver (belonging to different groups)
3) At IP level

but what can distinguish 2 SNDU ?
  - IP addresses ?
  - DVB Mac addr ?
But the DVB Mac addr is itself the result of IP address/prefix
resolution (which can use destination and/or sources)
So I think it can all be expresed in term of either destination and/or
source Addresses, which can perfectly be handled by IPsec. So 2) and 3)
seem to me to offer the same granularity and 3) is already defined and
working.

This is my current understanding,  and a counter-example where 2) would
solve a use-case and not 3) would be very helpfull.
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.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com