[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
I smiled reading this, I hope it was the intention ;-)
>From my recent experience with vulnerabilities it seems it's not the big
things that are the main issues but interesting software, firmware and
IP level threats which cost nothing but can create havoc. Use a truck
to take over a receivers is hard. To use a non secure port in the
firmware to download some harmful code to and then interfere with
eveyone is probably way easier. And BTW that could be the issue with
that satellite...
/mjm
> -------- Original Message --------
> Subject: RE: Réf. : RE: Thoughts on the impact of Signalling security
> on IP traffic
> From: "Allison, Art" <AAllison@nab.org>
> Date: Thu, October 27, 2005 2:45 pm
> To: <ipdvb@erg.abdn.ac.uk>
>
> Right...
> It is possible that someone could suitably equip a truck, drive it into a neighborhood and overpower the RF that arrives at the nearby homes. Interception and retransmission for replacement requires very low processing delay such that the real signal appears as reflection (pre-ghost) that the receiver can cancel/ignore. (If those technical constraints are not met, nothing is received - that is it effectively is simply a RF jammer - no standard can stop that. While I don't have quotes, certainly it would cost several 10s of thousands US dollars for the equipment; and for the homes in the next torus where it did not swamp the receivers it would seriously interfere with reception (jammer again). While determination of interference sources can be hard, the large panel truck with antennas on might help in this case. If the attacker were an apartment dweller, he perhaps could impact neighbors in a similar manner and be more difficult to detect. But it is not clear what benef!
> it could be obtained from this localized denial of service attack that many nearby would detect as lost of regular TV programming.
>
> After all the potential attacker can directly obtain all of the data stream and process it without interfering with anyone.
> I fail to see that discussion of a terrestrial spoofing attack is worthy of further time or IP packets. But have it...
>
> ______________
> 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 Gorry Fairhurst
> Sent: Thursday, October 27, 2005 12:45 PM
> To: ipdvb@erg.abdn.ac.uk
> Subject: Re: Réf. : RE: Thoughts on the impact of Signalling security on IP traffic
>
> When I started the thread, my comment was related to:
>
> draft-cruickshank-ipdvb-sec-req-00.txt
>
> Which includes a draft of an analysis of potential threats to the IP service when used over this type of network. To me this still seems a valid question...
>
> MPEG-2 signalling is a part of the system - and control-plane attacks are not unheard of in IP networks. (In many other networks the L2 control plane is also visibile).
>
> One conclusion may be that despite a lack of security mechanisms, such attacks are hard in most practical networks, because the physical infrastructure is itself secured (i.e. they require access to the multiplexor,modulator, etc), in contrast to WiFi networks were this is easy - to me, this seems to be the case put forward for DOCSIS. It was also put forward as a case for satellite TV broadcast networks. Although it seems the next generation of satellite on-board multiplexors could require some thought?
>
> I was primarilly thinking about terrestrial receivers - where a follow-on attack could be possible by receiving the bit-stream and then regenerating a different bitstream that was transmitted locally towards a receiver to manipulate the IP packet flow (e.g. inject data).
>
> Gorry
>
>
> Allison, Art wrote:
>
> > 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.
> >
> >
> >
> >