Networking fundamentals

Video, voice, management and alarm traffic have different network requirements. Plan for each flow's capacity, timing, packet loss and recovery needs.

Overview#

Physical security traffic combines bursty events, management operations, time sensitive voice/video, discovery multicast, firmware transfer, and sometimes control. Design for their different properties rather than placing all “security devices” into one undifferentiated network.

Layered path#

application message
  -> optional TLS/DTLS/security framing
  -> TCP stream or UDP datagrams
  -> IPv4/IPv6 packets
  -> Ethernet/Wi-Fi/VPN/link
  -> switches, routers, firewalls, NAT, WAN

Capture both endpoints, direction, DNS name, address family, transport, port, connection initiator, authentication, expected rate/size, and failure behaviour in an interface inventory.

TCP and UDP#

TCP is a reliable ordered byte stream, standardised by RFC 9293. Applications still need message framing, deadlines, cancellation, keepalive/health semantics, reconnect, and protection against stalled peers. A successful write only means bytes entered the local stack.

UDP, specified by RFC 768, preserves datagram boundaries but doesn't guarantee delivery, order, duplicate suppression, congestion handling, or peer identity. It is common for discovery, multicast, RTP, and constrained/field protocols. The application or enclosing protocol must provide required reliability and security.

MTU and fragmentation#

Paths have a maximum transmission unit (MTU). Tunnels, VPNs, IPv6, and WAN services can reduce effective payload size. Fragment loss can discard a whole datagram; middleboxes may mishandle fragments. Prefer protocol defined packetisation and path MTU aware libraries over arbitrary large UDP messages. Never assume a payload that worked on one LAN works across a routed or tunneled path.

Bandwidth isn't enough#

For video and voice, plan:

• average and peak bitrate, including I frame bursts;
• simultaneous live views, recording streams, playback, export, and analytics;
• packet loss, jitter, latency, and retransmission effects;
• multicast replication points and receiver joins;
• storage/WAN catch up after outage;
• encrypted tunnel and protocol overhead;
• failure of one link or recorder.

Quality of Service (QoS) markings don't create capacity. Trust and remarking policy must be consistent end to end, and control/management traffic must not be starved by video.

Address family and naming#

Support IPv4 and IPv6 intentionally. RFC 8200 defines IPv6; IPv6 link local addresses, neighbour discovery, multicast, extension headers, and firewall policy differ from IPv4. Avoid disabling IPv6 while leaving it unmonitored.

Use DNS names for services where certificates, migration, or redundancy require stable naming, but design for DNS outage and cache behaviour. Device identity must not equal IP address.

Network controls#

• Default deny inter zone policy based on documented flows.
• Separate observation, control, management, and guest/user paths where practical.
• Restrict device egress to named services and required destinations.
• Protect and monitor DHCP, DNS, time, certificate, update, and identity dependencies.
• Use network access control as one signal, not proof the endpoint is trustworthy.
• Preserve an out of band recovery path for critical controllers and gateways.

See IP addressing, routing, and ports, multicast, discovery, and NAT, and trust boundaries.

Section overview · Wiki home