Signaling, or exchanging some information between equipment over network with predefined rules, has always been a fight against the unexpected inputs. Without appropriate validation deployed, it might cause not only the crashes of equipment itself but also something more dumb, such as information leak, interception, or fraud.

In this post, by taking P-GW (PDN Gateway) as an example, I’ll give a brief explanation about how to expect the unexpected, and how we can prepare for that.

Scenario

Suppose you are to develop P-GW by your own, and you’ve done implementing normal call flows, you’d probably be able to imagine the cases that a subscriber’s status is not consistent with S-GW due to network failures, packet losses, etc.

Here’s a simple question for example: How should P-GW behave when it receives GTPv2 Create Session Request toward an existing subscriber?

First of all, the ideal behaviors of EPC nodes are defined in 3GPP TS23.401. We can find the description about the situation that P-GW receiving Create Session Request in “5.3.2.1 E-UTRAN Initial Attach”. It says MME should send Delete Session Request to S-GW first to clear the existing one—that’s considered as a part of mobility management.

TS23.401 Figure 5.3.2.1-1: Attach procedure

image from 3GPP TS23.401

Nope, this is NOT what we’re looking for. It’s fine as long as all the nodes are working right, which we always dream of, but realistically we do need to expect the situation that some of the nodes might be losing sanity. This is the way to expect the unexpected, that is to say “expect every type of signals to come, whatever the state a node is in”. It’s not always 100% sure that P-GW is in a state to wait for Create Session Request to come. Maybe Delete Session Request was lost somewhere in network and MME didn’t noticed about that, etc.

Solutions

What happens if a P-GW which is implemented just as told by 3GPP spec receives Create Session Request? It depends on how considerate implementors are. I witnessed some bad cases in my experience;

  • a P-GW created new session while keeping the previously-created one inside.
  • a P-GW deleted the previously-created session locally and created a new one.
  • or, maybe some other P-GWs I don’t know might even ignore the request!

In the first case the number of sessions continues to grow, which might cause a Denial of Service or unstability. It can at least be said it’s a waste of machine resource. The second one might result in having the inconsistent state between related nodes(typically S-GW and PCRF). And the third one, if the request is ignored, the subscribers might have trouble in their connectivity.

To avoid all of undesirable consequences above, my idea is to request the session deletion to the related nodes and accept the new session when there is existing one for the same subscriber.

  1. On receiving Create Session Request from S-GW, look up the existing session by IMSI and EBI.
  2. If there’s existing one,
    2-1. send Diameter Credit-Control-Request with the IMSI to terminate the Gx session to PCRF.
    2-2. send Delete Bearer Request with the EBI and associated TEID.
    2-3. delete the session and tunnel locally
  3. Accept Create Session Request. Just do what P-GW always do when it receives the request(ask AAA and PCRF, create session internally, and respond to S-GW).

It should be noted that step.3 should be done whether the step.2 succeeded or not for the service continuity. From the beginning we are expecting the inconsistency—it is not always guaranteed that S-GW also keeps the previously-created session, but if it does, deleting it explicitly may help S-GW not to have duplicate sessions.

Security Considerations

Note that the example above is relevant only in the internal network. Unfortunately MNO should consider much more from security perspectives in the cases that roaming or MVNO connection is deployed because there might be someone malicious in other operators who tries something nasty.

Imagine a vulnerable P-GW that always accepts the incoming Create Session Request on S8 interface. The attacker might be able to intercept subscribers’ session even if the targeted subscribers are in their own country just by sending Create Session Request continuously.

I won’t dig this into details as it is not what I want to emphasize in this post and I don’t want to be arrested by the ignorant police abusing their power, but if you’re interested more in security in mobile network I think it’d be nice to join Fraud and Security Group in GSMA to stay up to date with security issues in mobile network(I’m not actually sure as I’m not a member, though).

The idea is relevant not only for the case I took as an example. As mentioned. a node should be prepared for every type of signals to come. In general, the following simple rules can be applied.

  • Validate the sender of signals.
  • Validate the type of signals.
    • If it is never used, just discard it.
    • If it is used, limit the condition to accept it.

Hope this can be a good advice for implementors of EPC nodes.

Happy signaling :)