5G Transport Security Architecture and IPsec

Internet Protocol (IP) is with us for a few decades now, it is so commonly seen in all transport protocol stacks that it is always assumed to be available by default at network layer. In 5G networks also, whether it is Backhaul Control Plane or User Plane protocol stacks, Internet Protocol can be found with SCTP or with UDP, e.g., NG-AP or Xn-AP protocol stacks, (ref. 38.300). It is known that only Internet Protocol header didn’t have all security functionality. The main purpose of IP header fields was to support routing of IP packets among nodes, so ‘IPsec protocol suite’ was introduced in IETF to provide security features at IP layer. Over years it has evolved with many protocols and corresponding RFCs. In fact, ‘Security Architecture for the Internet Protocol’ (ref, RFC 4301) captures all requirements related to IP security.

IP security is achieved using mainly 2 top level IPsec suite Security protocols - Authentication Header (AH) and Encapsulating Security Payload (ESP). ESP support is mandatory when IPsec is supported and provides all the security features; AH may also be supported when IPsec is supported. These protocols have their own headers, and these headers are usually added just after IP header fields and before IP payload – this mechanism is used when deployment or network configuration is usual transport network. This mode is called ‘AH/ESP Transport mode’ also. There is another mode called ‘AS/ESP Tunnel Mode’ which is used when VPNs are configured. In AH/ESP Tunnel Mode, complete IP packet is appended with additional IP header (with routing information like Src, Dest IP address etc) and AH/ESP header fields. This additional IP header is used to transfer IP packets between 2 IP networks/VPNs. After incoming packet reaches the destination network/VPN, internal IP header is used to route to specific node with destination IP address. This tunneling mechanism is a well-known technique in VPN/IP routing.

ESP/AH protocol headers have interesting fields. There are sequence number fields in these protocols which are used to support anti-replay functionality. Another important field in these headers is Security Parameters Index (SPI) which is used to agree on a common Security Association (SA) or in simple words all the relevant security attributes between source and destination nodes. Integrity Check Value (ICV) field carries values calculated as per protocol specifications.

Apart from AH and ESP security protocols, other important aspects in IPsec protocol suite are ‘supported security algorithms’ and ‘Key agreement or IKE’. ESP supports encryption algorithms, such as, TripleDES-CBC, AES-CBC, AES-CTR. ESP supports authentication algorithms, such as, HMAC-SHA1-96, AES-XCBC-MAC-96. AH supports authentication algorithms, such as, HMAC-SHA1-96, AES-XCBC-MAC-96. (ref, RFC4305). Key agreement is achieved with protocol as specified in IKEv2 (ref RFC4306) – as you may guess each of these algorithms and IKEv2 are subjects of deeper discussions.

Based on interest you may like to start checking from a few of the reference RFCs listed in this article.

Now there is another interesting field of accelerators to help with quick development of products where IPsec support is needed as well as for offloading faster processing of IPsec headers, protocol negotiations in commercial products. Usually, any SoC these days that provides IP transport connectivity used in 5G gNB (including CU, DU) provide such security hardware processing engines or hardware blocks. Such SoCs also provide mechanism to enable, monitor and manage these security features by support in corresponding Linux/other OS kernel, device drivers. Usually for application software there are good documentation and scripts provided to quickly enable, test, and integrate such solution during 5G product design. So, even if Security Architecture is a complex topic, over years these solutions have evolved and matured. Application software can be used to control and monitor most of the security protocol behaviour. So, while creating new designs from scratch it may be good to keep a few key security architecture requirements in considerations from beginning.

Though 5G transport security is very interesting topic, and I will have at least one more micro article soon, let me mention as last thought in current article one important system design aspect when enabling security protocols. If this simple article has conveyed even a basic idea of security protocols, you must have noted additional fields in IP header getting introduced for each of the IP packets – both Transport Mode and Tunnel Mode cases. This creates additional processing steps in the source and the destination nodes where IPsec is enabled. This also impacts transport throughput significantly. So, 5G system designers you must be optimizing this area or at least putting together good analysis around this – not a new concept at all if you know already but for others, an important one to consider.

May be security at application layers of Software seem to be a probable next topic!