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. 

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.