Cellular Network Infrastructure » osmo-ePDG - VoWifi Evolved Packet Data Gateway

<pespin> ok so afaict you are basically missing "Config Attribute (t=3,l=0): INTERNAL_IP4_DNS" for now
<pespin> It may make sense to simply add a "PCO" IE being compatible with GTP
<pespin> we do have QoS and PDP-Address doing that anyway
<pespin> so that would be in line
<pespin> and easily extensible
<pespin> in osmo-epdg I may even pass it transparently, and let strongswan speak directly with open5gs-smfd

This needs to go into EPDG Tunnel Req/Res, since then it's when we'll get the PCO from SMF during GTPv2C CreateSessionReq.

https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/36023 gsup: Introduce a new PCO IE

According to 3GPP TS 29.274 (GTPv2C), we need to use Additional Protocol Configuration Options (APCO) (see Create Session Req/Resp) with the following internal IEs:

 "If the UE requests the DNS IPv4/IPv6 address in the
Configuration Payload (CFG_REQ) during the IPsec tunnel
establishment procedure (as specified in 3GPP
TS 33.402 [50]), and if the ePDG supports the Additional
Protocol Configuration Options IE, the ePDG may include
this IE over S2b interface and correspondingly set the
"DNS Server IPv4/v6 Address Request" parameter as
defined in 3GPP TS 24.008 [5]." 
"If the UE includes the P-CSCF_IP6_ADDRESS attribute,
or the P-CSCF_IP4_ADDRESS attribute or both in the
CFG_REQUEST configuration payload during the IPsec
tunnel establishment procedure as specified in 3GPP
TS 24.302 [63]), and if the ePDG supports these IKEv2
attributes and the Additional Protocol Configuration
Options IE, the ePDG shall include this IE over the S2b
interface and correspondingly set the P-CSCF IPv6
Address Request, or P-CSCF IPv4 Address Request, or
both parameters as defined in 3GPP TS 24.008" 

APCO IE is defined in 3GPP TS 29.274 (GTPv2C) clause 8.94:

The Additional Protocol Configuration Options (APCO) information element is used to exchange additional protocol
configuration options between the TWAN/ePDG and the PGW.
The Additional Protocol Configuration Options information element is specified in 3GPP TS 29.275 [26] and its GTPv2
coding is shown in figure 8.94-1.

From 3GPP TS 29.275, see clause 10.1.2 explaining epdg<->pgw regarding those options.

Also, APCO is basically encoded the same as PCO, simply the IE in GTPv2C is different:

12.1.1.19 Additional Protocol Configuration Options
The Additional Protocol Configuration Options IE contains additional 3GPP protocol configuration options
information. The IE is in the same format as the PCO IE specified in 3GPP TS 24.008 [16] subclause 10.5.6.3, starting
with octet 3.

The APCO fields are also defined in 3GPP TS 24.008 clause 10.5.6.3 "Additional parameters list":

0001H (P-CSCF IPv6 Address Request);
0003H (DNS Server IPv6 Address Request);
000CH (P-CSCF IPv4 Address Request);
000DH (DNS Server IPv4 Address Request);

So, in summary, we do:
- strongswan transcodes the CFG_REQ from IKEv2 into GSUP PCO IE (we keep a generic PCO IE in GSUP since it's encoded the same as APCO and we don't really need to have 2 of them)
- osmo-epdg takes the encoded GSUP PCO IE and copies/forwards it as value of APCO in GTP2C S2b Create Session Request
- open5gs-smfd provides APCO answer in CreateSession Response, osmo-epdg forwards it back using GSUP PCO IE to strongswan, and strongwas transcodes it to CFG_REQ again.

I'd say open5gs-smfd is not yet really using/replying the APCO by looking at code. I only see a unit test filling it in:

   req->additional_protocol_configuration_options.presence = 1;
   req->additional_protocol_configuration_options.data =
       (uint8_t *)"\x80\x00\x0d\x00";
   req->additional_protocol_configuration_options.len = 4;

Hence we may need to implement APCO handling in open5gs-smfd. Fortunately it should be super long, since the parsing is mostly the same as the existing PCO IE.
Maybe something which needs to be found out is how the P-CSCF is filled in by open5gs-smfd. I guess it's provided by AAA/HSS?

The P-CSCF address apparently is configured in open5gs-smfd smf.yml:

#  p-cscf:
#    - 127.0.0.1
#    - ::1

GSUP wireshark improvements (added missing messages, added PCO IE full decoding) in git@gitea-ssh.osmocom.org:osmocom/wireshark.git branch "pespin/gsup".
I'll submit to upstream once we have it a bit more in place.

I can already forward the PCO from strongswan to SMF in the ttcn3 docker setup:
https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36053 Forward PCO from GSUP ePDG Tunnel Req to SMF CreateSessionRequest

Next steps:
- Answer APCO IE in the emulated SMF in ttcn3
- implement forwarding back SMF->strongswan in osmo-epdg.

I have full end-to-end PCO enc/dec of DNS and PCSCF fields forwarding strongswan<->smf working in osmo-epdg, tested with osmo-epdg:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36059 epdg: Make sure PCO is forwarded from strongswan to PGW and back
https://gerrit.osmocom.org/c/erlang/osmo-epdg/+/36053 Forward PCO from GSUP ePDG Tunnel Req to SMF CreateSessionRequest

I need to give a try to the code in epdg.osmocom.org, and the outcome is most probably that APCO handling needs to be implemented in open5gs-smfd. Fortuantely it's the same encoding as PCO, so it should be "easy" at least for basic support we need so far.

I think lynxis already implemented sending hardcoded PCO requesting DNS4 and PCSCF4 during GSUP EPDG Tunnel Req.

The strongswan side is ready in branch lynxis/pco.

pespin currently the erlang code requires a PCO. We should make it optional otherwise client without PCOs can't connect.

I submitted a couple PRs to open5gs-smfd:
- Fix Gy session not triggered when UE registers through S2b interface (rat_type WLAN): https://github.com/open5gs/open5gs/pull/3009
- Implement APCO handling in GTPv2C CreateSessionReq/resp: https://github.com/open5gs/open5gs/pull/3010

Tested with:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36075 pgw: Introduce test TC_s2b_createSession_v4_no_apco
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36085 pgw: Introduce test TC_s2b_createSession_v4_apco

I think on my side (osmo-epdg, open5gs-smfd) all commits have been submitted, I'm waiting for review and finally get them merged and in place.

Once the open5gs ones are merged, we can switch epc.epdg.osmocom.org back to using osmocom-nightly apt repository.

lynxis are you missing some part in strongswan? or is everything completed there regarding this topic?

No, the strongswan part is ready.