IPsec Challenges in Non-Terrestrial Networks (NTN)

The IPsec protocol suite provides a robust framework for securing IP networks by authenticating and encrypting IP packets, ensuring confidentiality, integrity, and authenticity. In terrestrial networks, it is a mature and widely deployed technology. With the rise of Non-Terrestrial Networks (NTNs), including satellite constellations, IPsec remains a critical component for securing backhaul links and other network interfaces. However, NTN environments exhibit characteristics fundamentally different from terrestrial networks, such as high and variable propagation delays, frequent link interruptions, dynamic network topology, and node mobility. These factors introduce significant operational challenges for IPsec as it is currently specified. For example, the IKEv2 handshake protocol, Security Association (SA) management, and anti-replay mechanisms were designed with the assumptions of a relatively stable, low-latency terrestrial network. This document analyzes the problems that arise when using standard IPsec in NTN scenarios, using the 3GPP-defined 5G NTN architecture as a concrete example. It aims to inform the IETF community of these challenges and motivate discussion on potential enhancements or alternative solutions to ensure efficient and secure communications in these emerging networks.

The following terms are used in this document.

Non-Terrestrial Network(NTN): using satellites, HAPS, Non ground platforms such as drones serve as communication nodes, forming a three-dimensional communication network together with ground base stations, allows user equipment (UE) to directly access the network through satellites or high-altitude platforms, thereby achieving global communication services.
gNB: generation NodeB
base station: a base station is a fixed device in wireless communication networks, used to achieve wireless signal transmission and data exchange between mobile devices and the core network.
ground gateway station(abbreviated as gateway): a key equipment in satellite communication systems, mainly responsible for data transfer and routing management between satellites and ground networks
AMF: Access and Mobility Management Function is one of the core functional modules of the core network, defined by the international communication standards organization 3GPP in the technical specification TS 23.501
UPF: User Plane Function is an independent functional entity responsible for user plane data processing in the 5G core network. As a core component of the 5G SBA (Service Based Architecture) defined by the 3GPP standard, it is mainly responsible for routing and forwarding user data packets, policy execution, and protocol adaptation.
UE: User Equipment refers to user terminal equipment, which is a collective term for mobile communication devices that can access cellular networks.
DN: A network providing data services, such as the internet.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

In 3GPP-defined NTN architectures, satellites can host network functions like a gNB or even a UPF. UEs connect to these satellite-based nodes, which then backhaul traffic to the core network via ground gateways. This architecture creates several critical interfaces that rely on IPsec for security, as specified in 3GPP TS 33.501.

The security of the backhaul link between the satellite and the ground is paramount. Table 1 summarizes the key interfaces where 3GPP mandates or recommends IPsec. Summary of the interfaces related to ipsec in NTN network

Interfaces	Usage	Protocol	Description in 3GPP
N2	gNB-AMF	IPsec	In order to protect the N2 reference point, it is required to implement IPsec ESP and IKEv2 certificates-based authentication as specified in sub-clause 9.1.2 of the present document. IPsec is mandatory to implement on the gNB and the ng-eNB. On the core network side, a SEG may be used to terminate the IPsec tunnel.(TS 33.501)
N3	UE-UPF	IPsec	In order to protect the traffic on the N3 reference point, it is required to implement IPsec ESP and IKEv2 certificate-based authentication as specified in sub-clause 9.1.2 of the present document with confidentiality, integrity and replay protection. IPsec is mandatory to implement on the gNB and the ng-eNB.(TS 33.501)
N4	UPF-SMF	IPsec	9.9 Security mechanisms for non-SBA interfaces internal to the 5GC and between PLMNs Non-SBA interfaces internal to the 5G Core such as N4 and N9 can be used to transport signalling data as well as privacy sensitive material, such as user and subscription data, or other parameters, such as security keys. Therefore, these interfaces shall be confidentiality, integrity, and replay protected. Roaming interfaces between PLMNs except for N32, shall be confidentiality, integrity, and replay protected. Protection for the N32 interface is specified in clauses 13.1 and 13.2..For the protection of the above mentioned internal and roaming interfaces except N32, NDS/IP shall be used as specified in [3], unless security is provided by other means, e.g. physical security. A SEG may be used to terminate the NDS/IP IPsec tunnels.(TS 33.501)
N9	UPF-UPF	IPsec	Same with N4
backhaul	gNB-CN	IPsec	9 Security procedures for non-service based interfaces 9.1 General 9.1.1 Use of NDS/IPThe protection of IP based interfaces for 5GC and 5G-AN according to NDS/IP is specified in TS 33.210 [3]. Traffic on interfaces carrying control plane signalling can be both integrity and confidentiality protected according to NDS/IP.

Given that these critical interfaces rely on IPsec, its performance and reliability in the dynamic NTN environment are essential for the overall security and functionality of the network.

The IKEv2 handshake protocol [RFC7296], which establishes IPsec SAs, relies on a UDP-based request/response mechanism with retransmissions. This mechanism is not optimized for the high latency and variable packet loss common in satellite links. Premature Retransmissions: IKEv2 implementations typically use default initial timeout values (e.g., 1-2 seconds) tuned for terrestrial networks. In NTN, where round-trip times (RTTs) can range from tens of milliseconds (LEO) to over 500 milliseconds (GEO), these default timers can easily expire before a response is received. This triggers premature retransmissions, leading to duplicate messages on the network and potentially causing congestion or unnecessary processing at the responder. While timers can be manually configured, a static value is insufficient for links with highly variable latency. Exaggerated Handshake Latency: The IKEv2 retransmission strategy often involves an exponential backoff. The loss of a single critical message (e.g., IKE_AUTH) can cause the handshake to stall until the retransmission timer expires multiple times. In a high-latency environment, this can extend the total handshake time from seconds to minutes, severely delaying service establishment or recovery.

