-------- Original Message --------
Subject: Réf. : RE: Thoughts on the impact of Signalling security on
IP traffic
From: Stephane.Combes@alcatelaleniaspace.com
Date: Wed, October 26, 2005 5:57 am
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
Cc: ipdvb@erg.abdn.ac.uk
Hi Marie-José,
I admit that a conventional hub-and-spoke DVB network will not have
more stringent requirements than a DOCSIS network. But this is not the
case of mesh DVB-RCS networks (eg Amerhis system). Here the MPEG-2 mux
is on-board the satellite and the signalling is generated by a Network
Control Center
(NCC) which is just like any other sender/receiver. Therefore this NCC
is probably easier to impersonate than a cable headend.
Regarding preventing the return channel to be monitored, this is a
very important issue for the most "sensible" networks. And IPSec
cannot help here...
As a general comment on the current discussion thread, my feeling is:
- Securing DVB and MPEG-2 signalling seems a bit out-of-scope to me.
The current I-D mostly concentrate on securing ULE (and ULE
signalling). It is true that "the integrity of control and management
message in MPEG-2 networks" appears as an optional requirement in the
I-D. But perhaps this is too vague and we should first concentrate on
ULE and not go down to MPEG.
- We can discuss DVB and MPEG signalling security but this issue
should probably be owned by the DVB Forum or by groups which have
developed some specific additional signalling protocols (e.g. SatLabs
for RCS protocols)
cheers,
Stéphane
Marie-Jose
Montpetit Pour : ipdvb@erg.abdn.ac.uk
<marie@mjmontpet cc : ipdvb <ipdvb@erg.abdn.ac.uk>
it.com> "H.Cruickshank" <H.Cruickshank@eim.surrey.ac.uk>
Stephane Combes/ALCATEL-SPACE@ALCATEL-SPACE
25/10/2005 21:53 Laurence Duquerroy/ALCATEL-SPACE@ALCATEL-SPACE
Veuillez "S.Iyengar" <S.Iyengar@surrey.ac.uk>
répondre à Objet : RE: Thoughts on the impact of Signalling security on IP traffic
Marie-Jose
Montpetit
I ping'ed one of our security people here at Motorola and please find
below what he had as a comment:
"In the case of DOCSIS, we had the debate a few years ago on whether
or not it is easy to impersonate the headend and modify the contents
of a DOCSIS downstream, which is just an MPEG-2 multiplex. It was
decided by the working group that such an attack would be too costly
and impractical - for HFC cable networks at least. The same probably
applies for satellite networks.
This email suggests that the return channel could be monitored to
determine if an STB is logged in or not. As the email suggests, IP
traffic can be protected with IPsec - but generally any IP stack
including the one over DVB can be modified to include IPsec."
I think the group should look a bit more at what was done on the cable
side?
/mjm
-------- Original Message --------
Subject: Re: Thoughts on the impact of Signalling security on IP
traffic
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Tue, October 25, 2005 11:41 am
To: "S.Iyengar" <S.Iyengar@surrey.ac.uk>
Cc: ipdvb <ipdvb@erg.abdn.ac.uk>, "H.Cruickshank"
<H.Cruickshank@eim.surrey.ac.uk>, "stephane.combes"
<stephane.combes@space.alcatel.fr>, "Laurence.Duquerroy"
<Laurence.Duquerroy@space.alcatel.fr>
Here are some thoughts... Comments welcome!
Gorry
---
Some of the L2 signalling security properties include:
- No authentication of the signalling source. The layer-2 signalling
entity is often not be the encapsulation gateway itself.
- No encryption (but sometimes this is needed to bootstrap terminals).
- Integrity check is a CRC-32. This is relatively weak compared to a
cryptographic hash. (Should the forging of table contents needs to
be
considered?)
- (re)multiplexors do modify (or insert new SI tables), but there is
no security association with these devices within an MPEG-2
Transmission network.
- Modification/Denial of the SI information could result in
association
of a
different stream with the service, or an inability to identify the
TS Logical Channel (PID) that is used for a service.
Threats from interception of Forward link signalling.
In current MPEG-TS networks, the forward link signalling is not
encrypted.
Eavesdropping of the signalling information does not reveal any
information
which is not available to all receivers.
In the case of two-way networks, forward link signalling can reveal
traffic
parameters of the return links from specific users. This information
can also reveal the status of specific terminals (logon/logoff, etc)
and the timing and transmission parameters used by these terminals.
Some of these threats could be reduced by using IP-based signalling
[ref] and appropriate IP-level security mechanisms (e.g. IPsec).
Replay/Jamming
- SI information is required to associate PID values with Streams
and therefore to demultiplex the data at the Receiver.
- In two-way systems, denial of forward signalling may also prevent
link transmission in the return direction.
- Jamming/interception may also occur in the return link direction.
In
this
case, forged return link signalling could acquire return link
bandwidth,
or
modify the state of a terminal as perceived at the network control
centre.
These threats can be exploited as a DoS attack.
- SI information may be sent periodically. If the time of
transmission is predictable, this could be "jammed" resulting in
loss of signalling at
the
receiver, which is a DoS vulnerability. It requires access to the
stream
-
either on the air interface (e.g. A different transmitter injecting
a
signal
that is Received (e.g. On an antenna side-lobe).
- Modification of SI can also be a DoS attack, this requires access
to
the
network components (multiplexors, etc) and/or connecting physical
media -
a
man-in-the-middle attack.
Research Department/Advanced Telecom Systems -- R&D Engineer Tel :
+33 53435 6938 / Fax : +33 53435 5560 Porte : W219 / E-Mail :
stephane.combes@alcatelaleniaspace.com
This message and any attachments (the "message") is intended solely
for the addressees and is confidential. If you receive this message in
error, please delete it and immediately notify the sender. Any use not
in accord with its purpose, any dissemination or disclosure, either
whole or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. ALCATEL ALENIA SPACE
(and its subsidiaries) shall (will) not therefore be liable for the message if modified.
Ce message et toutes les pieces jointes (ci-apres le "message") sont
etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le detruire et d'en
avertir immediatement l'expediteur. Toute utilisation de ce message
non conforme a sa destination, toute diffusion ou toute publication,
totale ou partielle, est interdite, sauf autorisation expresse.
L'internet ne permettant pas d'assurer l'integrite de ce message,
ALCATEL ALENIA SPACE (et ses filiales)
decline(nt) toute responsabilite au titre de ce message, dans
l'hypothese ou il aurait ete modifie.