IPsecme M. Chen Internet-Draft L. Su Intended status: Informational China Mobile Expires: 8 January 2026 7 July 2025 IPsec problems when used in NTN network draft-chen-ipsec-problems-for-ntn-network-00 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. Copyright Notice 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. Chen & Su Expires 8 January 2026 [Page 1] Internet-Draft ipsec problems for NTN network July 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. IPsec used in NTN . . . . . . . . . . . . . . . . . . . . . . 3 4. Analysis of possible issues with continuing to use IPsec . . 5 4.1. The issues with the IKEv2 handshake protocol when faced with latency and packet loss . . . . . . . . . . . . . . 5 4.2. The issues with Security Association (SA) and IP Address Binding when the IP address of the satellite is changing 6 4.3. The issues with Zero tolerance for out of order windows . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Conflict between Lifetime and Link Interruption . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative Reference . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 Chen & Su Expires 8 January 2026 [Page 2] Internet-Draft ipsec problems for NTN network July 2025 * 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. Chen & Su Expires 8 January 2026 [Page 3] Internet-Draft ipsec problems for NTN network July 2025 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. Chen & Su Expires 8 January 2026 [Page 4] Internet-Draft ipsec problems for NTN network July 2025 +============+=========+========================================+ | 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 | +------------+---------+----------------------------------------+ Table 1: Summary of the interfaces related to ipsec in NTN network 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: Chen & Su Expires 8 January 2026 [Page 5] Internet-Draft ipsec problems for NTN network July 2025 * 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. Chen & Su Expires 8 January 2026 [Page 6] Internet-Draft ipsec problems for NTN network July 2025 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, March 1997, . Authors' Addresses Meiling Chen China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 China Email: chenmeiling@chinamobile.com Li Su China Mobile 32 Xuanwumen West Street, Xicheng District Beijing 100053 China Email: suli@chinamobile.com Chen & Su Expires 8 January 2026 [Page 7]