RE: Thoughts on the impact of Signalling security on IP traffic

[Marie-Jose Montpetit <marie@mjmontpetit.com>]

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.