UE IP allocation and various server IP can be assinged to UE over ePDG. This IP allocation happens during the IKE process when UE first go through ePDG. Overall IKE(key exchanging) protocol sequence in 33.402 is as shown below. (This is from Figure 8.2.2-1).

Followings are the topics :

• The full IKEv2 sequence, and the two steps that matter
• What the exchange looks like in a log
• Which message carries the APN
• How the APN is written into IKEv2
• Example 1
• What comes back in the response
• When the ePDG refuses the APN
• Reference

The full IKEv2 sequence, and the two steps that matter

Don't bother looking into each of these steps, only two of the steps in this sequence gets involved in the APN Request/Allocation. The simpler version of sequence will be shown after this figure. (If you are really interested in the details of each of these steps, refer to IKE page)

• Step 1 is the only symmetric exchange : IKE SA INIT carries headers, security associations, Diffie-Hellman values and nonces in both directions, and it is drawn as one double headed arrow because neither end has identified itself yet.
• Step 2 is the one this page is about : the IKE AUTH Request lists Headers, User ID, Configuration Payload, Sec, associations, Traffic Selectors and APN info. The APN travels here and nowhere else.
• Step 3 hands it straight on : the ePDG's Authentication and Authorization Req to the 3GPP AAA Server repeats User ID and APN info beside the EAP-Resp/Identity.
• Step 4 is where the answer is decided : the note says the AAA Server retrieves the user profile and authentication vectors if it does not already hold them, and checks the subscription for whether the tunnel is allowed.
• Steps 5 and 6 start EAP-AKA : the AKA-Challenge comes back through the ePDG, and the note at 6.a shows the UE running the AKA algorithm, verifying AUTN, and generating RES and MSK.
• Steps 7 and 8 carry the challenge response : the UE's EAP-Response/AKA-Challenge reaches the ePDG in an IKE AUTH Request and goes on to the AAA Server.
• 8.a is the check that matters : the note says the 3GPP AAA Server verifies whether AT_RES equals XRES, and that is the moment the subscriber is authenticated.
• The green block is optional : steps 8b to 8e are an AKA-Notification round trip, and a run without it goes straight from 8.a to step 9.
• The APN decision was already taken : it happened at step 4 in the figure above, so these messages settle identity and nothing else.
• Step 9 carries the result and the keys : EAP-success, key material and the IMSI go from the AAA Server to the ePDG.
• Step 10 is local to the ePDG : the note says the AUTH payload is computed using the keying material, which is the MSK.
• Steps 11 to 14 are the mutual AUTH check : the UE receives EAP-Success, sends its own AUTH in step 12, and the ePDG checks it and calculates its own in steps 13 and 14.
• Step 15 closes what step 2 opened : the IKE AUTH Response carries Headers, AUTH, Configuration Payload, Sec Associations and Traffic Selectors. That Configuration Payload is the CFG_REPLY described further down this page.

What the exchange looks like in a log

If you have the IP log at the UE and WiFi AP, you may see only following part (the steps happening at core network parts will not be captured at this terminal log). I put the step number in parethesis to match each line on the wireshark to the step number in the figure shown above. This is ISAKMP log that is not decoded. So you would not get the full details from this log except step (1).

Figure 4. A capture taken at the handset sees seven of the fifteen steps. The rest happen behind the ePDG.

• The numbers down the right are the author's : they map each row onto the figures above, and they read 1, 2, 6, 7, 11, 12 and 15.
• One step number covers two rows : frames 525 and 526 are both IKE_SA_INIT and both belong to step 1, because that step is a request and a response.
• Every row says ISAKMP : without the key, Wireshark can name the exchange type and nothing inside it, which is why only step 1 is fully readable here.
• The missing steps are the interesting part : 3, 4, 5, 8, 9 and 10 never appear, and those are exactly the ones between the ePDG and the AAA Server.
• The addresses are masked : the Source and Destination columns read Source IP and Destination IP rather than real values.

If you managed to decode the whole ISAKMP packet including the Encrypted Payload part, you will see the wireshark log as shown below.

Figure 5. With the encrypted payload decoded, three of the seven rows stop being ISAKMP and start being EAP.

• The Protocol column changes : the rows for steps 6, 7 and 11 read EAP instead of ISAKMP, because the decoder can now see inside the encrypted payload.
• The Info column names the method : steps 6 and 7 read Request and Response, UMTS Authentication and Key Agreement EAP (EAP-AKA). That is note 8.a of Figure 2 made visible.
• Step 11 is the success : its Info column reads Success, which is the EAP-Success the ePDG passes on.
• Source and Destination are labelled by role : Initiator and Responder replace the masked addresses, so the direction of every row is visible in the picture.
• The two logs are not the same run : the IKE_AUTH at step 2 is 342 bytes in Figure 4 and 358 bytes here, so these are two attempts at the same procedure rather than one capture shown twice.

Which message carries the APN

The three figures above are the whole authentication run. Only one leg of it carries the APN, and the drawing below cuts everything else away so that leg is easy to find. Keep the step numbers in mind, because the log rows above are labelled with the same ones.

