Project

General

Profile

Actions

Feature #5288

closed

architecture plan for osmo-epdg

Added by laforge over 2 years ago. Updated 19 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/03/2021
Due date:
% Done:

0%


Description

We need to come up with a good architectural plan of how we'd want to implement an ePDG.

In the end it is a "fancy" IPsec gateway between the 3GPP CN and the public internet. Somewhere on the level of A SGW in the LTE EPC.

Major elements are:

  • handling of ESP in UDP / NAT-T for the user plane
    • Linux kernel IPsec would be great to use
  • handling of IKE for session setup / key exchange framework
    • this could be strongswan
  • handling of EAP-AKA for 3GPP specific authentication againt HSS
    • this could be some strongswan plugin that then talks DIAMETER towards a HSS in order to obtain authentication tuples
  • DNS based look-up/resolution of PGW for the APN specified by the user
  • encapsulation of user plane traffic in GTP-U towards the PGW
    • in theory, the linux kernel GTP module should be able to do this [in "SGSN" role"]
    • of course there might be dificulty combining that with IPsec
    • in the worst case, we might be able to leverage a standard UPF to do the encap/decap part, but I hope we don't need to go there.
There's also a question of handling some of the "auxiliary" bits that in the PGW case is handled by PCO, such as
  • IP address allocation inside the tunnel
  • signaling of internal DNS servers
  • signaling of P-CSCF address (likely obtained via DIAMETER from HSS or via global config?)

In terms of code reuse, we could theoretically look at leveraging DIAMETER from open5gs, but then it uses freeDiameter, so we can likely also "just" use freeDiameter directly.

At first glance, there doesn't seem to be any IKEv2 implementation with Linux kernel IPsc support in Erlang, Go or Python, which would allow us to do the signaling / control plane in a higher-level possibly more safe programming language than C.

However, In terms of clients to test an ePDG with, there is
Actions #1

Updated by laforge over 2 years ago

Relevant specifications

  • ePDG
    • 3GPP TS 23.402, particularly Section 7
      • note Figures 7.1.1-2, 7.2.4-1 and 7.10 for the main procedures
    • 3GPP TS 24.302
  • 3GPP AAA Server
    • TS 33.402
    • TS 29.273 particularly Sections 7, 8 and 9

scope of implementation

What we need to implement is actually a combination of ePDG + "3GPP AAA Server".

The ePDG has to talk the following interfaces
  • SWu: IKEv2 and ESP on the SWu interface towards the UE
  • SWm: DIAMETER to 3GPP AAA Server
  • S2b: GTPv2C+GTPv1u to PGW
  • GXb: DIAMETER to PCRF

Implementation language / environment

IPsec side

  • IKEv2: No real alternative to StrongSwan/charon unless we want to start from scratch
  • ESP: Linux kernel IPsec should be used

GTP-U

  • Linux kernel GTP-U should be used back-to-back wit kernel IPsec

DIAMETER

Basically two options:
  1. use C, base around freeDiameter (open5gs fork?)
  2. use Erlang and its built-in DIAMETER application (already used in osmo_diameter2gsup)

GTPv2C

Basically two options:
  1. use C, use open5gs GTPv2C codebase
  2. use Erlang and the gtplib as used in ergw

Summary

Unless we want to reimplement everything from scratch in python, or go for a programming language we have limited to zero experience in (Go, Rust) this leaves us with either reusing open5gs code or Erlang code.

Basically we have to choose between writing the code in "open5gs world", or in the "Erlang world".

Starting the development of new control-plane network elements in a low-level language like C doesn't really make sense to me in 2021. The only performance critical part is the user plane, and we will use kernel ESP + kernel GTP for that.

So I think this project is an excellent opportunity to implement one "full" network element in Erlang. We rarely have this chance in other OSmocom CNI projects, as we always benefit from all the existing code/libraries we have for the classic 2G/3G netwokr elements. But here, none of that legacy would be useful. WE don't have Osmocom C language DIAMETER or GTPv2C. Merging open5gs code with libosmocore is also not an option, as it brings its own set of extensive libraries with different structures for timers, FSMs, packet buffers, etc.

Actions #2

Updated by laforge over 2 years ago

  • Status changed from New to In Progress

Started a wiki page regarding the plan at EPDG_implementation_plan

Actions #3

Updated by laforge about 2 years ago

  • Status changed from In Progress to Stalled
Actions #4

Updated by laforge about 1 year ago

Just had a call with lynxis, and related to that call, the following Erlang libraries/applications should be possible to use:

It would be an idea to first have a small stand-alone erlang program that uses those libraries to create kernel GTP tunnels whose creation/modification/removal can be confirmed using libgtpnl/tools/gtp-tunnel to display the current in-kernel state.

FYI: While current mainline gtp.ko doesn't yet support IPv6, @payuso will be working on this very soon. So it makes sense to have all our data structures prepared for that, rather than implement something new v4-only in 2023.

Actions #5

Updated by pespin 5 months ago

  • Description updated (diff)
Actions #6

Updated by laforge 19 days ago

  • Status changed from Stalled to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)