IP Security For Broadcasters: Part 2 - The Problem To Be Solved

By assuming that IP must be made secure, we run the risk of missing a more fundamental question that is often overlooked: why is IP so insecure?


All 12 articles in this series are available in our free 82 page eBook ‘IP Security For Broadcasters’ – download it HERE.

Articles in this series:


Broadcasters have been relatively lucky as we have always worked in a closed system. Not just the network and infrastructure, but the whole ecosystem too. The whole culture of broadcasting was limited to a relatively small group and specialist knowledge was needed to even view a video tape.

We worked with transport streams such as PAL, NTSC, SDI and AES, that needed specialist equipment to decode and decipher them. Video tape needed a massive investment in equipment to play and view the material; copying it onto VHS or similar domestic formats was not as easy as the layperson might think it should be. And it was easy to see if somebody was breaking into your network as they had a pair of wire cutters in their hands.

There was a much greater level of trust. We would quite happily send high-value media across telco networks or a satellite feed to other broadcasters. And even when a stream needed to be encrypted, it could easily be done by using point-to-point encryption systems with smart cards to enable specific decoders.

Flexible Open Systems
IP has brought a system of open connectivity to the world. Again, this isn’t just about the infrastructure, but also the whole ecosystem. When IP was first developed back in the 1970s and 1980s, it was designed to be an unreliable delivery system that does not guarantee the delivery of a datagram to the destination. Although this may seem like an oversight in its design, and possibly even an error, it actually turns out to be one of its greatest strengths.

By not burdening the IP protocol with guaranteed delivery it has become incredibly flexible in terms of its ability to hop between different transport stream technologies without intervention. An IP datagram, with the correct interface, can easily switch between ethernet and WiFi or HDLC. The ethernet, WiFi and HDLC frames encapsulating the IP datagram will change, but the actual IP datagram does not change. In other words, when switching between layer-2 transport streams, nothing in the IP header or payload needs to be amended.

Purists may suggest that the TTL (Time to Live) field being decremented is a transport stream dependency, however, the TTL is a feature that is independent of the transport stream and is used to stop the possibility of an IP datagram getting stuck in an endless network routing loop.

The openness of the IP header makes the international routing of IP packets possible. If the header was encrypted then it would be almost impossible to route packets between networks, especially if they were not linked within the same broadcaster. The open IP header, combined with protocols such as BGP (Border Gateway Protocol) make the internet possible. 

Figure 1 – when a laptop sends an IP packet to the server the IP packet is first encapsulated in a WiFi frame, the layer-2 switch has already ascertained that the frame is being sent to the server and will substitute the WiFi frame for the Ethernet frame. Critically, the IP packet does not change.

Figure 1 – when a laptop sends an IP packet to the server the IP packet is first encapsulated in a WiFi frame, the layer-2 switch has already ascertained that the frame is being sent to the server and will substitute the WiFi frame for the Ethernet frame. Critically, the IP packet does not change.

IP payloads can and are encrypted, but layer-3 routers and layer-2 switches can happily transfer packets and frames based on the header contents only. The fact that the payload is encrypted has no relevance to them.

Unfortunately, the open IP header means that anybody with access to the network also has access to the IP packets. And if the payload is in the clear, that is, not encrypted, then a hostile actor has the potential to cause havoc in a network. Packets can be intercepted, their contents monitored, decoded, and changed.

Intercepting IP Packets
Once a packet stream has been intercepted, it’s relatively easy to use readily available tools such as Wireshark to receive the streams and decode the data. From here, it’s a trivial job to change the packet payload and replace the original packet. Anybody with even a basic understanding of C or Python could write code to achieve this and is in effect how man-in-the-middle attacks operate. This is one of the reasons HTTPS (Hyper Text Transfer Protocol Secure) was developed.

In HTTPS the server and host exchange SSL (Secure Socket Layer) keys that are used to encrypt the data in the IP packet payload. Therefore, anybody intercepting the packet will be able to decode the header but not the encrypted payload data.

It turns out that IP’s greatest strength is potentially its greatest weakness. But this is what IP security is all about. IP security is recognizing that we are working in an open environment where we assume the packets can be intercepted and changed. IP security is stopping unauthorized access to the network and hence the datagrams, as well as stopping anybody changing the contents if this isn’t feasible.

One type of network where we assume that packets can be recorded and changed is WiFi. By definition, the data frames are being broadcast all around us and anybody within a reasonable distance to the router can see the WiFi streams. A host of WiFi sniffers are easily available that show this, even for cell phones. Therefore, access to the WiFi network is heavily restricted and a great deal of work has gone into stopping hostile actors intercepting and changing the packet data. In the extreme they may be able to see the traffic if it isn’t encoded, but they won’t be able to change it as they don’t have access to the network.

Vulnerabilities
Another area of security concern is that of vulnerabilities. When we speak of vulnerabilities, we’re usually referring to operating systems running on computers, servers, and cell phones etc. Any unethical hacker will be aware of vulnerabilities in operating systems and will work to exploit them. Memory buffer overflows continue to be a source of vulnerability leading to operating system providers and programming language designers continuously working to remove these vulnerabilities.

Security and efficiency are often traded as the more secure a system becomes, then the less efficient are the execution speeds. An example of this is a software functions return-address monitor. The monitor reads the return-address of a function when it is being executed to check for any changes as a change in the return address often indicates malicious or suspicious behavior. But this level of monitoring often incurs a high level of efficiency overhead.

Although high level languages such as Python, PHP, Java, and Perl often catch buffer overrun attacks and will cause runtime exceptions to halt execution, there are no absolute guarantees as these languages often have low level languages such as C at their core and many of the buffer overflow errors are a result of badly written C libraries, or incorrect assumptions about the environment they are operating in.

Security Flexibility Trade Off
IP is one of the most important advances in broadcast television. But a trade-off between security and flexibility was made during its inception and we must be aware of this when building our IP systems. Also, software vulnerabilities continue to manifest themselves as operating systems and programming languages improve. As vendors and designers become aware of them, they are fixed quickly resulting in new version releases of operating systems and programming languages. Another reason to constantly keep servers and workstations up to date with the latest software releases.

Part of a series supported by

You might also like...

Designing IP Broadcast Systems: Integrating Cloud Infrastructure

Connecting on-prem broadcast infrastructures to the public cloud leads to a hybrid system which requires reliable secure high value media exchange and delivery.

Designing IP Broadcast Systems: Where Broadcast Meets IT

Broadcast and IT engineers have historically approached their professions from two different places, but as technology is more reliable, they are moving closer.

Encoding & Transport For Remote Contribution At NAB 2024

As broadcasters embrace remote production workflows the technology required to compress, encode and reliably transport streams from the venue to the network operation center or the cloud become key, and there will be plenty of new developments and sources of…

KVM & Multiviewer Systems At NAB 2024

We take a look at what to expect in the world of KVM & Multiviewer systems at the 2024 NAB Show. Expect plenty of innovation in KVM over IP and systems that facilitate remote production, distributed teams and cloud integration.

Wi-Fi Gets Wider With Wi-Fi 7

The last 56k dialup modem I bought in 1998 cost more than double the price of a 28k modem, and the double bandwidth was worth the extra money. New Wi-Fi 7 devices are similarly premium-priced because early adaptation of leading-edge new technology…