-----Original Message-----
From: owner-ip-dvb@erg.abdn.ac.uk [
mailto:owner-ip-dvb@erg.abdn.ac.uk]On
Behalf
Of Laurent.Claverotte@space.alcatel.fr
Sent: Thursday, February 26, 2004 6:11
PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Réf. : Re: Encryption control of
SNDU
Importance: Low
Dear All,
I am working on
layer 2 security solution for broadband satellite systems
based on the
DVB-RCS standard (part 9.4 of the EN301790) and I see several
advantages for
an ULE-level encryption as explained below.
Why ULE level encryption
?
1. Role Model and security requirements
Satcom systems based on
DVB-S/DVB-RCS are operated by Access Network
Operators that want to provide
their customers (ISP) with security
services.
Common targeted security
services are : terminal authentication and data
confidentiality (for the
unicast and multicast streams) between the gateway
and the terminals (also
limited to the satcom system).
The objective is to provide the same level of
privacy as the terrestrial
links.
Moreover, in the same time, the ISP may
want to provide end-to-end security
services to the end-users (based on the
well known IPSec).
As a matter, I think this is really important to
understand that both
security solutions ((ANO to ISP) and (ISP to End-users))
can co-exist and
are economically viable.
2. Solutions
comparison
For the end-to-end security solution between the ISP and the
end-users, it
is obvious that IPSec or an application security (TLS or SSL)
are largely
deployed and accepted by the telecom world.
Regarding the
satcom security (between the gateway and the terminals),
different solutions
were envisaged by Alcatel Space :
- DVB-S Common Scrambling (security
solution deployed for the digital
broadcast television) : this solution is
not compliant to the granularity
security requirement (scrambling per PID and
not per unicast user!).
Moreover, key distribution techniques are one way
only and does not benefit
from the interactive return link.
- IPSec has
lot of drawbacks : it is not a L2 solution, it is an
end-to-end
technology, it can interfere with the end-to-end security
solution, it can
interfere with satellite techniques (PEP), it does not
provide encryption
of multicast flows and it generates many overheads and
number of
signaling messages!!!!!! Lots of comparison studies and
simulations have been
performed by Alcatel leading to reject this
solution!!
- Proprietary
solutions close to the DVB-S CS : same conclusion as DVB-S CS
- DVB-RCS
security solution : we believe that it is the most interesting
solution
regarding the intrinsic satcom security as it complies with the
ANO
security requirements.
Indeed, it is a layer 2 solution (control plane
defined in the DVB-RCS
standard and traffic plane below the IP layer)
enabling to encrypt not only
IP streams but also Ethernet frames (PPPoE for
example) or other
protocols... It can support unicast or multicast streams
encryption.
Moreover, regarding the performances, It largely reduces the
number of
signaling messages and overheads (main worry in satcom!).
It is
currently based on the 2 bits payload_scrambling_control of the MPE
header
providing the information if the packet is encrypted or not and with
which
key (odd or even)...... and this essential information would be
canceled in
the ULE definition.
3. Concurrent systems and standardization
As you
know, the main concurrent to the european ETSI DVB-S/DVB-RCS
standards is the
US DOCSIS standard that includes (in its baseline!!!) a
layer 2 security
solution providing terminal authentication and
confidentiality (called
BPI+).
Alcatel believes that it is really important to make the DVB-RCS
standard
evolve (current Satlab contributions) to offer a complete DVB-RCS
security
solution that can be compared to the US DOCSIS standard.
That
would really be worrying if the ULE encapsulation could not include
this
feature because it would not be compliant with the DVB-RCS
security
solution.
I hope that you will understand my
concern.
Regards.
Laurent Claverotte
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.comSincères
Salutations / Best regards
Laurent Claverotte
ALCATEL
SPACE
DSR/DRE
Tel : 33 (0)5.34.35.46.47 / Fax : 33
(0)5.34.35.61.69
E-Mail :
Laurent.Claverotte@space.alcatel.fr