Securing TDM over IP: IPsec Scope, MTU and Circuit Quality

First confirm which service segment needs protection

After sending legacy E1 circuits into an IP network, data passes through switching, routing, and possibly shared links. Normal service does not mean communication is encrypted; using fiber does not automatically protect packet contents. TDM over IP describes transport and circuit recovery, not a security protocol that uniformly includes confidentiality. A plan should clearly list which network segments are trusted, which need extra protection, and who manages the gateways.

Security goals separately include who is allowed to access, management permissions, content confidentiality, integrity, and service availability. VLAN grouping, account permissions, routing authentication, and encryption answer different questions. Deploying one of them should not be declared as completing all. For a specific project, check against the actual data path and device capabilities, rather than adding a lock to every line on a diagram.

Routing authentication does not protect circuit content

RIP is used to exchange routing information, while TDM over IP packets carry service traffic. The two types of traffic have different roles. Authenticating routing updates mainly helps judge whether the corresponding updates are trustworthy; it does not automatically encrypt circuit data. Nor can the two be combined into a universal protocol that has both routing and encryption. Related security mechanisms should be configured and verified separately.

Management login protection also has its own scope. If HTTPS or SSH is supported by the model, it can protect the corresponding management session, but it does not mean all E1 carried content passing through the gateway is encrypted. TLS is also not a ready-made switch that can be arbitrarily applied to any bearer packet; it requires application or protocol implementation support. Do not continue to use the outdated SSL name as a capability promise for a current security solution.

Between which two endpoints does an IPsec tunnel work?

One approach is to deploy security devices at both ends that support the corresponding IPsec capability, so that IP packets from the circuit gateway pass through the tunnel. In the diagram, the circuit gateway and the external security gateway are two independent roles: the security endpoint applies protection to matching traffic, and the remote end verifies and restores the corresponding original packets, then hands them to the circuit gateway for processing. This is only a deployment concept; it does not mean all TDM products have built-in IPsec.

The protection scope should be marked along the real path. The short link from the circuit gateway to the local security endpoint, if there is no other protection, is not covered by this tunnel. Whether it is complete end-to-end protection depends on endpoint locations and other network segments. Capabilities such as authentication, encryption, and anti-replay depend on the security mechanism used and its effective configuration. You cannot assume all services are protected just because there is a VPN name.

Policies and device identities must correspond

Both sides check trusted endpoints, traffic that needs to enter the tunnel, allowed sources, and management paths, and choose security configurations according to current product and organizational requirements. The issuance, update, and revocation of keys, certificates, and accounts also need maintenance records. A general article does not provide a shared default key applicable to all products, and certainly cannot use configurations from unknown sources to overwrite production devices.

Service data, device management, and routing control can use different access scopes. Restricting management sources does not mean circuit packets will definitely pass, and allowing management addresses does not require allowing all services at the same time. Check access and return paths in both directions, and record which traffic is protected according to policy and which is denied. Security devices can also become new failure points; their capacity, redundancy, and maintenance access should be included in the plan.

Why does encapsulation overhead affect circuits?

A security tunnel adds headers and corresponding protection overhead, and consumes device processing resources. MTU is the packet length constraint that a certain path segment can carry; the original bearer packet plus the tunnel may no longer meet the original path conditions. How exactly to fragment, avoid fragmentation, or discard depends on the protocol, configuration, and device. You cannot uniformly promise that the tunnel will automatically solve all length problems.

Therefore, you need to check the circuit gateway’s packet length, path MTU, and security device settings at the same time. Larger service blocks may reduce part of the encapsulation ratio but increase collection waiting; smaller service blocks increase packet rate and overhead. Do not choose the maximum value just for efficiency. The packet layers in the diagram are a functional illustration; they do not replace model parameters with fixed byte counts or algorithms, nor do they indicate that all outer addresses are encrypted.

Arrival changes cannot be hidden by encryption

Security processing, shared egress queuing, and tunnel re-establishment may change packet arrival times. The receiving gateway still needs to process services in order and continuously output E1 with a suitable clock. Buffering can leave room for data that arrives early or slightly late, but it cannot recreate lost original content. The tunnel being online and the circuit meeting quality requirements are two states that need to be observed separately.

Critical services should also evaluate the impact of security connection updates and abnormal recovery on calls or data. You cannot remove all protection for a long time just to keep services from stuttering, nor ignore that the circuit already has bit errors or frequent alarms just for superficial security. Record results under normal, security change, and approved fault conditions, then decide according to project requirements whether to accept the bearer solution.

Check capabilities with FCTEL gateways

The Feichang Technology FCT-E1 and FCT-E4-M details describe E1 circuit access, clock recovery, configurable packet length, VLAN, and loopback maintenance directions, and can serve as reference objects for bearer equipment. FCT-E4-M also describes mapping of different destination IPs and ports, suitable for managing corresponding circuits one by one. These capabilities can help plan and observe services, but they cannot directly imply built-in encryption, security tunnels, or complete firewall functions.

The pages checked do not provide sufficient basis to prove that these two models have all the IPsec security functions in this article’s example, so the diagram uses independent external security devices. Whether they can actually be combined must be verified against the complete path and model conditions. Clock specifications, interfaces, and firmware should also be confirmed according to valid manuals, and any low-latency statement on the web page should not be treated as a guarantee that remains unchanged after adding security processing.

Accept security and service together

First verify device identity, allow and deny rules, the actual tunnel matching scope, and management permissions in an approved test network, then add representative circuit load. On the IP side, observe packet arrival, loss, length-related anomalies, and security device resources; on the E1 side, observe loss of signal, loss of frame, bit errors, and real services. Being able to ping a management address does not prove data is encrypted, let alone cover these circuit indicators.

When packet capture or logs are used for review, permissions should be limited and data properly stored to avoid spreading service data for testing. Deliver the topology, protection scope, model versions, configuration backups, alarms, and recovery records. When adding circuits or replacing security devices later, recalculate overhead and capacity. The conclusion of a security solution must answer both who is allowed access and whether the retained circuit service still meets requirements.

Translated from the Chinese technical article. Source first published: 2024-05-06. Source last revised: 2026-10-13T11:14:38+08:00. Read the Chinese source