| Internet-Draft | ipsec problems for NTN network | October 2026 |
| Chen & Su | Expires 1 May 2027 | [Page] |
This document describes the problems in the use of IPsec in satellite Internet and NTN network scenarios.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119].¶
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.¶
+-------+ +---------+ +--------------+
UE---|Sat/gNB|-----| Gateway |-----| Core Network |
+-------+ +---------+ +--------------+
+----------+ +---------+ +--------------+
UE---|Sat/gNB+UPF|-----| Gateway |-----| Core Network |
+-----------+ +---------+ +--------------+
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.¶
| 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:¶
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.¶