An IPsec SA is uniquely identified by a triplet: the Security Parameter Index (SPI), the destination IP address, and the security protocol (AH or ESP). This tight binding to the IP address is problematic in NTN. SA Invalidation on Handover: Satellites, especially in LEO constellations, are in constant high-speed motion. This results in frequent handovers, where a satellite (hosting a gNB) may switch its connection from one ground gateway to another. This handover often involves a change in the satellite's IP address. When the IP address of an IPsec endpoint changes, all existing SAs associated with the old address become invalid, forcing a complete teardown and re-establishment of the IPsec tunnel. Insufficiency of MOBIKE: While MOBIKE [RFC4555] was designed to handle IP address changes for mobile VPN clients, it is not well-suited for NTN scenarios. MOBIKE assumes that typically only one end of the tunnel (the client) changes its address, while the other (the server) remains stable. In NTN, particularly with inter-satellite links (ISLs), both endpoints may change their network attachment points and IP addresses simultaneously or in rapid succession. MOBIKE's address update and verification process is not designed for this "dual-ended" mobility and may be too slow or fail entirely, again requiring a full IKEv2 re-negotiation.

IPsec's anti-replay protection uses a sequence number and a sliding window (e.g., 64 or 128 packets by default) to detect and discard replayed packets. This mechanism assumes a high degree of in-sequence packet arrival. High Probability of Out-of-Order Packets: NTN environments are prone to packet reordering due to several factors: dynamic routing over multiple paths (e.g., different ISLs or ground paths), satellite handovers, and QoS-based scheduling. The degree of reordering can easily exceed the small default anti-replay window. False Positives and Performance Degradation: When legitimate but out-of-order packets arrive outside the window, they are incorrectly dropped as suspected replay attacks. This packet loss is invisible to the IPsec layer and must be handled by higher-level protocols like TCP. This triggers spurious retransmissions, leading to a significant reduction in throughput and a poor user experience, a phenomenon sometimes referred to as a "retransmission storm." While the window size is configurable, making it very large increases memory and processing overhead and may slightly weaken the protection against actual replay attacks over long periods.

IPsec SAs have finite lifetimes, managed by time or data volume limits, to ensure keys are refreshed periodically. In NTN, links can be temporarily but frequently interrupted. Link Interruption vs. SA Lifetime: Links may be interrupted due to satellite movement (e.g., moving out of a gateway's coverage area), line-of-sight obstruction, or atmospheric conditions (e.g., rain fade). If the duration of this interruption exceeds the SA's remaining lifetime or the rekeying window, the SA will be deleted by one or both peers. Forced Full Re-negotiation: When the link is restored, the peers find they no longer have a valid SA and must perform a full IKEv2 exchange from scratch to resume communication. This is a slow and resource-intensive process. Setting an extremely long SA lifetime to "survive" the worst-case interruption is a poor security practice, as it violates the principle of regular key rotation. This creates a direct conflict between operational resilience and security hygiene.

The challenges outlined above demonstrate that a direct application of the standard IPsec suite is suboptimal for many NTN scenarios. The protocol's overhead, complex state management, and sensitivity to network instability lead to performance degradation and increased resource consumption. To address these issues, we propose the development of a lightweight IPsec framework specifically tailored for constrained and dynamic network environments like NTNs. This framework should not aim to replace IPsec but rather to define a profile or a set of extensions that optimize its operation. The key design goals for such a framework should include:

Modular and Profile-based Design:: Create a modular architecture where essential security features are mandatory, while optional or complex functions (e.g., certain authentication methods, advanced traffic selectors) can be excluded. A "NTN Profile" could define a minimal compliant implementation, reducing the negotiation overhead and memory footprint on resource-constrained devices like satellite terminals or IoT sensors.
Simplified Handshake Process:: Investigate methods to reduce the number of round-trips in the IKEv2 handshake. This could involve pre-configured security parameters, optimistic SA establishment, or combining multiple negotiation steps into a single exchange. The goal is to minimize the time-to-first-packet, which is critical in high-latency environments.
Optimized Cryptographic Algorithms:: Prioritize and recommend cryptographic suites that offer a strong security-to-performance ratio on constrained hardware. This includes lightweight ciphers and authentication algorithms that minimize computational overhead and power consumption without compromising security. The selection should be guided by performance benchmarks on typical NTN node hardware.
Enhanced Resilience Mechanisms:: Design more robust and faster mechanisms for re-keying and SA recovery after link interruptions. This could involve proactive SA renewal based on predicted link loss or a streamlined re-establishment process that reuses previous session information to bypass a full handshake, making the connection more resilient to the intermittent nature of NTN links.

By focusing on these areas, a lightweight IPsec framework can provide the robust security guarantees of IPsec while being practically deployable in the challenging operational context of Non-Terrestrial Networks. This will ensure that next-generation integrated networks can be secured end-to-end without compromising performance or feasibility.

This document does not require actions by IANA.

This document describes problems with the use of existing IPsec protocols in NTN environments. It does not propose a new protocol, but the newly added Section 5 outlines requirements for potential future solutions. Any work to address these issues, whether through extensions to IPsec or a new framework, must be carefully analyzed to ensure that it maintains or improves upon the security guarantees of the current IPsec suite. For example, proposals for longer key lifetimes, SA suspension, or modified anti-replay mechanisms must be scrutinized to prevent the introduction of new vulnerabilities.

The authors welcome feedback and contributions from the community to further refine the problem statement and explore potential solutions.