[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Réf. : RE: Thoughts on the impact of Signalling security on IP traffic
Just a toe back into the security discussion - even though US terrestrial broadcasters (my interest group) won't be using ULE anyway. I posted some thoughts a while back- they still seem consistent with all data available to me. The transport of ULE packets in MPEG-2 TS is the responsibility of someone else<and I agree out of scope here>. If you don't trust the transport security provisions, either don't use it or convince the provider to improve them. Or add a layer that reduces your payload and increases your complexity.
Attempting to define how a transport shall be constructed when there are other standards that already do that just adds to the list of voluntary standards one must decide among when selecting what to support.
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N St. NW
Washington DC 20036
202 429 5418
-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of Marie-Jose Montpetit
Sent: Wednesday, October 26, 2005 8:00 AM
To: Stephane.Combes@alcatelaleniaspace.com
Cc: ipdvb@erg.abdn.ac.uk
Subject: RE: Réf. : RE: Thoughts on the impact of Signalling security on IP traffic
Should Amerhis drive all the requirements for MPEG/ULE security? We should make sure that IP over DVB does not become another IP over satellite - that too many people think it is BTW.
And yes: we should do ULE and leave DVB (and other groups) to address the big picture.
/mjm
> -------- 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.