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

strongswan (UE) -> strongswan (epdg) -> osmo-epdg (epdg & AAA) -> HSS works for Authentication.

The strongswan (epdg) component is now doing both Send Auth Info and Location Update Request which the epdg responds. The authentication data is collected from the HSS via SWx.

I think this ticket can be renamed to make sure it relates to osmo-epdg, or simply close it since it's a bit ambiguous.

Regarding passing allocated UE IP Address over CEAI (GSUP) ePDG -> strongswan in EPDGTunnel Response, imho what would make sense is to send the existing grouped IE OSMO_GSUP_PDP_CONTEXT_INFO_IE (struct osmo_gsup_pdp_info).

• APN-Configuration Diameter AVP (S6b, 3GPP TS 29.272 7.3.35) (" The Served-Party-IP-Address AVP may be present 0, 1 or 2 times. The AVP shall contain the IPv4 address, IPv6 address and/or the IPv6 prefix of the user, if static IP address allocation is used. ")
• APN-Configuration is also available in SWx interface ePDG->HSS in 3GPP TS 29.273, through Non-3GPP-User-Data AVP
• also APN-Configuration in MAP (" servedPartyIP-IPv4-Address [2] PDP-Address OPTIONAL ")

However, the GSUP OSMO_GSUP_PDP_CONTEXT_INFO_IE IE is actually missing fields to provide configured IP addresses for the subscriber (like the Served-Party-IP-Address AVP in Diameter/MAP).

So IMHO we need to add a new "struct osmo_gsup_eua eua²" in "struct osmo_gsup_pdp_info", since it should also be available in regular GSUP messages where the HLR may want to tell the subscriber static address.
Then, we can reuse this OSMO_GSUP_PDP_CONTEXT_INFO_IE in "GSUP EPDGTunnel Response" message.

This would mean breaking ABI of "struct osmo_gsup_pdp_info" and as a consequence "struct osmo_gsup_message" too, but I don't see any other good way of what seems to be a shortcoming from the past?
On the GSUP protocol in the air it's fine, since for the old messages the new "EUA" IEs can be considered optional maybe.

I agree in breaking the ABI of libosmo-gsup.
Let's add IPv4/IPv6 to OSMO_GSUP_PDP_CONTEXT_INFO_IE

FYI: https://gerrit.osmocom.org/c/libosmocore/+/35237

Please go for the struct osmo_gsup_eua as it seems better than the simple IPv4/IPv6 approach I did in 35237.

lynxis ack, I agree that the proposal with 2 separate IEs you presented there is not good, I just wrote the same before seeing your comment here.

• 0..2 TLV OSMO_GSUP_PDP_ADDRESS_IE, each containing 1 address whose type depends based on size. (this would mean GSUP is a proto which can contain multiple same IE per message)
• 0..1 TLV OSMO_GSUP_EUA_IE, each containing 0..2 addresses, like in GTPv1C (TS29.060 7.7.27 End User Address), where you end up with 1 buffer containing either (ipv4|ipv6|ipv4+ipv6).

lynxis assuming I'm taking over and redoing your patch based on your last statements. Let me know if you end up working on it before me.

The AVP shall contain the IPv4 address, IPv6 address and/or the IPv6 prefix of the user

This reads you have 3 types. IPv4 address, IPv6 address and a IPv6 prefix (including netmask)?

lynxis wrote in #note-11:

The AVP shall contain the IPv4 address, IPv6 address and/or the IPv6 prefix of the user

This reads you have 3 types. IPv4 address, IPv6 address and a IPv6 prefix (including netmask)?

Not really. If you check the sentence following that one in the spec it says:

For the IPv6 prefix, the lower 64 bits of the address shall be set to zero.

So still 128 bits being encoded.

https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/36276 gsup: Document ePDG Tunnel Req/Res/Err