Internet-Draft ipsec problems for NTN network July 2025
Chen & Su Expires 8 January 2026 [Page]
Workgroup:
IPsecme
Internet-Draft:
draft-chen-ipsec-problems-for-ntn-network-00
Published:
Intended Status:
Informational
Expires:
Authors:
M. Chen
China Mobile
L. Su
China Mobile

IPsec problems when used in NTN network

Abstract

This document describes the problems in the use of IPsec in satellite Internet and NTN network scenarios.

Status of This Memo

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.

Table of Contents

1. Introduction

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.

2. Terminology

2.1. Terms

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: Data network.

2.2. Requirements Language

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].

3. IPsec used in NTN

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 |
     +-----------+     +---------+     +--------------+
Figure 1: UE access the ground mobile core network through satellite

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.

Table 1: Summary of the interfaces related to ipsec in NTN network
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.

4. Analysis of possible issues with continuing to use IPsec

4.1. The issues with the IKEv2 handshake protocol when faced with latency and packet loss

IKEv2 relies on UDP transmission and defined retransmission in RFC 7296. Under long inter satellite link latency, the following issues may be encountered:

  • The default initial timeout an easily trigger premature retransmission, leading to a storm of repeated requests. Setting a longer timeout default value during implementation based on transmission latency can solve this problem.
  • The loss of a single control message (such as IKE_AUTH) may reach the maximum number of retransmissions, leading to an exponential increase in handshake latency.

Different retransmission rules need to be set according to different environments, especially in the case of satellite networks, then avoid network congestion.

4.2. The issues with Security Association (SA) and IP Address Binding when the IP address of the satellite is changing

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.

4.3. The issues with Zero tolerance for out of order windows

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.

4.4. Conflict between Lifetime and Link Interruption

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.

5. IANA Considerations

This document does not require actions by IANA.

6. Security Considerations

This document mainly presents issues and does not involve new security considerations at the moment

7. Acknowledgements

Welcome everyone to contribute together

8. Normative Reference

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.

Authors' Addresses

Meiling Chen
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
100053
China
Li Su
China Mobile
32 Xuanwumen West Street, Xicheng District
Beijing
100053
China