[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
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.