In their basic form, IP packets are sent in-the-clear across networks and the internet, that is, without any form of encryption. Interception is possible on compromised or shared networks, allowing attackers to read packets and, in some cases, modify and resend them if they are able to position themselves as a man-in-the-middle. The internet is effectively an untrusted network as we have no idea who has access to it and who is monitoring our data. For some applications this isn’t really an issue, but for others, it is. For example, a broadcaster will care deeply if unknown people can see, record, or tamper with their high value content when it is transferred over the internet.

Furthermore, the ability to intercept and manipulate traffic is particularly concerning as it lays the field open to malicious payloads or exploited application data, which in turn can be used to infiltrate IP connected devices. And we haven’t even touched on content being substituted for an altogether different message (channel hijacking).

Although broadcast networks provide a degree of isolation as they are protected behind firewalls with network address translation functions, the real challenge becomes apparent when a broadcaster wants to stream media to other facilities across an unsecured network such as the internet.

Remote Security

Outside broadcasts require a network connection between the remote event and the broadcast facility. Using the internet is by far the most cost-effective solution as custom video and audio circuits or leased lines are often prohibitively expensive. However, connecting the outside broadcast to the studio through the internet is going to put the media streams at unacceptable risk.

A Real-World Failure Scenario

To understand why this matters, consider a typical outside broadcast contribution workflow.

A live sports event is being captured and encoded on-site, with the video stream sent over the public internet to the broadcast facility. The stream is compressed using a low-latency codec and transmitted as a series of IP packets towards the studio.

Without encryption, an attacker positioned within the network path, for example, on a compromised router or shared upstream provider, can observe the traffic and analyze its structure. Even if the content itself is not immediately decoded, the flow characteristics such as bitrate, timing, and destination, are fully visible.

More critically, if the attacker is able to establish a man-in-the-middle position, they can begin to interfere with the stream. This could take several forms:

• Packet Injection: inserting crafted packets into the stream, potentially causing decoder instability or visible artefacts.
• Packet Modification: altering payload data, leading to corruption of video frames or audio distortion.
• Stream Substitution: redirecting the flow to an alternative source, effectively hijacking the contribution feed.
• Traffic Analysis: inferring event timing, commercial breaks, or operational patterns from bitrate and flow behavior alone.

In a live broadcast environment, even brief disruptions can have significant impact, from visible glitches on-air to complete loss of signal.

By introducing IPsec in tunnel mode, the entire original packet is encrypted and authenticated. This means that even if an attacker can observe the traffic, the payload is unreadable, and any attempt to modify or inject packets will fail integrity checks at the receiving endpoint.

Crucially, the attacker no longer has sufficient visibility or control to meaningfully interfere with the stream, reducing the attack surface from active manipulation to little more than blind disruption.

IPsec is a collection of Layer 3 protocols dating back to the 1990s that provide two fundamental functions: data integrity and confidentiality. Integrity guarantees the data packets haven’t been tampered with through cryptographic authentication, and confidentiality stops unauthorized people from viewing and recording the data payload, and hence the streamed media. Although the data packets can be seen and routed across the network, the data in the payload can only be decoded by somebody possessing the necessary keys.

Virtual Private Networks (VPNs) are one of the methods that use the IPsec protocols. Not only are they a tried and tested method of providing security, but their use is ubiquitous throughout the internet and have proved their worth.

Encrypting Packets

IPsec VPNs operate at Layer 3 of the OSI model, meaning they secure IP traffic at the network level. This differs from protocols such as Transport Layer Security (TLS), often referred to as Secure Sockets Layer, or SSL, which operate above the transport layer and secure specific applications such as web traffic or streaming protocols.

In practical terms, IPsec can protect all traffic flowing between two endpoints, regardless of the application, whereas TLS is applied on a per-service basis. Both approaches are widely used and secure when correctly implemented, but IPsec is particularly useful for site-to-site connectivity where entire networks need to be protected transparently.

In the most common VPN configuration, known as tunnel mode, IPsec encapsulates the entire original IP packet (including its header) and encrypts it. A new outer IP header is then added in-the-clear so that the packet can be routed across the internet.

Fundamentally, the IPsec VPN will prevent unauthorized users from viewing or modifying the media, assuming the security of the keys is maintained.

Establishing a VPN is a two-stage process. The first part creates a secure control channel over the internet between two trusted partners, such as IP routers, allowing cryptographic parameters and keys to be negotiated. These keys are then used during phase-2 to encrypt the IP packets so that any snoopers will only see seemingly random data.

To establish the first stage, the IKE (Internet Key Exchange) phase-1 protocol takes place by initiating a secure association between the two devices.

This can use pre-shared keys or digital certificates for authentication.

During the IKE phase-1 sequence, security policies are negotiated, and a secure channel (the IKE Security Association) is established. This is then used to secure the negotiation of phase-2 parameters.

IKE phase-2 establishes the IPsec Security Associations that are used to protect the actual data traffic. In tunnel mode, this results in the encryption of the entire original IP packet and the addition of a new outer IP header that remains in-the-clear for routing purposes.

Changing IP Addresses

It might seem a bit strange that we have gone to all the trouble of encrypting the entire IP packet, including the header, and then added a new header without encryption. However, this outer header serves a different purpose: it allows the packet to be routed across the public internet between the VPN endpoints.

In Figure 1 there are two routers, one at the OB and one at the studio facility. Each of these will have its own IP address for the connection to the internet, and it is these addresses that are used in the additional IP header. This means that anybody observing the traffic will only see the addresses of the VPN endpoints, not the internal devices such as cameras or microphones.

Only devices that possess the correct cryptographic keys can decrypt the inner packet and verify its integrity using authentication checks. Unauthorized users cannot modify the encrypted payload or inner headers without detection, as any tampering will cause the integrity checks to fail and the packet to be discarded by the receiving VPN endpoint. Routers within the internet do not need access to any encryption keys; they simply forward packets based on the outer IP header.

Compliant Routers

This whole process relies on the VPN-enabled routers at both the OB and broadcast facility being correctly configured. Phase-1 is initiated when traffic matching the defined security policies is detected, at which point the devices establish the secure association and proceed to phase-2.

Once established, phase-2 remains active for as long as traffic is flowing, with security associations periodically refreshed. This helps minimize latency impact from repeated setup, although encryption, encapsulation, and potential packet fragmentation must still be considered in real-time media workflows.

The fundamental method of operation when working with the internet is that we assume the network is untrusted. Both interception and tampering are potential risks for broadcasters, but they can be effectively mitigated by using security protocols such as IPsec VPN, alongside good operational practices such as strong authentication and key management.

And just in case you wondered how IPsec-encrypted packets manage to get through firewalls: IPsec uses protocols such as ESP (Encapsulating Security Payload) for data transport, while IKE uses UDP (typically ports 500 and 4500). In networks that use NAT, IPsec traffic is often encapsulated within UDP (NAT traversal) to ensure compatibility with standard firewall and routing behavior.