If I point out the message that carries APN Info, it is shown as follows.

Figure 6. The APN's whole journey is two arrows. It is put into step 2, and passed on in step 3.

• The red box marks the field : APN info sits at the end of the step 2 parameter list, after Traffic Selectors.
• Step 2 is UE to ePDG : the same IKE AUTH Request as Figure 1, drawn with everything after step 4 cut away.
• Step 3 is ePDG to AAA Server : APN info appears again beside User ID, and this is the copy the subscription is checked against.
• Step 4 is the decision : the note says the AAA Server retrieves the user profile and vectors if it needs them, and checks whether the tunnel is allowed for this subscriber.
• Nothing sends the APN back : no arrow here returns it. The answer arrives much later, in step 15 of Figure 3.

How the APN is written into IKEv2

IKEv2 has no field called APN. The exchange predates EPC and knows nothing about 3GPP naming, so 3GPP had to borrow a payload that already existed. It borrowed the one that names the peer you think you are talking to, and that choice is why the capture below looks the way it does.

24.302 clause 7.2.2 lists what the UE puts in the first IKE_AUTH request. Two identity payloads go in, and they carry different things.

The specification is specific about the type field. The UE shall set the ID Type field of the IDr payload to ID_FQDN, as defined in RFC 7296. It is also specific about the default case, and this is the part worth remembering: the UE indicates a request for the default APN by omitting the IDr payload altogether. There is no empty APN on this interface. There is a payload, or there is not.

Clause 6.5.2 then says what the ePDG does with it. On receiving that first IKE_AUTH message, the ePDG sends an Authentication and Authorization request to the 3GPP AAA server. The EAP response travels in the EAP payload. The User Identity is taken from the IDi payload, and the APN information is taken from the IDr payload. That sentence is step 2 and step 3 of the figure above, written out in stage 3 language.

One more rule matters when a second PDN is involved. For an additional PDN connection over S2b the UE builds a whole new IPsec tunnel to the same ePDG, indicates the new APN in it, and does not send the INITIAL_CONTACT notification. So each APN gets its own tunnel here, which is not how the same job is done over LTE.

• IKEv2 has no APN field : 3GPP reuses the IDr payload instead.
• IDi is who, IDr is where : the NAI identifies the subscriber, the APN identifies the PDN.
• The type is ID_FQDN : 24.302 states it, and the capture below does something else.
• Omitting IDr asks for the default APN : there is no such thing as an empty APN over IKEv2.
• An extra PDN means an extra tunnel : to the same ePDG, without INITIAL_CONTACT.

Example 1

The capture below is the first IKE_AUTH request, the step 2 message, taken apart by a decoder that had the key. Read it for the two identity payloads rather than for the crypto, because those are the two fields the sections above were about.

CFG Request, the step 2 IKE_AUTH request, decoded. Field values are from a live capture, not from the specification.

CFG Request (in Step 2 ) ------------------------------------------------------------------------

Internet Security Association and Key Management Protocol
    Initiator SPI: 63b6607c34cf9e41
    Responder SPI: aaaaaaaaaaaaaaaa
    Next payload: Encrypted and Authenticated (46)
    Version: 2.0
        0010 .... = MjVer: 0x02
        .... 0000 = MnVer: 0x00
    Exchange type: IKE_AUTH (35)
    Flags: 0x08 (Initiator, No higher version, Request)
        .... 1... = Initiator: Initiator
        ...0 .... = Version: No higher version
        ..0. .... = Response: Request
    Message ID: 0x00000001
    Length: 428
    Type Payload: Encrypted and Authenticated (46)
        Next payload: Identification - Initiator (35)
        0... .... = Critical Bit: Not Critical
        Payload length: 400
        Initialization Vector: 2e25ced9813fef344057cd7c1284b750 (16 bytes)
        Encrypted Data (368 bytes)
        Decrypted Data (368 bytes)
            Contained Data (351 bytes)
                Type Payload: Identification - Initiator (35)
                    Next payload: Identification - Responder (36)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 80
                    ID type: ID_RFC822_ADDR (3)
                    Protocol ID: Unused
                    Port: Unused
                    Identification Data:0001010123456789@5C-A4-8A-1F-59-50
                                       :nai.epc.mnc001.mcc001.3gppnetwork.org
                        ID_FQDN: 0001010123456789@5C-A4-8A-1F-59-50
                               :nai.epc.mnc001.mcc001.3gppnetwork.org
                Type Payload: Identification - Responder (36)
                    Next payload: Configuration (47)
                    0... .... = Critical Bit: Not Critical
                    Payload length: 11
                    ID type: KEY_ID (11)
                    Protocol ID: Unused
                    Port: Unused
                    Identification Data:
                        ID_KEY_ID: 696d73 ==> ims
                Type Payload: Configuration (47)
                ....

Two payloads in that listing carry the identities, and they are the ones the sections above described. The Identification - Initiator payload holds the NAI, and the Identification - Responder payload holds the APN.

