[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Réf. : Re: Encryption control of SNDU
Hi everyone,
I like to support for the requirement of Encryption/security at L2 with in satellite network(Terminal and Gateway) for any confidential informations, both signaling and data packets.
Further to the extension header for ULE,
it can be made option as we have for destination mac address, without effecting any implementation and design
- [Dest Mac Addr bit][ext. header present bit][ULE_Header] [DVB_MAC*] [Ext. Header*] [xxx SNDU Payload xxx]
we can change 15 bits of payload length into 14 bits.. which is much more than the present DSMCC payload/section length, which is 12 bits.
with that bit we can define any extension header is present for any future updations to the ULE,
the Ext. Header is defined as
+---+--------+---// ..... // ----+
|EHT| NHB & L| Ext.Header params |
+---+--------+---// ..... // ----+
where, EHT = 1 byte of extension header type field. Which has to be defined, might be ULE specific.
L = LSB 7 bit of ext. header parameter length, i.e. supports 127 bytes.
NHB = MSB 1 bit contains if there is any other extension header present.
Ext.Header params = variable length based on the ext. header parameter length.
Best Regards,
William.
On Thu, 26 Feb 2004 Tarif.Zein-Alabedeen@space.alcatel.fr wrote :
>
>
>Hi alain and every body
>Concerning point I, let me go back to dvb-rcs : encryption at the
>encapsulation layer
>(which is now MPE but may become ULE in the future) has been provisioned
>and the way it is
>controlled by the 2 bits field in the MPE header has been clearly specified
>(see my precedent mail)
>
>I am not aware of the exact reasons which led poeple who contributed to the
>dvb-rcs definition to do this
>may be they did something wrong or expected a functionnality that will
>never be used....!!!!
>But it is more probable that they had real reasons to do this (so we can
>avoid to reinvent the wheel as you said)
>Any one has an idea?
>
>I see an example which could make case 3 difficult to apply. It concerns
>bridging
>When forwarding (in the Gateway for example) is performed by bridging (as
>in Ethernet switches) and not by routing (as routers),
>IPsec can not apply because the GW handles frames and not datagrams (am I
>wrong?). Such case may happen with e.g a PPPOE access scheme.
>So if IPsec is not applied end-to-end (but this can not be controlled by
>the satellite segment), traffic will be transmitted clear on the
>sat interface
>
>Concerning the use of the extension header, the main question is : when
>encryption is applied at ULE level, do we need the encryption control field
>in all SNDUs or not. If yes, the extension header solution may turn to be
>inefficient since it would lead to about 5 bytes extra header (taking your
>example below). I submitted this question to Alcatel's security experts but
>would be great if others in this groupe could also think about it and make
>suggestions
>
>regards
>
>
>
>
>
>Alain RITOUX <alain.ritoux@6wind.com>@erg.abdn.ac.uk on 26/02/2004 15:25:15
>
>Veuillez répondre à ip-dvb@erg.abdn.ac.uk
>
>Envoyé par : owner-ip-dvb@erg.abdn.ac.uk
>
>
>Pour : IPDVB <ip-dvb@erg.abdn.ac.uk>
>cc :
>Objet : Re: Encryption control of SNDU
>
>
>
>
>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
>
>
>
>
>
>
>T. Zein
>
>ALCATEL SPACE
>DRT/RST -- Ingénieur Systèmes
>Tel : 0534356918 / Fax : 0534355560
>Porte : W.220
>
>
>
>