Internet-Draft | ipsec problems for NTN network | July 2025 |
Chen & Su | Expires 8 January 2026 | [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 8 January 2026.¶
Copyright (c) 2025 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 provides end-to-end security for IP networks by authenticating and encrypting IP packets to ensure the confidentiality, integrity, and authenticity of data during transmission. Under satellite Internet and NTN network, IPSEC is still a very important and commonly used security protocol. Due to the dynamic characteristics of satellites, there are also some problems in the use of IPsec.¶
This document describes the problems in the use of IPsec in satellite Internet and NTN network scenarios.¶
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].¶
For NTN network, the wireless access network defined in 3GPP is used with satellite network, UE can access data network via 3GPP wireless network and satellite network. NTN network supports gNB and UPF on satellites, UE connects to the base stations on satellites, and then connect to the core network through ground gateway stations.¶
The data transmission path between the wireless access network and the core network is called the backhaul link, used to transmit user data, signaling, and control information from the wireless access layer to the core network for processing, forwarding, and storage. When the position of the base station changes, it will affect the security of the return link. This document takes 5G as an example to analyse the use of ipsec problems existed in NTN network.¶
+-------+ +---------+ +--------------+ UE---|Sat/gNB|-----| Gateway |-----| Core Network | +-------+ +---------+ +--------------+ +----------+ +---------+ +--------------+ UE---|Sat/gNB+UPF|-----| Gateway |-----| Core Network | +-----------+ +---------+ +--------------+
Multiple security interfaces are involved in this network architecture, and the 3GPP standard(TS33.501) specifies the use of IPsec to solve end-to-end secure transmission issues. The interfaces related to the ipsec protocol are summurised in Table 1.¶
Interfaces | Usage | Description in 3GPP |
---|---|---|
N2 | gNB-AMF | 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 | 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-AMF | NDS/IP |
N6 | UPF-DN | NDS/IP |
N9 | UPF-UPF | NDS/IP |
backhaul | gNB-CN | IPsec |
From the table, we can see that the security of these interfaces relies entirely on IPsec providing end-to-end transmission security. In NTN networks, there are some issues to use IPsec due to the dynamics of datellites.¶
IKEv2 relies on UDP transmission and defined retransmission in RFC 7296. Under long inter satellite link latency, the following issues may be encountered:¶
Different retransmission rules need to be set according to different environments, especially in the case of satellite networks, then avoid network congestion.¶
The security alliance is uniquely identified by a triplet. This triplet includes: Security Parameter Index (SPI), destination IP address, and Security Protocol Number (AH or ESP). Due to the high-speed movement of the satellite, the overhead time is approximately 5-10 minutes, and at least one end's IP address is dynamically changing.¶
SA lacks a IP independent identification mechanism. When the IP changes, the existing SA becomes invalid and the tunnel must be rebuilt. Although MOBIKE supports IP updates, but it cannot solve the problem of simultaneous changes in IP and entity.¶
The default anti replay window of IPSec is only 64 packets, relying on strict packet sequences. Due to multi-path routing, QoS scheduling, satellite switching, the probability of out of order arrival in satellite links is extremely high.¶
The sliding window model will result in he legitimate packet was mistakenly rejected as a replay attack due to out of order, triggering a TCP retransmission storm.¶
SA needs to update the key regularly (based on time/traffic), but the inter satellite link is frequently interrupted (obstructed, switched). If the interruption exceeds the survival time of SA, SA will be cleared and a full reconstruction is required for recovery.¶
It is necessary to set the lifetime of SA based on the worst-case scenario of the satellite network to ensure that SA will not be deleted due to interruption.¶
This document does not require actions by IANA.¶
This document mainly presents issues and does not involve new security considerations at the moment¶
Welcome everyone to contribute together¶