The APN is the easiest thing to miss, because it is three bytes of hexadecimal. The IDr payload reads ID_KEY_ID: 696d73, and the decoder helpfully expands it: 0x69, 0x6d and 0x73 are the ASCII letters i, m and s. The requested APN is ims.

That payload also shows the capture disagreeing with the specification. 24.302 clause 7.2.2 says the UE shall set the ID Type field of the IDr payload to ID_FQDN. This UE set it to KEY_ID (11) instead. Both carry the same three letters, and an ePDG will usually accept either, so the tunnel comes up and no error is raised. It is still worth knowing, because a stricter gateway is entitled to reject it, and the capture is left exactly as it was recorded.

The IDi payload is worth one more look. Its type reads ID_RFC822_ADDR (3), which is the type for an email style address, and that suits an NAI. Wireshark then labels the value line ID_FQDN, which is a quirk of the decoder rather than anything in the message. Read the ID type field, not the label on the line below it.

The listing ends in four dots. The author cut it there, at the Configuration payload, and the CFG_REQUEST attributes that would follow are the subject of the next section.

• IDi carries the NAI : an IMSI based identity in the nai.epc realm.
• IDr carries the APN : as raw bytes, so a decoder that does not expand them shows only hex.
• 696d73 is ims : three ASCII letters, and the whole of the APN request.
• The ID type here is KEY_ID, not ID_FQDN : which is not what 24.302 asks for.
• The capture is truncated : it stops at the Configuration payload, and it is left that way.

What comes back in the response

The APN goes out in step 2 and nothing answers it directly. The answer arrives at the far end of the run, in step 15, once the authentication has finished and the ePDG has an authorised subscriber to hand a tunnel to.

24.302 describes that message as an IKE_AUTH response carrying a single CFG_REPLY Configuration Payload with the assigned remote IP address in it, as an IPv4 address or an IPv6 prefix. The UE asked for it in the CFG_REQUEST it sent back in step 2, which is the Configuration payload the figure lists alongside the APN info.

Two more things can ride in the same reply, and both are requested the same way. The UE may put the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attribute in its CFG_REQUEST and get zero or more DNS server addresses back. It may put the P_CSCF_IP4_ADDRESS or P_CSCF_IP6_ADDRESS attribute in and get zero or more P-CSCF addresses back, which is what an IMS APN over WiFi needs before it can register.

Note the wording in both cases. Zero or more means the network is entitled to answer with nothing at all. A UE may treat a missing address as a protocol error, and it will then fail against a network that is behaving correctly. The address side of this is covered on the IP Allocation page.

• The APN is answered in step 15, not step 2 : nothing is assigned until authentication succeeds.
• CFG_REPLY carries the assigned address : an IPv4 address or an IPv6 prefix.
• DNS and P-CSCF are requested, not given : the UE asks in CFG_REQUEST and may get nothing back.

When the ePDG refuses the APN

A refusal here does not look like a refusal over LTE. There is no PDN Connectivity Reject and no ESM cause, because none of that exists in IKEv2. What comes back instead is an IKEv2 Notify payload, and 3GPP defines its own private error types for the job.

24.302 clause 8.1.2.2 sets them out. RFC 7296 reserves the decimal range 8192 to 16383 for private error use, and 3GPP fills part of it. These are the ones that answer a question about the APN rather than about the tunnel.

The 9000 series is worth reading as a block. Each of those values maps onto a Diameter result code that the 3GPP AAA server returned to the ePDG over SWm, which 29.273 defines. So a 9002 in an IKEv2 trace is the ePDG passing on an answer it received from the AAA server, and the decision was taken against the subscription rather than at the gateway. The place to look is the user profile.

The distinction between 8192 and 9002 is the one to keep. Both mean the tunnel is not coming up, and they point at different teams. 9002 says the name is not on the subscription. 8192 says the request was refused for this connection, and the extra sentence about the first connection is what tells you whether the APN is barred outright or merely full.

• An ePDG refusal is a Notify payload : not an ESM cause, and not a reject message.
• 8192 and 8193 are about connections : one about this APN, one about the count of them.
• The 9000 series comes from the AAA server : each value maps to a Diameter result code in 29.273.
• NO_APN_SUBSCRIPTION points at the profile : the gateway is reporting, not deciding.

Reference

Two specifications and one RFC carry the material added to this page. The figures and the capture stay as they were, and these are the documents that say what the payloads in them are for.

• 33.402 - Security aspects of non-3GPP accesses, v19.0.0. Figure 8.2.2-1 is the sequence reproduced in the three figures at the top of this page.
• 24.302 - Access to the 3GPP EPC via non-3GPP access networks; Stage 3, v19.0.0. Clause 7.2.2 is what the UE puts in the IKE_AUTH request. Clause 6.5.2 is the ePDG passing the APN on to the AAA server, and clause 6.5.3 is the one tunnel per APN rule. Clause 8.1.2.2 lists the private error Notify types.
• RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2). It defines the IDi and IDr payloads, the ID_FQDN type, and the private range that 3GPP takes its error values from.
• APN - the same subject over LTE, where the name travels in a NAS message rather than in an IKEv2 payload.